DeepSeek《Super-agent 设计探索》导读：瓶颈不在模型，在人的注意力

← 返回目录

来源（一手原文）：DeepSeek Harness 团队《Super-agent 设计探索：迈向更自主的 Agent 系统》，DeepSeek 官方微信公众号（”DeepSeek 产品部”），2026-10-31 晚。全文转贴：https://www.uied.cn/posts/922127 ；另一转贴：http://www.uml.org.cn/ai/202611023.asp?artid=27640 。英文讲解（带原图）：https://agentspulse.github.io/tutorials/deepseek-super-agent-architecture/ 详细摘要见 deepseek-super-agent-summary.md；本篇是导读（为什么值得看、主线、怎么读）。 注意：微信原文链接（mp.weixin.qq.com）未取到，不编造；网上传的英文标题 “Scheduling Beyond the Conversation” 原文里没有，是转述的提法；”1.4 万字”这个长度也没法核实。

一句话结论

单任务的上限看模型能力，多任务的上限看人的注意力——DeepSeek 把 Agent 从”一个对话框包办一切”里拆出来，搭了一套长期存活的 Super-agent：常驻 Router 只管派活，隔离的 Worker 各干各的活，事件直通、异步执行、云端算力 + 本地环境分离，再配一个独立的 Watchdog 巡检跑偏。

为什么值得看

• 换了一个问题：全网都在卷参数、刷跑分，拼单个对话框多聪明；这篇说真正的分水岭不在单点智力，而在系统对人类注意力的极致释放。一个人同时最多跟进 3–5 个活跃会话——系统再强，把切窗口、催进度、理上下文的负担甩给用户，也只是个把人累死的玩具。
• 不是理论，是工程思路：作者开篇就声明，这不是新理论，是把计算机系统里的老办法（调度、缓存、存算分离、外部看门狗）套到 Agent 上。没有发明新概念，全是可落地的取舍。
• 有内部实例 + 有开源原型：DeepSeek 内部已经跑着一个 Super-agent 实例（修 bug、回代码评审、自己迭代 Harness，还会在群聊里没人 @ 它时主动发现缺陷提 PR）；同时开源了研究原型 dsh-superagent-prototype，MIT，11,088 stars（2026-11-02）。
• 跟你的三个项目都对得上：WorkBuddy（长期存活的个人助手，正需要 Router/Worker 分层和 Watchdog）、muse-agent-harness（原则沉淀层，这篇的”注意力预算”和”接受模式”是可以直接借的规则）、open-memex（Chain of Recall 那套上下文当缓存的思路，跟编译式记忆是同一路数）。

叙事主线

1. 瓶颈转移：单任务 Agent 已经证明模型能少盯着干复杂活；但主流 Agent 仍以一个 Session 为基本单位，会话之间互不相通。用户并行推几个任务，得自己切会话、自己记上下文——3–5 个就是上限。
2. 破局：把 Agent 从单次手动会话里解放出来，做成一个跨会话保持上下文、并行推进多个复杂任务的连续实体，叫 Super-agent。四性：连续（一个 Agent 横跨 IM、GitHub 评论等渠道）、高效（并行多任务、新指令不用等上一个跑完）、主动（盯着环境事件，该推进的推进、不该说话时安静）、持久（一直在线、直连真实工作环境、异常自愈）。
3. 五大模块：Router + Worker 两层架构（Router 常驻、只派活不干活，甚至不需要 Bash；Worker 上下文隔离、一个任务一个、用最强模型）；事件驱动 + 订阅直通（群聊、邮件、代码提交都是触发器；后续事件由程序代码直送对应的 Worker，不再绕回 Router）；全双工与多渠道适配（长任务全改异步；IM 回复焊死 100 词以内、只在需要决策时打扰人）；计算、状态、环境彻底解耦（云端跑 Agent 循环、数据库存持久状态、执行环境留在用户自己的机器上 BYOM）；独立 Watchdog 巡检（不只看进程死没死，更查模型是不是空转或偏离目标）。
4. 实验：合成负载上，Super-agent 任务完成 p50 12.4 分钟、p95 15.7 分钟，传统单会话 p95 拖到 29.5 分钟；Router 批处理把单次决策摊销耗时从 6.4 秒压到 1.6 秒。但代价是 Token：缓存读取 23.23M 对 6.05M，将近 4 倍。
5. 诚实的一面：第 8 节自己列了局限——只是架构探索、不是产品功能；实验是合成负载、初步参考；安全 §8.4 最尖锐：云端 loop 一旦被提示词注入攻破，所有接进来的端侧机器都会被控制；原型里 Watchdog、存算分离等设计还没实现。

摘要第 8 节：原型里真正落地的部分（Trigger/Ticket/Mandate、SQLite 持久化、接受模式 off/observe/auto）——这些是可以直接抄进 WorkBuddy 的。

怎么读（分级）

• 【对照正文】——第 2–6 节五大模块：这是全文的骨架，值得对照原文读一遍，概念密度不高、但每个取舍都值得琢磨（比如 Router 为什么不需要 Bash、订阅直通省的到底是 Token 还是时间）。
• 【摘要即可】——第 7 节实验：详细摘要里有完整数据表和合成负载的口径说明，只看摘要就能把握结论与保留条件，不用去抠实验细节。
• 【摘要即可】——第 8 节局限与第 9 节结论：摘要里已全文转述，尤其是 §8.4 安全那段，建议读摘要里的原话。
• 原型仓库不用通读：先看 README 的研究原型声明，再按摘要第 8 节的清单对照 docs/000–008 看你关心的部分（授权、执行、架构三篇最有用）。

跟你的咬合

• WorkBuddy：最直接。长期存活的个人助手正需要这套东西——Router/Worker 分层（你现在的设计里，模型跑偏了谁来发现？Watchdog 就是答案）、事件订阅直通（WhatsApp/邮件/日历消息进来直接送达对应的 Worker，不用每次都过 Router）、接受模式 off/observe/auto（先 observe 记录、再 auto，渐进放权，跟你”先观察再放手”的思路同构）。
• muse-agent-harness：”注意力预算”是一条可以直接写进 harness 的原则——”只在人必须行动或能用上结果时才说话”；”消息/输入不能改权限，只有版本化的 Policy 能改”也是一条好规则。
• open-memex：Chain of Recall（上下文当缓存、Inline 与 Spill、引用图谱多跳取回）跟编译式记忆是同一路数——wiki 层就是编译后的记忆，Chain of Recall 是取回时的引用图谱。这篇没发明新理论，但把”上下文当缓存”这句话落到了可执行的规则上。