DeepSeek Super-agent 的架构设计与运行机制
内容提要
DeepSeek Super-agent采用Router与Worker双层架构：Router负责全局交互与任务路由，Worker隔离执行具体任务。系统由Trigger事件驱动，经规则与模型两阶段过滤；通过Thread订阅让后续事件直通Worker，降低路由开销。此外还包括上下文链式召回、投机执行、异步工具调用、多信道输出、计算与执行环境解耦，以及Watchdog异常检测与恢复机制。
延伸解读
双层架构的调度粒度差异
文章将Router与Worker的分工与常见的“主Agent加subagent”模式做了对比：后者通常围绕单个任务拆解步骤，而Router调度的是可独立推进的完整任务，如修复登录问题或调整活动页面。这意味着Router追踪任务间关系，但不介入每个任务的实现细节，Worker内部仍可再调用subagent。这种粒度差异决定了Router可用更轻量模型，而Worker需要更强推理能力，也解释了为何各Worker上下文相互隔离。
直通机制的成本收益需分开看
消融实验显示，去掉Thread直通后Router决策数增加约30%，缓存读取token总量从23.2M增至31.8M，增幅约37%，但任务完成时间基本不变。文章明确提醒，该实验用耗时工具模拟编码工作，验证的是调度与协调，不能推断真实代码质量提升；缓存读取token也只是成本的一部分，不能直接换算为总费用同比例变化。读者应把直通理解为降低路由开销的机制，而非提升执行效果的保证。
异步与解耦的边界条件
全双工交互通过异步工具调用解除同步阻塞，但文章指出新消息仍需等当前推理步骤结束后才能处理，并非能在一次模型推理中途即时插入指令；能接收停止指令也不代表命令可安全瞬间中断，取消任务、清理进程和处理已产生改动仍需执行层配合。计算与执行环境解耦后，云端可继续接活和调度，但若某步必须访问已离线设备，该步仍需等待恢复连接，换机工作也需具备对应代码、依赖和权限。
Watchdog的局限与配合思路
Watchdog作为独立于主执行流程的检查会话，按计划查看Worker状态和近期行为，识别重复失败、目标偏移或长期停滞并尝试恢复。但文章强调它依赖模型判断，不能当作正确性保证；长时间排查可能确实没有中间结果，频繁干预反而打断正常任务。作者更倾向将模型检查与确定性限制配合：程序负责超时、重试次数和资源预算，模型识别方向偏移，无法恢复的异常再交给人处理。
Q&A
DeepSeek Super-agent 的 Router 和 Worker 分别负责什么？
Router 维护全局交互和任务路由，接收来自不同入口的需求，创建或选择 Worker，并转达任务的关键结果；Worker 维护单个任务的执行上下文，负责具体的代码阅读、修改和测试。用户通过 Router 跟进工作，无需逐个管理 Worker 会话。
Super-agent 如何过滤外部事件，避免处理无关消息？
系统采用两阶段过滤：第一阶段用确定性规则检查事件来源、群组和发送者等条件，在调用模型前排除无关消息；第二阶段由模型结合上下文和团队规则，判断候选事件是否值得处理。固定条件交给程序，依赖语义的判断留给模型。
Thread 订阅和事件直通机制有什么作用？
Router 首次分派任务时让 Worker 订阅对应 Thread，后续事件由程序直接投递给订阅者（Pass-through），Worker 可沿用已有上下文继续处理，Router 主要负责新事件和跨任务协调。实验显示，去掉直通后 Router 决策数增加约 30%，缓存读取 token 总量增加约 37%，任务完成时间基本不变。
Acting Ahead 投机执行是什么意思？
Acting Ahead 指系统根据环境信号提前在后台执行可能用到的工作，有用的结果才交付，其余结果丢弃，用额外计算换取更短的等待时间。例如 Worker 先静默复现和寻找修复方案，确认问题并找到可交付的修复后再反馈，避免把探索过程变成新的消息负担。
Super-agent 如何实现异步工具调用和全双工交互？
耗时操作使用 start() 启动并立即返回，任务在后台执行；完成后系统把结果作为新事件送回会话，需要取消时通过 stop() 发起停止。这样 Agent Loop 不会被阻塞，会话可以继续处理新消息。但新消息仍需等当前推理步骤结束后才能被处理，并非能在一次模型推理中途即时插入指令。
计算与执行环境解耦解决了什么问题？
本地 Agent 把 Agent Loop、会话状态和执行环境绑定在同一台机器上，设备休眠或离线时任务推进和外部事件处理会停止。Super-agent 将三者分开部署：Agent Loop 运行在云端，会话和任务状态写入独立持久化存储，代码仓库、工具链等保留在原有执行环境，由轻量 daemon 接收命令并回传结果。这样进程重启或迁移不必丢失任务历史，云端服务可继续接收消息和调度。
Watchdog 如何检测和恢复异常？
Watchdog 是独立于主执行流程的检查会话，按计划触发，查看 Worker 的状态和近期行为，判断是否存在重复失败、目标偏移或长期停滞，并尝试恢复。但它依赖模型判断，不能保证正确性；实际实现中建议把模型检查和确定性限制（如超时、重试次数、资源预算）配合使用，无法恢复的异常再交给人处理。
