DeepSeek公开Super-agent架构：让AI同时干多件事，难点在模型之外

当一个编程智能体能够独立修复问题、运行测试并提交代码，用户接下来的需求往往是让它同时推进更多工作。新的麻烦也随之出现：不同会话的信息如何同步，后台任务如何接收新要求，几十条消息涌入时哪些值得处理，程序中断后又该从哪里继续？

DeepSeek Harness团队10月31日晚公开的Super-agent架构探索，试图在系统层面回答这些问题。其核心是将全局协调与具体执行拆开，让用户面对一个持续在线的智能体，底层则由多个独立会话并行工作。

一层协调、多路执行，解决会话连续与任务并发的矛盾

把所有工作放进一个会话，智能体容易掌握完整背景，但任务只能围绕有限的执行循环推进，细节也容易混在一起；为每项工作分别开启会话，可以提高并发度，却又需要用户充当协调员，告诉不同会话此前发生了什么。

Super-agent采用Router与Worker双层设计。Router承接用户交互，维护跨任务的关联信息，并将工作交给Worker；Worker在各自隔离的上下文中执行具体任务，再向Router汇报。

这种分工的关键在于，Router不必深入承担每项任务内部的全部推理。它主要处理“这件事归谁、是否与旧任务有关、什么时候需要人决定”，具体开发、测试和排错交给执行层。由此，全局协调不再与耗时操作绑定，用户也不必等待一个任务结束后才能提出另一项要求。

公开原型的执行文档给出了更具体的实现：每个工作项拥有自己的执行会话和目录，长时间运行的命令会转入后台。后台作业完成后，再把结果交回执行会话；需要用户回答问题或验收结果时，则释放相应的工作名额。

真正需要管理的是事件，而不只是提示词

持续在线的智能体面对的是不断变化的环境。一条代码评审意见、一次测试失败、群聊中的补充说明，都可能改变正在执行的任务。

如果所有后续事件都要由Router重新理解并转发，协调层就容易成为瓶颈。团队提出的订阅与直通机制，是让已经确定归属的事件直接进入对应Worker；Router主要处理新任务和跨任务协调。其工程价值在于减少重复判断，同时保持相关任务能够持续接收新信息。

公开代码也反映出另一项重要选择：任务状态必须由系统可靠记录。原型将事件、讨论串、工作项和执行分配等对象交给Engine统一管理，状态修改通过事务完成，外部操作在提交后执行。这样，系统才能区分“已经决定要做”与“实际已经完成”，为重启恢复和错误处理提供依据。

从设计逻辑看，这里的进展主要来自系统组织方式。调度、缓存、状态持久化和看门狗都是成熟的计算机系统思想，将它们用于智能体，目标是让模型的单次能力转化为可持续的工作流程。它改变的首先是任务如何进入、如何流转、如何恢复，而非模型本身掌握了多少知识。

初步实验验证调度效率，公开代码仍是研究原型

据团队披露的初步实验，每次负载包含约300条消息、其中约20条为工作请求，各方案重复运行5次。Super-agent的任务完成时间中位数为12.4分钟，95分位为15.7分钟；中性提示下的单会话方案，95分位为29.5分钟。

这些结果有明确边界：实验采用合成负载和简化环境，主要评估调度与协作，不代表真实软件项目的代码质量或交付成功率。

对开发者而言，此次公开的价值，是提供了一套可以检查和修改的工程样本。项目说明明确指出，dsh-superagent是研究原型，并非正式DeepSeek产品，也不等同于团队内部版本，文章中的部分设计尚未实现。持续在线、多任务并发的方向已经被拆解成具体工程问题，距离可放心托付的生产系统，还需要逐项解决权限、恢复和真实任务质量。