DeepSeek Super-agent 拆解：架构设计与开源插件的实现边界
内容提要
DeepSeek Harness团队提出Super-agent架构，将全局协调的Router与执行任务的Worker分层，并用Ticket、Mandate、订阅和Effects等对象显式建模任务分派、授权、上下文投递与故障恢复。开源原型基于SQLite实现持久化与重启恢复，默认observe模式限制主动接单。实验显示分层调度可降低长尾完成时间，但未验证真实编程能力提升；原型仍以完全权限运行，安全隔离与长期记忆等边界尚待完善。
延伸解读
设计目标与公开代码之间存在落差
文章描述的 Router 可以轻量到不配 Bash，但公开原型的主会话仍开放 bash、read 等工具，避免读代码只是提示词规则而非工具层限制。类似地，原文设想的 BYOM 与语义 Watchdog 在部署文档中并未完整交付。读者应把架构图视为设计意图，把代码视为当前可验证的行为，两者不能混为一谈。
实验测的是调度长尾，不是编程能力
原文用合成消息流和模拟编码工具做对比，P95 完成时间从 29.5 分钟降到 15.7 分钟，反映的是任务分派与协调开销的改善。补丁是否正确、返工多少、人工审查时间是否减少，实验都没有覆盖。因此这个降幅不能外推为真实修 bug 效率或总费用同步下降，多会话反而增加缓存读取 token。
默认 observe 不等于系统只读
observe 模式只阻止推断候选自动开工，显式请求仍会创建工单并执行命令。它适合观察系统会主动接下哪些任务，但不能当作安全沙箱。原型以 danger-full-access 运行，独立工作目录也不阻止进程读取其他目录，接入前应使用低影响仓库和专用账户，并保留人工合并。
持久化恢复不等于外部操作恰好一次
SQLite 事务能把任务状态与待执行动作一起保存，重启后未完成的 Assignment 会要求先检查目录、git 历史和 GitHub 状态再继续。但 Outbox 先调用外部发送、再保存回执，中间仍有进程退出的间隙。内部去重与重试有明确价值，外部操作是否恰好一次仍取决于各目标接口的幂等能力。
Q&A
DeepSeek Super-agent 的 Router 和 Worker 是怎么分工的？
Router 负责全局协调，保存全局背景，接收不同渠道的输入，判断消息属于哪个任务，并负责分派与对外沟通；Worker 在独立上下文中执行具体任务，使用完整的工作工具，把关键进展和结果汇报给 Router。这样既能避免单会话被长任务阻塞，又能保持任务间的关联。
Super-agent 原型中的 Ticket 和 Mandate 分别起什么作用？
Ticket 表示一项已接受、具有明确范围的工作，拥有独立于会话的生命周期，用于描述“还欠用户什么结果”；Mandate 是这项工作的授权依据，包括范围、策略版本和请求来源，确保任务执行有明确的授权边界。
默认的 observe 模式是什么意思？它会阻止所有自动执行吗？
observe 是评估推断候选的默认模式：系统会对推断出的候选工作进行评估，但即使评估结果为接受，也只记录 would_accept，不会真正建立任务。它只阻止推断候选自动执行，显式请求仍然可以正常工作，因此不能理解为整个系统只读或不会执行命令。
Super-agent 如何保证任务在进程重启后还能继续？
原型使用 SQLite 持久化 Trigger、Thread、Ticket、Decision、待执行动作和消息回执。Engine 在事务中修改状态，外部工作通过 Effects 记录后再执行，Outbox 管理回复回执与重试。重启后，未完成的 Assignment 会获得恢复说明，要求先检查工作目录、git 历史和 GitHub 状态再继续，避免重复已完成的外部操作。
实验显示分层调度能降低长尾完成时间，这个结果能说明编程能力提升了吗？
不能。实验使用合成消息流，编码工作由一个消耗时间的工具模拟，测的是任务调度、协调和结果返回时间，并没有测真实补丁是否正确。因此 P95 完成时间从 29.5 分钟降到 15.7 分钟只反映该实验中的调度收益，不能外推为实际修 bug 速度或编程能力的提升。
把 Super-agent 原型接入真实团队前，需要特别注意哪些安全边界？
原型中 Router 和 Worker 都以 danger-full-access 运行，使用操作者的 OS 身份，独立工作目录并不阻止进程读取其他目录。外部文本（群聊、代码平台）与机器上的私有代码、服务和凭据连通后，不能仅靠独立会话判断风险已隔离。自动合并条件放在提示词中，强制审查仍需依赖 GitHub 分支保护等平台机制。建议选择低影响仓库、专用账户，保留人工合并，并先用默认 observe 观察。
