大家好，我是程序员天天困。
先给结论：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 为什么卡住了"，也能让它在线改主系统的行为，比如增删提示词、调触发规则。
| 维度 | 本地单会话 Agent | Super-agent |
|---|---|---|
| 计算在哪 | 你的电脑 | 云端无状态容器 |
| 状态在哪 | 内存或本地文件 | 持久化数据库 |
| 执行环境在哪 | 同一台机器 | 原地 daemon，可跨设备接入 |
| 关机之后 | 任务停 | 继续跑，设备上线后再补 |
| 谁管会话 | 你 | Router 层 |
六、那组实验数据，能证明什么，不能证明什么
官方原文给了两组实验。我把设置和结论分开讲，因为传得最广的那半句是被截出来的。
端到端消融：一次实验约 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 阶段并行算了。
不能证明的部分得说清楚：这是合成负载、简化环境、假工具，作者自己也写了"仅作为初步参考"。它衡量的是调度与协作能力，不是这个 Agent 写代码有多强。
所以拿 47% 去说"效率翻倍"，是过度解读。我的判断是：这组数据足以支撑"双层架构比单会话更能扛并发"，但远不足以支撑"你上线就能省一半时间"。
七、开源原型不等于官方原文里的蓝图
这是我最想提醒的一点。
仓库叫 dsh-superagent-prototype，MIT 协议。README 开头写得很直白：仅供参考的研究原型，不是 DeepSeek 官方产品；是研究代码，不是生产级软件；为公开发布做过适配，和团队内部版本、和官方原文里描述的实现都不完全一致，有些设计只停留在方向层面，原型并没有实现。
我对着 README 和官方原文比了一遍，差距主要在这几块：
| 官方原文里讲的 | 原型里的情况 |
|---|---|
| Router/Worker 双层、GitHub 与飞书触发 | 有，README 写了 |
| Thread 订阅直通、投机执行 | README 未提 |
| 云端存算分离、BYOM 接本地开发机 | README 未提，属设计方向 |
| 跨实例 A2A 通信、跨月长程记忆 | 官方原文明确列为开放问题 |
原型实际能干的活，范围比标题小得多：它只服务一个 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 这套双层架构，你觉得它真能替你管过来吗？