一文快速聊聊：DeepSeek 开源的 Super-agent 架构是个啥？

昨晚，DeepSeek Harness 团队发布了一篇新推文，相信不少人已经刷到了，分享团队在持续在线、多任务智能体上的架构探索。部分设计已经公开在 dsh-superagent-prototype^[1]，可以结合代码理解它如何接入 GitHub、飞书，以及组织任务的分派、执行与跟进。

要点速览

• 解决的瓶颈是人的注意力。 多个智能体能同时干活之后，谁来管理会话、补齐背景、跟进结果，成了新的问题。
• Router 负责协调，Worker 负责执行。 新任务统一分派，已有任务的评论和 CI 等事件可以直达对应 Worker。
• 持续工作不等于持续推理。 任务状态可以保存，在等待人工决策时释放执行名额，后续事件到来再继续；这与释放虚拟机、进程或内存是不同层面的事情。
• 记忆围绕工作对象组织。 消息、讨论、任务和会话通过引用关联，按需找回上下文，而非把全部历史塞进窗口。
• 这是架构探索，尚有落地边界。 实验主要验证调度，云端部署、跨设备执行和 Watchdog 等设计也不能全部视为公开原型已有功能。
• 文末延伸讨论：让 Worker 职业化。 将职业能力、任务档案与执行实例分开，再把经过验证的经验回流到共享技能池。

当 AI 能独立干活，谁来管这些工作

你在飞书里让智能体修一个问题，又在 GitHub 的评审评论里修改方案；与此同时，另一个任务正在跑测试，第三个任务等待验收。代码可能写得不错，但你仍需要记住每项工作在哪个会话、已经说过什么、接下来该去哪里追问。

Super-agent 针对的就是这种协调负担。单个 Coding Agent 越来越能独立完成任务，人却还充当着跨会话的路由器和记忆管理员。它希望把这些工作交给系统，让用户继续在熟悉的聊天、Issue 和 PR 中提出需求、调整方向、验收结果。

这套设计首先来自研发协作，也讨论了个人助手的可能形态。它追求四个特征：跨入口保持连续性，多任务高效并发，根据环境事件主动行动，以及长期在线并从异常中恢复。它并非一个新模型，也不是一套已全部落地的正式产品功能。

双层架构：一个入口，多个独立执行现场

如果所有事件都进入同一个会话，上下文容易保持连续，但执行会串行阻塞，不同任务的细节也会互相干扰。如果每条消息都新开会话，并发容易做，却丢失了全局协调和用户交互的一致性。

Super-agent 将这两类职责拆开。Router 维护跨任务的高层关联，接收请求、识别归属并分派任务，不亲自承担具体编码。Worker 在独立上下文中执行单项任务，必要时还能继续调用子智能体。具体任务的复杂度留在 Worker 内部，不让中央节点承担每一步技术判断。

这与常见的多智能体团队形态相似，区别主要在职责边界：Router 不必成为深入参与所有子步骤的技术主管。这样的约束由系统结构承接，减少对“模型这次会不会决定委派”的依赖。

公开原型将工作组织为 Ticket，每个任务关联自己的执行会话和目录，面板集中显示等待回答、等待审查或发生阻碍的事项。任务的状态和讨论可以延续，用户不必用聊天窗口的位置来记住工作进度。

事件驱动：新任务走路由，老任务直接找负责人

持续接入群聊、代码平台和 CI，会带来大量不需要处理的消息。如果每条都让大模型判断一次，成本和延迟很快会上升。

系统先用确定性规则检查来源、接收范围与准入条件，再将需要语义判断的候选交给模型。对于已经分配的工作，同一个 PR、IM 话题或邮件串构成 Thread，由相关 Worker 订阅。后续评论和运行结果可直接送到订阅者，省去中央 Router 再次调用工具转发。

Thread 与 Worker 可以多对多关联：一个任务跟踪多个讨论，一个讨论也可能与多个任务相关。订阅提供信息，不自动赋予新的操作权限；超出当前任务范围的要求，仍要重新分派。

主动性也可以发生在明确规则内。例如，团队配置“静默复现并修复”策略后，智能体可以先在后台调查群里的问题，找到有价值的结果再交付，没有结果则保持安静。公开原型对推断产生的任务默认采用观察模式，先记录“本来会接什么”，再决定是否开放自动执行。

上下文：把工作历史变成可追踪的引用关系

长期运行的系统无法把所有历史任务一直放在上下文中。Super-agent 采用 Inline & Spill：近期很可能需要的信息直接带入上下文，长内容和低频细节留在外部，仅保留摘要与读取入口。

消息、Thread、Worker Session 等对象有唯一 ID，返回一个对象时附上紧密关联对象的引用。模型可以从当前消息找到所属讨论，再找到相关任务与其他评审记录，逐步展开。这就是链式召回。

它解决的是工作历史的定位与恢复：之前讨论过什么，相关证据在哪里，为什么采用当前方案。跨月的长期记忆仍是开放问题，链式召回也没有自动完成跨任务经验提炼。

持续在线：执行、等待与恢复要分开

全双工交互首先要求耗时工具不堵住会话。长命令启动后立即返回，完成时再通过事件交回结果，新输入可以在当前推理步结束后进入处理，而不必等待整条命令结束。

任务的生命周期也不需要与执行名额完全绑定。公开原型在交付待审查结果、提出问题等人工交接点释放 Worker 名额，后续输入再恢复工作；后台仍有任务运行时，则可能继续占用名额。相关机制见执行与恢复文档。

释放名额意味着其他任务可以获得调度机会，并不直接证明对应进程、容器或内存已经回收。架构进一步提出计算、持久状态与执行环境分离：会话状态存入持久存储，计算可以重启或替换，实际工作环境通过端侧 daemon 按需连接。

Watchdog 则位于主系统之外，由定时消息驱动，既检查基础设施故障，也判断 Worker 是否陷入无效循环或偏离目标。主工作流靠事件推进，Watchdog 承担外部巡检和异常干预。

它验证了什么，还有什么没有解决

初步实验用约 300 条消息驱动不同架构，其中约 20 条是工作请求，每种方案重复运行五次。实验将消息间隔与工作时长按 1/4 缩放，模型调用耗时保持真实；编码工作被只消耗时间的工具替代，因此测量的是调度与协作，不能据此判断代码质量。

Super-agent 的任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟；中性提示下的单会话方案 p95 为 29.5 分钟。多会话消耗了更多读缓存词元，换来更短、更稳定的完成时间。在 Super-agent 内部移除订阅直通后，完成时间基本不变，但读缓存词元增加约 37%。这支持直通机制节省协调开销，并未显示它提高了单任务执行质量。

安全边界也尚未闭合。云端持续接收不可信事件，同时连接存有私有代码和凭据的设备，会扩大错误授权与提示注入的影响范围。凭据如何在不进入模型上下文的情况下被使用、多个实例之间如何隔离信息，仍是关键问题。公开仓库也明确，任务目录和命令包装不是安全隔离边界。

延伸思考：让职业长期积累，让实例按需出现

以下是我们在这套架构之上的延伸讨论，并非已经实现或验证的 Super-agent 功能。

按任务创建 Worker，有利于保持上下文清晰。但如果希望系统长期积累专业能力，还可以把职业信息、任务档案和执行实例进一步分开：

例如，一个“测试工程师”职业可以同时派生多个实例，每个实例加载相同版本的通用技能，再进入不同任务的独立工作区。复制的是能力配置，项目细节与历史讨论仍随任务保存。通用职业升级，也可以通过版本记录避免正在执行的任务被无意改变。

在这个基础上，还可以增加跨任务的经验整理者：当多个同职业实例形成类似的解决方法时，提炼其中可复用的部分，经过其他任务验证，再发布到通用职业技能池。相似经验只是候选信号，多个实例也可能重复同一种误判；项目专属配置与通用方法也需要分开。

这种方式类似把深入具体任务的交付经验，逐步转成组织可复用的专业能力。若借用 FDE 作类比，我们关注的是现场解决问题与经验产品化之间的连接，而不是宣称两者具有相同的岗位定义。

职业长期存在，任务独立留档，实例按需扩容，经过验证的经验逐步共享。这样，系统积累的资产便有机会从越来越长的聊天记录，转向可追溯、可复制的专业技能；其中的实际收益，仍需通过跨任务复用效果和维护成本来检验。