不是新模型，是架构提案：拆解 DeepSeek Super-agent 的 Router-Worker 设计
10 月 31 日晚，DeepSeek Harness 团队发了篇长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，顺手挂了个 MIT 协议的 GitHub 仓库。当晚技术群的标题一个比一个猛："超级智能体来了""AI 开始给 AI 派活"。
原文读完、仓库 README 也对过一遍，先给结论：DeepSeek Super-agent 不是一个模型，也不是能装的产品，是一份回答 "谁来管会话" 的架构提案——作者在文首就写了一句很多人略过的话：本文谈的是工程实践里的架构思路，并非对现有产品功能的介绍。
一、它戳的痛点：你不是在写代码，你在当消息总线
研发团队的日常：支付群报超时、GitHub 来 review comment、另一个需求的测试还在跑、产品在飞书里问 "按钮什么时候上"。四件事，四个窗口，四份上下文——真正写代码的时间，往往远少于在窗口之间搬运信息的时间。
官方原文给了个数：一个人同时能跟住的活跃会话大约 3 到 5 个。超出这个数，你脑子里存的不是代码，是 "哪件事卡在谁那里"。由此引出全文的核心命题：
一个任务能走多远，看模型；十件事能不能同时推进，看人的注意力。
现在市面上的 Agent 产品卷上下文窗口多大、能开几个子 Agent、一次能改几个文件——这些回答的是 "一个任务能做多好"，没回答 "十个任务谁来管"。
二、Router-Worker：把会话这层劈开
大多数 Agent 围着 Session 转：一个会话一个 ReAct Loop，串行。Super-agent 直接拆成两层：
- Router（路由层）：常驻全局入口，所有人类交互先进这里，维护全局上下文、判断消息归属、分派任务。关键在于它不干具体的活——原文甚至说 Router 可以不配 Bash 工具。这个细节我喜欢：不是靠"请勿执行任务"的提示词约束，而是直接把工具拿掉，能力边界比自我克制可靠。
- Worker（工作层）：执行单元，每个上下文隔离、挂满工具，专心推进一件事，不直接跟人说话，结果统一由 Router 对外回复。
打个比方：Router 是餐厅大堂经理，接客排桌递单子，自己不炒菜；Worker 是后厨灶台，各炒各的。经理要是自己冲进厨房炒两个菜，门口就没人接客了。
有人会说这不就是 Agent Team？区别在负载：常见 Agent Team 是围绕一个复杂任务拆步骤，步骤耦合紧，主 Agent 要深入细节、高频协调，推理负担很重；Super-agent 的 Router 只处理任务之间的关系，不碰任务内部拆解，所以原文说它用轻量模型往往就够。一句话：Router 管关系，Worker 管细节。
三、事件驱动：没人 @ 它，它怎么主动干活
本质是换驱动源。以前是你敲字它才动，现在驱动它的是环境事件——群消息、PR 评论、CI 结果。原文管这叫 Trigger。一个工作群一天几千条，全丢给大模型判断钱和延迟都受不了，所以做了两级过滤，思路借的是计算机系统的快慢路径：程序层按来源 / 群范围 / 白名单先过一遍（快路径），剩下的交给模型结合上下文判断值不值得动手（慢路径）。
Thread（事件流）：同一个 PR、同一个 IM 话题、同一封邮件串下的连续事件算一条流。这里有个我觉得最聪明的设计——直通：Router 给某条 Thread 开了 Worker 后，后续事件由程序直接发给 Worker，不再经过 Router。Worker 能订阅多条 Thread，多 Worker 撞到同一个 PR 上时互相能看到对方动静、自己解决冲突。
去掉直通会怎样？原文给了数：任务完成时间几乎没变，但 Router 要做的决定多了约 30%，总读缓存 token 从 2323 万涨到 3177 万（+37%）。这个数比很多跑分都能说明问题：多 Agent 协作出毛病，常常不是模型不聪明，而是架构让一个中心节点扛了不该扛的流量。
另外几个机制值得记：
- Inline & Spill：近期大概率要用的信息塞进上下文，超预算的留在窗口外只留引用——把上下文窗口当缓存管。
- 链式召回（Chain of Recall）：Trigger、Thread、Worker Session 都编 ID，底层连成引用图，模型顺着 ID 一跳一跳把旧任务捞回来。
- 投机执行：收到会议邀约先后台查日程冲突、备好草稿；群里有人报 bug，先静默复现，确认了、也找到修法了才说话，否则全程安静。内部真配了"静默复现并修复"策略。
四、为了"一直在"，动了三处
本地跑 Agent 有个很土但致命的问题：电脑一合盖它就停了。
- 异步 ReAct Loop：原 run() 是阻塞的，工具不返回循环就卡着。改成异步 start()/stop()，后台结果跑完作为新事件投进来。这个能力已在 DeepSeek Harness 实现，但没有默认开启——别看到原文就以为现在能用。
- 存算分离：推进 Loop 的计算进云端无状态容器，Session 状态进数据库，容器可重启替换，连续性由存储兜。
- 计算与执行环境分离：代码、未提交改动、私有凭据没法搬上云，环境留在原地，端上只放一个不存会话状态的轻量 daemon，支持 BYOM（Bring Your Own Machine）。
再加一个 Watchdog：主系统之外单开 Session、定时消息驱动的外部控制回路。它不只盯接口报错，还让模型判断每个 Worker 有没有实质进展、有没有跑偏。因为它本身是带完整工具的 Session，维护者可以直接用自然语言问它 "昨天那个 Worker 为什么卡住了"。
五、那组实验数据，能证明什么
端到端消融：一次实验约 300 条消息，真正算工作请求的只有 20 条上下，其余是聊天、催进度、CI 通知；写代码那步换成空转耗时的假工具，每种方案跑 5 遍：
| 方案 | 完成时间 p50 | 完成时间 p95 |
|---|---|---|
| Super-agent | 12.4 分钟 | 15.7 分钟 |
| 单 Session + Subagent（中性提示） | — | 29.5 分钟 |
| 单 Session + Subagent（提示优先委派） | 好于中性 | 仍慢于 Super-agent |
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 阶段并行算了。
但限定条件必须跟上：合成负载、简化环境、假工具，作者自己写了 "仅作为初步参考"。它衡量的是调度与协作能力，不是写代码有多强。拿 47% 说 "效率翻倍" 是过度解读——这组数据足以支撑 "双层架构比单会话更能扛并发"，远不足以支撑 "上线就能省一半时间"。
六、开源原型 ≠ 原文蓝图
仓库 dsh-superagent-prototype，MIT 协议，README 开头就摊牌：仅供参考的研究原型，不是 DeepSeek 官方产品；和团队内部版本、和原文描述的实现都不完全一致，有些设计只停留在方向层面，原型并没有实现。对比下来：
- Router/Worker 双层、GitHub 与飞书触发——有；
- Thread 订阅直通、投机执行——README 未提；
- 云端存算分离、BYOM 接本地机——README 未提，属设计方向；
- 跨实例 A2A 通信、跨月长程记忆——原文明确列为开放问题。
原型实际能干的活比标题小得多：只服务一个 GitHub 仓库，有人要活时开个 work item，在自己的会话和目录里干，完事开个 PR 回你，外加一个 web 面板列待办。正确用法是把它当能跑起来读的架构参考，不是今天就能部署的效率方案。
七、我的判断
- 最值得学的不是两个词，是视角转换：把 Session 当实现细节、把用户从会话管理里摘出去。你现在用的产品，有几个是围着"这件事做到哪了"设计的，而不是围着"这个窗口聊到哪了"？多数还是后者。
- 别被"AI 给 AI 派活"带跑：它接的活仍被白名单和团队写下的规则框着，开源这套来源目前也就 GitHub 和飞书。真实研发上下文散在会议、私聊、线上事故里，复杂不止一个量级。程序员的位置没变：你还是在真实世界收集信息、做判断、把结论喂给 Agent 的那个人。
- 安全是真问题：原文自己列了——云端 Agent 接进本地设备后，提示词注入、端侧凭据泄露、跨设备权限一个比一个难。他们提的方向是"让 Agent 不接触凭据本身却能使用凭据"，说起来容易，做起来是另一回事。
- 带限定的结论：以 2026 年 11 月这个时间点，DeepSeek Super-agent 更像一份写给整个行业的架构提案，不是今天装上就能提效的工具。想尝鲜去读仓库 README 和 docs；想提效，先把你自己那几个会话的边界理清楚，收益可能更直接。
资料来源：DeepSeek Harness 团队《Super-agent 设计探索：迈向更自主的 Agent 系统》（2026-10-31）、开源仓库 dsh-superagent-prototype README，及公开解读文章（阿里云开发者社区，2026-11-03）。