DeepSeek Super-agent 技术文档：Router+Worker 如何把「人管会话」换成「系统管会话」
Router+Worker 双层 · 事件直通省 30% 决策 · 12.4 分钟实测的边界 · 开源原型≠可上生产
| 厂商 | DeepSeek（Harness 团队） | 分类 | 开源框架 |
|---|---|---|---|
| 发布 | 2026-10-31 晚（技术文章 + 原型开源） | 形态 | Agent 编排架构（非模型、非成品） |
| 架构 | Router + Worker 双层 | 许可 | MIT（研究原型） |
| 定位 | 官方明确：面向工程实践的架构探讨，不是正式产品，不可直接上生产 | ||
| 入口 | github.com/deepseek-ai/dsh-superagent-prototype | ||
一、它是什么：一次「架构公开」，不是一次「产品发布」
先把预期校准。这波发布里没有新模型、没有可下载的客户端，只有两样东西：一篇讲设计取舍的技术文章，和一份 MIT 许可的原型代码。文章标题里的「迈向更自主」是方向，不是完成度。
它要解决的问题很具体：单个任务上 AI 已经不太需要人盯了，但人能同时跟进的活跃会话仍然只有 3 到 5 个。多任务的上限，已经从「模型能力」转移到了「人的注意力」。这个判断决定了整套设计的方向 —— 不是让模型更聪明，而是让系统替人记住「哪件事进行到哪一步」。
它不是什么
- 不是模型：文章谈论的是编排，模型能力被当作已经足够的前置条件。
- 不是成品：官方明确公开版本与内部版本有差异，部分特性仍在开发。
- 不是「让一个 Agent 更强」：它优化的是多个任务之间的调度与不干扰，单任务场景看不出差别。
二、Router + Worker：两层各自负责什么
整篇文章的骨架就是这个两层结构。把它拆成「谁接收、谁执行、上下文怎么隔离」，很多宣传语就自然落地了：
| 层 | 职责 | 状态 | 关键约束 |
|---|---|---|---|
| Router | 统一接群聊 / GitHub / 邮件等渠道消息，维护共享上下文，判断该不该派活、派给谁 | 常驻运行 | 它一停，所有渠道同时失联 |
| Worker | 各自持有独立上下文，并行做问题复现、代码审查、功能开发 | 按任务起停 | 上下文隔离，互不污染 |
| Subagent | Worker 在执行中再向下拆分出的子任务 | 按需 | 层级越深，可观测性越差 |
这个拆分最容易被忽略的一点是上下文隔离。传统单会话方案里，多个任务共享同一段对话历史，任务一多就互相干扰：改 A 的代码时，B 的报错信息还留在上下文里。Worker 各自持独立上下文，本质上是把「上下文污染」这个工程问题用进程隔离的方式消掉了 —— 这也解释了为什么它敢让多个任务并行。
三、四个设计目标，各自对应哪个机制
官方把目标归纳成四条：连续性、效率、主动性、持久性。这四条不是形容词，每一条背后都有一个具体机制，也各自带来一种新的失败模式：
| 目标 | 对应机制 | 新增的失败模式 |
|---|---|---|
| 连续性 | 同一个 Agent 跨消息平台与编码平台工作，状态不随会话结束而丢 | 状态存哪、存多久、谁能读 —— 变成新的权限问题 |
| 效率 | 多 Worker 并行，任务之间不排队 | 并发峰值 → token 尖峰；两个 Worker 改同一处代码会冲突 |
| 主动性 | 事件驱动 + 两级过滤：没人 @ 也能从群聊里识别潜在缺陷 | 误报会变成噪音，噪音多了人就不看通知了 |
| 持久性 | 外部监控 Watchdog，长任务可跨天、可从中断中恢复 | 恢复点选错 = 重复执行有副作用的动作 |
四个目标里，「主动性」是最需要设边界的一个。文章举的例子是：开发者在群里讨论一个疑似 Bug，Agent 在没有被点名的情况下自己复现、自己找修复方案，方案可行就交给人，没结果就保持安静。这套「有结果才说话」的抑制逻辑是设计的核心 —— 因为主动型 Agent 一旦开始刷「我看到了但没搞定」的通知，几天之内就会被全员静音。
四、事件直通：为什么它是成本结构，不是优化项
这套设计里最有工程价值、也最少被转述的细节，是「订阅与直通」。Worker 接手一个 GitHub PR 之后，可以直接订阅该 PR 的后续评论：有人提修改意见，消息直接进这个 Worker，不必再绕回 Router 层层转发。
官方给的对照数据很能说明代价：取消事件直通后，Router 的决策次数增加约 30%，读取缓存 Token 增加约 37%。这两个数字的含义是 —— 直通省下的不是「一点点延迟」，而是每一次消息都要过一遍全局调度器所带来的决策开销与重复上下文读取。
| 路径 | 消息怎么走 | 成本特征 |
|---|---|---|
| 有直通 | PR 评论 → 订阅它的 Worker 直接处理 | Router 决策少、缓存复用高 |
| 无直通 | PR 评论 → Router 判断 → 再转给某个 Worker | 决策 +30%、缓存 token +37% |
所以自建时如果为了「结构简单」把这层砍掉，账单会替你把这层补回来。这也是本文认为它最值得抄的一点：多 Agent 系统的成本，大半花在「消息怎么路由」上，而不是「模型怎么回答」上。
五、12.4 分钟这组数字，能说明什么、不能说明什么
官方在模拟多任务环境下给出的初步实测：任务完成时间中位数 12.4 分钟，95 分位 15.7 分钟；对照组是传统单 Session 方案在「中性提示」下 95 分位 29.5 分钟。
能说明的是长尾被压掉一半以上：中位数和 95 分位贴得很近（12.4 vs 15.7），说明慢任务没有拖出长尾 —— 这正是并行 + 独立上下文的直接效果。不能说明的是绝对值：模拟环境的任务构成、消息噪声、失败重试都和真实工程不同，把 12.4 分钟当成「你的任务会这么快」是误读。
正确的读法是横向比：同一套测试里，两种方案的 95 分位差了近一倍，这个相对差距比绝对数字可靠得多。评估任何多 Agent 方案时都可以套这个问法 —— 别看它平均多快，看它最慢的那 5% 有多慢。
六、自建步骤（按原型能跑通的最小路径）
- 先只上 Router，不接 Worker：让它把多渠道消息收进来、判断该不该派活，人工确认它的判断准不准。这一步跑不通，后面全是空中楼阁。
- 接一个 Worker，只做只读任务：例如「复现问题并给出原因分析」，不写代码、不改配置。先验证上下文隔离是否真的干净。
- 加第二个 Worker，制造一次冲突：让两个任务碰同一处代码，观察系统怎么处理冲突。这是并行方案真正的分水岭，别等到生产才发现。
- 打开事件直通：让 Worker 订阅它负责的那条 PR/issue 的后续消息，对比开关前后的 Router 决策次数与缓存命中。
- 最后才开主动性：先只在内部群、只对一个明确的问题类型开启「无人 @ 也能介入」，并设好「没结果就闭嘴」的抑制阈值。
七、成本账：钱花在哪三项上
| 项 | 性质 | 怎么算 |
|---|---|---|
| 代码 | MIT 开源，免费 | 0 |
| Router 常驻 | 持续开销 | 按「每天 24 小时都在读消息」估，而不是按「问了几次」估 |
| Worker 并发 | 尖峰开销 | 峰值并发数 × 单任务上下文长度；并行越多，尖峰越高 |
| 路由损耗 | 隐性开销 | 取消直通 = 决策 +30%、缓存 token +37%（官方对照数据） |
| 运维 | 人力 | 凭据（GitHub / IM / 邮件）管理、Watchdog 告警、失败重放 |
算账要点：这类系统的账单不是「按次」的，是「常驻 + 尖峰」的。用「一次任务多少钱」的思路去估，会系统性低估 —— 因为 Router 在你睡觉的时候也在烧钱。具体单价按站内 DeepSeek 模型价格页现价折算；缓存命中价与输入价差得远，这也是为什么「直通」那 37% 的缓存差异值得单独算。
八、和同类方案的差别
| 维度 | DeepSeek Super-agent | Claude Code 的子 Agent | 千问 Go! / 灵光 2.0 |
|---|---|---|---|
| 形态 | 开源编排架构（原型） | 产品内置能力 | 成品 App 功能 |
| 调度层 | 独立常驻 Router | 主会话内派生 | 平台侧托管 |
| 触发方式 | 消息事件 + 主动识别 | 主 Agent 调用 | 用户提需求 / 授权后主动 |
| 能否自建 | 可以（MIT） | 不能 | 不能 |
| 上手成本 | 高（要自己接渠道、管凭据） | 低 | 最低 |
差别最大的是第一行和第四行：它是唯一一套「你可以自己拥有调度层」的方案。代价也很诚实 —— 渠道接入、凭据管理、冲突处理、Watchdog 告警，全都得你自己做。想要开箱即用，这一列不是给你的。
九、四个坑
- 把它当产品等下载。没有客户端、没有安装包，只有文章和原型代码。等「Super-agent App」会一直等不到。
- 拿原型上生产。官方自己写了「非生产可用、与内部版本有差异、部分特性开发中」。这句话不是免责声明，是使用说明。
- 砍掉事件直通求简单。省下的结构复杂度，会以 30% 决策与 37% 缓存的形式回到账单上。
- 先开主动性再设抑制。顺序反了，团队会在三天内把它静音，然后这套系统就废了 —— 主动性一旦被当成噪音，再难恢复信任。
十、常见问题
Super-agent 是 DeepSeek 发布的新模型吗？
不是。它是一套系统架构方案，由 DeepSeek Harness 团队在 2026-10-31 晚的技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》中公开，底层仍然调用 DeepSeek 已有的模型。开源出去的也是编排原型的代码，不是权重。所以「Super-agent 有多强」这个问法本身不成立 —— 该问的是「用这套编排，同样的模型能多干成多少事」。
它和 DeepSeek Harness 是什么关系？
Harness 是 2026-08-13 发布的插件化 Agent 框架（MIT 开源，模型/工具/技能/会话/沙箱全部可替换），是底座；Super-agent 是跑在这个底座之上的编排层方案 —— 解决的不是「怎么调工具」，而是「多个任务、多个会话、多个渠道怎么被一个人管住」。团队在文中说明，基于该架构的内部实例已经在日常研发中运行，参与问题修复、代码审查响应，以及 Harness 自身的迭代。
开源了吗？现在能直接拿来用吗？
代码已开源（MIT 许可，研究原型 dsh-superagent-prototype），但官方明确说明：不是正式产品，也不具备生产可用性，公开版本与内部实际运行的版本存在差异，文中描述的部分特性仍在开发中。所以正确用法是「读设计、抄结构、做实验」，而不是「接进生产流水线」。这条边界官方自己划得很清楚，别被二手转述抹掉。
Router 和 Worker 具体分工是什么？
Router 是常驻的全局协调节点：统一接收群聊、GitHub、邮件等多渠道消息，维护共享上下文，判断一条消息该不该变成任务、派给谁。Worker 各自维护独立上下文，并行执行问题复现、代码审查、功能开发等具体工作，需要时还能再调用 Subagent。关键差别在于：用户面对的是同一个 Agent，底层有多个会话在跑，而这些会话的管理不经过人。
12.4 分钟是怎么测出来的，可信吗？
出自官方在模拟多任务环境下的初步实测：任务完成时间中位数 12.4 分钟，95 分位 15.7 分钟；对照组是传统单 Session 方案在「中性提示」下 95 分位 29.5 分钟。可信的部分是同一套测试里两个方案的相对差距（长尾被压掉一半以上）；不可信的部分是把它当绝对值 —— 模拟环境不是真实工程，任务构成、消息噪声、失败重试都和线上不同。
自己跑起来贵吗？成本落在哪？
代码 MIT 免费，钱花在三处：① Router 常驻意味着即使没人提需求它也在跑，是持续开销；② Worker 并行执行会把 token 消耗从「一条平滑曲线」变成「并发尖峰」；③ 取消事件直通后 Router 决策次数增加约 30%、读取缓存 Token 增加约 37% —— 直通不是优化项，是成本结构的一部分。具体单价按站内 DeepSeek 模型页现价折算，别用本文数字替代。
十一、继续看
同门的底座框架见 DeepSeek Harness 技术文档（插件化架构、与 Claude Code / Codex 的对照）；同样在解决「多任务并行」的产品化路线，见 千问 App 与 蚂蚁灵光 2.0。开源框架横向对比看 AI Agent 大全 的「开源框架」分类。