同时使用多个 Coding Agent 时，很快会遇到一个问题：任务可以并行执行，会话却仍然需要人来管理。
例如，一个 Agent 修改接口，一个补测试，另一个排查线上问题。它们各自推进任务，但需求确认、错误反馈和结果验收分散在不同窗口里。用户需要反复切换会话，记住每个任务的上下文，再决定下一步。
任务越多，这部分协调工作就越明显。单个 Agent 能独立完成开发，并不意味着多个 Agent 就能自然地协同运行。
DeepSeek 的 Super-agent 设计把会话管理和任务执行分成两层，并围绕外部事件、异步工具调用、状态持久化和异常恢复组织整个系统。本文按任务进入系统、分派执行、接收后续消息的顺序，拆解这些机制。
以下讨论的是 Super-agent 的架构设计。开源原型 dsh-superagent-prototype 与团队内部版本并不完全一致，设计文章中的部分能力仍属于后续方向。
图 1 Super-agent 总体架构。事件经筛选进入 Router，Worker 负责独立任务，底层会话存储保留状态。 图片来源：DeepSeek Harness 设计文章。
Router 与 Worker 双层架构
双层架构首先划分了两种职责：Router 维护全局交互和任务路由，Worker 维护单个任务的执行上下文。
Router 接收来自不同入口的需求，创建或选择 Worker，并转达任务的关键结果。具体的代码阅读、修改和测试由 Worker 完成。用户通过 Router 跟进工作，不需要逐个管理 Worker 会话。
这样的划分也影响模型选择。Router 主要处理任务归属和高层协调，可以使用更轻量的模型；Worker 的推理质量直接影响执行结果，通常需要能力更强的模型。各个 Worker 的上下文相互隔离，避免不同任务的执行细节混在一起。
与“主 Agent 加 subagent”的常见用法相比，这里的区别主要在调度粒度。
主 Agent 通常围绕一个任务做规划，把其中一些步骤拆给 subagent，最后再汇总结果。比如开发一个功能，分别让子 Agent 查接口、写页面、补测试。
Router 调度的通常是可以独立推进的完整任务，例如修复登录问题、调整活动页面。它追踪任务之间的关系，但不负责拆解每个任务的实现步骤。Worker 内部仍然可以调用 subagent，或者组织一个 Agent Team。
Trigger 事件驱动与两阶段过滤
系统要持续响应工作中的变化，输入就不能只依赖用户在聊天框里发送指令。
群消息、GitHub 评论、CI 结果都可以转换为 Trigger。Trigger 表示一次外部事件，是否需要启动任务，还要经过过滤和语义判断。
麻烦在于，消息多不代表任务多。群里的闲聊、重复通知、与项目无关的讨论，如果全交给大模型判断，既浪费调用，也容易让 Agent 忙一些没人需要的事。
过滤分为两阶段。第一阶段用确定性规则检查事件来源、群组和发送者等条件，在调用模型前排除无关消息；第二阶段由模型结合上下文和团队规则，判断候选事件是否值得处理。固定条件交给程序，依赖语义的判断留给模型。
假设群里有人说：“登录之后页面一直在转圈。”在允许主动排查这类反馈的规则下，系统可以把它交给 Worker，尝试复现问题、定位原因，最后提交修复 PR。后面有人补充复现条件，或者 CI 报了新错误，也能继续推进这件事。
这里的“主动”仍然需要边界。开源原型的规则是，Agent 在收到获准用户的请求，或团队事先写好的规则允许时才行动。随口一句讨论，并不天然等于授权它修改项目。行为原则
Thread 订阅与事件直通
同一个任务会持续产生新事件。PR 提交之后，还可能收到评审意见、CI 结果和需求补充。
如果每个后续事件都经过 Router 重新判断和转发，既增加推理开销，也让全局路由承担了本可直接完成的消息投递。
Super-agent 用 Thread 表示相关事件形成的消息流，例如同一个 PR、IM 话题或邮件会话。Router 首次分派任务时，让 Worker 订阅对应 Thread；后续事件由程序直接投递给订阅者，这条路径称为 Pass-through。
这样，Worker 可以沿用已有上下文继续处理任务，Router 主要负责尚未建立订阅的新事件和跨任务协调。直通的是输入事件；Worker 的关键结果仍回报给 Router，由它统一对外回复。
Thread 与 Worker 的订阅关系是多对多的：一个 Worker 可以订阅多个相关 Thread，同一个 Thread 也可以有多个 Worker 订阅。共享 Thread 的事件会送给所有订阅者，让它们有机会发现彼此的改动并协调冲突。不过，收到相同通知并不等于自动解决代码冲突，执行环境仍需要处理并发修改。
图 2 Thread 订阅与事件直通。首次分派经过 Router，后续事件直接进入订阅该 Thread 的 Worker。 图片来源：DeepSeek Harness 设计文章。
直通机制的实验结果
设计文章用合成消息流做了消融实验，每种配置运行 5 次。去掉直通后，Router 每轮实验的决策数增加约 30%，所有会话的缓存读取 token 总量由 23.2M 增至 31.8M，增加约 37%；任务完成时间则基本不变。
这组结果主要说明了直通对路由开销的影响。实验中的编码工作由耗时工具模拟，验证的是调度与协调，不能据此推断真实代码质量的提升。缓存读取 token 也只是成本的一部分，不能直接换算成同等比例的总费用变化。数据见设计文章第 7.1 节。
Router 的批处理
对于需要路由判断的新事件，Router 采用批处理：当前推理轮次执行期间，新事件先进入队列，下一轮再合并送入模型。突发消息可以共用一次请求的部分开销，但单批处理量仍受上下文容量和判断准确率限制。
不过，减少路由判断不等于整个系统的费用按同样比例下降。Worker 执行任务也要消耗 token，缓存命中、上下文长度都会影响账单。同样，批处理降低的是分摊到每条事件上的开销，排队中的消息仍然可能等待。这些指标得分开看。
上下文组织与链式召回
事件找到 Worker 之后，还要决定给模型看多少内容。把整个 PR 的评论、日志和历史记录都塞进去，会很快占满上下文；只给一个事件 ID，又会让模型反复调用工具补信息。Inline & Spill 就是在这两种情况之间做取舍。
Inline 把近期可能用到的信息放进当前上下文，例如事件摘要、相邻评论和关联对象的 ID。Spill 则把超出预算或暂时用不到的完整内容留在窗口之外，只保留摘要、引用或续读入口，需要时再读取。这里省略的是当前窗口里的内容，并不意味着把原始记录删掉。
Router 还需要找回已经离开上下文的旧任务。Chain of Recall 利用 Trigger、Thread 和 Worker Session 的对象 ID 建立引用关系：模型先从当前事件找到相关 Thread，再沿着关联 ID 查询 Worker 会话和其他讨论。工具返回的信息也带有下一跳的摘要与引用，模型可以按需要继续查下去。
因此，历史任务不必始终完整驻留在 Router 的上下文里。系统保留可追溯的记录和关联关系，Router 再根据当前问题逐步恢复所需信息。这个机制解释了用户换一个渠道继续讨论旧任务时，上下文可以怎样被找回来。机制见设计文章第 3.3 节。
Acting Ahead 投机执行
事件驱动回答了什么时候启动处理，Acting Ahead 则进一步考虑：结果还不确定会不会用到时，是否值得先做一些工作。系统根据环境信号提前在后台执行，有用的结果才交付，其余结果丢弃，用额外计算换取更短的等待时间。
前面“群里反馈登录转圈”的例子，也可以按这种策略处理。Worker 先静默复现和寻找修复方案，确认问题并找到可交付的修复后再反馈；如果没有得到有用结果，就不把整个尝试过程发进群里。提前执行仍须符合团队设定的规则。这里的重点既包括提前开工，也包括对交付结果的筛选，避免把探索过程变成新的消息负担。设计文章第 3.4 节将其称为 Acting Ahead。
异步执行与全双工交互
同步工具调用会阻塞 Agent Loop。例如，Worker 调用 run() 执行测试后，如果必须等待测试结束才能进入下一轮推理，那么这段时间内的新输入也无法及时处理。
全双工交互通过异步工具调用解除这类阻塞。耗时操作使用 start() 启动并立即返回，任务在后台执行；完成后，系统把结果作为新事件送回会话。需要取消时，再通过 stop() 发起停止。
Router 派发任务也遵循同样的方式：收到启动反馈后继续处理其他输入，Worker 完成任务时再回传结果。
图 3 同步与异步 ReAct Loop 的时序对比。后台工具执行期间，会话可以继续处理新消息。 图片来源：DeepSeek Harness 设计文章。
Worker 跑长命令也是一样。测试放到后台运行，期间仍然可以接收 PR 评论或新的需求。开源原型的执行文档中，也描述了将耗时 shell 命令转到后台的机制。执行机制
因此，接收新指令不必等待后台测试结束。不过，新消息仍需要等当前推理步骤结束后才能被处理；这里的全双工并不意味着能在一次模型推理中途即时插入指令。
当然，能接收停止指令，不代表任何命令都能安全地瞬间中断。消息接进来之后，如何取消任务、清理进程、处理已经产生的改动，仍然需要执行层配合。
多信道的输出规范
能持续接收消息之后，还需要决定如何回复。IM 群聊适合简短结论和需要人处理的事项，GitHub PR、邮件和文档则适合完整的问题背景、改动说明与验证结果。Worker 的工具调用和详细推理留在内部，由 Router 按渠道组织输出。
设计文章给出过一条 IM 实践规则：单次回复不超过 100 words。这个数字是团队验证过的沟通约束，并非 Super-agent 必须遵守的架构参数，也不能直接等同于 100 个汉字。多信道设计的重点，是让同一项工作的输出适应不同渠道，而不是把同一份日志复制到所有地方。
计算与执行环境解耦
本地 Agent 往往把 Agent Loop、会话状态和执行环境绑定在同一台机器上。设备休眠或离线时，任务推进和外部事件处理也随之停止。
Super-agent 将三者分开部署。
Agent Loop 运行在云端，会话和任务状态写入独立的持久化存储。代码仓库、工具链和依赖服务保留在原有执行环境中，由轻量 daemon 接收命令并回传结果。运行服务的生命周期与会话状态分离后，进程重启或迁移不必丢失整个任务的历史。
这里包含两层解耦：计算与状态分离，以及计算与执行环境分离。只把会话记录存进数据库，还不足以解决跨设备执行的问题。
图 4 Agent Loop、会话存储与执行环境分离。执行端可以是开发机、云端环境或间歇在线的个人设备。 图片来源：DeepSeek Harness 设计文章。
工作环境留在本地，有很实际的原因：代码可能还有没提交的改动，测试服务只能从内网访问，有些工具和凭据也只在这台机器上可用。为了让 Agent 在线，就把整套环境复制到云上，未必划算。
拆开之后，云端服务可以继续接收消息、记录任务，并把适合的工作交给在线的执行环境。如果某一步必须访问已经离线的笔记本，那一步还是得等它恢复连接。
所以，“一直在线”指的是系统还能接活、保留状态、继续调度。它并不会让一台关机的电脑继续执行命令。换到另一台机器工作，也需要那台机器具备对应的代码、依赖和访问权限。
Watchdog 异常检测与恢复
长期运行的 Agent 会遇到两类异常：进程或外部服务不可用，以及进程仍然正常、任务却没有有效进展。
后一类更难靠传统存活探针发现。例如，Worker 反复执行相同的失败测试，或者需求已经变化，它还沿着旧方案继续修改代码。
Watchdog 是独立于主执行流程的检查会话，按计划触发。它查看 Worker 的状态和近期行为，判断是否存在重复失败、目标偏移或长期停滞，并在发现异常后尝试恢复。
不过，Watchdog 也依赖模型判断，不能把它当作正确性的保证。一次长时间的排查可能确实没有中间结果，频繁干预反而会打断正常任务。
实际实现时，我更倾向于把模型检查和确定性限制配合使用：程序负责超时、重试次数和资源预算，模型负责识别方向偏移；无法恢复的异常再交给人处理。这样比不断增加新的监督 Agent 更容易控制。
这套设计里，我比较关注会话边界的变化。用户围绕任务持续沟通，系统在内部决定消息属于哪个 Worker、需要恢复哪段上下文，以及什么时候返回结果。会话仍然存在，但不再要求用户手动维护。
架构是否有效，最终还要看真实工作负载：任务能否跨消息入口继续推进，后续反馈会不会丢失，后台执行失败后能否恢复，以及减少人工协调所增加的模型成本是否值得。这些比同时启动多少个 Worker 更能说明问题。