DeepSeek 公开 Super-agent 设计：不用再切会话，AI 自己找活干，原型代码已开源
DeepSeek Harness 团队公开 Super-agent 架构设计，同时开源可跑的研究原型。它不是新模型，而是一套关于「Agent 怎么长期在线、并行干活」的系统答案。
3分钟看懂：这次到底发了什么
DeepSeek 把「会话管理」从用户眼前拿走：Router 管分派、Worker 并行执行、事件驱动让 Agent 自己找活、存算分离让任务不随设备关机而中断。架构思路值得抄，但原型是研究代码，不是产品。
10 月 31 日晚，DeepSeek Harness 团队在官方公众号发了一篇技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》。同一时间，GitHub 上多了一个仓库 deepseek-ai/dsh-superagent-prototype，MIT 协议，README 第一行就写着"仅供研究参考，不是 DeepSeek 官方产品"。
所以先把预期校准：这不是新模型，不是新 App，也不是要卖的产品。它是一套系统设计思路，加一份能跑起来的原型代码。
它要解决的问题很具体：现在你用 AI 干活，本质上是在"管窗口"。一个窗口问需求，一个窗口改代码，一个窗口查资料，来回切，切多了就忘。按 DeepSeek 团队的说法，一个人通常只能同时跟进 3 到 5 个活跃会话——瓶颈已经从"AI 会不会干"变成"人盯不盯得过来"。
Super-agent 想干的事，是把会话这件事从用户眼前拿走：你面对的还是同一个助手，背后是一层常驻的 Router 在分派任务，多个 Worker 在各自独立的上下文里并行干活。团队给的四个关键词是：连续、高效、主动、持久。
需要说明：本文基于多家媒体转述整理（DeepSeek 官方技术文章发布在公众号，正文事实依据 IT之家、智东西、第一财经等报道，叠加 GitHub 仓库一手信息）。文中所有性能数字都来自 DeepSeek 团队自测，实验基于合成负载与简化环境。
为什么值得关注：Agent 的瓶颈已经不在模型
过去一年，Coding Agent 已经能自己读代码、定位 Bug、跑测试。模型这一侧的进步是肉眼可见的。
但真用过的人都会碰到同一堵墙：任务一多，人就成了调度器。你要记住哪个会话在干什么、进行到哪一步、上次说改哪个方案，还要在几个窗口之间搬运上下文。DeepSeek 团队把这个现象讲得很直白——多任务的上限取决于人的注意力，而不是模型能力。
他们列的三个具体毛病，都是日常会遇到的：
- 单会话串行：一个会话里发起一个耗时工具调用，就得等它回来，期间没法接新指令。
- 多任务上下文混乱：不同会话彼此独立，同一个项目的方案 A 和方案 B 散在两个窗口里。
- 设备离线即停：Agent 跑在你本地，电脑一合盖，任务就断在那儿。
这三个问题都不是"模型再强一点"能解决的，是系统层的问题。这也是这篇文章真正的价值：它把工程约束摊开讲，而不是发个 benchmark 图。
架构怎么搭：五块拼图
按官方描述，整套架构由五部分组成。翻译成人话：
1）双层结构：Router 分派，Worker 干活
Router 是常驻的全局层，负责接人类的消息、维护全局上下文、决定这件事该给谁做。它刻意不干具体活，官方说甚至可以不给它配 Bash 工具——因为一个中心节点一旦开始干重活，就会变成瓶颈。
Worker 才是执行者。每个 Worker 有自己独立的上下文和工具集，可以并发跑，任务之间互不干扰。关键细节：Worker 不直接回复用户，它把状态和结果报给 Router，由 Router 统一对外说话。所以你感觉上始终只有一个助手。
这个设计跟常见的 "Agent Team" 不太一样。Agent Team 一般是把一个复杂任务拆成子步骤、几个角色协作；Super-agent 拆的是任务与任务之间的关系，单个任务内部怎么拆，Router 不管。
2）事件驱动：让 Agent 自己找活
传统助手是你问它答。Super-agent 换了个模型：群聊消息、邮件、日程提醒、GitHub 评论、CI 结果，这些都叫 Trigger，是可能触发行动的事件。
绝大多数群聊消息不需要 AI 介入，所以做了两级过滤：先由程序规则快速筛掉无关消息，再交给大模型结合上下文判断要不要动手。
已经分派出去的事件流，Worker 可以"订阅"对应的 Thread，后续评论和状态变化直接送到 Worker，不用每次都过一遍 Router。官方说这一层直通省掉了不少路由开销。
3）异步 ReAct Loop：不再同步阻塞
标准 ReAct 循环里，模型发起一个耗时工具调用就得等着。DeepSeek 改成异步：工具调用变成 start() 和 stop()，Agent 启动后台任务后立刻返回"已开始"，结果晚点作为新事件回到会话里。前台继续接你的新消息，你还能中途改方向或者叫停。
这里有个必须说清的边界：这个机制已经在 DeepSeek Harness 里实现，但没有默认开启。
4）存算分离：电脑关机，任务不停
他们把 Agent 的执行循环放在云端，会话状态存数据库，而代码仓库、文件、工具链这些工作环境仍然留在你自己的机器上，本地只跑一个轻量 daemon 接命令、回结果。
这个设计官方叫 BYOM（Bring Your Own Machine）。好处很直接：你的代码不用上传，但任务不会因为你合上笔记本就消失，设备重新上线后可以接着跑。
5）Watchdog：给 Agent 配一个监督员
独立的一个 Session，不参与干活，专门盯：接口报错、状态恢复失败这类基础设施问题；也通过模型判断 Worker 是不是真的在推进、方向有没有跑偏。发现异常就介入修复。
一张表看懂五块拼图
| 模块 | 它解决什么问题 | 关键细节 |
|---|---|---|
| 双层架构 Router + Worker | 连续交互 vs 高并发，二者不必二选一 | Router 只分派不干活，甚至不配 Bash；Worker 隔离并发，不直接对用户说话 |
| 事件驱动 Trigger / Thread | 从「你问它答」变成「它自己找活」 | 程序规则先粗筛，大模型再判断；已分派的事件由 Worker 直接订阅，绕过 Router |
| 异步 ReAct | 耗时工具调用把会话堵死 | 调用变成 start()/stop()，后台跑、前台继续接指令。已实现但未默认开启 |
| 存算分离 BYOM | 电脑关机，任务就没了 | 循环在云端、状态进数据库、代码留在本地，本地只跑轻量 daemon |
| Watchdog | Agent 跑飞了没人管 | 独立 Session 监督：既看基础设施报错，也用模型判断进度是否跑偏 |
三个最值得看的细节
没人 @ 它，它也会修 Bug。 这是全文最有画面感的一段。DeepSeek 内部给用户群配了一个"静默复现并修复"策略：有人在群里反馈 Bug 或者讨论改法时，Super-agent 在后台悄悄复现问题、分析原因、找修复方案；只有确认问题真实存在、并且找到相对简单的修法，才把结果交出来，否则全程不说话。
技术上这叫投机执行——借用了计算机体系结构里的思路：在结果是否会被采用还不确定的时候，先用后台算力试一把，有价值就交，没价值就丢。
代价也很明显：这是拿算力换响应速度。后台在猜你要什么，猜错的部分就是纯浪费。
同一件事能在群聊和 PR 之间连续推进。 你在群里说"用方案 A"，后来在 GitHub 的 PR 评论里改成"还是方案 B 吧"，Agent 能理解这是同一个任务的前后变化，并调整执行方向。靠的是 Trigger、Thread、Worker Session 之间的引用链，官方叫"链式召回"——模型可以沿着关联 ID 一步步把历史信息找回来，不用把所有东西都塞在上下文窗口里。
配套的还有 "Inline & Spill"：近期可能用到的信息直接放进上下文窗口，超出预算或低频的内容留在窗口外，需要时再读。
Router 靠"堵车"提效率。 这一段有点反直觉。事件稀疏时，Trigger 一条条进 Router，延迟低；事件密集时，Router 会排队，但上一轮推理期间积压的多条 Trigger 会自动合并，在下一次模型调用里一起注入。因为 Router 的活儿是"长输入、短输出"，合并处理在 Prefill 阶段并行算，单次请求耗时的增长远慢于批处理大小的增长。
结果是：积压越多，单个决定分摊的推理时间反而越低。官方压测里，Trigger 到达速率从每分钟约 1 条提到约 40 条，平均批处理从 1.0 升到 2.8，单次请求耗时从 2.5 秒涨到 3.9 秒，而单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。
实验数字怎么读
官方初步实验（合成负载，5 次重复）
| 指标 | Super-agent | 单 Session + Subagent |
|---|---|---|
| 任务完成时间 p50 | 12.4 分钟 | — |
| 任务完成时间 p95 | 15.7 分钟 | 29.5 分钟（中性提示词） |
| 实验负载 | 每次约 300 条消息，其中约 20 条为真实工作请求 | |
| 代价 | 更多 token：去掉订阅直通后，Router 决定数 +30%，读缓存 token 2323 万 → 3177 万 | |
⚠️ 厂商自测口径：实验基于合成负载与简化环境，衡量的是调度与协作能力，不是单任务执行质量；尚无第三方复现。
数字背后的取舍
团队做了一组初步实验：模拟群聊和 GitHub CI 的消息流，每次约 300 条消息，其中约 20 条是真正的工作请求，每种方案重复跑 5 次。
结果：
- Super-agent 任务完成时间 p50 为 12.4 分钟，p95 为 15.7 分钟。
- 单 Session 加 Subagent、用中性提示词的方案，p95 为 29.5 分钟。
- 去掉订阅直通机制后，Router 的决定数增加约 30%，读缓存 token 从 2323 万涨到 3177 万。
怎么读这组数：它衡量的是调度与协作能力，不是单个任务干得好不好。官方自己也写了，实验基于合成负载和简化环境，主要看系统层能不能扛住并发。而且它是拿更多 token 换时间和稳定性——这一点在文章里没有被藏起来，值得记一笔。
换句话说：这套架构不是让模型变聪明，是让"多个任务同时推进"这件事变得可管理。省的是人的注意力，花的是算力。
怎么用：原型能干什么，装之前要知道什么
开源仓库 dsh-superagent-prototype 是 DeepSeek Harness 的一个插件包，定位很窄：
- 只面向一个 GitHub 仓库。它监听 GitHub，可选接飞书；有人（在允许名单里）提出请求时，它开一个工作项，在独立的 agent 会话和目录里干活，最后回到原来的对话里回答，比如直接提一个 PR。
- 带一个 Web 面板，只显示"需要人处理"的东西。健康的运行状态不占地方。
- 安装方式是让 Agent 带你装：README 建议直接跟你的编程 Agent 说"读 SETUP.md，帮我装 dsh-superagent"，它会一次问一个短问题，给一次完整计划，然后装完。
- 文档编号成册（000 哲学 → 001 领域模型 → … → 008 扩展新来源），按顺序读，不跳。
- MIT 协议，可以改、可以商用，但 README 原话是"研究代码，不是生产就绪软件"，可能有 bug、代码风格可能不一致，用之前自己要审。
成本和时间预估（先说清怎么算账）：原型本身免费（MIT），要花钱的是模型调用。它跑在 DeepSeek Harness 上，一次任务通常是几十到上百轮工具调用。按 DeepSeek 官网挂的现价（deepseek-flash，对应 V4.1-Flash-1017）：输入缓存未命中低峰 $0.15、高峰 $0.30 每百万 token，输出低峰 $0.60、高峰 $1.20。粗算一次中等复杂度的修复任务（累计几十万输入 + 几万输出）大概在 0.05~0.3 美元区间，合人民币几毛到两块；但如果你让它常驻盯群聊，后台"投机执行"会持续产生调用，这部分是纯支出，也是最容易把账算错的地方。时间上：安装按文档走一次大概 1~2 小时，接上自己仓库再调提示词通常要花一个下午。
装之前值得先想清楚一件事：这个原型的默认哲学是"尽量少占用人的注意力"。它的规则写得很克制——只在被要求、或者团队写下的规则允许时才行动；只在有人必须行动、或者结果真有用时才说话；一次只问一个具体问题。如果你想要一个"什么都主动汇报"的助手，它跟你预期是反的。
限制与避坑：官方自己列了五个坑
文章末尾，团队把没解决的问题也写出来了，这部分比成绩更值得看：
- Router 怎么随规模扩展。目前单个常驻 Router Session 在团队规模下够用，再大就不好说。Router 是全局序点，理论上是最容易堵的地方。
- 长程记忆。跨月、跨更长周期的记忆怎么组织，还没有答案。
- 脱离 Session 之后的人机协作方式。会话被藏到系统内部了，那人怎么"介入"、怎么"验收"，交互范式要重新设计。
- Agent 之间的 A2A 通信。多个实例之间怎么对话、怎么分工。
- 安全与隐私。云端 Agent 接本地设备，意味着提示词注入、端侧凭据泄露、跨设备权限这些问题都会被放大。这是 BYOM 架构绕不开的账。
还有一个工程上的现实约束：这套东西强依赖 DeepSeek Harness 的插件体系。你不用 Harness，架构思想可以参考，代码基本搬不走。
适合谁，不适合谁
值得看的人：正在做 Agent 产品、被"多任务调度"和"上下文管理"卡住的工程师；想理解 Agent 系统设计而不只是调 API 的开发者；在评估"要不要自建一套常驻 Agent 基础设施"的团队负责人。
可以先跳过的人：只想找个好用的 AI 助手写文案、改表格的普通用户——这次没有面向你的产品更新；以及需要开箱即用、稳定 SLA 的商业场景，研究原型不适合直接上生产。
给你的第一步建议：别急着装。先花十分钟读仓库里的 docs/000-philosophy.md，看它"少打扰人"的那套规则你认不认；认了，再让 Agent 带你走 SETUP.md。如果不认，这套架构的工程价值仍然成立，但落地形态你得自己改。
一句话总结
DeepSeek 这次没发模型，发的是"Agent 该怎么长期活着"的一套答案：把会话藏进系统、把分派交给 Router、把执行摊给 Worker、把监督交给 Watchdog，再用开源原型证明这条路能跑。它的短板同样清楚——实验是合成负载、代价是更多 token、原型不是产品、安全边界还没解。但对正在做 Agent 的人来说，这份"设计探索"比又一张跑分图有用得多。
📚 参考来源
- 一手代码：GitHub · deepseek-ai/dsh-superagent-prototype（创建于 2026-10-31，MIT） github.com/deepseek-ai/dsh-superagent-prototype
- 技术文章出处：第一财经《DeepSeek发布全新Agent架构》（2026-10-31 22:35，注明文章发表于 DeepSeek Harness 官方公众号） yicai.com/news/103419784.html
- 媒体转述（含架构图与实验数据）：IT之家（2026-10-31 21:36） ithome.com/1/020/615.htm
- 媒体转述（含 Router 压测）：智东西《DeepSeek又开源了！公布Super agent架构》（2026-11-01） zhidx.com/p/606311.html
- 同稿转载：凤凰科技、新浪财经、21 经济网、网易/APPSO、潮新闻
本文基于多家媒体转述整理，数据为 DeepSeek 团队自测口径 | 加装AI助手整理发布