DeepSeek又开源了！公布Super agent架构

智东西

作者 | 李水青

编辑 | 心缘

智东西11月1日报道，10月31日晚间， DeepSeek Harness 团队公布了其关于自主Agent探索—— Super-agent（超级智能体）的底层架构 。

▲Super-agent开源项目地址

GitHub地址：

https://github.com/deepseek-ai/dsh-superagent-prototype

DeepSeek想做的“Super-agent”，可以通俗理解为一个 一直在线、能同时干多件事、会主动找活干、出问题能自己恢复 的Agent。该团队本次推出的成果并非一款新产品，而是更接近一种新思路——把计算机系统里的 调度、缓存、存算分离、看门狗（Watchdog） 等经典思想搬进Agent架构。

随着模型执行单任务减少人工干预，瓶颈转向人的注意力。DeepSeek Harness试图通过五大模块—— 双层架构、事件驱动、异步多信道交互、存算分离与外部Watchdog 在底层接管会话管理与上下文同步，使人上移到决策与验收，提升Agent应用体验。

▲Super-agent整体系统架构

实验上，基于该思路的Super-agent任务有一半任务 12.4分钟 内完成，95%的任务 15.7分钟 内完成，显著优于带Subagent工具的单Session（会话）；去掉订阅直通后，Router决定数增加约30%，读缓存token从2323万增到3177万；Router批处理能把单个决定分摊的推理时间从6.4秒降到 1.6秒 。

这组数据意味着Super-agent在初步实验中 证明了“系统层接管会话调度”的可行性。

一方面，多任务完成 更快更稳 ，Router靠直通省开销、靠批处理扛突发；但另一方面，它是 拿更多token来换取时间和稳定性 ，而且实验基于合成负载与简化环境，只是初步参考，不是正式产品结论。

一、Super-agent：不用切会话，一个Agent并行推进多任务

过去一年，Coding Agent等单任务Agent已证明模型能用工具解决复杂问题，人越来越少介入底层执行，角色上移到决策与验收。个人助手等持续在线、事件驱动的新形态开始涌现。

但现有Agent以单一Session为单位，多任务上限受人的注意力限制，简单扩展仍受同步阻塞、上下文混乱、设备离线即停等制约。

因此，DeepSeek Harness团队提出Super-agent：跨会话保持上下文、并行推进多任务且互不干扰的连续实体，并且已有内部实例在IM与GitHub间连续推进任务。

▲同一个任务在 IM 群聊与 GitHub Pull Request 评审之间连续推进

▲持续关注公共群聊，在无人@的情况下主动识别缺陷并提交修复Pull Request

团队认为，Super-agent具备四个基础特征：

– 连续：用户可以直接在IM聊天、GitHub评论等熟悉界面与它交互，感觉始终只存在一个Agent，不需要去想“Session X的上下文中是否有Y信息”。例如用户先在IM提出采用方案A，随后在GitHub PR评论里改为方案B，它能理解并调整执行方向。

– 高效：交互响应迅速，同时能并行、高质量完成多个复杂任务。无需等上一个命令或任务完成，就能接受下一条指令。

– 主动：无需等待用户逐条下达指令，能持续观察环境事件并主动推进值得处理的事项，不需要介入时保持安静。

– 持久：始终在线、直接接入用户真实工作环境，并在长期运行中遇到异常时自动恢复。

单个ReAct Loop无法同时支持上述四个特征，底层需要一套相应架构。文章认为，相似设计约束会导出相似架构选择。无论是个人助手，还是软件开发等商业场景的Agent，如果目标是构建持续在线、并发响应环境事件的系统，底层可能采用相近架构。这一过程中面临的许多问题与传统计算机系统长期探讨的问题高度相似，因此计算机系统中的经典设计思想同样适用。

具体落地会有不同变体，但文章认为五个模块构成支撑上述四个特征的基本框架：通过双层架构兼顾连续交互与高效并发，通过事件驱动实现主动响应，通过面向人的交互在交互过程中同时做到连续与高效，并通过计算、状态与环境分离及Watchdog实现跨设备持久在线与异常自愈。

二、双层架构：连续与吞吐不必二选一，一层分派、一层干活

跨信道连续交互与多任务高效并发存在根本权衡：全交给一个Session，上下文最连续，但单ReAct Loop串行、吞吐低、细节混杂；全开独立Session，吞吐最高，但缺全局上下文、结果割裂、交互混乱。

DeepSeek Harness团队的解法是把“维护全局连续性”与“高并发执行”拆成两层：常驻Router层承接人类交互与全局协调，上下文隔离的Worker层并发执行具体任务。Session应成为系统实现细节，而非用户认知负担。

▲双层架构：Router层统一负责路由与对外交互，多个Worker Session隔离并发执行任务

1、Router层：只分派不干活，靠批处理摊薄成本

Router层是常驻的全局路由层，负责承接所有入口的人类交互。所有跨任务的信息与决策都在Router层汇总，由它充当全局序点、协调点和记忆。为避免这一全局节点成为性能瓶颈，Router层在设计上不直接执行具体任务，只负责人类交互与任务分派，甚至可以不配备Bash工具。

这种由一个中心节点分派多个执行节点的结构，表面上与常见Agent Team相似，但侧重点不同。常见Agent Team主要用于单个复杂任务内部的步骤拆解与角色协作，子步骤通常耦合较紧，Team Lead往往需要深入理解任务细节、规划子任务并高频协调成员，自身承担很重推理负载。而在Super-agent中，Router层只处理任务之间的高层关联与分派，无需介入单任务内部拆解。相反，如果通过提示词约束一个Agent Team的主会话不亲自执行具体任务，仅负责对外交互并将不同任务分派给各成员独立推进，也可以视为这种双层架构。团队实践显示，Router层任务常常没有想象中复杂，使用较轻量模型往往就能兼顾速度与效果。

内部实现上，Router层同样不必局限于单个Session，甚至部分逻辑未必需要调用LLM。团队选择最直接的单个常驻LLM Session作为Router层核心实现，并发现它并没有表面看起来那么容易成为吞吐瓶颈，因为上一轮推理期间到达的环境事件会积压下来、在下一轮一并处理，形成批处理，而合并处理的额外开销很小：

– 外部事件流平稳时，Trigger逐条进入Router Session，单次响应延迟较低；

– 事件密集涌入、Router Session出现排队拥堵时，上一轮推理期间积压的多条Trigger会自动合并，在下一次LLM调用中一并注入。Router Session只做轻量交互与分派，每步通常是长输入、短输出。把积压多条Trigger合并进一次LLM API调用，会在Prefill阶段并行计算，单次请求耗时增长远慢于批处理大小。因此在一定范围内，积压越多，单个决定分摊的推理时间越低；上限取决于上下文长度，以及模型在一轮中能准确处理多少条Trigger。

文章在后文通过实验定量展示批处理机制效果。加上订阅与直通机制以及链式召回，单个常驻Router Session在保持上下文连续的同时，在目前团队规模下已经够用。

当规模进一步扩大、单个会话确实不足以承载时，Router层内部也可设计为多层过滤结构，或水平切分为多个会话。此时Router层内部设计本质上是连续性与吞吐量的权衡。切分粒度越细，Router层并发吞吐量越高，但分片之间的记忆与上下文连续性越低。在全局记忆问题被解决前，这一权衡始终存在。

2、Worker层：只干活不抢话，冲突靠订阅同一Thread自己发现

Worker层由负责具体执行的会话组成，各Worker彼此上下文隔离，挂载完整执行工具，在独立上下文中专注完成单一任务。由于Worker Session直接决定任务结果与代码质量，通常需要配置能力最强的模型。

Worker不会直接与人类交互，其推理过程和工具调用不会直接输出到外部信道，而是向Router层汇报状态，由Router层统一向用户回复，从而在保障并发度与交付质量的同时避免多个会话各自回复带来混乱。

多任务并发执行时，各Worker独立推进任务，同层Worker之间通常不需要直接通信。多个Worker在具体执行中的冲突往往出现在同一个Pull Request等共享工作环境中；只要它们都订阅了对应Thread，就会收到相同事件通知，从而有机会自行发现和解决冲突，少数跨任务协同则由Router层中转。

与Router层类似，每个Worker Session内部也不必局限于单个会话：执行复杂单任务时，Worker内部可再创建Subagent，也可本身就是一个Agent Team，这些对上层的Router层保持透明。这一结构既适用于代码协作场景，同时推进多个独立问题复现、PR评审与特性开发而互不阻塞；也适用于个人助手场景：虽然个人助手界面上通常只提供一个单会话聊天页面，但当用户在同一对话框同时讨论多个不同话题时，前端单一聊天页负责维持交互连续性，底层可为每个话题分别分派Worker，并行推进任务、起草回复。

三、事件驱动：不等指令，环境事件当输入，四步让Agent主动干活

要让Super-agent具备主动性，首先需要改变系统驱动方式。驱动Agent的主要输入不再是人类在Session中逐条键入的提示词，而是环境中的半结构化事件。在Super-agent中，群聊消息、邮件与日程提醒、代码审查评论、CI运行结果等环境事件被称为Trigger。通过监听并响应Trigger，Agent不必再像单Session模式下那样，等人类下达指令才被动执行一次。

围绕一条环境事件从进入到处理的生命周期，文章依次讨论四个递进问题：如何通过程序与模型结合的两级策略过滤大量噪音；如何通过订阅与直通机制将事件路由给Worker；如何利用Inline & Spill与链式召回向模型高密度注入与按需召回上下文；如何利用投机执行根据环境信号在后台提前行动。

1、 事件过滤：程序先快筛，模型再慢判

接入真实群聊与代码平台后，环境事件流呈现显著“高噪音、低触发率”特征，绝大多数日常消息并不需要Agent介入。如果对每个事件都调用大模型从头判断，延迟和算力成本都难以承受。借鉴计算机系统中的Fast Path / Slow Path思想，大模型推理可看作灵活但高成本的Slow Path，而将已经明确且稳定的高频判断固化为确定性代码，则构成低延迟、低成本的Fast Path。

因此，事件进入系统后的第一步是过滤，目标是在调用大模型之前先用确定性策略筛除噪音，只将需要语义理解的候选事件交给模型判断。团队采用程序策略与大模型相结合的两级过滤机制：

– 程序层策略，作为Fast Path：针对事件来源、群组范围、用户或机器人白名单等确定性条件，直接通过代码进行快速准入检查，例如对不同来源分别设置“仅响应明确请求”“作为候选事件”或“直接忽略”，在调用模型前滤除大部分无关消息。

– 语义层策略，作为Slow Path：通过程序层准入的候选事件交给LLM，由它根据用提示词编写的策略和上下文判断是否需要行动。语义层同时作为面向人类的自然语言扩展点，方便随时通过提示词开关或新增策略。

▲两级过滤：先由程序层策略筛除大部分无关消息，再交由语义层策略判断

2、事件路由：后续事件不再绕Router，订阅了就直接发Worker

第2节引入的全局Router层负责维持跨信道连续性，但如果已分配任务的每个后续事件仍需经由Router层转发，这一全局节点依然会承受大量负载，推高系统响应延迟。因此，Fast / Slow Path同样适用于过滤后的事件路由。全局Router层仅负责新任务冷启动与跨任务协调，已确定归属关系的后续事件由程序直接发往对应Worker会话，无需经由Router层转发。

实际工作流中，同一个GitHub PR、同一个IM话题或同一封往来邮件串下的连续事件构成一条事件流，即Thread。

▲Thread示例：同一个IM话题或同一个GitHub Pull Request下的连续Trigger构成一条Thread

Router层根据某个Thread的初始事件创建Worker Session后，该Worker会直接订阅对应Thread，从而将事件路由分为两条路径：

– 已订阅，Fast Path：同一Thread下后续事件由程序直通已订阅Worker，无需Router层再次调用工具转发。若新事件超出当前任务范围，Worker也可取消订阅或交回Router层重新分派。

– 未订阅，Slow Path：Router层仍可观测所有事件以掌握全局状态，但仅负责判断和分派尚未被订阅的新事件。

▲订阅与直通：初始事件经由 Router 层创建 Worker 并建立订阅，同一 Thread 的后续事件直接发往该 Worker

此外，Thread与Worker之间的订阅是多对多关系。一个Worker可同时订阅多个相关Thread，同一个Thread也可被多个Worker订阅。当多个Worker在同一个工作环境或讨论中发生交集时，该Thread下新事件会同时直通给所有订阅它的Worker，使它们无需点对点通信，也有机会获知彼此操作并自行解决冲突。在输出侧，Worker仍将关键结论汇报给Router层，由Router层统一向用户回复并同步全局记忆。

3、上下文组织：常用直接放，长文先摘要，旧任务顺ID找

事件经过过滤与路由、进入目标Session后，下一个问题是应向模型上下文窗口注入多少信息。由于系统输入从有限人类提示词转向环境持续产生的半结构化事件，工具调用与事件注入的结构设计变得更加重要。注入过多会挤占窗口、稀释模型注意力，注入过少又会迫使模型反复调用工具读取，增加执行步数。文章直言：浪费上下文窗口，就是浪费模型的智能。…

资讯由采集器定时从公开的机器人 / AI 信息源自动聚合。