DeepSeek 发布 Super-agent：让 AI Agent 从聊天助手进化为自主工作的智能体
DeepSeek 发布 Super-agent：让 AI Agent 从聊天助手进化为自主工作的智能体
2026 年 10 月 31 日，DeepSeek Harness 团队发布了 Super-agent 架构设计，并开源研究原型。这次的亮点不是新模型，而是一个能够持续工作、并行处理任务、主动响应外部事件的 Agent 系统架构。
一、DeepSeek 这次到底发布了什么？
传统大模型的使用方式通常是：
用户提出问题 → 模型思考 → 调用工具 → 返回结果。
即使是具备工具调用能力的 Coding Agent，大多数情况下仍然以单个 Session（会话）为核心。
例如，你使用 Coding Agent 开发项目时：
- Session A：让 Agent 修复项目中的一个 Bug。
- Session B：让 Agent 开发新的 API。
- Session C：让 Agent 分析另一段代码。
- Session D：让 Agent 检查 GitHub 上的 Pull Request。
虽然这些任务都可以交给 AI，但你仍然需要自己管理每个 Session，检查任务进度、补充上下文，并决定下一步做什么。
当任务数量越来越多时，瓶颈可能已经不再是模型的代码能力，而是人类管理多个 Agent 的注意力。
DeepSeek 团队观察到，一个人通常只能有效跟进约 3～5 个活跃会话。
为了解决这个问题，DeepSeek 提出了 Super-agent（超级智能体）。
它希望把 Agent 从独立的聊天会话中解耦出来，构建一个能够长期运行、统一协调多个任务的智能体系统。
需要说明的是，这次发布的是架构设计与开源研究原型，而不是一款已经成熟商用的全新 DeepSeek 产品。
二、Super-agent 想实现什么？
DeepSeek 将 Super-agent 的核心能力归纳为四个方面。
| 核心特性 | 英文 | 具体含义 |
|---|---|---|
| 连续性 | Continuous | 跨会话、跨平台保持任务上下文 |
| 高效性 | Productive | 多个复杂任务并行执行 |
| 主动性 | Proactive | 根据环境事件主动发现并处理任务 |
| 持久性 | Persistent | 持续在线，并能从异常中恢复 |
例如，一个研发团队使用 Super-agent 时，可以出现这样的工作流程：
上午：
开发人员在飞书群中提出：
“这个接口最近经常超时，帮忙分析一下。”
Super-agent 识别到这是一个需要处理的问题，于是创建任务并开始分析日志和代码。
下午：
Agent 找到可能的原因，尝试修复代码，并提交 Pull Request。
晚上：
其他开发人员在 GitHub PR 中留下评审意见。
Super-agent 根据 PR 与原任务的关联继续工作，修改代码并重新运行测试。
整个过程中，不需要开发人员反复打开不同的 Agent Session，再把之前的上下文复制进去。
这就是 Super-agent 想要实现的交互方式：
人类负责提出目标和验收结果，Agent 系统负责协调、执行和跟踪任务。
三、核心架构：Router + Worker
我认为这是 Super-agent 最值得学习的设计。
DeepSeek 没有选择让一个 Agent 承担所有工作，而是采用了双层架构：
Router 层负责协调，Worker 层负责执行。
用户 / GitHub / 飞书
|
v
+---------------+
| Router |
| 接收事件、判断任务 |
| 维护全局上下文 |
| 统一对外沟通 |
+---------------+
|
+------------+------------+
| | |
v v v
+---------+ +---------+ +---------+
| Worker A| | Worker B| | Worker C|
| 修复Bug | | 开发功能 | | 代码审查 |
+---------+ +---------+ +---------+
| | |
+------------+------------+
|
v
状态与结果汇报
|
v
Router
|
v
返回给用户
3.1 Router：智能体的任务调度中心
Router 可以理解为项目经理。
它主要负责：
- 接收来自 GitHub、即时通讯等渠道的事件。
- 判断事件是否值得处理。
- 创建任务并分配给 Worker。
- 维护全局任务关系与必要的上下文。
- 将任务进度和结果统一反馈给用户。
最关键的设计：Router 尽量不亲自执行具体任务。
例如用户要求修复 Bug，Router 不应该自己花半小时分析代码，而是将任务分配给 Worker。
为什么？
因为 Router 需要持续处理新事件。如果它被某个耗时任务占住，其他任务可能无法及时响应。
因此，Router 应该尽可能轻量化，只处理调度、协调与沟通。
3.2 Worker：真正执行任务的智能体
Worker 是具体干活的 Agent。
每个 Worker 拥有相对独立的：
- Session 上下文。
- 任务执行状态。
- 工作目录。
- 工具调用过程。
例如：
Worker A：修改支付模块
Worker B：优化数据库查询
Worker C：处理测试失败
三个 Worker 可以并行推进任务，避免不同任务的中间推理过程混杂在同一上下文中。
Worker 完成任务后，将关键状态和结果报告给 Router，再由 Router 统一反馈给用户。
如果某个任务本身非常复杂，Worker 还可以进一步调用 Subagent，或者内部组织一个 Agent Team。
3.3 与传统 Multi-Agent 有什么区别？
传统 Multi-Agent 系统通常关注：
如何把一个复杂任务拆分给多个 Agent 协作完成？
例如：
用户需求
|
Planner
|
+----------+
| |
Coder Reviewer
| |
+----------+
|
最终结果
而 Super-agent 更关注：
如何长期管理许多相对独立的任务，并且不让用户手动管理所有 Session？
简单比较：
| 对比维度 | 传统单任务 Multi-Agent | Super-agent |
|---|---|---|
| 核心目标 | 完成一个复杂任务 | 长期管理多个任务 |
| 调度方式 | 围绕单个任务分工 | 跨任务、跨会话协调 |
| 上下文 | 通常围绕任务展开 | 全局协调与局部任务上下文分离 |
| 任务执行 | 多角色协作 | 多 Worker 并行 |
| 触发方式 | 通常由用户提出任务 | 可以由外部事件触发 |
两者不是互斥关系，一个 Super-agent 的 Worker 内部也可以采用 Multi-Agent 架构。
四、事件驱动：Agent 不再只能等待用户提问
传统 Agent 大多数时候是被动工作的：
用户输入 Prompt
|
v
Agent
|
v
执行并返回
Super-agent 引入事件驱动机制。
系统可以从真实环境中接收事件，例如：
- GitHub 新增 Issue。
- PR 出现代码评审意见。
- CI 测试失败。
- 飞书群中有人反馈 Bug。
- 邮件或日历出现新的待处理事项。
DeepSeek 将这些外部事件称为 Trigger（触发事件）。
但并不是每条消息都需要调用大模型。
如果一个团队每天有几千条消息，让 LLM 对每条消息都进行完整推理，成本和延迟都可能非常高。
因此，DeepSeek 采用两级过滤。
4.1 Fast Path：程序规则过滤
首先由确定性代码执行简单判断，例如：
- 事件来自哪个平台？
- 是否来自允许的用户？
- 是否属于需要监听的群聊？
- 是否符合预先设定的触发规则？
不符合条件的事件直接忽略。
这一阶段通常不需要大模型参与。
4.2 Slow Path：LLM 语义判断
通过初步过滤的事件，再交给大模型判断：
- 这是不是需要执行的任务？
- 是否属于已有任务的后续讨论？
- 有没有足够依据主动开始工作？
- 是否需要进一步询问用户？
例如：
群聊消息：
“昨天合并的代码好像让登录接口变慢了。”
在经过权限和触发规则检查之后，系统可能判断这是一条值得调查的技术问题。
随后创建任务，让 Worker 在后台分析。
值得注意的是，主动性不等于 AI 可以不受限制地执行任何操作。实际系统仍然需要设置允许的来源、用户、行为规则和权限范围。
五、Subscription：减少重复路由
假设一个 Worker 正在处理 GitHub Issue #100。
第一次出现任务时：
Issue #100
|
v
Router
|
v
Worker A
后来，Issue 中又出现了一条评论：
“已经找到新的报错日志。”
如果每条评论都重新交给 Router 判断，再转发给 Worker，就会增加大量不必要的开销。
因此，DeepSeek 提出了基于 Thread 的订阅与直通机制。
当 Worker 订阅某个 Thread 后，后续相关事件可以由程序直接送给 Worker：
Issue #100
|
v
Worker A
后续评论
|
v
Worker A
CI结果
|
v
Worker A
不需要每次都经过 Router 的完整推理。
这是一种类似计算机系统中 Fast Path / Slow Path 的优化。
Router 主要负责新任务的识别和跨任务协调，Worker 则持续接收自己负责的任务事件。
好处是降低 Router 的推理负担和 Token 消耗。
六、上下文管理：Inline & Spill + Chain of Recall
这是另一个值得关注的设计。
Super-agent 需要长期运行，任务可能持续数天甚至数周。
如果把全部事件、历史消息和工具结果都放进上下文窗口，很快就会面临：
- 上下文长度限制。
- Token 成本不断增加。
- 无关信息干扰模型判断。
DeepSeek 将上下文窗口类比为一种缓存。
6.1 Inline & Spill
基本思想：
把当前最可能需要的信息直接放入上下文，把其他内容放在外部存储中，按需读取。
例如：
当前上下文：
任务：修复登录超时
状态：正在测试
关联 Issue：#100
关联 PR：#105
历史日志：可按需读取
模型不需要一次看到全部日志，只需要知道在哪里能够找到它们。
6.2 Chain of Recall
DeepSeek 还提出了链式召回机制。
系统为 Trigger、Thread、Worker Session 等对象分配唯一标识，并建立关联关系。
例如：
当前 PR #105
|
v
关联 Issue #100
|
v
关联 Worker Session
|
v
历史分析结果
|
v
之前的日志与讨论
当模型需要了解某个任务的历史时，可以沿这些引用关系逐步读取。
这里的重点不是把所有历史内容永久放进 Prompt，而是建立一种能够找回相关上下文的机制。
可以把它理解为：
上下文窗口负责保存当前工作所需信息，外部存储负责保存可按需召回的历史信息。
这与传统的聊天历史无限拼接有明显区别。
七、异步 ReAct：让 Agent 在执行任务时继续响应
传统 ReAct Agent 通常是这样的：
Thought
|
Action：调用工具
|
等待工具完成
|
Observation
|
Thought
|
下一步
如果工具执行需要10分钟，Agent 可能需要等待工具完成后才能继续处理后续步骤。
Super-agent 提出异步 ReAct Loop 的思路。
例如：
用户：执行完整测试
Agent：start(test_command)
|
v
返回 Started
后台：测试运行中……
用户：顺便检查一下 README
Agent：可以继续接收新任务
后台测试完成
|
v
结果作为新事件送回 Agent
这意味着耗时任务不必始终占住前台交互流程。
其核心机制包括：
start()：启动后台任务。- 后台任务完成后，将结果作为新事件送入 Session。
stop()：必要时终止后台任务。
这里的 start() 和 stop() 表示官方设计中的异步工具接口思想，不是要求直接使用某个 Python SDK 中的同名函数。
需要注意：异步执行不意味着模型可以同时进行无限次推理。前台通常仍需等待当前推理步骤结束，但不必等待整个后台工具任务完成。
八、存算分离：让 Agent 不再绑定一台电脑
传统本地 Coding Agent 的一个问题是：
如果电脑休眠、终端关闭或程序退出，任务可能中断。
Super-agent 希望分离三个部分：
- 计算（Compute）：负责运行 Agent Loop。
- 状态（State）：保存会话和任务的持久化信息。
- 执行环境（Environment）：保存项目代码、依赖、文件和工具链。
例如：
云端
+----------------------+
| Agent Loop |
| Router + Workers |
+----------------------+
|
v
+----------------------+
| 持久化任务与会话状态 |
+----------------------+
|
v
执行环境连接
|
+------+------+
| |
v v
本地 Mac 云端服务器
代码、工具 代码、工具
这样设计后，即使本地设备暂时离线，云端仍然可以维护任务状态；需要本地环境的任务可以在设备重新上线后继续推进。
DeepSeek 将接入用户自己机器的思路称为 BYOM（Bring Your Own Machine）。
不过，这种架构也带来了明显的安全问题：本地设备通常拥有私有代码、凭据和敏感文件，云端 Agent 不能因为连接了本地执行环境就获得无限制操作权限。
九、Watchdog：谁来监督 Agent？
持续运行的 Agent 不仅可能遇到程序崩溃，也可能出现另一类问题：
程序还在运行，但 Agent 已经陷入无效循环。
例如：
Worker A：
检查错误
↓
修改代码
↓
运行失败
↓
重复相同修改
↓
再次失败
↓
无限循环……
普通的进程监控工具只能判断进程是否存活，不一定能发现 Agent 是否仍然在推进目标。
因此，DeepSeek 提出了独立 Watchdog Session 的设计。
Watchdog 负责监控：
- API 调用异常。
- 状态恢复失败。
- Worker 是否长期停滞。
- Agent 是否偏离原始任务目标。
- 是否需要重新尝试或介入修复。
这种设计将传统计算机系统中的看门狗机制扩展到了 Agent 行为层面。
它不仅关心程序有没有运行，还关心智能体是否在有效工作。
十、Super-agent 的实验效果怎么样？
DeepSeek 团队针对任务调度和路由设计进行了初步实验。
实验模拟了群聊消息、GitHub CI 事件和任务请求，并比较不同架构下的任务完成时间。
| 架构 | p50完成时间 | p95完成时间 | 每轮缓存读取Token |
|---|---|---|---|
| Super-agent | 12.4分钟 | 15.7分钟 | 23.2M |
| Super-agent（无直通机制） | 12.6分钟 | 15.5分钟 | 31.8M |
| 单Session + Subagent（普通提示） | 20.4分钟 | 29.5分钟 | 6.1M |
| 单Session + Subagent（优先委派提示） | 13.8分钟 | 29.0分钟 | 10.8M |
其中：
- p50：一半任务的完成时间不超过该值。
- p95：95%的任务完成时间不超过该值。
可以看到，Super-agent 在这组测试中的任务完成时间更短，长尾延迟也有所改善。
但它并非在所有维度上都更优秀。
Super-agent 使用更多的缓存读取 Token，换取了更好的并发处理和任务完成时间表现。
另外，订阅直通机制在实验中主要减少的是 Router 的推理负担，而不是明显缩短任务完成时间。
还需要强调：实验使用了合成负载和简化执行环境，编码工作由模拟耗时工具代替，不能据此得出它在真实软件开发中一定比其他 Coding Agent 写代码更快或质量更高的结论。
十一、开源代码目前实现了什么？
DeepSeek 同时公开了：
GitHub： https://github.com/deepseek-ai/dsh-superagent-prototype
这是一个基于 DeepSeek Harness 的主动式 Coding Agent 研究原型，采用 MIT 开源许可证。
公开原型主要面向单个 GitHub 仓库，可以接收 GitHub 事件，并可选接入飞书。
其基本工作流程是：
GitHub / 飞书事件
|
v
Trigger
|
v
权限与规则检查
|
v
判断是否接受任务
|
v
创建 Ticket
|
v
分配 Executor
|
v
独立 Session 执行
|
v
汇报进度与交付结果
|
v
GitHub / 飞书原渠道回复
例如，获授权的开发人员在 GitHub 中提出修复需求，系统可以创建工作项，在独立执行环境中推进任务，最终通过 Pull Request 等形式交付结果。
项目还提供了任务状态、授权规则、执行机制和 Web 管理面板等文档。
但官方明确说明：
- 这是研究原型，不是正式商业产品。
- 代码不保证达到生产环境质量。
- 公开实现与内部系统并不完全一致。
- 技术文章中的部分架构方向尚未在原型中实现。
因此，不能把文章中所有构想都当成已经可直接运行的功能。
十二、对于 Agent 开发者，有哪些值得借鉴的设计？
我认为 Super-agent 最有价值的地方，是把经典计算机系统设计思想运用到了智能体架构中。
| Super-agent 设计 | 可以借鉴的工程思想 |
|---|---|
| Router + Worker | 调度与执行分离 |
| Fast Path / Slow Path | 确定性规则和模型推理分层 |
| Thread Subscription | 事件订阅、减少重复路由 |
| Inline & Spill | 上下文缓存与按需读取 |
| Chain of Recall | 通过关联关系检索历史 |
| 异步 ReAct | 非阻塞工具执行 |
| 存算分离 | 持久化状态与弹性计算 |
| Watchdog | 独立监控与异常恢复 |
如果正在开发自己的 Agent 系统，我建议优先思考以下问题：
第一，Agent 是否应该始终围绕一个聊天窗口工作？
对于简单问答，这种设计没有问题。但对于需要长期执行的复杂任务，可能需要将任务状态独立于聊天历史保存。
第二，Router 是否应该亲自执行任务？
如果路由节点需要同时承担复杂任务执行和持续事件响应，它很容易成为系统瓶颈。
第三，是否所有事件都需要 LLM 判断？
确定性规则能处理的事情，通常没必要反复调用模型。
第四，长程记忆是否只能通过增加上下文长度解决？
不一定。外部存储、结构化关联关系和按需召回同样重要。
第五，如何判断 Agent 真正完成了任务？
不能只看模型是否返回了成功消息，还需要实际的执行结果、测试证据和外部监控。
这些问题比简单地在系统中增加几个 Agent 节点更值得深入研究。
十三、总结
DeepSeek 这次提出的 Super-agent，并不是让一个大模型拥有更多工具，也不是简单增加几个负责不同工作的 Agent。
它尝试改变 Agent 系统的基本组织方式：
从一个需要人不断发指令、管理会话的聊天助手，转向一个能够持续感知环境、协调任务并自主推进工作的数字协作者。
其核心架构可以归纳为：
- Router 负责全局协调和人机交互。
- Worker 负责隔离执行与并行处理。
- 事件驱动 使系统能够主动发现任务。
- 上下文管理 使跨会话工作成为可能。
- 异步执行 降低长时间任务对交互的阻塞。
- 存算分离与 Watchdog 为持续运行和故障恢复提供支撑。
当然，Super-agent 仍然面临上下文共享、权限隔离、多智能体协作、安全隐私和生产可靠性等挑战。
它的意义不在于已经彻底解决这些问题，而在于提出了一套值得实践和验证的系统设计思路。
未来 Agent 的竞争，可能不仅取决于底层模型有多聪明，还取决于整个系统能否长期、可靠、低干扰地把任务完成。
参考资料
更多推荐
1
0- 0
已为社区贡献2条内容
所有评论(0)