震撼，DeepSeek又上大招Super-agent，硬刚Claude的单会话模式

技术宅 2026.11.03 阅 1,682 约 15 分钟

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

看到这个消息的第一反应是：又一个 Agent 框架？但把文档读完会发现，它想解决的其实是一个很朴素的问题——当 Agent 越来越能干，人怎么反倒成了最忙的那个调度员。

人成了系统里最慢的那一环

先想一个场景：你电脑上现在同时开着几个 Agent 窗口？

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

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

DeepSeek 团队给了一个很准的数字：现在主流 Agent 以单个 Session 为基本单位，Session 之间互相独立，而一个人通常只能同时跟进 3 到 5 个活跃 Session。

「单任务的上限取决于模型能力，多任务的上限取决于人的注意力。」

这句话基本就是整套架构的出发点。

有人会问，给 Agent 接上 CLI、MCP，能收群消息、能看 GitHub，不就行了？答案是：在本地单会话 Agent 上做这种外挂，躲不开三个问题。

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

这三件事最后还得靠人工去维护，人的注意力瓶颈一点没少。

Super-agent 想做成什么

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

DeepSeek 内部已经跑着一个实例，有两个场景很能说明问题。

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

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

从这两个场景能总结出四个基础特征：

连续——你在 IM、GitHub 评论这些熟悉的地方说话，感觉对面始终只有一个 Agent
高效——响应快，能并行做好多个复杂任务，不用排队
主动——不用你一条条下命令，Agent 自己看着环境，值得处理就推进
持久——一直在线，接入真实工作环境，出了异常还能自己恢复

现在的 Agent 基本都跑在一个 ReAct Loop 里：模型想一步、调一次工具、看完结果再想下一步。单靠这样一个循环，撑不起上面四个特征。所以这套架构设计了五个模块来支撑——双层架构、事件驱动、面向人的交互、存算分离、Watchdog。

双层架构：Router 派活，Worker 干活

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

两个极端都不行。所有事件交给同一个 Session，上下文最连续，但单个 ReAct Loop 只能串行执行，任务一多就排长队，几个任务的细节还混在一起。反过来每来一条事件就新开一个 Session，并发上去了，可各 Session 缺少全局上下文，结果互相割裂，而且好几个 Session 各自回复用户，交互会乱成一锅粥。

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

Router 像团队里的项目负责人兼对外窗口。新任务都先到这里，跨任务的信息和决策也在这里汇总。为了不让这个中心节点变成瓶颈，Router 被刻意设计成不干具体的活，只负责跟人沟通、给 Worker 派活，甚至连 Bash 工具都可以不配。实践下来发现，用较轻量的模型就能兼顾速度和效果。

一个常驻 Session 为什么扛得住所有消息？因为有个天然的批处理效果。Router 在跑上一轮推理时，新事件会先积压，等下一轮一起处理。而 Router 每一步读的东西多、写的东西少，模型读输入这一步又能并行算，所以一次读 3 条和读 1 条，耗时差不了多少。

这就像外卖小哥送餐：单子少的时候一趟送一单，单子一多就顺路带好几单。

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

Worker 就是真正干活的工程师。每个 Worker 上下文互相隔离，挂着完整执行工具，专心做一件事。它直接决定代码质量，所以一般配最强的模型。Worker 不直接跟人说话，干完活向 Router 汇报，由 Router 统一回复——这样并发上去了，用户那边也不会被一堆消息刷屏。

看到这儿会有人说，这不就是常见的 Agent Team 吗？结构上确实像，侧重点不同。Agent Team 主要拆的是单个任务内部的步骤，Team Lead 得深入理解任务细节、高频协调成员，推理负担很重。Super-agent 的 Router 只管任务和任务之间怎么分，不碰单个任务内部怎么拆，负担轻得多。

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

事件驱动：从「人敲提示词」到「环境推着走」

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

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

接入真实群聊后会发现，绝大多数消息根本不需要 Agent 插手。要是每条都调大模型从头判断，延迟和成本都扛不住。所以这里借用了计算机系统的 Fast Path 和 Slow Path 思想：常见确定的情况交给又快又便宜的程序处理，只有拿不准的少数情况才交给大模型。

过滤因此分两级。第一级是程序层策略，按事件来源、群组范围、用户白名单这些确定性条件用代码判断，在调模型之前就把大部分无关消息筛掉。第二级是语义层策略，把候选事件交给大模型，按提示词里写的策略判断要不要行动——想加新策略，改提示词就行。

过滤完发给谁？这里引入了 Thread 概念：同一个 Pull Request、同一个 IM 话题、同一串往来邮件下的连续事件，就是一条 Thread。Router 为某条 Thread 的第一条事件创建 Worker 后，这个 Worker 会直接订阅这条 Thread。之后同一 Thread 的新事件由程序直接发给它，不再经过 Router。

归属已确定的事件走程序直通这条 Fast Path，拿不准的才交给 Router 这条 Slow Path。这个订阅还是多对多的——两个 Worker 改到同一个 PR，都会收到新事件，彼此不用点对点通信，也有机会自己发现并解决冲突。

DeepSeek 做过对比实验：去掉直通机制后，Router 要做的决定多了约 30%，token 消耗多了约 37%。

把上下文窗口当缓存来管

事件送到对应 Session 之后，还得决定往模型上下文里塞多少信息。塞多了挤占窗口、分散注意力，塞少了模型又得反复调工具去读。

「浪费上下文窗口，就是浪费模型的智能。」

做法有两个基本操作。Inline 是把近期很可能用到的信息直接塞进窗口，省掉一次工具调用；Spill 是把太长或不常用的内容放在窗口外，窗口里只留引用或摘要。

打个比方：常用的资料摊在桌面上，这是 Inline；不常用的放回书柜，桌上只留一张写着位置的便签，这是 Spill。

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

投机执行：先偷偷做好，有用再交付

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

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

于是就有了前面那个场景——群里还在讨论怎么改，修复 PR 已经提上去了。

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

全双工：边干活边接指令

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

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

这样就从对讲机变成了打电话，两边可以同时说。

另一个问题是不通渠道该怎么说话。面向单人终端的输出直接搬进群聊，满屏推理过程和工具调用，多人协作谁都受不了。所以按渠道定了规矩：IM 这类即时渠道讲究低打扰，只在需要决策或验收时发消息，DeepSeek 验证过一条硬规定——单次回复不超过 100 词；GitHub、邮件这类异步渠道正好相反，要写结构化、信息密度高的内容。

电脑关机了，Agent 还能干活吗

最后一个特征是持久，靠的是存算分离和 Watchdog。

现在的本地 Agent，负责思考调度的 Agent Loop、要保存的会话状态、代码仓库和工具链，全绑在同一台电脑上。电脑一休眠，Agent 就停了。

这里借鉴存算分离，分两步拆。第一步，把计算和状态分开：Agent Loop 放到云端无状态容器，Session 这些需要持久保存的状态放进数据库。容器可以随时扩容、重启、替换，连续性由数据库保证。

第二步，把计算和执行环境分开。有人会想，把代码拉到云端沙箱跑不就行了？问题是真实工作环境里有没提交的本地修改、私有凭据、内网服务、特定硬件和工具链，同步到云上成本高还容易漏。

既然环境难复制，那就干脆别搬。Agent Loop 在云端跑，执行环境留在原地，只在设备上装一个不保存会话状态的轻量 daemon，负责执行命令、返回结果。

这个思路和 Anthropic 提出的「脑手分离」是一致的：脑指模型和 Agent Loop，手指沙箱、工具这些执行环境，两边拆开再通过统一接口按需连接。区别在场景——Anthropic 讲的是托管服务里的沙箱，这里首先要接入的是用户天天在用、可能时不时离线的个人电脑。DeepSeek 把这种模式叫 BYOM（Bring Your Own Machine）。

还有另一半：出了问题能自己恢复。在 Agent 系统里，光看进程活没活着是不够的——很多异常发生时进程好得很，真正出问题的是模型陷入无效循环，或者干着干着偏离了目标。

所以主系统外面单独放了一个 Watchdog Session，每隔一段时间被定时消息叫醒，把整个系统巡查一遍。除了处理接口报错、状态恢复失败这些基础设施故障，还会判断每个 Worker 有没有实质进展、方向有没有跑偏。Watchdog 本身也是个工具齐全的 Agent，维护者可以用自然语言问它故障原因，也能吩咐它在线改提示词、调整触发规则。