拆解 DeepSeek 全新 Super-agent 架构：为什么 Agent 的终极瓶颈是人的注意力？
大家好，我是不会喷火的小火龙。
用上 Claude Code 或 Codex 之后，不知道你有没有经历过这种崩溃瞬间：
单开一个窗口让 AI 写功能、修 Bug，体验确实爽飞。于是你胆子大了，试图化身“多线程时间管理大师”，在桌面上同时开了五六个终端 Session 窗口并行推进。
十分钟后，噩梦开始了。
窗口 1 卡在半路等你点权限审批；窗口 2 跑单测报错陷入死循环；窗口 3 和窗口 4 正在静默修改同一个核心文件，眼看就要撞出巨大的合并冲突；而窗口 5 聊着聊着早就忘了你在窗口 1 刚刚敲定的接口规范。
你原本是个写代码的程序员，结果硬生生退化成了在十几个聊天框之间来回切换、人工同步上下文的“路由器”。
就在最近（10 月 31 日晚），DeepSeek Harness 团队发表了一篇重磅技术长文《Super-agent 设计探索：迈向更自主的 Agent 系统》（IT之家全文实录），并同步以 MIT 协议开源了研究原型 dsh-superagent-prototype。
文章里有一句极其一针见血的判断：
“单任务的上限取决于模型能力，多任务的上限取决于人的注意力。”
根据 DeepSeek 团队的实测观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。一旦超过这个阈值，人类的认知负荷就会彻底拉满。
如下图所示，要打破这个僵局，唯一的出路就是把繁琐的会话编排与上下文同步从人手上夺过来，下沉到系统底层：
这篇文章，我想带你深入扒一扒 DeepSeek 这套全新的 Super-agent 架构：为什么靠写 Prompt 调不好多 Agent 协作、Router + Worker 双层解耦是怎么跑通的、以及它如何把经典的计算机操作系统思想搬进 Agent 运行时。
一、为什么“单 Session + Subagent 提示词”在真实工程里频频翻车？
聊新架构之前，很多熟悉 Claude Code 的同学肯定会问一个问题：
“现在的 Coding Agent 不都内置了 Subagent（子智能体）工具吗？我在系统提示词里写一句‘遇到复杂任务或并行请求时，请主动调用 Subagent 处理’，不就解决多任务问题了？”
听起来很合理。但 DeepSeek 团队直接做了一组对照实验，结果非常打脸（MindStudio 拆解）。
在一段包含约 300 条群聊与 GitHub CI 消息流（其中夹杂着约 20 个真实工作请求）的测试环境里，研究人员给单 Session Agent 配了一段中性提示词——建议它在合适的时候使用 Subagent 工具。
连续跑了 5 轮实验，你猜模型调用了几次 Subagent？
0 次。一次都没有。
所有的工作请求全被主模型揽在主会话里串行硬扛，中途还不断被新涌入的群消息打断，导致 p95 任务完成耗时高达 29.5 分钟（MarkTechPost 报告）。
即便研究人员把提示词改成了强推委派（明确敦促它必须派活），在 5 轮测试里依然有 1 轮，模型临场判断“这活儿不大，我自己顺手干了就行”，结果再次把主会话卡死。
这个实验揭示了一条非常核心的工程铁律：
任务委派（Delegation）必须是系统结构层面的硬约束，绝不能寄希望于自然语言 Prompt 的软劝说。
只要一个 Agent 手里同时握着“跟人聊天”的麦克风和“写代码跑命令”的锤子，它在概率上就极易产生自己动手的冲动。
更深层的问题在于，现有主流 Agent 把单一 Session 当作基本工作单位，本质上只是在延续底层 LLM API 的设计惯性。正如 DeepSeek 团队所指出的（OSCHINA 拆解）：
“Session 应当是系统的实现细节，而不应是用户的认知负担。”
二、Router + Worker 双层解耦：把“全局连续性”和“高并发执行”彻底拆开
既然单个 Session 扛不住多任务，那如果每来一条外部消息就新开一个独立 Session 呢？
这会陷入另一个极端。我们来算一下这笔架构账：
1）所有事件塞进同一个大 Session：全局上下文最连续，AI 记得你说过的每一句话；但受限于单个 ReAct Loop 的串行阻塞，吞吐率极低，不同任务的中间报错和代码细节还会互相污染。 2）每条事件都新开独立 Session：并发拉满了，但不同任务之间彻底失忆；而且人类要同时面对七八个 Agent 窗口的提问和汇报，注意力照样原地爆炸。
看懂了这个死结，你就看懂了 Super-agent 最核心的洞察：
“维护全局上下文连续性”和“高并发隔离执行”是两件完全冲突的事，根本不该由同一层来承担。
为此，DeepSeek 设计了 Router + Worker 双层解耦架构。如下图所示，两层各司其职，边界极其干净：
这套双层设计有三个非常精妙的工程细节：
1. 物理拔掉 Router 的“手”，逼它专心当主管
在 Super-agent 中，Router 层是一个长期常驻的全局会话。无论你在飞书群聊、GitHub PR 评论还是邮件里找它，始终是这同一个 Router 在跟你对话，保证了跨平台交互的连续性。
但为了彻底根治它“自己撸袖子写代码”的毛病，DeepSeek 直接在工具集层面做了物理阉割——Router 甚至可以不配备 Bash 等具体执行工具（在开源原型中使用受限的 dsh-superagent-router 预设）。它手里没有锤子，唯一的出路就是把任务打包成一张带不可变授权契约（Mandate）的工单（Ticket），分派给下层的 Worker。
2. Worker 只干活不接客，对外永远只有一个声音
每个 Worker 领到一张 Ticket 后，会在完全隔离的上下文和独立工作目录中启动（使用 dsh-superagent-worker 预设），并发执行写代码、跑单测、提 PR 等重度任务，必要时还能继续调用它自己的 Subagent。
关键规矩在于：Worker 绝不直接跟人类说话。 它们只向 Router 汇报进展和最终产物，再由 Router 统一组织语言回复给人类。对开发者来说，你永远只需要跟一个清爽的管家对话，背后到底跑了 3 个还是 30 个 Worker，全被系统屏蔽了。
3. 反常识的模型选型反转
平时我们设计多 Agent 系统，总习惯拿最贵、最强的旗舰模型当“主控大脑（Lead Agent）”，拿便宜模型当干活的小弟。
但 DeepSeek 发现，在 Router + Worker 架构下，这个逻辑刚好反过来（MindStudio 拆解）：
Router 这里并不需要把复杂代码拆解成十几个微步骤，它只负责理解对话意图、判断任务归属和跟踪状态——这项工作其实没想象中复杂，用轻量、低延迟的高性价比模型就能干得又快又好；反而是真正下场写代码、修 Bug 的 Worker，才应该把好钢用在刀刃上，挂载推理能力最强的旗舰模型。
三、把 Agent 当成“操作系统”来写：6 个教科书级的经典工程设计
如果只有 Router + Worker 双层拆分，把这样一个 Agent 扔进真实的团队飞书群和 GitHub 仓库里 24 小时常驻，不出半天就会遇到三大灾难：群聊废话把 Token 烧穿、上下文窗口被历史记录撑爆、长耗时任务把对话卡死。
DeepSeek Harness 团队最让我佩服的地方在于：他们没有造一堆玄乎的 AI 新词，而是把计算机操作系统（OS）和体系结构里验证了几十年的六个经典工程思想，原封不动地搬进了 Agent 架构（OSCHINA 拆解）。
如下图所示，这就是一条外部环境事件进入 Super-agent 后的完整操作系统级流水线：
我们逐个拆开来看，每一个都是能直接抄进自己项目里的干货：
1）事件驱动与 Fast / Slow Path 两级过滤
要让 Agent 从“等你提问”变成“主动干活”，第一步是把输入从 Prompt 变成外部环境事件（Trigger）——群聊消息、邮件、日程提醒、PR 评论、CI 报错全是 Trigger。
但真实的研发群聊是典型的“高噪音、低触发率”场景，95% 的日常闲聊和表情包根本不需要 AI 插嘴。如果每条消息都调一次大模型去判断，延迟高不说，API 账单直接原地起飞。
DeepSeek 借用了网络与系统设计中的 Fast Path / Slow Path（快慢路径分离）：
1）Fast Path（程序层初筛）：先用零成本、微秒级的确定性代码（事件源类型、群组范围、发送人白名单、基础规则）挡在最前面，直接过滤掉绝大多数无关噪音。
2）Slow Path（语义层评估）：只有通过初筛的少量候选事件，才会打包送给大模型（Eval），结合团队编写的自然语言规则判断要不要真正立项干活。
2）Thread 直通订阅（Pass-through）：砍掉 37% 的冗余 Token
当某个 Worker 接手了一个 GitHub PR 的修改任务后，人类往往会在这个 PR 下面连续追评五六条修改意见。
如果每一条新评论都要先发给 Router、让 Router 读一遍上下文再转发给那个 Worker，Router 就会沦为纯粹的传话筒。
因此，Super-agent 引入了 Thread 直通订阅机制：同一个 PR 或同一个 IM 话题下的连续事件构成一条 Thread。Router 只在初始事件发生时创建 Worker 并建立订阅关系；此后该 Thread 下的所有后续评论，由底层程序直接投递给已订阅的 Worker，不再绕道 Router。
口说无凭，看 DeepSeek 的消融实验数据（IT之家实录）：一旦去掉这个直通机制，Router 需要做出的决策次数直接增加了约 30%，系统消耗的缓存读取 Token 从 2,323 万暴涨到 3,177 万（多烧了 37%）！
3）把上下文当 CPU Cache 管：Inline & Spill 与链式召回
常驻运行的 Agent 怎么防止上下文窗口膨胀？DeepSeek 的做法是把 Context Window 当作 CPU 的高速缓存（Cache）来管理，核心就两个动作：
1）Inline（内联）：根据局部性原理，把近期高概率用到的摘要、对象 ID 和高频上下文直接内联进当前窗口，省去调工具查询的往返开销。 2）Spill（溢出）：把超出预算的长文本或低频历史留在窗口外部，窗口内只保留一个轻量引用指针，模型需要时再按需读取。
更妙的是，系统里的 Trigger、Thread 和 Worker Session 等对象之间都内联了下一跳关联对象的 ID。当遇到一个跨度好几周的老任务时，模型可以顺着这些 ID 引用关系逐跳往回找，形成链式召回（Chain of Recall）。
4）投机执行（Speculative Execution）：没人 @ 它，后台已经把 Bug 修好了
这是整篇技术报告里最惊艳的一个设计，借鉴自现代 CPU 的分支预测与投机执行思想：
在还不确定计算结果会不会被人类采纳时，先利用后台空闲算力试跑；如果结果有高价值就交付，如果没跑通就直接丢弃，绝不刷屏打扰人类。
DeepSeek 团队在他们自己的内部研发群里配了一条叫「静默复现并修复」的策略（爱范儿报道）：
当团队成员在群里反馈某个软件 Bug、大家还在激烈讨论怎么复现和谁去修的时候，群里没有任何人 @AI。但潜伏在群里的 Super-agent 捕捉到这个信号后，已经悄悄在后台拉起分支、尝试复现故障并寻找修复方案。
只有当它既成功复现了问题、又找到了干净简单的修复代码时，它才会突然在群里冒出来，直接甩出一个已经跑通测试的 GitHub Pull Request 链接供大家 Review；如果复现失败或者问题太复杂改不动，它就全程保持沉默，当作无事发生。
同样的思路放在个人助理场景也极其自然：收到一封会议邀约邮件时，AI 不等你开口，已经在后台查好你的日程冲突、搜集好参会人背景资料并写好了回复草稿，等你点一下确认就能发出去。
5）异步 ReAct Loop 与全双工交互
传统 Agent 的 ReAct Loop 是半双工阻塞的——一旦调了一个耗时的 run() 工具（比如编译整个项目或跑全量测试），前台会话就彻底卡死，你发新消息它也理不了你。
Super-agent 把耗时工具调用改造成了异步的 start() 和 stop()（在开源原型中，Shell 命令超过 5 秒自动转入后台）。调用 start() 后工具立即返回 Started 状态，前台对话窗口立刻解放，你可以继续跟它聊别的需求，甚至中途喊停修改方向；等后台任务跑完，结果会作为一条新的 Trigger 事件重新投递回会话。
6）存算分离（BYOM）与独立 Watchdog 控制回路
为了让 Agent 真正做到“7×24 小时持久在线”，哪怕你把笔记本合上塞进背包里也不中断，DeepSeek 做了两层加固：
1）存算与环境三分离（支持 BYOM）：把 Agent Loop 的计算放进云端无状态容器，把会话状态存进云端数据库，而代码仓库和编译工具链依然留在你自己的开发机上——本地只跑一个不保存任何状态的极简 daemon 守护进程，专门负责接指令跑命令。这不仅支持连接云端沙箱，还完美支持 BYOM（Bring Your Own Machine，自带设备接入）。
2）独立 Watchdog Session（AI 巡检员）：跑过长程 Agent 的人都知道，很多时候故障不是进程崩溃（Crash），而是模型在里面陷入了死循环或者方向彻底跑偏。因此 DeepSeek 在主系统外部单独设了一个由定时消息驱动的 Watchdog Session。它本身也是一个拥有完整工具的 Agent，不仅盯报错，还会用模型定期审查各个 Worker 有没有取得实质进展；一旦卡死就主动介入修复，维护者甚至可以直接用自然语言问 Watchdog：“刚才那个任务为啥卡住了？帮我把主系统的触发规则改一下。”
四、实测账单与冷思考：速度翻倍背后，代价和隐患是什么？
作为工程师，看到架构图画得再漂亮，也得拉出真实实验数据和成本账单来溜溜。
DeepSeek 团队非常诚实地放出了一组端到端消融实验结果（基于约 300 条合成消息流、20 个工作请求，每种方案重复运行 5 次求均值），同时把这套架构目前的代价与软肋摊在了桌面上。
我把这组核心实验数据与架构取舍整理成了下面这张对比表，如下表所示：
| 评估维度 | 传统单 Session + Subagent（中性提示） | Super-agent（去掉 Thread 直通） | 完整版 DeepSeek Super-agent |
|---|---|---|---|
| Subagent / Worker 触发率 | 5 轮运行 0 次调用（全在主会话硬扛） | 100% 结构化分派独立 Worker | 100% 结构化分派 + Thread 订阅直通 |
| p50 任务完成时间 | 未单列（严重串行积压） | ~12.4 分钟 | 12.4 分钟 |
| p95 任务完成时间 | 29.5 分钟（频繁被新消息打断） | ~15.7 分钟 | 15.7 分钟（提速近 1.9 倍） |
| 缓存读取（Cache-read）Token | 单会话基准 | 3,177 万 Tokens（Router 决策多 30%） | 2,323 万 Tokens（直通省下 37%） |
| 人类注意力占用 | 极高（需人工盯梢、切换与恢复上下文） | 极低（单一入口交互） | 极低（仅在立项确认与最终验收时介入） |
除了表格里的完成速度翻倍，Router 层的抗压表现也很亮眼：当外部事件（Trigger）到达速率从每分钟 1 条飙升到 40 条时，Router 会自动把积压事件合并成微批次处理（平均 Batch 大小从 1.0 升至 2.8），单次请求耗时仅从 2.5 秒微增到 3.9 秒，分摊到每个决定的推理时间反而从 6.4 秒降到了 1.6 秒（IT之家实录）。这意味着单靠一个常驻 Router，就足以扛住一整个研发团队的日常事件流。
但是，天下没有白吃的午餐。这套架构有两个必须正视的代价与边界：
1. 这是一套“吃缓存大户”架构，极度依赖便宜的快模型
注意看表格倒数第二行：跑完一轮 300 条消息的测试，哪怕开启了 Thread 直通优化，Super-agent 依然消耗了整整 2,323 万个 Cached Read Tokens。
为什么这么吃 Token？因为 Router 常驻在线加上多个 Worker 并发推进，每一轮事件判断和工具调用都要高频读取上下文缓存。
按照 DeepSeek 自家的 Flash 模型叠加错峰优惠来算，这 2,323 万缓存读取 Token 大概只需要 $7（约合人民币 50 元），完全用得起；但如果你把底层换成海外按原价计费的顶级闭源大模型，同样的架构跑一天下来，账单绝对能让你肉疼到失眠（MindStudio 拆解）。
这也解释了为什么 DeepSeek 会在这个时间点抛出 Super-agent——只有当底层模型的推理成本与 KV Cache 缓存价格被打到白菜价时，“7×24 小时常驻在线、后台投机试跑”的自主 Agent 才在经济账上算得过来。
2. 尚未完全解开的难题：长程记忆衰减与“BYOM 安全连坐”
在文章末尾，DeepSeek 团队没有做任何营销粉饰，直接列出了目前还没彻底解决的硬骨头：
1）跨月度的长程记忆：系统跑上几个月后，历史 Ticket 和对话成千上万，如何在不撑爆上下文的前提下精准召回几个月前的隐性约定，依然没有完美答案。 2）外部事件流的 Prompt 注入与跨设备风险：这一点最值得所有开发者警惕。因为 Super-agent 持续监听群聊消息和公开的 GitHub PR 评论，而这些外部输入是不受控的。一旦有人在 PR 评论里埋了一段恶意的 Prompt 注入指令，攻破了云端的 Agent Loop，那么所有通过 BYOM 接入这个云端大脑的开发者个人电脑（拥有完整 OS 用户权限），都面临被横向控制或泄露本地凭据（SSH Key / API Token）的风险！
正因如此，在 DeepSeek 开源的原型里，主动工作模式（Proactive work）提供了 off、observe 和 auto 三档，并且出厂默认严格锁定在 observe（观察模式）——它只会在日志里记录“如果允许的话，我刚才准备接下这个活”，而不会擅自动手，直到团队明确建立好白名单和沙箱隔离。
五、给独立开发者的启示：现在怎么试玩？
如果你手痒想亲自体验一下这套架构，DeepSeek Harness 团队已经把配套的 TypeScript 原型代码放在了 GitHub 上：
开源仓库指路：
https://github.com/deepseek-ai/dsh-superagent-prototype（MIT 协议，v0.1.0）
它的安装方式本身就很“Agent 原生”。因为需要配置 Node.js（22.19+）、Git、Python、tmux、GitHub CLI 以及 DeepSeek Harness 运行时，官方甚至不建议你手动一行行敲命令配置，而是让你直接把仓库克隆下来，对你的 Coding Agent 说一句话：
▼text复制代码Read SETUP.md in this repository and set up dsh-superagent with me.
你的 Agent 就会顺着 SETUP.md 的指引，每次问你一个简短的配置问题，展示完整计划后自动帮你把整套环境装好。（再次提醒：由于 Worker 运行时具备完整的操作系统用户权限，尝鲜试玩时，强烈建议放在 Docker 容器、虚拟机或独立的测试机里跑，不要直接裸跑在存有核心生产密钥的主力机上。）
哪怕你现在并不打算部署一整套常驻的 dsh-superagent，看完 DeepSeek 这次的架构交底，我们自己在搓 Agent 工具或写工作流时，至少可以立刻抄走三条极具含金量的作业：
1）别靠 Prompt 劝主控 Agent 分工，直接拔掉它的执行工具：如果你在做多 Agent 编排，发现主 Agent 老是越俎代庖自己干活，不要再去改提示词加感叹号了。直接学 DeepSeek，把主控节点的 파일读写和 Shell 工具全部移除，只留一个 dispatch_worker 工具，从物理结构上逼它做纯粹的路由器。
2）在大模型前面永远挡一层 0 成本的 Fast Path 代码筛子：凡是接入 Webhook、飞书/企微群聊或定时巡检的 Agent，先用几十行确定性的正则、白名单和状态判断过滤掉 90% 的无效事件，别拿昂贵的大模型当粗筛网。
3）把“少占人类注意力”写进 Agent 的第一铁律：我很喜欢 dsh-superagent 哲学文档（000-philosophy.md）里定下的交互规矩——收到任务确认一次，干活期间保持安静，只有在产出最终结果（如 PR）、遇到必须人类拍板的问题、或者彻底失败时才开口说话。
写在最后
回看最近半年 AI 工程圈的风向变化，你会发现一个特别有意思的趋势：
前有 Anthropic 在 Claude Code 里放弃花里胡哨的向量 RAG，用 50 年前的 grep 做出极简高效的 Agentic Search；后有 DeepSeek Harness 团队拒绝炒作玄学概念，把计算机操作系统里的快慢路径、Cache 局部性、投机执行和看门狗机制搬出来，搭出了 Super-agent。
顶尖团队都在用行动证明同一件事：大模型时代的下半场，拼的早就不只是谁的 Prompt 写得花哨，而是谁能用扎实的计算机系统工程基本功，把原本散漫、耗费人类注意力的概率模型，收拢进确定、高效、可自治的工程护栏里。
当 AI 真正学会在后台自己调度 AI、自己静默复现并修好 Bug 的时候，我们作为开发者，才算真正从“盯终端窗口的监工”，升级成了设定目标与验收成果的架构师。
我是一个持续在 GitHub 等开源社区挖掘真正好用、能打的高价值项目，同时记录自己用 AI 搓工具、做产品、踩坑填坑全过程的独立开发者。如果今天这篇硬核拆解对你有启发，欢迎关注公众号「小火龙AI 手记」，我们下篇见。
参考资料：
- DeepSeek Harness Team，《Exploring Super-agent Design: Towards a More Autonomous Agent System》及开源原型仓库：https://raw.githubusercontent.com/deepseek-ai/dsh-superagent-prototype/main/README.md
- IT之家，《DeepSeek 提出 Super-agent 架构设计：Router 与 Worker 双层架构，探索更自主的 Agent 系统》：https://www.ithome.com/1/020/615.htm
- OSCHINA（局），《DeepSeek 团队把 Agent 设计成“操作系统”：多任务的上限不该是人的注意力》：https://www.oschina.net/news/503338/deepseek-harness-super-agent
- MindStudio（Luis Chavez-Mattos），《DeepSeek's Super Agent Harness: Fixing the Attention Bottleneck in AI Coding》：https://www.mindstudio.ai/blog/deepseek-super-agent-harness-design
- MarkTechPost（Asif Razzaq），《DeepSeek Open-Sources dsh-superagent, a Router-Worker Coding Agent》：https://www.marktechpost.com/2026/11/01/deepseek-dsh-superagent-router-worker-coding-agent/
