Super-agent：DeepSeek 把「管人」这件活，交给了 AI

2026 年 10 月 31 日晚，DeepSeek Harness 团队发布了一篇技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》， 同步开源了原型。团队特别强调：这是面向工程实践的架构探讨，不是产品功能发布会。 这个说明本身挺重要——它讲的不是能力，是结构。

一、被转移的瓶颈

过去两年，行业习惯把 Agent 的进展等同于模型能力的进展：更长的上下文、更稳的工具调用、更强的推理。 但真把 Agent 放进日常工作流之后，很多人会发现另一条曲线先撞墙： 一个人能同时盯着几个任务？

DeepSeek 给出的经验数字是三到五个活跃会话。超过这个量，人就开始丢上下文： 忘了哪个任务进行到哪一步、忘了回复某条消息、忘了自己上次让 AI 改什么。 任务并没有失败，是人的管理带宽先耗尽了。

多任务的上限，正在从「模型能力」转向「人的注意力」。

这句话是整个架构的起点。既然瓶颈在人这边，那就把原本由人承担的协调工作—— 会话切换、上下文同步、任务分派、进度追踪——上移到系统层面。 人退到更上层：定目标、做判断、验收结果。

这和管理学里"管理者不该亲自干活"是同一个道理，只不过这里的下属是一群 Agent。

二、Router 与 Worker：两个层级的权责

整体结构是两层的，很接近传统分布式系统里的协调节点与工作节点：

层	职责	生命周期
Router	持续在线的全局协调节点。统一接收群聊、GitHub、邮件等多渠道消息，判断该不该处理、该交给谁，并维护任务的共享上下文。	常驻
Worker	各自持有独立上下文，并行执行具体工作：复现问题、审查代码、开发功能。必要时可以再调用更下一层的 Subagent。	随任务生灭

这个划分最关键的一点不是"分了两层"，而是上下文的所有权被切开了。 Worker 不需要知道其他 Worker 在干什么，也不背着别人的历史包袱； Router 只保留调度所需的元信息，不下沉到执行细节。

文章里提到一个细节：Worker 接手任务后，可以直接订阅后续的相关消息， 不必所有沟通都绕回 Router 转发。这是一个很工程化的取舍——用少量的一致性代价，换掉大量的协调开销。

一个任务可以跨平台连续推进

典型案例是：同一个问题先在 IM 群里被提出来，讨论到一半需要落到代码，于是转到 Pull Request 评审， 改完再回到群里回执。对人来说这是三个场景，对系统来说这只是同一个任务的三个阶段。 会话边界被打破了，任务边界还在。

三、主动性从哪来：事件驱动与两级过滤

如果 Agent 只能被 @ 才动，那它本质上还是一个问答框。Super-agent 强调的"主动性"， 建立在把外部信号都当成事件源上：群聊消息、邮件、日程提醒、代码评论、CI 结果，都可以触发行动。

但这里有个绕不过去的成本问题：绝大多数群聊消息跟 AI 无关。 如果每条都过一遍大模型，成本高、延迟大，还会制造大量噪声。 所以他们做了一个两级过滤：

1. 第一级：程序规则。用确定性规则先筛掉明显无关的消息（机器人自己的消息、无关频道、格式不符）。
2. 第二级：模型判断。剩下的小比例消息再交给模型判断是否值得行动。

这是把成本控在"便宜的地方做粗筛、贵的地方做精判"。自己系统里落地时，这一层往往比模型选型更影响可用性—— 没人愿意用一个每天都在群里插话、但十次有八次说废话的助手。

四、投机执行与「静默复现」

这是全文最值得借鉴的设计，借用了计算机体系结构里的投机执行（speculative execution）思想： 在还不确定结果会不会被采用时，先在后台提前做，有价值就提交，没价值就丢弃。

DeepSeek 在内部配置的策略叫"静默复现并修复"。具体流程是： 有人在群里反馈一个问题，即使没有人叫 AI 帮忙，它也会在后台尝试复现、分析原因； 只有确认问题真实存在、并且找到相对简单的修复方式，才会出来说话；否则保持安静。

先做，但不先说。做了没价值就当作没做过。

这条规则解决的是 AI 助手最让人反感的一个毛病：抢答。 一个只会"收到，我来看看"然后没有下文的助手，比一个沉默的助手更消耗信任。 而"静默复现"把承诺换成了结果——不出声就意味着没找到有价值的东西。

同样的机制可以平移到个人场景：收到会议邀请后，提前核对日程冲突、整理相关材料、起草一份回复草稿， 等人回来只需要点确认。

五、存算分离与 Watchdog

要长期运行，就不能假设"进程一直活着"。Super-agent 在这块的处理相对务实：

• 存算分离：执行循环放在云端，会话状态存数据库，本地只留一个轻量 daemon。人合上笔记本电脑，任务照样往下跑。
• Watchdog：独立进程负责检查任务是否陷入无效循环——比如反复修改同一个文件、连续多轮没有产出。发现异常就介入或终止。
• 异步 ReAct Loop：执行耗时任务时仍然能响应新指令，不必把人锁在一个等待状态里。

Watchdog 这个角色在大多数 Agent 框架里是缺失的。它承认了一个事实： Agent 会失败，而且会以"看起来在工作、实际上原地打转"的方式失败。 死循环不会自己停下来，必须有人在旁边看着。

六、哪些能搬进自己的系统，哪些不能

我自己跑了一套人机混合的协作机制（见另一篇）， 对照这套架构，有几个判断：

可以直接借鉴的

• 双层权责。哪怕只有一个协调 Agent 和几个执行 Agent，只要把"调度"和"执行"的上下文分开，稳定性就会明显提升。
• 两级过滤。规则先行、模型后判，是控制成本和噪声最有效的手段。
• 静默处理。没结果就不说话，这条规则对信任的维护作用被严重低估。
• Watchdog。哪怕只是一个定时检查，也能挡住大量"卡死但没报错"的情况。

需要谨慎的

• 完全无人监督的主动性。在研发场景里，改错了可以回滚；在业务流程里，一次误操作可能是真实损失。主动性必须配权限边界。
• 多渠道统一接入。接入越多，权限模型越复杂。自己用的话建议先收在一两个入口，把规则跑顺再扩。
• 常驻 Router 的成本。持续在线的协调节点意味着持续的成本和持续的运维责任，小团队未必划算。

最后一点观察：这篇文章讲的其实不是"AI 有多强"，而是"一个团队该长成什么样，才能容得下 AI"。 Router 与 Worker 的分工、事件驱动的触发条件、静默执行的边界—— 这些设计在人类团队里都能找到原型。真正新的部分，是这些规则第一次需要被写成代码， 因为 AI 不会靠"悟"来理解组织惯例。