DeepSeek 发布的新架构 Super-agent 是什么，带你认识新理念

大家好，我是程序员天天困。

先给结论：DeepSeek Super-agent 不是一个新模型，是一套回答“谁来管会话”的架构设计。

10 月 31 日晚上，DeepSeek Harness 团队发了篇长文，顺手把一个 GitHub 仓库挂了出来。

当晚技术群里转的标题一个比一个猛：超级智能体来了、AI 开始给 AI 派活。

我把它读完，又对着仓库 README 读了一遍，感觉大部分人是把它当成“DeepSeek 出了个新产品”在看。这不太对。今天这篇就干一件事：把 DeepSeek Super-agent 到底是个什么东西讲清楚，它解决什么、靠什么转、以及哪儿现在还只是个想法。

一、先把话说清楚：DeepSeek Super-agent 不是一个模型

DeepSeek Super-agent：DeepSeek Harness 团队 2026 年 10 月 31 日公开的 Agent 系统架构设计，把「维护会话、同步上下文、分派任务」这些原本压在用户身上的活搬到系统层。它不是模型，也不是一个能装的产品，你更该把它当成一份系统设计文档——只不过作者顺手把代码也开源了。

官方原文的标题是《Super-agent 设计探索：迈向更自主的 Agent 系统》。作者在文首就写了一句很多人会略过的话：这篇谈的是工程实践里的架构思路，并非对现有产品功能的介绍。

这句话是理解全文的前提。

他们把这种 Agent 形态归纳成四个词：

• 连续：你在 IM 里说用方案 A，转头在 PR 评论里改成方案 B，它得接得住。
• 高效：几个复杂任务并行推，不用等上一个跑完才听下一句。
• 主动：没人 @ 它，它也能从群聊里看出“这个问题值得管”。
• 持久：你合上电脑，它还在。

四个词翻译成人话，其实就一句：别让我记住哪个窗口里聊到哪了。

二、它戳的痛点：你不是在写代码，你在当消息总线

这种场景在研发团队里一天要演好几遍：支付群报超时、GitHub 来 review comment、另一个需求的测试还在跑，产品在飞书里问「按钮什么时候上」。

四件事，四个窗口，四份上下文。真正写代码的时间，往往远少于在这些窗口之间搬运信息的时间。

官方原文的说法是：一个人同时能跟住的活跃会话，大概就是 3 到 5 个。超出这个数，你脑子里存的不再是代码，而是“哪件事卡在谁那里”。

一个任务能走多远，看模型；十件事能不能同时推进，看你还剩多少注意力。

现在市面上的 Agent 产品，卷的是上下文窗口多大、能开几个子 Agent、一次能改几个文件。这些当然有用，但它们回答的是“一个任务能做多好”，没回答“十个任务谁来管”。

三、Router 和 Worker：把会话这层拆开，架构就懂了

大多数 Agent 都围着 Session 转：一个会话一个 ReAct Loop，串行。想并行就多开会话，然后自己当调度。

Super-agent 的做法是把这件事劈成两层。

Router（路由层）：常驻的全局入口，所有人类交互先进这里。它维护全局上下文、判断这条消息跟哪件事有关、把任务分派出去。关键在于它不干具体的活——官方原文里甚至说，Router 可以不配 Bash 工具。

这个细节我很喜欢。它不是靠“请勿执行任务”这种提示词约束，而是直接把工具拿掉：能力边界比自我克制可靠。

Worker（工作层）：真正的执行单元，每个 Worker 上下文隔离，挂满工具，专心推进一件事。它不直接跟人说话，状态和结果汇报给 Router，由 Router 统一对外回复。

打个比方，Router 像餐厅的大堂经理：接客、排桌、把单子递进后厨，自己不炒菜。Worker 是后厨各个灶台，各炒各的，炒完喊一声，经理端出去。经理要是自己冲进厨房炒两个菜，门口就没人接客了。

把这条链路画出来，就是下面这样——注意 Worker 之间没有连线，所有对外的话都由 Router 说。

有人会说，这不就是 Agent Team 吗？主 Agent 分派，子 Agent 干活。

区别在负载。常见的 Agent Team 是围绕一个复杂任务拆步骤的，步骤之间耦合紧，主 Agent 得深入细节、规划子任务、高频协调，推理负担很重。Super-agent 的 Router 只处理任务之间的关系，不碰任务内部的拆解，所以官方原文里说它用轻量模型往往就够。

一句话概括分工：Router 管关系，Worker 管细节。

四、事件、Thread、直通：没人 @ 它，它怎么主动干活

主动这件事，本质上是换驱动源。

以前是你往输入框里敲字，Agent 才动。现在驱动它的是环境里半结构化的事件——群消息、PR 评论、CI 结果、邮件。官方原文给这类事件起了个名字。

Trigger（触发事件）：进入系统的环境事件，是 Super-agent 的主要输入，替代了原来由人逐条敲进去的提示词。

但一个工作群一天几千条，全丢给大模型判断，钱和延迟都受不了。所以他们做了两级过滤，思路借的是计算机系统里的快慢路径：

• 程序层先过一遍：来源、群范围、白名单，规则能判的直接拦掉，这是快路径。
• 剩下的交给模型：结合上下文判断值不值得动手，这是慢路径。

Thread（事件流）：同一个 PR、同一个 IM 话题、同一封邮件串下面的连续事件，算一条流。

这里有个我觉得最聪明的设计：直通。Router 给某条 Thread 开了 Worker 之后，这条 Thread 后续的事件由程序直接发给对应的 Worker，不再经过 Router。Worker 能同时订阅多条 Thread，一条 Thread 也能被多个 Worker 订阅——两个 Worker 撞到同一个 PR 上时，都能看到对方的动静，自己解决冲突，不需要点对点通信。

把一条事件从进门到交付摊开，大概是这个走向：

效果有多大？官方原文给了个数：把直通去掉，任务完成时间几乎没变，但 Router 要做的决定多了约 30%，总读缓存 token 从 2323 万涨到 3177 万，涨了约 37%。

这个数比很多跑分都能说明问题：多 Agent 协作出毛病，常常不是模型不聪明，而是架构让一个中心节点扛了不该它扛的流量。

还有几个机制我快速带过：

• Inline & Spill：近期大概率要用的信息直接塞进上下文，超预算的留在窗口外只留引用，模型要用再去读。说白了就是把上下文窗口当缓存管。
• 链式召回（Chain of Recall）：给 Trigger、Thread、Worker Session 都编上 ID，注入时带上关联对象的 ID，这些对象在底层连成一张引用图，模型能顺着 ID 一跳一跳把旧任务捞回来。
• 投机执行：收到会议邀约，先在后台查日程冲突、备好回复草稿；群里有人报 bug，先在后台复现，确认了、也找到简单修法了才说话，否则全程安静。他们内部真配了这么一条“静默复现并修复”的策略。

可能有人会问：没人 @ 它，它凭什么判断该不该管？

靠两层策略叠加。程序层先按来源和范围粗筛，语义层再由模型按提示词里写的策略判断。语义层是纯自然语言的，团队想加规矩，改提示词就行，不用动代码——所以“该不该管”，最后拼的是团队把规则写得有多清楚。

五、为了“一直在”，他们动了三处

前四节讲的是怎么接活，这一节讲怎么不下班。

现在你在本地跑 Agent，有个很土但很致命的问题：电脑一合盖，它就停了。计算、状态、执行环境全绑在一台机器上。Super-agent 分三步处理这件事：

1）异步 ReAct Loop。原来的 run() 是阻塞的，工具不返回，循环就卡着，你发消息它也不理。他们改成异步的 start() 和 stop()：调 start() 立刻拿到“已启动”，循环继续往下走，后台结果跑完再作为一条新事件投进来。这个能力已经在 DeepSeek Harness 里实现了，但没有默认开启——别看到官方原文就以为现在就能用。

2）存算分离。把推进 Agent Loop 的计算放进云端无状态容器，Session 这类要持久化的状态进数据库。容器可以重启、替换、水平扩，连续性由存储兜。

3）计算与执行环境分离。代码、未提交的本地改动、私有凭据、内网服务，这些东西根本没法完整搬上云。他们的选择是让环境留在原地，端上只放一个不保存会话状态的轻量 daemon，只负责执行命令、返回结果。这套设计支持 BYOM（Bring Your Own Machine），也支持云端托管机器。

再加一个 Watchdog：主系统之外单开一个 Session，用定时消息驱动，构成外部控制回路。它不只盯接口报错、状态恢复失败这些基础设施问题，还会让模型判断每个 Worker 有没有实质进展、方向有没有跑偏。发现不对就介入修，偶发故障就持续复查到恢复。

因为 Watchdog 本身也是个有完整工具的 Session，维护者可以直接用自然语言问它“昨天那个 Worker 为什么卡住了”，也能让它在线改主系统的行为，比如增删提示词、调触发规则。

六、那组实验数据，能证明什么，不能证明什么

官方原文给了两组实验。我把设置和结论分开讲，因为传得最广的那半句是被截出来的。

端到端消融：一次实验约 300 条消息，真正算工作请求的只有 20 条上下；剩下的是聊天、催进度、中途喊停，还有一堆 CI 通知。写代码那一步被换成了一个空转耗时的假工具，每种方案跑 5 遍。

p95 从 29.5 分钟到 15.7 分钟，缩短约 47%。

但我觉得更值得看的是中间那段。中性提示下，模型 5 次运行一次都没有主动调 Subagent，所有活都在主会话里干，被新消息不停打断。换成明确鼓励委派的提示词后，5 次里 4 次委派了，还剩 1 次它觉得“这活很小”自己干了，于是结果里多出一根明显的长尾。

同样的模型，同样的工具，只换提示词，协作行为就完全变了。这才是他们要把协调写进架构的真正理由——不是提示词没用，是提示词太不稳。

Router 压测那边：Worker 换成 Mock，把需要判断的 Trigger 从每分钟 1 条加到 40 条。平均 batch 从 1.0 涨到 2.8，单次请求耗时只从 2.5 秒到 3.9 秒，摊到每个决定上反而从 6.4 秒降到 1.6 秒。积压越多、单位成本越低，因为合并后的 Trigger 在 Prefill 阶段并行算了。

不能证明的部分得说清楚：这是合成负载、简化环境、假工具，作者自己也写了“仅作为初步参考”。它衡量的是调度与协作能力，不是这个 Agent 写代码有多强。

所以拿 47% 去说“效率翻倍”，是过度解读。我的判断是：这组数据足以支撑“双层架构比单会话更能扛并发”，但远不足以支撑“你上线就能省一半时间”。

七、开源原型不等于官方原文里的蓝图

这是我最想提醒的一点。

仓库叫 dsh-superagent-prototype，MIT 协议。README 开头写得很直白：仅供参考的研究原型，不是 DeepSeek 官方产品；是研究代码，不是生产级软件；为公开发布做过适配，和团队内部版本、和官方原文里描述的实现都不完全一致，有些设计只停留在方向层面，原型并没有实现。

我对着 README 和官方原文比了一遍，差距主要在这几块：

原型实际能干的活，范围比标题小得多：它只服务一个 GitHub 仓库，监听 GitHub（可选飞书），有人向它要活时开一个 work item，在自己的会话和目录里干，然后回到原对话里回你，比如直接开个 PR。另外有个 web 面板，把需要人处理的事列出来。

所以现在的正确用法是：把它当成一份能跑起来读的架构参考，而不是一套今天就能部署的效率方案。想动手，README 里有一套让 Agent 带着你配的流程；想省事，先别急。

八、我的判断：方向值得盯，工作流先别换

说几个我自己的看法。

这套东西最值得学的不是 Router 和 Worker 这两个词，是它处理“人的注意力”的方式。把 Session 当成实现细节、把用户从会话管理里摘出去，这个视角转换比任何具体模块都重要。你现在用的产品，有几个是围着“这件事做到哪了”设计的，而不是围着“这个窗口聊到哪了”？多数还是后者。

也别被“AI 自己给 AI 派活”这种说法带跑。它接的活仍然被白名单和团队写下的规则框着，开源的这套，来源目前也就 GitHub 和飞书。真实研发上下文散在会议、私聊、线上事故和深夜的电话里，比这两个渠道复杂不止一个量级。短期看程序员的位置没变：你还是在真实世界里收集信息、做判断、把结论喂给 Agent 的那个人。

安全那块是真问题，不是走过场。官方原文自己列了：云端 Agent 接进本地设备之后，提示词注入、端侧凭据泄露、跨设备权限，一个比一个难。他们提的方向是让 Agent 在不接触凭据本身的前提下使用凭据——这话说起来容易，做起来是另一回事。

带限定的判断：以 2026 年 11 月这个时间点看，DeepSeek Super-agent 更像一份写给整个行业的架构提案，而不是你今天装上就能提效的工具。想尝鲜，去读仓库的 README 和 docs；想提效，先把你自己那几个会话的边界理清楚，收益可能更直接。

我是程序员天天困，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：你现在同时开着几个 Agent 会话？看完 DeepSeek Super-agent 这套双层架构，你觉得它真能替你管过来吗？