不 @ 它也会去修 Bug：DeepSeek 公开 Super-agent 架构，一个 Router 指挥一群 Worker

10 月 31 日晚上，DeepSeek Harness 团队发布了一篇技术长文，标题很朴素——《Super-agent 设计探索：迈向更自主的 Agent 系统》。文章没有发布会，没有演示视频，却把一个正在发生的变化讲得很清楚：真正限制 AI 干活的，已经不是模型能力，而是人的注意力。

一分钟速览

• DeepSeek 提出 Super-agent 架构，核心是 Router + Worker 双层结构，Router 对接人，Worker 并发干活。
• 四项基础特征：连续、高效、主动、持久，目标是让 Agent 从单次会话变成长期在线的协作者。
• 事件驱动：群聊、邮件、日程、PR 评论、CI 结果都是 Trigger，先由程序规则过滤，再交给模型判断。
• 引入投机执行：在没人要求的情况下后台复现问题、写修复，确认有价值才提交，没价值就保持沉默。
• 实验中任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟，传统单会话方案 p95 为 29.5 分钟。
• 代价是更高的缓存读取：去掉事件直通机制后，Router 决策增加约 30%，缓存读取量增加约 37%。
• 团队明确表示，这仍是面向工程实践的架构探索，不是正式产品。

为什么是“会话”出了问题

现在大多数 Agent 仍以 Session 为基本单位。用户要并行推进几件事，就得在几个窗口之间来回切换，自己记住每个任务的上下文，自己盯着进度。DeepSeek 团队给了一个很具体的观察：一个人通常只能同时跟进 3 到 5 个活跃会话。再往上加，人就成了瓶颈。

通过 CLI、MCP 或外部连接器把 Agent 接到更多平台上，并不能解决根本问题。单会话同步阻塞、多任务上下文混乱、本地设备一关机任务就停，这三件事仍然存在。DeepSeek 的判断是：会话本来就该是系统内部的技术细节，而不是用户要管理的工作单元。

Router 负责想，Worker 负责干

双层架构的分工很直接。Router 是长期运行的全局协调节点，统一接收来自群聊、GitHub、邮件等渠道的信息，维护跨任务上下文，决定一件事该交给谁。Worker 在相互隔离的会话里并发执行，各自拥有独立上下文和工具能力，需要时还能再调用子代理。Worker 不直接对用户说话，它把状态和结果汇报给 Router，由 Router 统一对外沟通。

为了让协调开销降下来，系统加了订阅机制：某个 Worker 接手一个 PR 之后，后续评论和状态变化直接发给它，不必每次都经过 Router 重新分派。文章还提到 Inline & Spill 与链式召回：近期可能用到的信息放进上下文窗口，超预算的内容留在窗口外按需读取；历史任务则沿着 Trigger、Thread、Worker Session 之间的引用关系，一步步找回来。

没人 @ 它，它也会动手

比多任务并行更值得看的是“主动”。群聊消息、邮件、日程提醒、代码评审评论、CI 运行结果，都可以成为触发条件。考虑到绝大多数群聊消息与工作无关，系统做了两级过滤：先由程序规则快速排除，再让模型结合上下文判断是否值得行动。

再往前一步，是借用计算机体系结构里的投机执行思路。在结果尚不确定时，先用后台算力试着做：DeepSeek 内部群里配置了“静默复现并修复”策略，有人反馈问题或讨论改法时，Agent 会提前复现、定位、找修复方案，只有确认问题存在且改法足够简单，才把结果交给开发人员；否则全程不发声。文章给的场景很有画面感：团队还在群里讨论方案，修复的 PR 已经躺在那里等评审了。

云端跑循环，本地留环境

传统 ReAct 循环里，模型发起一次耗时工具调用后只能等结果，期间无法响应新指令。DeepSeek 把工具调用改成异步的 start() 和 stop()，Agent 启动后台任务后立刻返回 Started 状态，结果之后作为新事件回到会话。前台可以继续接新消息，用户也能中途改方向或叫停。这套机制已经在 Harness 中实现，但没有默认开启。

另一个设计是把计算、会话状态和执行环境解耦：Agent 循环放云端，状态存数据库，代码仓库、文件、工具链留在用户设备上，本地只跑一个轻量 daemon。电脑临时离线，任务可以在设备重新上线后继续。系统外围还挂了一个独立的 Watchdog 会话，既看接口报错和状态恢复失败，也用模型判断 Worker 是否真的在推进、方向有没有跑偏。

数据好看，但别急着下结论

实验设置是这样的：模拟群聊与 GitHub CI 的消息流，单次约 300 条消息，其中约 20 条是真正的工作请求，每种方案重复五次。Super-agent 的任务完成时间中位数 12.4 分钟，p95 为 15.7 分钟；采用中性提示词的传统单会话方案，p95 达到 29.5 分钟。更值得注意的是，后者五次实验里模型一次都没有主动调用子代理，所有任务都挤在主会话里，被不断到来的新消息打断。

Router 的压力测试也有数字：事件到达速率从每分钟约 1 条升到 40 条时，平均批处理大小从 1.0 升到 2.8，单次请求耗时从 2.5 秒升到 3.9 秒，但分摊到每个决定的推理时间反而从 6.4 秒降到 1.6 秒。也就是说，突发流量下靠合并积压事件，吞吐是能撑住的。

代价同样明确：维护多个独立会话要读更多缓存。取消事件直通机制后，Router 需要做的决定增加约 30%，总缓存读取量从 2323 万涨到 3177 万 Token，增幅约 37%。另外，实验用的是合成消息和模拟耗时工具，验证的是调度与协作，不是真实编码质量。

离“数字同事”还差哪几步

文章自己列了待解问题：任务积累到数周甚至数月后，如何准确恢复长期记忆；Router 如何随任务规模横向扩展；脱离会话之后，人该怎么查看进度、何时介入；多个 Agent 实例之间如何协同。安全上的风险更直接——Super-agent 持续接收外部消息，又通过云端访问本地设备，一旦遇到提示词注入或服务端被攻破，代码仓库、敏感数据和本地凭据都在风险面上。

趋势洞察

这篇文章真正的价值，不在于又出现了一个新名词，而在于它把 Agent 的竞争焦点从“单任务做得多好”挪到了“多任务怎么编排”。当模型能力逐渐够用，瓶颈就从推理转向调度、记忆、权限和可观测性。谁先把这些工程问题解决，谁就能让一个人同时带十个 AI 干活，而不是被十个窗口追着跑。