一个人只能盯 4 个会话：Super-agent 的 Router-Worker 拆法

原文：DeepSeek Harness - 《Super-agent 设计探索：迈向更自主的 Agent 系统》（https://www.ithome.com/1/020/615.htm）

现在主流的 Agent 设计都以单个 Session 为基本单位，不同 Session 之间相互独立。你手上同时推三件事，就得开三个会话、手动切换、各自维护上下文。

DeepSeek Harness 团队 10 月 31 日发了一篇设计探索文章，从这个问题切入。他们给出的观察是：一个人通常只能同时跟进三到五个活跃 Session；就算用 CLI、MCP 或外部连接器把本地 Agent 扩出去，还是会撞上三个老问题——单会话同步阻塞、多任务上下文混乱、本地设备一离线任务就停。

这套新形态他们叫 Super-agent，归纳成四个特征：连续、高效、主动、持久。整体由五部分组成：双层架构、事件驱动、面向人的交互、计算与状态及环境分离、Watchdog。

工程上最值得先看懂的是第一块——Router 与 Worker 的分层。同时开源的还有个原型 dsh-superagent-prototype，MIT 许可，团队明确说它是用来验证技术路线的插件，不是正式产品。

一、双层架构：谁能跟用户说话

分工只有一句话：Router 接人、Worker 干活。

• Router 层负责承接人类交互、维护全局上下文、分派任务；
• Worker 层在相互隔离的会话里并发执行具体工作；
• Worker 不直接回复用户，把状态和结果报给 Router，由 Router 统一对外沟通。

这条"Worker 不许对外说话"的规则是整个架构的地基。它带来的直接后果是：不管你并行开了多少个 Worker，用户看到的始终是一个对话对象、一份全局上下文。上一节说的"多任务上下文混乱"，根源在于每个会话各自维护一份世界状态；把对外接口收敛到一层，混乱就不可能出现在用户侧。

同一条任务可以在不同渠道之间连续推进——比如从 IM 群聊讨论一路做到 GitHub PR 评审——靠的也是这一层统一持有上下文，而不是让每个渠道各留一个孤岛会话。

对比一下常见的单 Session 加 Subagent 方案：Subagent 更像是主会话临时雇来的帮手，它的产出要回流到主会话里由主会话整理；而 Router 是一个常驻的调度者，它不需要记住每个任务的全部细节，只需要知道谁在做什么、做到哪了。这个区别决定了它能handle 的并行规模。

二、事件驱动：Trigger、Thread 与两级过滤

系统不靠人喊才动，靠事件。群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果，这些外部信息统称 Trigger。

一条 Trigger 进来之后先过两道滤网：

1. 程序规则先筛掉大部分明显无关的（这个群跟我无关、这条 CI 是绿的）；
2. 交给大模型判断是否需要采取行动。

为什么不让模型直接把关？因为 Trigger 的量和模型的成本不在一个量级上。程序层几乎免费，能扛住全部流量；语义层才贵，只处理漏过来的那一小部分。原文给这页配的图注就叫"两级过滤：先由程序层策略筛除大部分无关消息，再交由语义层策略判断"。

第二级过滤里还有个调度优化：任务一旦分配出去，Worker 就可以订阅对应的 Thread，后续相关事件由程序直接投递给 Worker，不必每次都绕经 Router。Thread 的定义很朴素——同一个 IM 话题或同一个 GitHub Pull Request 下的连续 Trigger 构成一条 Thread。

这一步的意义在于，Router 的负载不会随事件量线性上涨。任务分配完之后，事件流是绕过 Router 直达 Worker 的。

Long-running Agent 的一个老问题是上下文膨胀。团队给了两个互补的机制：

• Inline & Spill：近期可能用到的信息直接放进上下文窗口，超出预算或低频的内容留在窗口外，模型需要时按需读；
• 链式召回（Chain of Recall）：靠 Trigger、Thread、Worker Session 这些对象之间的引用关系，让模型沿着关联 ID 一步步把历史任务信息找回来。

前者管"现在该看什么"，后者管"以前的东西去哪找"。合起来就是不把所有历史都塞进窗口，也不假装历史不存在。

三、投机执行：把等待时间抢回来

人在等 Agent 的时候，时间都花在"我提了需求，它想，它回来，我再说"的往返上。

Super-agent 的做法是投机执行：根据环境信号在后台提前开工。文章给了两个例子——收到会议邀约，先查日程冲突、搜背景资料、备一份回复草稿；在研发协作场景里，群聊讨论到某个问题时，先去尝试复现故障、找修复方案，确认问题成立并且修复足够简单之后，才把结果交给用户。

这里有个措辞值得注意：“确认问题并找到简单修复方式后才交付”。不是提前做完就交付，而是提前做完、筛掉不成形的，再交付。投机执行的失败成本被限制在后台，没有变成用户的噪音。

再往前一步是异步 ReAct Loop：把耗时的工具调用拆成异步的 start() 和 stop()。Agent 启动后台任务后立刻返回 Started 状态，不用等任务完成，后台结果随后作为新事件进入会话，前台对话可以继续接收用户的新消息。

这一条有明确的落地状态说明——这套异步任务机制已经在 DeepSeek Harness 里实现了，但尚未默认开启。如果自己在做类似改造，得注意这里的副作用：会话里开始出现"启动了但没结束"的中间状态，状态机比同步版本复杂一层，中断和恢复的路径都要重新想。

四、计算、状态、环境三者分离

长期在线运行绕不开一个问题：Agent 到底跑在哪。

团队的答案是解耦：

• 计算与持久化状态放云端；
• 执行环境可以留在用户本地设备，只部署一个负责执行命令、返回结果的轻量 daemon。

这就是他们说的 BYOM（Bring Your Own Machine）——把日常用的开发机或个人电脑接进云端 Agent。同时也支持接云端托管机器，或按需创建的计算环境。

这么拆的好处很直接：计算和状态在云端，本地设备离线不会让任务上下文丢失；执行环境在本地，Agent 能用到你机器上的真实环境和凭据。对比一下"全部云端"的方案，你可能得先配置一套镜像和凭据；对比"全部本地"的方案，笔记本合盖任务就断了。

五、Watchdog：不管业务的外部回路

主架构之外还有一个独立的 Watchdog Session，构成外部控制回路。

它盯两类事：一是接口报错、状态恢复失败这类基础设施问题；二是通过模型判断 Worker 到底有没有取得实质进展、执行方向有没有偏离目标，发现异常就介入修复。

把它放在主架构之外这一点很关键。如果监控逻辑跑在监视对象同一个上下文里，一旦那个上下文本身出了问题，监控也一起停摆。独立 Session 是让监管者与被监管者不共享失败域。

另外，"是否取得实质进展"这个判断项值得单独拎出来——长时间在线运行的 Agent 不只是会崩，更常见的是在原地打转：反复读同一个文件、反复调同一个失败的工具、在错误的假设上越走越远。这类失败不报错，只看日志也看不出问题，必须由另一个视角来判断。

六、实验数据：p50 12.4 分钟，p95 15.7 分钟

作者做了初步实验，四种方案对照：

• Super-agent；
• 去掉事件直通机制的 Super-agent；
• 单 Session 加 Subagent，中性提示；
• 单 Session 加 Subagent，另配一种提示。

每次约 300 条消息，其中约 20 条是工作请求，每种方案重复 5 次。

结果：Super-agent 的任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟；中性提示下的单 Session 方案 p95 是 29.5 分钟。

看这组数据要抓住两件事。

一是 p95 比 p50 更说明问题。中位数只差几分钟的方案，到了尾部差距拉开——中性提示的单 Session 方案 p95 接近 Super-agent 的两倍。做单任务演示时这种差距根本看不出来，只有多任务并发、排队和上下文切换叠加起来才暴露。

二是这条结论的边界在原文里写得很清楚：实验基于合成负载和简化环境，主要评估系统调度与协作能力，并不衡量单个任务的实际执行能力。也就是说，这些数字证明的是"调度层不再拖后腿"，不能拿来说"模型变强了"。按 300 条消息、20 条工作请求的规模折算，这确实更像一次调度压力测试。

Router 层单独做了压力测试：Trigger 到达速率从每分钟约 1 条提到约 40 条时，平均批处理大小从 1.0 涨到 2.8，单次请求耗时从 2.5 秒涨到 3.9 秒，而单个决定分摊的推理时间从 6.4 秒降到 1.6 秒。

这组数字讲的是合并批处理的价值。事件变密之后，单次请求确实变慢了一点（2.5 秒到 3.9 秒），但因为一次处理的量从 1.0 涨到 2.8，摊到每个决定上的时间反而降到四分之一。代价是延迟——攒批必然多等一会儿，换来的是吞吐。

七、原型怎么跑，以及它的边界

dsh-superagent-prototype 是 MIT 许可的编码智能体原型，以插件包形式在用户本机运行，面向单个 GitHub 仓库，可监听 GitHub 和可选的 Feishu 请求，生成并行工作的 Ticket。

运行依赖不算轻：Node.js 22.19+ 或 24+、git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+。如果只是想看看它长什么样，先确认这几样都在。

主动工作的范围受授权控制，分三档：off、observe（默认）、auto。默认 observe 意味着它先只看不动手，这个默认值选得挺稳——主动型 Agent 一旦默认动手，一次误判的代价就是真实提交。

团队也说清了定位：该插件用于验证技术路线，并非 DeepSeek 正式产品。不想装任何东西的话，读一遍设计文档也能拿走大部分东西。

八、还没解决的问题

原文自己列了待解的清单，这几条对想跟进这个方向的人比成功案例更有参考价值：

• Router 层怎么随任务规模扩展。现在靠批处理扛住了每分钟 40 条的 Trigger，但再往上呢？
• 跨月乃至更长时间跨度的长程记忆。Inline & Spill 和链式召回解决的是"这次任务内"的找回，时间跨度拉到几个月就不够了。
• 脱离 Session 之后的人机协作方式。异步、多任务、投机执行之后，人该在什么粒度上介入？
• 不同 Agent 实例之间的 A2A 通信。
• 安全与隐私。尤其是云端 Agent 接入本地设备之后，提示词注入、端侧凭据泄露、跨设备权限这三类风险都需要专门解决。

最后一条值得多看一眼。BYOM 让 Agent 能用你本地机器上的真实环境，能力边界和风险边界是同时扩大的：本地有哪些凭据、哪些目录可写、能不能推代码，这些授权粒度如果没设计清楚，“持久在线"就是"持久持有你的机器权限”。

九、如果你要给自己的 Agent 加一层调度

抽掉具体实现，这套设计里有四条可以立刻用上的：

1. 对外只有一个声音。不管内部并行多少执行单元，用户层面的上下文和回复收敛到一处。这是可控性的前提。
2. 两级过滤，别一上来就叫模型。程序规则扛量，语义判断扛精度，成本结构才对得上。
3. 任务分配后让事件直达执行者。Router 只负责路由，不做中转瓶颈。
4. 监管者独立失败域。盯"有没有实质进展"这件事，必须在被监管的上下文之外做。

至于投机执行和异步 ReAct Loop，我的建议是先别急着上。投机执行需要一套"什么算足够好、可以交付"的判据，异步 ReAct 会引入中间状态。这两块的复杂度都不在代码量上，在状态管理和判据设计上。原文自己也说了，异步机制实现了但没默认开——这个谨慎程度值得参考。

推荐标签 多智能体架构 事件驱动 Agent调度 上下文管理 DeepSeek