一个人只能盯 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-prototypeMIT 许可团队明确说它是用来验证技术路线的插件不是正式产品。一、双层架构谁能跟用户说话分工只有一句话Router 接人、Worker 干活。Router 层负责承接人类交互、维护全局上下文、分派任务Worker 层在相互隔离的会话里并发执行具体工作Worker 不直接回复用户把状态和结果报给 Router由 Router 统一对外沟通。这条Worker 不许对外说话的规则是整个架构的地基。它带来的直接后果是不管你并行开了多少个 Worker用户看到的始终是一个对话对象、一份全局上下文。上一节说的多任务上下文混乱根源在于每个会话各自维护一份世界状态把对外接口收敛到一层混乱就不可能出现在用户侧。同一条任务可以在不同渠道之间连续推进——比如从 IM 群聊讨论一路做到 GitHub PR 评审——靠的也是这一层统一持有上下文而不是让每个渠道各留一个孤岛会话。对比一下常见的单 Session 加 Subagent 方案Subagent 更像是主会话临时雇来的帮手它的产出要回流到主会话里由主会话整理而 Router 是一个常驻的调度者它不需要记住每个任务的全部细节只需要知道谁在做什么、做到哪了。这个区别决定了它能handle 的并行规模。二、事件驱动Trigger、Thread 与两级过滤系统不靠人喊才动靠事件。群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果这些外部信息统称 Trigger。一条 Trigger 进来之后先过两道滤网程序规则先筛掉大部分明显无关的这个群跟我无关、这条 CI 是绿的交给大模型判断是否需要采取行动。为什么不让模型直接把关因为 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。这就是他们说的 BYOMBring 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 加一层调度抽掉具体实现这套设计里有四条可以立刻用上的对外只有一个声音。不管内部并行多少执行单元用户层面的上下文和回复收敛到一处。这是可控性的前提。两级过滤别一上来就叫模型。程序规则扛量语义判断扛精度成本结构才对得上。任务分配后让事件直达执行者。Router 只负责路由不做中转瓶颈。监管者独立失败域。盯有没有实质进展这件事必须在被监管的上下文之外做。至于投机执行和异步 ReAct Loop我的建议是先别急着上。投机执行需要一套什么算足够好、可以交付的判据异步 ReAct 会引入中间状态。这两块的复杂度都不在代码量上在状态管理和判据设计上。原文自己也说了异步机制实现了但没默认开——这个谨慎程度值得参考。推荐标签多智能体架构 事件驱动 Agent调度 上下文管理 DeepSeek
一个人只能盯 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-prototypeMIT 许可团队明确说它是用来验证技术路线的插件不是正式产品。一、双层架构谁能跟用户说话分工只有一句话Router 接人、Worker 干活。Router 层负责承接人类交互、维护全局上下文、分派任务Worker 层在相互隔离的会话里并发执行具体工作Worker 不直接回复用户把状态和结果报给 Router由 Router 统一对外沟通。这条Worker 不许对外说话的规则是整个架构的地基。它带来的直接后果是不管你并行开了多少个 Worker用户看到的始终是一个对话对象、一份全局上下文。上一节说的多任务上下文混乱根源在于每个会话各自维护一份世界状态把对外接口收敛到一层混乱就不可能出现在用户侧。同一条任务可以在不同渠道之间连续推进——比如从 IM 群聊讨论一路做到 GitHub PR 评审——靠的也是这一层统一持有上下文而不是让每个渠道各留一个孤岛会话。对比一下常见的单 Session 加 Subagent 方案Subagent 更像是主会话临时雇来的帮手它的产出要回流到主会话里由主会话整理而 Router 是一个常驻的调度者它不需要记住每个任务的全部细节只需要知道谁在做什么、做到哪了。这个区别决定了它能handle 的并行规模。二、事件驱动Trigger、Thread 与两级过滤系统不靠人喊才动靠事件。群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果这些外部信息统称 Trigger。一条 Trigger 进来之后先过两道滤网程序规则先筛掉大部分明显无关的这个群跟我无关、这条 CI 是绿的交给大模型判断是否需要采取行动。为什么不让模型直接把关因为 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。这就是他们说的 BYOMBring 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 加一层调度抽掉具体实现这套设计里有四条可以立刻用上的对外只有一个声音。不管内部并行多少执行单元用户层面的上下文和回复收敛到一处。这是可控性的前提。两级过滤别一上来就叫模型。程序规则扛量语义判断扛精度成本结构才对得上。任务分配后让事件直达执行者。Router 只负责路由不做中转瓶颈。监管者独立失败域。盯有没有实质进展这件事必须在被监管的上下文之外做。至于投机执行和异步 ReAct Loop我的建议是先别急着上。投机执行需要一套什么算足够好、可以交付的判据异步 ReAct 会引入中间状态。这两块的复杂度都不在代码量上在状态管理和判据设计上。原文自己也说了异步机制实现了但没默认开——这个谨慎程度值得参考。推荐标签多智能体架构 事件驱动 Agent调度 上下文管理 DeepSeek
)
)
)
)
