DeepSeek 开源 Super-agent 拆解：当“人的注意力“成为 Agent 系统瓶颈

DeepSeek 开源 Super-agent 拆解：当"人的注意力"成为 Agent 系统瓶颈

写在前面

10 月 31 日晚，DeepSeek Harness 团队发布技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，同步在 GitHub 开源了研究原型 dsh-superagent-prototype。两天内，澎湃、虎嗅、智东西、通信世界集中解读，热搜口径出奇一致：AI 又进化了。

来源：IT之家，2026-10-31。

但把官方原文和仓库 README 读完，你会发现这次真正值得聊的不是"AI 更强了"，而是开头那句很反直觉的判断：

模型执行单任务所需的人工干预越来越少，瓶颈正在转向人的注意力。一个人通常只能同时跟进 3-5 个活跃会话。

翻译一下：过去两年模型能力的增速远超人类注意力的增速。单个 Coding Agent 已经能把活干到八成，但你还是得盯着它——开新窗口、补前情、等结果、切回来验收。AI 能干的活变多了，你能管的活没变多。 这才是多任务 Agent 的真实上限。

Super-agent 的解法不是发明新理论，而是把操作系统里玩了几十年的经典设计——进程调度、事件循环、Cache 管理、存算分离、看门狗——系统地搬进 Agent 架构。这篇文章拆四件事：瓶颈到底卡在哪、五件套各自解决什么、实验数据该怎么读、以及原型的真实边界在哪。

一、瓶颈转移：会话管理本不该是人类的职责

先把问题定义讲清楚。现有 Agent 系统以单一 Session 为单位运行，这个前提天然带三个锁：

• 同步阻塞：你下达一条指令，就得等它跑完才能下一条。串行的 ReAct Loop 吞吐上限极低。
• 上下文割裂：开多个会话并行？每个会话互相不知道对方的存在。你在 A 窗口说"方案改用 B 实现"，正在 C 窗口写方案的 Agent 一无所知。
• 设备绑定：电脑一关，Agent 就停。它不是"在线的员工"，是"开着的工具"。

DeepSeek 团队的观察是：这三个锁共同把多任务上限钉死在人的注意力上——不是模型不够聪明，而是"会话管理与上下文同步"这件本该由系统做的事，一直摊派给了人。

所以 Super-agent 的目标定义得很克制：一个跨会话保持上下文、并行推进多任务且互不干扰的连续实体，具备四个特征——

特征	含义	对抗的旧限制
连续	用户始终感觉只有一个 Agent，不用想"这事在哪个会话里说过"	上下文割裂
高效	无需等上一个任务完成就能接受新指令	同步阻塞
主动	持续观察环境事件，该出手时出手，不该出手时安静	被动等指令
持久	始终在线、接入真实工作环境、异常自愈	设备绑定

注意这四个特征没有一个是"更聪明"。这是系统设计问题，不是模型能力问题。 单个 ReAct Loop 无法同时满足四个特征，于是有了下面这五件套。

二、五件套拆解：操作系统思想的 Agent 移植

1. Router/Worker 双层架构：一层分派，一层干活

跨信道连续交互（要一个统一入口）与多任务高效并发（要上下文隔离）存在根本权衡。全塞进一个 Session，连续但串行；全拆成独立 Session，并发但割裂。Super-agent 的答案是拆成两层：

• Router 层：常驻的全局协调节点，统一接收群聊、GitHub、邮件等所有入口的消息，只做任务分派和全局协调，不执行具体任务——甚至可以不配 Bash 工具。因为不做重活，Router 可以用轻量模型。
• Worker 层：多个上下文完全隔离的执行会话，各自挂完整工具链，专注单一任务。Worker 决定交付质量，所以要配最强模型。

这个结构和常见的 Agent Team 表面相似，侧重完全不同：Agent Team 的 Team Lead 要深入任务细节、拆解子步骤、高频协调成员，自身推理负载很重；而 Router 只处理任务之间的高层关联，不介入任务内部。一句话：Team Lead 是项目经理，Router 是调度器。

2. 事件驱动：从"等指令"到"看事件流"

这是五件套里最有意思的一个。驱动 Agent 的主要输入不再是人类逐条键入的提示词，而是环境中的半结构化事件——群聊消息、邮件、日程提醒、PR 评论、CI 结果，官方称之为 Trigger。围绕一条事件的生命周期有四步设计：

两级过滤（Fast Path / Slow Path）。真实群聊事件流是高噪音、低触发率的——绝大多数消息不需要 AI 介入。对每条消息都调大模型判断，成本无法承受。所以程序规则先快筛（来源、白名单、群组范围等确定性条件），过滤后的候选事件才交给 LLM 语义判断。这是 CPU 设计里 Fast/Slow Path 的标准搬运。

订阅与直通。同一个 PR、同一个 IM 话题下的连续事件构成一条 Thread。Router 根据初始事件创建 Worker 后，Worker 直接订阅该 Thread——后续事件绕过 Router 直通 Worker。只有冷启动的新任务才走 Router。订阅还是多对多的：多个 Worker 订阅同一 Thread 时，它们会收到相同事件，冲突时有机会自行发现并解决，不需要点对点通信。

Inline & Spill。上下文窗口当 Cache 管理：近期高频信息直接内联（Inline）省掉工具调用往返，低频长文本留在窗口外只存引用和摘要（Spill），按需读取。官方原文有句很硬的话：浪费上下文窗口，就是浪费模型的智能。

投机执行。借 CPU 的 speculative execution：结果还没被需要时先在后台试跑，有价值再提交，没价值就丢弃。内部配置了"静默复现并修复"策略——有人反馈 Bug，Agent 先在后台复现、定位、找修复方案，确认问题存在且修复简单才提交，否则保持安静。这个"否则保持安静"值得单独品味：主动性的边界不是"能做什么"，而是"什么时候不该说话"。

3. 异步多信道 + 存算分离 + Watchdog

剩下三件快速过：

• 异步多信道：异步 ReAct Loop 让 Agent 执行耗时任务时仍能响应新指令（官方注明该特性尚未默认开启）。用户在 IM、GitHub 等原有工作界面里跟它交互，不需要学习新入口。
• 存算分离：执行循环放云端，会话状态存数据库，本地只留轻量 daemon——电脑合上盖子，任务照跑。这是把"进程和状态分离"的老思想直接平移。
• 外部 Watchdog：独立进程检查各任务是否陷入无效循环，并尝试修复。Agent 系统的看门狗——名字都没换。

五件套与两组关键数据：任务中位数 12.4 对 20.4 分钟；事件率从约 1 条/分钟升到 40 条/分钟时，Router 单次决策摊销推理从 6.4 秒降到 1.6 秒。合成负载，未经独立复现。95 分位（15.7 对 29.5 分钟）见下文。

三、数据怎么读：一半是速度，一半是"拿 token 换时间"

来源：智东西，2026-11-01。

官方给出的实验数据，三个数字最值得看：

第一组：任务完成时间。 多任务负载下，Super-agent 的任务完成中位数为 12.4 分钟，95 分位为 15.7 分钟；对照组（带 Subagent 工具的单 Session）中位数 20.4 分钟，95 分位 29.5 分钟。差距主要出现在长尾——单 Session 的排队延迟会随并发任务数恶化，双层架构把队列拆掉了。

第二组：批处理的规模效应。 事件到达率从约 1 条/分钟升到 40 条/分钟时，Router 单次决策摊销的推理时间从 6.4 秒降到 1.6 秒。原因：Router 推理期间到达的事件会积压，下一轮 LLM 调用合并处理——Prefill 阶段并行计算，请求耗时增长远慢于批大小。越忙越省，这是批处理系统的经典曲线在 Agent 上的复现。

第三组：直通的价值。 去掉订阅直通后，Router 决策次数增加约 30%，读缓存 token 从 2323 万涨到 3177 万（+37%）。直通不是锦上添花，是成本结构的关键设计。

但读这组数据要带三个清醒标记：其一，实验基于合成负载与简化环境，官方自己承认只是初步参考，不是产品级结论；其二，这套架构本质是拿更多 token 换时间和稳定性——省下的是人的注意力，花掉的是推理算力，这笔账在真实生产环境里能不能算平，待验证；其三，全部数字来自 DeepSeek 自述，目前没有独立第三方复现。

四、冷静面：README 里写了什么"丑话"

这也是我实读 GitHub 仓库（deepseek-ai/dsh-superagent-prototype，MIT 协议，TypeScript 实现）之后觉得最值得写的部分。README 开头的免责声明写得相当诚实：

来源：deepseek-ai/dsh-superagent-prototype，MIT，研究原型。

"Research prototype for reference only, not an official DeepSeek product. … Treat it as research code, not production-ready software."

拆开看，有四句"丑话"值得放大：

1. 公开版 ≠ 内部版。 README 明确说：为发布做了适配，与内部版本及文章描述的实现均不一致；文章讨论的部分设计属于未来方向，并未在原型中实现（比如异步 ReAct Loop 就不在默认路径上）。读架构文章和读代码之间有真实落差。
2. 原型只面向单个 GitHub 仓库，可选接入飞书，作为 DeepSeek Harness 的一个 bundle 打包。多平台"超级智能体"是愿景，不是现状。
3. 代码很大一部分由 coding agents 写成，官方自己提示"可能包含 bug、风格不一致，使用前请 review"。一个讲"Agent 自主干活"的项目，本身就是 Agent 干活的产物——这大概是最有意思的自证。
4. 工程完成度是研究代码水位。文档结构（philosophy/authorization/execution 分篇）比代码完成度更成熟——这也符合它"思路输出"的定位。

一句话总结：文章是架构宣言，仓库是参考实现，两者之间隔着一段"未来工作"。 拿它直接上生产会失望，拿它对照学设计很值。

五、给开发者的可操作启示：三件事今天就能抄

抛开宏大叙事，这套设计里有三件事是任何做 Agent 应用的团队现在就能借鉴的：

第一，注意力经济学要写进产品原则。 README 里有句比架构图更值得抄的话："take as little human attention as possible, and give as much value as possible"（占用尽可能少的人力注意力，交付尽可能多的价值）。它的后半句更关键："An agent that can act for a whole team can also waste a whole team's attention"——能替整个团队干活的 Agent，也能浪费整个团队的注意力。 评估一个 Agent 系统的指标不该只有任务完成率，还该有"人类介入次数"。

第二，主动性必须配授权边界。 原型文档里专门有一篇 Authorization（docs/002），核心规则是：只在被要求时行动，或按团队写好的规则行动；只在有人必须行动或能用上结果时才说话。配合"静默复现、确认才提交"的投机执行策略，主动性被关进了规则的笼子。想做"主动型 Agent"的产品，先把这个笼子设计出来。

第三，从 observe 模式起步。 别急着让 Agent 自动干活。先让它只监听、只汇报、不动手，跑两周事件流，看看两级过滤的误判率，再逐步放开写权限。原型自带的 Web 面板就是这个思路——面板上只显示"哪些事需要人"，剩下的系统自己消化。

写在最后

回到标题那个问题：当"人的注意力"成为 Agent 系统的瓶颈，意味着什么？

意味着 Agent 竞赛的一个分水岭到了。单任务看模型，多任务看系统——过去两年大家卷的是"一个会话里能干多难的活"，接下来的问题会变成"一个人能同时管理多少个干活的 Agent"。后者拼的不是智力，是调度、过滤、缓存、恢复这些"无聊"的系统工程。DeepSeek 这次贡献的不是最强模型，而是一份把经典系统思想系统化搬进 Agent 的完整参考——连"哪些还没做"都标得很清楚。

对开发者，最实际的下一步不是部署它（研究代码，别上生产），而是把它的三张图纸拿走：双层调度、两级过滤、授权边界。人的角色上移到定目标和验收，这件事的方向感已经写清楚了——至于什么时候成真，盯着三件事：异步 ReAct Loop 什么时候默认开启、多仓库支持什么时候来、以及第一个把这套架构跑到生产环境的第三方会是谁。

Agent 的下一个战场是调度，不是智力。

---

参考与信源：DeepSeek Harness 团队《Super-agent 设计探索：迈向更自主的 Agent 系统》（官方公众号，2026-10-31）；GitHub 仓库 deepseek-ai/dsh-superagent-prototype（MIT 协议，README 及 docs/000-008）；智东西《DeepSeek 又开源了！公布 Super agent 架构》（2026-11-01，含实验数据全文转述）；通信世界《DeepSeek 开源 Agent 底座》（网易转载，2026-11-01）；浙江在线报道（2026-11-01）。文中全部实验数据为 DeepSeek 官方自述、基于合成负载，未经独立验证。

注：本文为个人技术分析，与文中提及的任何公司无关；"3-5 个活跃会话""内部实例已用于日常研发"等表述以官方原文口径为准。