震撼，DeepSeek开源超级 Agent 架构！

大家好，我是小林。

就在昨天，DeepSeek 在 GitHub 上开源了一套全新的 Agent 架构，叫 Super-agent，原型项目是 dsh-superagent-prototype。

开源地址 ：https://github.com/deepseek-ai/dsh-superagent-prototype

要理解 Super-agent 到底是干嘛的，先来想一个问题，你现在电脑上同时开着几个 Agent 窗口？

开一个的话，其实挺舒服的。把任务丢给 Claude Code 或者 Codex，读代码、跑测试、改 Bug 都能自己搞定，你偶尔过去看两眼就行。

但只要同时推进的事情一多，情况就变了。这个窗口在修 Bug，那个窗口在写需求，还有一个在等 CI 结果。你得自己来回切，切回来还得愣一下，这个窗口刚才干到哪了？

这就有点离谱了，对吧？Agent 越能干，人反而成了最忙的那个调度员。

那 Super-agent 想干的事情，说白了就一件，把这些调度的活从你身上拿走。开窗口（也就是 Session）、来回切、补上下文，统统交给系统自己去管。

你看到的始终只有一个 Agent，背后怎么拆任务、派给几个 Agent 并行去做，都由系统自己安排。

这一点让我觉得，Super-agent 很像真正意义上的贾维斯。

接下来，我们就来一起看看 Super-agent 架构到底是什么。

────一、为什么需要 Super-agent？────

开头说的这种困境，DeepSeek 团队给了一个更直观的数据。

现在主流 Agent 还是以单个 Session 为基本单位，Session 之间互相独立，而一个人通常只能同时跟进 3 到 5 个活跃 Session。

他们有一句话总结得很到位，「单任务的上限取决于模型能力，多任务的上限取决于人的注意力」。

看到这估计有同学就问了，给 Agent 接上 CLI、MCP，能收群消息、能看 GitHub，不就行了？

答案是，在本地单会话 Agent 上做这种外挂，消息确实能接进来，但躲不开三个问题。

• 第一个是同步阻塞，单个会话一次只能干一件事，前一个任务没跑完，新消息只能排队。• 第二个是上下文混乱，多个任务的细节全挤在同一个会话里，互相干扰。• 第三个是本地设备一离线就停，电脑合上盖，Agent 也跟着睡了。

这些问题最后还是得靠人工去维护，人的注意力瓶颈一点没少。

────二、Super-agent 到底是什么？────

要突破这些限制，思路是让 Agent 和单次手动会话解绑，变成一个能跨会话保持上下文、同时推进多项任务又互不干扰的「连续实体」。简单来说，不管你在哪个平台找过来，面对的都是同一个 Agent，这个 Agent 记得之前聊过的事，还能同时推进好几件事。

这种 Agent 形态和背后的系统架构，就叫 Super-agent。

光看定义有点抽象，DeepSeek 内部已经跑着一个 Super-agent 实例，有两个真实场景很能说明问题。

第一个场景，同一个开发任务可以在 IM 群聊和 GitHub 之间连续推进。你先在群里说用方案 A，后来在 Pull Request 评论里改口用方案 B，Super-agent 能接上前面的话，调整执行方向。

第二个场景更有意思。Super-agent 会一直看着公共群聊，群里有人反馈问题，哪怕没人 @，Super-agent 也会自己去定位根因，然后提交修复的 Pull Request。

从这两个场景里，可以总结出 Super-agent 的四个基础特征。

• 连续，你在 IM、GitHub 评论这些熟悉的地方说话，感觉对面始终只有一个 Agent，不用去想「这件事我在哪个 Session 里说过」• 高效，响应快，能并行做好多个复杂任务，不用等上一个任务做完才接下一条指令• 主动，不用你一条条下命令，Agent 自己看着环境，值得处理就推进，不需要介入就保持安静• 持久，一直在线，接入你真实的工作环境，出了异常还能自己恢复

现在的 Agent 基本都跑在一个 ReAct Loop 里，也就是模型想一步、调一次工具、看完结果再想下一步，一轮一轮地循环，Claude Code 这类工具也是这么跑的。单靠这样一个循环，撑不起这四个特征，所以这套架构设计了五个模块来支撑。

这五个模块，每个都对应着一两个特征。

1. 双层架构，一个 Router 统一对接人、负责派活，多个 Worker 在背后并行干活，撑起「连续」和「高效」2. 事件驱动，群消息、PR 评论、CI 结果这些事件都能触发 Agent 干活，不用等人下命令，撑起「主动」3. 面向人的交互，后台跑着任务也不耽误前台接新指令，回复方式还会按渠道调整，让「连续」和「高效」落到交互体验上4. 计算、状态与环境的分离，Agent 放在云端跑，状态存进数据库，执行环境留在你自己的电脑上，撑起「持久」5. Watchdog，在系统外面单独盯着，哪个任务卡住或者跑偏了就去修，同样是为了「持久」

先别急着看细节，我们跟着一条消息走一遍，看看整套系统是怎么转起来的。

假设群里有人反馈了一个 Bug。这条消息先经过一道过滤，确认值得处理，再交给 Router。Router 发现这是个新任务，就派一个 Worker 去跟进，之后和这个 Bug 有关的新消息，都直接发给这个 Worker。

Worker 在云端干活，需要跑命令时，通过你电脑上的 daemon 去执行，会话状态都存在数据库里。干完了，Worker 向 Router 汇报，Router 再用适合群聊的方式回复大家。整个过程外面还有一个 Watchdog 盯着，谁卡住了就去修。

DeepSeek 还有一个判断，我觉得很有道理。无论是 Personal Agent 还是软件开发场景，只要目标是做一个一直在线、能同时处理各种外部消息的系统，底层大概率会长成相近的架构。

下面我们就一个个模块来看。

────三、双层架构是怎么分工的？────

下面先来看 Super-agent 架构中最核心的第一个模块，双层架构。回到刚才那条 Bug 消息，Router 和 Worker 到底是怎么分活的？

这里有一对绕不开的矛盾。想让 Agent 什么都记得，最好一个 Session 管到底，想让 Agent 同时干很多事，又得多开几个 Session，这两件事是打架的，也就是连续性和吞吐量的矛盾。

先看两个极端。如果所有事件都交给同一个 Session 处理，上下文是最连续的，但单个 ReAct Loop 只能串行执行，任务一多就排长队，几个任务的中间细节混在一起，还会拖累完成效果。

反过来，每来一条事件就新开一个 Session，并发是上去了，可任务之间往往有关联，各个 Session 缺少全局上下文，结果就会互相割裂。更麻烦的是，好几个 Session 各自回复用户，交互会乱成一锅粥。

解法是把这两件事拆到两层去做。维护全局连续性交给常驻的 Router 层，高并发执行交给上下文隔离的 Worker 层。

Router 层：对接人、负责派活

你可以把 Router 理解成团队里的项目负责人兼对外窗口。

新来的任务都先到 Router 这里，跨任务的信息和决策也在这里汇总，相当于整个系统的协调点和全局记忆。

为了不让这个中心节点变成瓶颈，Router 被刻意设计成不干具体的活，只负责跟人沟通、给 Worker 派活，甚至连 Bash 工具都可以不配。DeepSeek 团队实践下来发现，Router 的活常常没想象中复杂，用较轻量的模型就能兼顾速度和效果。

你以为一个常驻 Session 扛不住所有消息？其实没那么容易成为瓶颈，因为有个天然的批处理效果。

Router 在跑上一轮推理时，新到的事件会先积压起来，等下一轮一起处理。而 Router 每一步要读的东西多、要写的东西少，模型读输入这一步又是可以并行算的，所以一次读 3 条消息和读 1 条，耗时差不了多少。

这就像外卖小哥送餐，单子少的时候一趟送一单，单子一多就顺路一趟带好几单，每单分摊的时间反而少了。Router 也一样，消息越挤，平均每个决定花的时间反而越少。

DeepSeek 做过压测，事件到达速率从每分钟约 1 条升到约 40 条，平均每批从 1.0 条涨到 2.8 条，单次请求耗时只从 2.5 秒涨到 3.9 秒，摊到每个决定上的推理时间从 6.4 秒降到了 1.6 秒。

Worker 层：各干各的，并行推进

Worker 就是真正干活的工程师。每个 Worker 上下文互相隔离，挂着完整的执行工具，在自己的上下文里专心做一件事。Worker 直接决定代码质量，所以一般配最强的模型。

Worker 不直接跟人说话，推理过程和工具调用都关在自己内部，干完活向 Router 汇报，由 Router 统一回复用户。这样并发上去了，用户那边也不会被一堆 Session 的消息刷屏。

对了，Worker 内部还可以再开 Subagent，甚至本身就是一个 Agent Team，这些对 Router 都是透明的。

看到这估计有同学就问了，这不就是常见的 Agent Team 吗？

结构上确实像，侧重点却不一样。Agent Team 主要拆的是单个复杂任务内部的步骤，Team Lead 得深入理解任务细节、高频协调成员，自己的推理负担很重。Super-agent 的 Router 只管任务和任务之间怎么分，不碰单个任务内部怎么拆，负担轻得多。

这一部分还有一个观点挺犀利。底层大模型 API 本来就是按一次次会话设计的，产品照搬过来，就变成了让用户自己开窗口、管窗口。在 DeepSeek 看来，Session 应该是系统内部自己管的事，不该让用户操心。

────四、事件驱动怎么让 Agent 主动干活？────

双层架构解决了连续和高效，那 Agent 没人喊也会干活，又是怎么做到的？

这就是 Super-agent 架构中的第二个模块，事件驱动，管的是消息进入 Router 之前的那一段。

关键在于换掉驱动方式。以前推动 Agent 干活的，是人在 Session 里一条条敲的提示词。到了 Super-agent 这里，驱动 Agent 的变成了环境里的各种事件，群聊消息、**、日程提醒、代码评审评论、CI 运行结果，这些都叫 Trigger。

围绕一条 Trigger 从进来到被处理，要解决四件事。

过滤：筛掉无关信息

接入真实群聊之后会发现，绝大多数消息根本不需要 Agent 插手。要是每条都调大模型从头判断一遍，延迟和成本都扛不住。

这里借用了计算机系统里 Fast Path 和 Slow Path 的思想。简单来说，常见、确定的情况交给又快又便宜的程序直接处理，这是 Fast Path，只有拿不准的少数情况，才交给灵活但贵的大模型，这是 Slow Path。按这个思路，Super-agent 做了两级过滤。

第一级是程序层策略，相当于 Fast Path。按事件来源、群组范围、用户或机器人白名单这些确定性条件，直接用代码判断，比如某个来源只响应明确请求，某个来源直接忽略，在调模型之前就把大部分无关消息筛掉。

第二级是语义层策略，相当于 Slow Path。通过第一级的候选事件交给大模型，按提示词里写的策略和上下文，判断要不要行动。想加一条新策略，改改提示词就行。

路由：找到负责的 Worker

过滤完的事件要发给谁？如果每条都经 Router 转一手，Router 的负担又上去了。

这里引入了一个概念叫 Thread。同一个 Pull Request、同一个 IM 话题、同一串往来**下面的连续事件，就是一条 Thread。

Router 根据某个 Thread 的第一条事件创建 Worker 之后，这个 Worker 会直接订阅这条 Thread。之后同一个 Thread 下的新事件，由程序直接发给已经订阅的 Worker，不再经过 Router。只有还没人订阅的新事件，才轮到 Router 去判断和分派。

你会发现，这里又用上了前面 Fast Path 和 Slow Path 的思路。归属已经确定的事件，走程序直通这条 Fast Path，拿不准该给谁的新事件，才交给 Router 这条 Slow Path。

这个订阅还是多对多的。两个 Worker 改到了同一个 PR，都会收到这个 PR 的新事件，彼此不用点对点通信，也有机会自己发现并解决冲突。

DeepSeek 做过对比实验，去掉直通机制后，Router 要做的决定多了约 30%，token 消耗多了约 37%（统计的是读缓存的 token）。

上下文组织：按需提供相关的信息

事件送到对应的 Session 之后，还得决定往模型的上下文里塞多少信息。

塞多了挤占窗口、分散注意力，塞少了模型又得反复调工具去读。DeepSeek 团队有句话说得好，「浪费上下文窗口，就是浪费模型的智能」。

做法是把上下文窗口当缓存来管，有两个基本操作。Inline 是把近期很可能用到的信息直接塞进窗口，省掉一次工具调用。Spill 是把太长或不常用的内容放在窗口外，窗口里只留引用或摘要，要用再去读。打个比方，常用的资料摊在桌面上，这是 Inline，不常用的放回书柜，桌上只留一张写着位置的便签，这是 Spill。

在这个基础上，还衍生出了链式召回。系统给 Trigger、Thread、Worker Session 这些对象都分配了唯一 ID，每次召回一个对象，结果里又带着下一跳对象的摘要和 ID。这就像网页上的超链接，每一页只放摘要和链接，想看哪个再点进去。用户隔了很久突然提起一个旧任务，Router 就能从当前消息找到所在 Thread，再顺着 ID 找到相关 Worker，顺藤摸瓜，把上下文一点点找回来。

提前行动：后台先试，有用再交付

这是我觉得整篇文章最有意思的一个设计，投机执行。

意思是 Agent 在还不确定结果会不会被采用时，就根据环境信号在后台先试着做。做出来有价值就交付，没价值就扔掉，用一点后台算力，换人更少的等待和介入。

DeepSeek 在内部用户群里配了一条「静默复现并修复」策略。群里有人反馈问题或讨论改动方案时，Agent 先在后台尝试复现、找修复方案，只有确认问题存在、找到了简单的修法，才把结果交给大家，否则全程不吭声。

于是就有了第二章提到的那个场景，群里还在讨论怎么改，Super-agent 已经把修复 PR 提上去了。

放到 Personal Agent 场景也一样。收到一封会议邀约**，Agent 可以先在后台核对日程冲突、搜集相关资料、备好回复草稿，你过目一下就能直接发出。

────五、怎么做到边干活边接新指令？────

接下来是 Super-agent 架构中的第三个模块，面向人的交互。

双层架构从上下文层面保证了连续，可落到实际跟人打交道的时候，还剩两个问题。

第一个是阻塞。经典的 ReAct Loop 里，模型调一次 run() 工具，循环就卡住，直到工具执行完返回结果，这期间你说什么 Agent 都听不到。这就像用对讲机，一方说完另一方才能说，通信里管这叫半双工。

Super-agent 把耗时的命令和子任务调用改成了异步的 start() 和 stop()。模型调 start() 之后马上拿到一个「已启动」的返回，循环继续往下走，后台跑完了，结果再作为一条新事件投递回会话。后台命令跑得太久，模型还能调 stop() 主动停掉。

这样对话就从对讲机变成了打电话，两边可以同时说，也就是全双工。Agent 在后台跑长任务的同时，前台照样能接你的新指令。

第二个是不同渠道该怎么说话。面向单人终端的那套输出直接搬**聊，满屏的推理过程和工具调用，多人协作时谁都受不了。

双层架构已经把冗长的执行过程关在 Worker 里了，在此基础上又按渠道定了规矩。

IM 这类即时渠道讲究低打扰，像同事一样只在需要决策或验收时发消息，DeepSeek 验证过一条简单有效的硬规定，单次回复不超过 100 词。GitHub、**、文档这类异步渠道正好相反，要写结构化、信息密度高的内容，比如 PR 里写清楚问题背景、改动说明和验证结果。

────六、电脑关机了，Agent 还能干活吗？────

最后一个特征是持久，靠的是 Super-agent 架构中的最后两个模块，计算、状态与环境的分离，以及 Watchdog。

存算分离：Agent 上云，环境留在本地

现在的本地 Agent，负责思考和调度的那部分程序（也就是 Agent Loop）、要保存的会话状态、代码仓库和工具链这些执行环境，全绑在同一台电脑上。电脑一休眠，Agent 就停了，也碰不到别的设备上的环境。

这里借鉴了存算分离的思想，分两步拆。

• 第一步，把计算和状态分开。Agent Loop 放到云端无状态的容器里，Session 这些需要持久保存的状态放进数据库。容器可以随时扩容、重启、替换，任务的连续性由数据库来保证，Agent 就不再受某台电脑开关机的影响。• 第二步，把计算和执行环境分开。你可能会想，把代码拉到云端沙箱里跑不就行了？问题是真实的工作环境里有没提交的本地修改、私有凭据、内网服务、特定的硬件和工具链，同步到云上成本高，还容易漏。

既然环境难复制，那就干脆别搬。

Agent Loop 在云端跑，执行环境留在原地，只在设备上装一个不保存会话状态的轻量 daemon，负责执行命令、返回结果。

这个思路和 Anthropic 提出的「脑手分离」是一致的。

「脑」指模型和推进 Agent Loop 的那部分，「手」指沙箱、工具这些执行环境，两边拆开，再通过统一接口按需连接。

区别在于场景，Anthropic 那篇讲的是托管服务里的沙箱，这里首先要接入的是用户天天在用、可能时不时离线的个人电脑，DeepSeek 把这种模式叫 BYOM（Bring Your Own Machine）。

这样一来，Agent 可以在不同设备之间切换执行。某台电脑暂时离线也没关系，等这台电脑重新上线，云端 Agent 再把需要在上面跑的任务接着做完。

Watchdog：盯着系统，跑偏了就修

持久在线还有另一半，出了问题能自己恢复。

说实话，在 Agent 系统里，光看进程活没活着是不够的。很多异常发生时进程活得好好的，真正出问题的是模型陷入了无效循环，或者干着干着偏离了目标。

Super-agent 在主系统外面单独放了一个 Watchdog Session，每隔一段时间就被定时消息叫醒一次，把整个系统巡查一遍。

Watchdog 除了处理接口报错、状态恢复失败这些基础设施故障，还会判断每个 Worker 有没有实质进展、方向有没有跑偏，发现异常就介入修复。

对了，Watchdog 本身也是一个工具齐全的 Agent，维护者有问题可以直接用自然语言问故障原因，也能吩咐 Watchdog 在线改主系统的提示词、调整触发规则。

────写在最后────

当然，这套架构也不是没有短板，DeepSeek 自己列了几个还没解决的问题，我挑三个最关键的说说。

• 第一个是长程记忆。Router 加链式召回能解决近期任务的检索，可一旦运行周期拉到几个月，记忆就会成为最大的瓶颈。• 第二个是安全和隐私。Agent 被更多外部事件驱动，接触不可信输入的风险也更大。云端 Agent Loop 连着各台设备上的 daemon，一旦云端被入侵或者被提示词注入攻破，所有连着的设备都有被控制的风险。就算云端没出事，本地凭据只要进了模型上下文，也有泄露的可能。• 第三个是人和 Agent 怎么协作。Session 被藏到底层之后，用户怎么看各个任务的进度，执行到一半想插手、想接管又该怎么办，这些都得重新设计。DeepSeek 的看法是，大家现在都在聊天窗口里用 Agent，很大程度上只是习惯了，以后的交互可能更多发生在 GitHub Issue、PR 这类贴近工作本身的界面里。

不过话说回来，还记得前面那条 Bug 消息吗？消息先被过滤，再由 Router 派给 Worker，Worker 在云端干活，需要时去你电脑上跑命令，外面还有 Watchdog 盯着进度。

这里面的每一步都谈不上新理论，只是把计算机系统里的经典工程思想用到了 Agent 上。可组合到一起之后，Agent 从一个你问一句才答一句的对话框，变成了一个一直在线、会自己找活干的同事。

最后想深入研究的同学，建议去仓库的 docs 目录翻一翻。从 000-philosophy.md 到 008-cookbook.md 一共 9 篇，开头讲设计理念，结尾给实战用法，顺着读下来，这套架构为什么这么设计、具体怎么落地，基本就摸清楚了。

不管你是想在上面做二次开发，还是在准备 Agent 方向的面试，都值得花时间读一读。