DeepSeek Super-agent 技术拆解：Router、Worker 与持续运行的 Agent 系统
一个开发者同时让 Agent 修 Bug、审 PR、跟进 CI，往往很快就要面对一排会话窗口：哪个会话知道最新需求？CI 失败该发给谁？刚才在飞书里说的“先别合并”，另一个会话能否看到？单个 Agent 越能独立完成任务，这些协调问题反而越突出。
DeepSeek Harness 团队提出的 Super-agent，尝试把“持续与人沟通”和“并行执行任务”拆成两个层次。它讨论的不是一种新的基础模型，也不是把工具调用次数调得更高，而是围绕会话、事件、授权、状态和执行环境重新组织 Agent 系统。团队同时公开了 dsh-superagent 研究原型。先划清边界：设计文章讨论的是目标架构；公开仓库是可供参考的原型，两者并不完全一致，也不能把文中的每项设想当作现有产品功能。
一、为什么一个更强的 Agent，还需要新的系统架构？
传统编码 Agent 通常围绕一个 Session 工作：用户输入任务，模型推理、调用工具、读取结果，再继续下一步。这个循环适合解决一件相对完整的事。但真实团队里的工作是事件流：新需求会在群聊出现，代码审查意见在 GitHub 出现，CI 结果稍后才到，开发者还可能随时改变优先级。
如果把所有事件塞进同一会话，任务会争用一个推理循环，细节互相污染；如果每件事都开一个独立会话，系统又失去跨任务的全局视角，用户必须自己记住各会话的背景和关系。DeepSeek Harness 团队的判断是：单任务的上限主要看模型，多个任务同时推进时，瓶颈常常转移到人的注意力。 这是设计动机，不是“模型已经能无人监管地完成一切”的结论。
Super-agent 因而追求四种能力：跨渠道交互时保持连续感；多个复杂任务并行推进；根据经过筛选的环境事件主动工作；在设备离线、进程重启或任务异常时维持长期运行。这四点都不能只靠一个更长的提示词或一个更大的 ReAct 循环获得，需要系统层面的调度与状态管理。
二、Router 与 Worker：把“接活”和“干活”分开
设计文章里的第一层是 Router：它长期存在，接收来自飞书、GitHub 等入口的事件，维护跨任务的高层关系，决定是否创建任务、交给谁，以及何时向人反馈。Router 尽量不亲自执行长时间的编码工作。这样它才能持续回应新消息，不被一次测试或构建阻塞。
第二层是 Worker：每个 Worker 围绕一个具体任务运行，有独立的会话上下文和执行目录，可以读代码、修改文件、运行命令、提交 PR。多个 Worker 可以并行，任务中冗长的推理和工具输出留在各自内部；对外由 Router 统一沟通。
图：Router 统一接收与分派两项开发工作，后续 CI 事件经订阅回到对应 Worker。
图中“任务 A”把 Issue 和后续 CI 事件画在一起，是为了展示同一项工作的连续推进；在原型的数据模型中，它们可以属于不同的 Thread，再通过 Ticket 对相关 Thread 的订阅关联，并非必须是同一条 GitHub 讨论串。
以“修复接口超时”和“审查另一条 PR”同时发生为例：Router 收到两条请求，判断它们属于不同工作流，分别建立任务并交给 Worker A 和 Worker B。A 正在跑测试时，开发者在原 Issue 中补充复现条件，系统把这条后续消息送到 A；与此同时，B 可以继续处理审查。用户看到的仍是同一个 Agent 在各自原来的讨论串里回应，而不需要寻找两个内部会话。
这里的区别并非“主 Agent 调用了两个 subagent”这么简单。普通 Agent Team 常常围绕一个复杂任务拆步骤，Team Lead 要深入协调成员；Super-agent 的 Router 主要负责跨任务的入口、分派与全局关系。一个 Worker 内部仍然可以再调用子 Agent，两个层级解决的问题不同。
三、从一条消息到一个任务：真正重要的是事件模型
公开原型的领域模型文档比“Router + Worker”两个方框更值得读。它把一次工作拆成一串可追踪的对象：
| 对象 | 在系统里负责什么 |
|---|---|
| Source | 接入 GitHub 或飞书等事件来源，保存读取进度 |
| Trigger | 一条不可变的外部事件，例如评论、CI 更新或消息 |
| Thread | 把同一讨论中的事件组织成有顺序的流 |
| Eval / Decision | 判断事件是新工作、已有工作的后续、停止请求，还是无需处理 |
| Mandate | 记录为什么允许做这件事，以及授权范围 |
| Ticket | 一项被授权的工作，拥有自己的生命周期 |
| Assignment / Executor | 把 Ticket 交给具体执行会话 |
| Subscription / Channel | 将后续事件送达原任务，并在原渠道回复 |
这套模型解决的是 Agent 工程里容易被忽略的三个问题。
第一，事件要能去重。 GitHub 通知或消息源重放时，同一个 Trigger 不应重复创建任务。文档把 Trigger 视为审计和幂等的基本单位；Source 自己还要维护读取位置，避免进程重启后把旧事件当作新事件。
第二，后续消息要找到原任务。 一个 PR 后来出现审查评论或 CI 失败，未必需要 Router 再问一次模型“这要交给谁”。原型使用 Thread 与 Subscription：订阅了该讨论串的 Ticket 可以直接收到后续事件。如果事件已经超出当前任务范围，Worker 才把它交回 Router 重新判断。这就是设计文章所说的订阅直通思路。
第三，任务状态不能等同于会话状态。 Ticket 可以等待、结束、恢复，执行它的 Session 也可能重建。把业务任务的生命周期从会话生命周期中抽出来，才能在重试、恢复和交接后仍知道“这件事到底做到哪了”。
可以用一段概念性伪代码理解这个过程；它解释职责分配，并非项目原样导出的 API：
onTrigger(event):
trigger = source.normalizeAndDeduplicate(event)
thread = locateThread(trigger)
delivered = false
for ticket in thread.activeSubscriptions:
deliverAsContext(ticket, trigger)
delivered = true
if needsNewDecision(trigger, thread, delivered):
decision = evaluate(trigger, currentPolicy)
if decision.accepted:
ticket = createTicket(decision.mandate)
assignExecutor(ticket)
关键不在伪代码的几行，而在每一步都有不同的失败条件和审计边界：来源可能重放、订阅可能失效、策略可能变化、执行器可能断开。如果没有这些对象，系统就只能把大量隐含状态塞进提示词，出了问题也很难定位。
四、主动工作必须先回答：它凭什么能动手？
“看到群聊有人说 Bug，就自动修复并发 PR”听起来很诱人，也容易造成误触发。原型把准入分为确定性的 Gate 和需要语义判断的 Assessment：先检查来源、身份、允许列表和接收范围，再让模型判断候选事件是否符合团队写下的规则。外部消息或被引用的文档只是输入，不能修改权限。
原型的自动接单有三种模式：off 不把推断事件变成候选；observe 是默认模式，只记录“如果自动化开启，本会接单”的判断；auto 才允许符合规则的推断事件真正创建任务。被允许的人明确向 Agent 提出的请求，在三种模式下仍可按明确请求处理。这个渐进路径很实际：先观察误报和漏报，再放开主动触发。
接单时创建的 Mandate 记录授权依据、范围、强度与策略版本。比如，一个 Issue 授权“复现并提出修复”，并不自动授权“合并所有相关 PR”。即使同一讨论串后来又来了消息，也不能凭上下文把权限无声扩大。原型还规定策略变化时要通知受影响的任务；已结束任务恢复前需重新校验其授权是否仍成立。具体规则见授权文档。
这里有一个值得借鉴的工程原则：让模型负责判断语义，让宿主程序负责执行权限约束。 只在系统提示词里写“谨慎行动”，无法替代事件准入、授权范围、幂等记录与停止机制。
五、长期运行不等于“把会话永远开着”
设计文章还提出几项支撑持续协作的机制，需要和原型的已实现能力分开看。
异步交互。 经典同步 ReAct 循环调用一个耗时工具后，会等待结果，期间难以及时处理新输入。文章提出用 start() 启动后台工作、立即返回“已启动”，完成时再把结果作为新事件投递；必要时可用 stop() 中止。这样前台对话不必等后台构建完成。文章说明相关异步机制已经进入 DeepSeek Harness，但当时尚未默认开启；不能据此推断公开 Super-agent 原型已经完整具备文中的全部全双工能力。
计算、状态与环境分离。 文章设想把推进 Agent Loop 的计算放到可替换的云端计算单元，把 Session 状态持久化；真实代码仓库、未提交修改和本地工具链仍可留在用户机器，由轻量代理按需执行命令。这样设备暂时离线时，任务状态不会随本地进程一起消失。它是面向长期在线系统的架构方向，不能把公开原型理解成已经提供了完整的跨设备云服务。
独立 Watchdog。 进程活着不代表任务有进展。设计中的 Watchdog 定期检查基础设施故障、Worker 是否陷入无效循环或偏离目标，再进行恢复或告警。对于持续运行的 Agent，进度监控比单纯的健康检查更难，也更重要。公开仓库 README 已提醒：设计文章中的一些方向并未进入原型。
六、落到公开代码，现阶段能看到什么？
dsh-superagent 当前是围绕单个 GitHub 仓库的研究原型，可以选择接入飞书。允许的成员在 GitHub 或飞书发起工作后，系统创建 Ticket，为它准备独立的 Worker Session 和目录，再把结果送回原讨论串，例如提交 PR。Web 面板优先显示需要人处理的事项。它依赖 DeepSeek Harness，公开代码按 MIT 许可证发布；仓库明确提醒代码并非生产级软件，也与内部版本不同。
从执行文档看，原型为每个 Ticket 建立独立的执行会话与目录；目录准备命令可用于建立 Git worktree。执行并发有槽位限制，并为人的新消息或状态请求保留额外容量，避免后台任务占满资源后，人反而无法及时继续已有工作。任务可以处于排队、工作中、等待事件、等待回答、等待审查、受阻或失败等阶段，面板据此决定何时需要人看一眼。
但“目录隔离”不等于安全沙箱。文档明确说明 Worker 以操作者的系统用户身份执行命令，命令封装和目录约定不是强安全边界。若要接入企业代码、凭据和 CI，仍需在部署环境、账号权限、审查和合并策略上单独设计边界。这个限制比“能自动提 PR”更值得团队在试用前先确认。
七、设计文章里的性能数字该怎么看？
团队做了一个初步的合成负载实验：约 300 条群聊及 CI 消息，其中约 20 条是工作请求；编码工作由一个只消耗时间的工具模拟。文中双层方案的任务完成时间 p95 为 15.7 分钟，单 Session 加中性委派提示的方案为 29.5 分钟。这说明在该实验设置下，路由和并行调度可以减少等待；它没有测量真实代码修改质量，也不能直接换算成生产团队的提效百分比。实验设置与结果见设计文章。
实验还有一个有意思的信号：提示词要求“优先委派”后，单 Session 方案的中位数有所改善，但尾部任务仍可能被新消息打断。由此能看到系统约束和调度策略的价值：不能只期待模型每次都主动选择正确的委派方式。
八、如果自己做一个类似系统，先实现哪一层？
不必一开始就搭建持续在线、跨设备、全自动的庞大平台。对于开发团队，更稳妥的起点是把下面几件事做实：
- 统一事件入口。 先接一个 GitHub 仓库，建立 Trigger ID、Thread ID、去重和事件记录。
- 明确授权。 区分“被允许的人明确要求”与“系统从环境中推断”，主动触发先用
observe观察。 - 任务与会话分离。 Ticket 保存授权、状态和来源；Worker Session 可以失败或重建，Ticket 仍可追踪。
- 按讨论串路由后续事件。 PR 评论、CI 更新尽量回到原任务，减少重复研判与上下文丢失。
- 限制并发与交付范围。 预留人的响应容量，把“提交可审查 PR”和“自动合并”作为不同级别的权限。
- 只汇报有用的变化。 成果、阻塞和待决策事项进入外部渠道；中间工具日志留在 Worker 内部。
这也解释了 Super-agent 名字里的“Super”到底指什么：它的重点是系统能持续协调多个任务、跨入口保持关系，并在合适的时候主动推进，而不是某个 Worker 的单次推理能力突然变强。 Router、Worker 和事件模型把会话降为内部实现细节；授权与可恢复状态则决定这种主动性是否可用。
参考资料
更多推荐
2
0- 0
已为社区贡献1条内容
所有评论(0)