原文链接：https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg
这篇文章很值得研究。它不是在介绍一个新的大语言模型，而是 DeepSeek 团队对 下一代 AI Agent 应该如何设计 的一次系统性探索。
文章标题是《Super-agent 设计探索：迈向更自主的 Agent 系统》。
它讨论的核心问题其实非常有意思：
当 AI 已经能够完成复杂任务，为什么我们还得花大量时间管理 AI？
比如你同时使用 Claude Code、Codex，开几个 Agent 并行开发，可能会遇到这些问题：
- 每个 Agent 都有独立的上下文，需要自己记住它们分别在做什么。
- 一个任务执行十几分钟甚至更久，你需要不断检查进度。
- 新消息来了，你需要判断应该交给哪个 Agent。
- 电脑关机、会话结束，任务可能就中断了。
- 多个 Agent 之间缺乏协调，甚至重复工作。
DeepSeek 想解决的，已经不只是让 Agent 更聪明，而是让它成为一个能够持续工作、自主调度、主动发现问题的系统。
我认为这篇文章最重要的价值在于：它把 Agent 的竞争从模型能力，进一步推向了 Agent Harness（运行框架）和系统架构。
一、Super-agent 到底是什么？
先看它的整体结构。
人类用户
|
v
Router（总调度：接收消息、理解意图、安排工作、掌握全局状态）
|
+--> Worker（执行者：一个任务一个上下文，独立工作环境）
| |
| +--> Subagent（子执行者：Worker 再拆给下级 Agent）
|
+--> Watchdog（监督者：发现卡死、异常、偏离目标时介入）可以把它理解成一个 AI 公司：
- Router（总调度）：类似项目经理，接收各种消息，理解用户意图，安排工作，掌握所有任务的整体状态。
- Worker（执行者）：类似具体的工程师，每个人负责一个任务，有独立的上下文和工作环境。
- Subagent（子执行者）：Worker 还可以进一步拆分任务，安排自己的下级 Agent。
- Watchdog（监督者）：独立监控系统，发现任务卡死、异常或者偏离目标时进行干预。
举个例子。
假设你在公司的飞书群里说：
最近用户反馈订单导出功能有时候会报错，帮忙看看。
传统 Agent 的工作方式：
- 你打开 AI 对话窗口。
- 把问题告诉它。
- AI 检查代码，尝试复现。
- AI 给出解决方案。
- 你检查结果，决定是否提交。
Super-agent 的工作方式则不同：
- Router 在群聊中发现这个问题。
- Router 判断这是一个值得处理的研发任务。
- 创建独立 Worker，安排它检查代码。
- Worker 在独立环境中复现问题、分析原因、尝试修复。
- Worker 将进展和结果报告给 Router。
- Router 在原来的群聊中反馈，必要时提交 PR 等待人工审查。
而且，在这个过程中，你可以继续在群里讨论其他事情，不需要一直盯着这个任务。
这里有个很重要的变化：
Agent 不再是一个聊天会话，而是一个持续运行的任务管理和执行系统。
DeepSeek 将目标归纳为四个特征：
| 特征 | 含义 |
|---|---|
| 连续 | 跨聊天、群聊、GitHub 等渠道保持任务连续性 |
| 高效 | 多个任务并行执行 |
| 主动 | 能够观察环境事件，主动发现和处理问题 |
| 持久 | 长期在线，任务状态可以恢复 |
二、最重要的架构设计：Router + Worker
我认为这是整篇文章最值得关注的设计。
传统 Agent 体系中，通常以 Session 为中心。
例如你同时打开三个 Claude Code：
传统模式
你：人类用户
|
+--> Session A 独立上下文 / 独立任务
+--> Session B 独立上下文 / 独立任务
+--> Session C 独立上下文 / 独立任务
你负责在不同会话之间切换、协调和同步信息问题是：每个 Session 都是独立的。
Session A 不知道 Session B 在做什么，Session B 也不知道 Session C 的进度。你自己成为了整个系统的调度中心。
DeepSeek 的设计：
Super-agent 模式
人类用户（提出目标、提供反馈、验收结果）
|
v
Router（统一入口 / 全局协调 / 任务分发 / 信息汇总）
|
+--> Worker A 独立上下文 / 独立执行
+--> Worker B 独立上下文 / 独立执行
+--> Worker C 独立上下文 / 独立执行
执行结果、进度和需要人工决策的问题返回 Router这里有一个容易忽略的细节：
Router 和 Worker 不只是两个不同的提示词，而是两个职责不同的运行角色。
Router 不应该亲自承担所有具体工作，否则它又会变成一个庞大、拥堵的 Session。
Worker 也不应该直接向用户各自汇报，否则用户又要面对多个 Agent。
所以，Router 统一管理交互，Worker 专注执行。
这是一种系统架构层面的职责隔离，而不只是 Prompt Engineering。
三、五个值得深入研究的技术设计
除了双层架构，文章还提出了几个很有意思的设计。
1. 事件驱动：Agent 不再只是等你提问
这是我认为 Super-agent 与传统 Coding Agent 最大的区别之一。
传统 Agent：
用户输入
|
v
Agent 思考
|
v
执行工具
|
v
返回结果
|
v
等待下一次用户输入Super-agent：
外部环境持续产生事件
|
v
事件过滤
|
v
Router 判断是否需要处理
|
v
创建或唤醒 Worker
|
v
执行任务
|
v
持续接收后续事件这里的 Trigger（触发事件）可以来自很多地方：
- 飞书群消息
- GitHub Issue
- Pull Request 评论
- CI 构建结果
- 邮件
- 日程提醒
例如，Worker 正在处理一个 GitHub PR。
这时候有人在 PR 下追加了一条评论。
传统设计可能需要用户把评论复制给 Agent，或者重新触发一次会话。
Super-agent 引入了 Thread 订阅机制。
Worker 接手任务后，可以订阅对应的 Thread。后续与这个任务有关的事件，直接发送给它。
这就像一个程序订阅了消息队列的 Topic。
GitHub PR #123
|
+-- 新评论
+-- CI 失败
+-- Review 意见
+-- 新提交
|
v
Thread 订阅
|
v
对应 Worker这里有一个非常重要的优化：
后续事件不需要每次都经过 Router 重新理解、重新分配。
这叫事件直通（Direct Delivery）。
它减少了不必要的模型调用，也避免 Router 成为整个系统的性能瓶颈。
2. 快慢双通道：先过滤，再让模型思考
如果 Agent 长期监听群聊，可能会收到大量消息。
假设一个研发群每天有 1000 条消息。
难道每条消息都要调用一次大模型，让模型判断有没有必要处理？
明显不合理。
DeepSeek 的思路是两级过滤：
外部事件流（1000 条消息）
|
v
第一层：程序规则过滤（关键词、来源、订阅关系、规则等）
|
v
第二层：LLM 语义判断（是否存在值得处理的任务？是否需要采取行动？）
|
v
创建任务 / 忽略事件这实际上是一个经典的计算机系统设计思想：
能用便宜的确定性规则解决的问题，就不要交给昂贵的概率模型。
这点对你自己构建 Agent 系统也很有参考价值。
特别是企业级 Agent，不能把所有邮件、消息、业务事件都无差别地塞进 LLM。
3. Inline & Spill：上下文管理不再依赖无限增长的 Prompt
这个设计也值得注意。
Agent 长期运行，必然遇到上下文窗口问题。
假设一个 Worker 已经处理了 100 条消息、调用了 50 次工具，产生了大量中间结果。
如果每次都把所有历史内容塞进上下文：
- Token 成本越来越高。
- 模型需要处理大量无关信息。
- 重要信息容易被淹没。
- 上下文最终会达到窗口上限。
DeepSeek 提出 Inline & Spill 的思路：
- Inline：近期可能使用的信息，直接放入当前上下文。
- Spill：超出预算或不常用的信息，放在上下文之外，需要时再读取。
这有点像操作系统的内存管理。
| 类别 | 数据 | 处理 |
|---|---|---|
| Inline | 热数据：当前任务、近期消息、关键状态 | 直接进入上下文 |
| Spill | 冷数据：历史消息、完整执行记录、低频信息 | 按需读取 |
此外还有 Chain of Recall（链式召回）。
它没有简单地对所有历史消息做一次向量检索，而是通过 Trigger、Thread、Worker Session 等对象之间的关联关系，逐步找回相关历史。
例如：
当前 PR 评论
|
v
PR 对应的 Thread
|
v
Thread 对应的历史任务
|
v
Worker Session
|
v
历史分析和执行结果这种方式有点类似关系数据库里的关联查询。
我觉得这个思路特别值得研究：长期记忆不应该只是一个越来越大的文本库，还应该是一套可追溯、可关联的状态系统。
4. 异步 ReAct Loop：任务执行和用户交互分离
这是一个非常实用的设计。
传统 ReAct Agent 调用工具时，往往是同步等待：
用户提出任务
|
v
Agent 调用工具
|
v
等待工具执行完成
|
v
Agent 继续思考
|
v
返回结果如果某个任务需要执行 10 分钟，用户就可能一直等着。
DeepSeek 提出将耗时操作改成异步模式：
Agent 启动任务
|
v
返回 Started
|
+--------- 用户继续发送新消息
|
+--------- 后台任务继续执行
|
v
执行完成
|
v
产生新事件
|
v
Agent 接收结果也就是说：
Agent 的思考循环，不必被一个耗时工具调用阻塞。
从软件工程角度来看，这其实就是把同步函数调用转换成后台任务与事件通知机制。
需要注意，DeepSeek 特别说明，这项异步任务机制已经在 DeepSeek Harness 中实现，但尚未默认开启。
5. Watchdog：让另一个 Agent 监督 Agent
这个设计尤其有意思。
我们知道，Agent 有时候会陷入死循环：
- 不断重复执行同一条命令。
- 修复一个问题，又引入另一个问题。
- 一直尝试，但始终没有实际进展。
- 任务已经偏离最初的目标。
传统程序可以通过超时、进程状态、异常码进行监控。
但这些规则无法完全判断任务有没有实质进展。
所以 DeepSeek 引入了独立的 Watchdog Session。
它从外部观察 Worker：
- 是否持续取得进展？
- 是否陷入无效循环？
- 是否偏离了原定目标？
- 是否出现异常，需要恢复或重新安排？
它不仅监控程序有没有活着，还尝试判断 Agent 有没有在有效工作。
这与传统操作系统的 Watchdog Timer 有相似之处，但多了语义层面的监督。
当然，这里也有一个问题：监督 Agent 的模型本身也可能判断错误。因此 Watchdog 应该结合确定性规则、运行状态和模型判断，而不能完全依赖另一个 LLM。
四、一个容易被忽略的设计：计算、状态、执行环境分离
这一部分非常有工程价值。
传统本地 Coding Agent：
本地电脑
+-- Agent 进程
+-- Session 状态
+-- 模型调用
+-- 文件系统
+-- 命令执行环境电脑关机，Agent 就无法继续工作。
DeepSeek 希望把它们拆开：
云端
+----------------+
| Agent 计算逻辑 |
| |
| Session 状态 |
| |
| Router/Worker |
+--------v-------+
|
网络通信
|
+----------------+
| 本地执行环境 |
| |
| 文件系统 |
| Shell |
| Git |
| 开发工具 |
+----------------+这里有三个概念：
- Compute：Agent 的计算逻辑。
- State：任务、会话、事件等持久化状态。
- Environment：真正执行命令、访问文件和操作系统的环境。
它们不必部署在同一台机器上。
例如，你可以让 Agent 的大脑运行在云服务器上，而把自己的 Windows 开发机作为执行节点。
即使你关闭本地电脑，云端 Agent 仍然可以继续接收事件、管理任务、等待执行环境恢复。
DeepSeek 把这种方式称为 BYOM（Bring Your Own Machine）。
它还可以使用云端托管机器，或者按需创建计算环境。
这里其实有一个很清晰的架构方向：
Agent 的生命周期不应该与某台物理设备的生命周期绑定。
不过需要注意，云端 Agent 如果拥有本地机器的 Shell、文件和凭据权限，安全边界就变得非常重要。尤其要防止外部消息通过 Prompt Injection 诱导 Agent 执行危险操作。
五、实验数据：它真的比传统 Subagent 快吗？
DeepSeek 做了一组初步实验，对比了四种方案。
| 方案 | p50 | p95 |
|---|---|---|
| Super-agent | 12.4 分钟 | 15.7 分钟 |
| Super-agent（去掉事件直通） | 实验对照 | 实验对照 |
| 单 Session + Subagent（中性提示） | 约 20 分钟 | 29.5 分钟 |
| 单 Session + Subagent（优先派发提示） | 约 14 分钟 | 约 29 分钟 |
数据来自 DeepSeek 团队公布的初步实验，部分数值为文章及相关报道披露的结果。
任务完成时间对比（p95，分钟，数值越低越好）
Super-agent ################ 15.7
单 Session + Subagent ############################## 29.5
优化提示词的 Subagent ############################# 29这里有一个很值得思考的现象。
即使给传统 Subagent 修改提示词，要求它优先派发任务，中位数也从约 20 分钟下降到约 14 分钟，但 p95 仍然接近 29 分钟。
也就是说，提示词优化可以改善平均表现，却不一定能解决系统调度和任务排队的问题。
Super-agent 的 p95 则下降到了 15.7 分钟。
这说明系统架构本身可能比单纯调整 Prompt 更重要。
不过，必须给这组实验加几个限定：
- 实验使用的是合成负载和简化环境。
- 每种方案只重复运行了 5 次。
- 主要衡量调度与协作效率，不是单个 Agent 的编码能力。
- 不能据此认定真实企业研发效率也能提升相同比例。
还有一个很重要的成本问题：
Super-agent 并不是免费获得这些性能提升。
相关实验披露，Super-agent 的缓存读取 Token 达到约 2323 万，而单 Session 对照方案约为 600 多万，接近四倍。
所以它实际上是在用更多的模型调用和系统资源，换取更好的并行能力和任务完成时间。
这对于企业部署尤其重要：不能只看任务完成速度，还要看单位任务成本。
六、开源了什么？能不能自己部署？
dsh-superagent-prototype（DeepSeek Super-agent 开源原型）
DeepSeek 官方 GitHub 仓库 · MIT License；用于验证 Super-agent 技术路线的原型。
项目地址：deepseek-ai/dsh-superagent-prototype
需要区分三个层次：
| 层次 | 状态 |
|---|---|
| Super-agent 架构思想 | 已公开 |
| 内部 Super-agent 实例 | 已用于 DeepSeek 团队日常研发 |
| 开源原型 | 已公开，可以研究和尝试 |
它不是 DeepSeek 发布的一款面向普通用户的正式商业产品。
开源原型主要围绕持续接收事件、Router 调度、Worker 执行和研发协作展开。可以结合 GitHub、飞书等渠道理解它的设计。
如果你想深入研究，我建议优先看：
尤其是第二份文档，可以进一步理解它如何管理 Trigger、Thread、Ticket、Assignment，以及任务状态和事件之间的关系。
这比只看一个 Agent 的 Prompt 更有价值。
七、我的看法：Super-agent 真正重要的是什么？
我觉得这篇文章有三个值得重视的信号。
第一，Agent 正在从 Session 思维转向任务系统思维。
过去我们使用 Claude Code、Codex，通常是一个窗口对应一个任务。
现在越来越多的人开始使用多个 Agent 并行工作。
但问题是，多个 Agent 只是增加了执行能力，并没有自动解决任务管理问题。
Super-agent 的思路是把 Session 变成底层实现细节，把任务、状态、事件和调度提升为系统的一等公民。
这是一个重要的架构转变。
第二，未来 Agent 的竞争力，不仅取决于模型，还取决于 Harness。
这里的 Harness 可以理解为模型外面的运行框架，包括：
- 上下文管理。
- 任务调度。
- 工具调用。
- 异步执行。
- 状态持久化。
- 错误恢复。
- 权限与安全控制。
模型决定 Agent 能不能做好某项工作，Harness 决定它能不能长期、稳定、经济地做好很多项工作。
这也是为什么我认为 DeepSeek 这次公开的内容，比单纯发布一个模型版本更值得开发者研究。
第三，Agent 的主动性是一个很大的机会，但也是一个很大的安全挑战。
以前的 Agent 通常是人下达指令，它才执行。
现在 Agent 开始监听邮件、群聊、代码仓库、日程等外部事件，自己判断是否需要行动。
也就是说，它的权限范围和影响范围都会扩大。
尤其是 Prompt Injection：
假设一个 Worker 在 GitHub Issue 中读取到恶意指令，要求它执行某个 Shell 命令。如果这个 Worker 又拥有生产环境凭据，那么风险就远远超过普通聊天机器人。
所以，真正成熟的 Super-agent 必须有权限隔离、操作审批、审计记录、资源限制和故障恢复机制。
DeepSeek 自己也将安全与隐私列为仍待解决的重要问题。
八、对开发者来说，值得借鉴什么？
我认为可以从一个小型版本开始实践。
不必一开始就做完整的 Super-agent。
可以先实现下面这套架构：
一个简化版 Super-agent
Router（接收事件、意图识别、任务分配）
|
+--> Worker A 代码分析
+--> Worker B 文档处理
+--> Worker C 数据分析
+--> Watchdog 异常监控、任务恢复
基础设施
+-- MySQL / PostgreSQL 持久化任务与状态
+-- Redis / MQ 事件与任务队列
+-- Worker Runtime 独立执行环境
+-- 权限与审计 安全控制我会特别重视以下几个工程原则：
- 任务持久化：Agent 不能只依赖内存中的对话历史。
- 事件驱动：任务完成、失败、收到新消息，都应该变成事件。
- 执行隔离：不同 Worker 不应该随意共享文件和执行权限。
- 幂等与恢复：任务重复触发不能造成重复操作，异常后可以恢复。
- 成本控制：Router 尽量轻量，复杂任务才使用更强的模型。
这些设计不需要依赖某一家模型厂商。使用 OpenAI API、Claude、DeepSeek，甚至本地部署模型，都可以实现类似架构。
最后总结
我认为 DeepSeek 这次最值得关注的，是它提出了一个值得认真研究的方向，而不只是又创造了一个新的 Agent 名词：
AI Agent 的下一阶段，不只是让一个 Agent 更聪明，而是让一群 Agent 能够像一个真正的组织一样持续运作。
过去我们在研究如何让 AI 更好地完成任务。
现在开始需要研究如何让 AI 自己管理任务、协调资源、处理异常，并且长期持续运行。
这两者之间，隔着相当多的软件工程问题。
而这些问题，恰恰是未来 AI 应用基础设施的重要组成部分。
我建议下一步直接研究它的 GitHub 源码，而不只是停留在架构文章。 尤其值得看的是 Router 如何调度 Worker、任务状态如何持久化，以及事件如何在不同 Session 之间传递。这些才是把理论变成可运行系统的关键。