一个人大约只能同时跟进 3 到 5 个 AI 编程会话——DeepSeek 的设计文章给自己立的靶子就是这个。10 月 31 日开源的 dsh-superagent-prototype 想用"一个 Router + 一批一次性 Worker"解决它。但通读设计文章和原型代码后，一个更根本的问题浮了出来：这套架构承诺节省的东西，恰恰是无法度量的东西。

一、问题的起点：注意力瓶颈

2026 年 10 月 31 日，DeepSeek 在 GitHub 发布 dsh-superagent-prototype（MIT 协议，首日约 4,137 stars），随附设计文章《Exploring Super-agent Design: Towards a More Autonomous Agent System》。次日 Bloomberg 将其解读为对 Anthropic Claude Code 的开源挑战。

这个原型来自 DeepSeek 的官方 Harness 团队，但 README 第一句就写了“not an official DeepSeek product”——它是研究代码，不是生产软件；公开代码为发布做了适配，与内部版本不完全一致，设计文章中的部分设计尚未在原型中实现。下文涉及实现状态处会就地标注，实验数据也均来自团队自评，尚无第三方复现。

这篇设计文章的出发点是一个观察：AI 编程的瓶颈已从模型能力转向人的监督能力——一个人大约只能同时跟进 3 到 5 个活跃 agent 会话。这个判断作为工作假设是成立的。但设计文章没有给出注意力的度量方法：会话数、上下文切换频率、决策延迟，三者都不是同一个东西。

Agentic coding 的具象：AI 在屏幕前完成 Pull Request（图源：DEV Community）

二、架构：一个 router，N 个一次性 worker

分层设计：Router 是 Super Agent 内部唯一长期存活的会话，对接 GitHub/飞书、跟踪任务、分发工作，自己不写代码；每个任务派生一个一次性 Worker 会话加独立工作目录，上下文干净，从不直接与人对话，做完即弃。流水线为六阶段：source → trigger → eval → ticket → executor → result。其中 Router/Worker 分层、GitHub 轮询、飞书接入、ticket 机制在原型代码中可见。

设计文章还描述了一个外部 Watchdog 会话：巡检存活、诊断异常、自我恢复。这个组件在开源原型中没有完整落地，SETUP.md 只提供每小时健康检查脚本——一个健康检查的雏形，而非设计文章描述的自愈控制回路。因此下面的架构示意图是愿景图，不是原型现状图；阅读时请以这个差别为准。

按设计文章绘制的架构示意（图源：KINGY.AI）——注意其中的 Watchdog 属于未落地设计

全链路视图（图源：AgentsPulse）：Triggers、过滤、Router、Worker、会话数据库与 Watchdog

三、主动性治理：监听优先，规则限流

系统主动处理：GitHub 默认每分钟轮询。但主动性的每一步都被规则约束，且规则有文档级设计，不只是提示词：

• 白名单授权：只响应授权用户的显式请求，或团队预设规则覆盖的场景；

• 观察模式：默认只记录"若处于自动模式本会接受该任务"，但不执行——建议先审记录再切 auto；

• "silently reproduce and fix"：有人报 bug 时后台复现，确认并修好就直接开 PR，修不好就保持沉默。

设计文档给出的动机是：一个能代表整个团队行动的 agent，也能浪费整个团队的注意力。每条规则的落地程度未逐项核对，效果如何没有数据。

四、实验：一个方向性信号

测试为合成负载：编码环节用 sleep 模拟工具耗时，因此只测调度、不测代码质量；每轮约 300 条消息，其中约 20 条工作请求，消息间隔和工作时长缩为原设定的四分之一，模型调用耗时保留真实值；每种配置跑 5 次。仓库截至报道时仅有 1 个 commit、0 个 issue。

配置	完成时间 P50 / P95（分钟）	单次实验读缓存 token
Super-agent	12.4 / 15.7	2323 万
Super-agent，去掉直通	12.6 / 15.5	3177 万
单会话 + Subagent，中性提示	20.4 / 29.5	605 万
单会话 + Subagent，优先委派提示	13.8 / 29.0	1082 万

（表中数字转引自设计文章官方实验表；原始出处为随仓库发布的设计文章。）

三个解读：

1. 结构隔离优于提示委派，但目前只是方向性信号。 中性提示下 5 次运行 0 次委派，强推委派的提示下仍有 1 次自己全干；提示委派的 p95（29.0 分钟）约为结构委派的 1.8 倍。样本量为每种配置 5 次，无独立验证或社区复现。

2. 直通机制省的是 router 开销，不是时间。 去掉直通后完成时间基本不变，但 router 决策数增加约 30%，token 增加约 37%——它削减的是调度层的算力开销。

3. 时间收益有账，注意力收益没账。 表里能算出"快了多少分钟""贵了多少 token"，但整组实验没有任何一栏对应"人省下了多少注意力"——恰恰是这套架构的核心承诺。

五、成本：token 有单价，注意力没有

第四节那张实验表只统计缓存读取 token，不能直接折算账单涨幅；媒体按 V4.1-Flash 缓存命中价估算，多出的约 1718 万 token 对应几毛钱的量级，真正的账单取决于所用模型与时段定价。

在这个口径下，Super-agent 的单轮 token 是单会话中性提示基线的 3.8 倍（2323 万对 605 万）；按团队自报的低谷闪惠价，一轮约 7 美元，若按每轮约 20 个任务单位粗算，每个单位约 0.35 美元。注意这里的"任务"是合成负载里的标注单位，与生产环境的任务不可直接等同；也没有公开数据说明一张真实工单的实际花费。

团队自己给这个架构划了边界：只适合便宜且快的模型。这不是成本论证，是边界声明——成本论证需要的对照，比如不同模型与时段下的账单曲线、真实任务上的花费，文章都没有。对照数字的缺席本身就是一条边界。另一处更基础的空白在第一节：这套架构要优化的核心变量——注意力——没有度量标准。

六、度量学缺口的两个面

把前面两个空白并置：一个是人的认知资源的度量问题，一个是 AI 系统的可靠性的度量问题——但在"缺少度量标准"这一点上，结构是相似的。

第一面在第一节：注意力的度量方法不存在。架构的全部承诺——"省注意力"——建立在一个没有度量标准的概念上。实验表格里时间是分钟、开销是 token，唯独注意力没有单位。

第二面是 Router 的失效模式：把监督对象从 N 个 worker 收束为 1 个 router 之后，注意力没有被消除，只是被推迟和集中化了。Router 误判任务优先级、错误授权一个不该做的任务、对真正需要人介入的问题选择沉默——这些情况如何被发现、如何被度量，设计文章基本没有展开。官方自己在文末列了未解决问题：Router 何时水平切分、长程记忆如何处理、凭据泄露风险。观察模式缓解了这些问题的频率，但不能度量 router 的决策质量。

两面合起来看：这套架构要优化的核心变量（注意力）和它要信任的新单点（router 决策质量），都缺少度量标准——不是同一个缺口，而是同一类缺口。这不是实现进度的欠缺，而是范式级的空白——在度量存在之前，"省了多少注意力"和"router 多可靠"都无法从工程上验证。

七、安全与部署现实

• Executor 以 danger-full-access 模式在 OS 用户权限下运行；官方声明沙箱与审批控制不保证隔离、未做安全审计；

• 每次安装仅支持一个 GitHub 仓库，且仅支持 GitHub.com；

• 依赖 DeepSeek Harness v0.2.1-alpha.2+、Node 22.19+、pnpm、tmux、gh CLI；

• 不绑定模型，走 Harness profile 的默认 provider。

官方推荐的隔离清单：专用系统账户、独立 GitHub 账户、最短授权白名单、人工 review 所有 PR。MIT 协议加无安全审计的组合意味着：可自托管的另一面，是安全责任整体转移给部署者。若部署，按此清单执行，别无捷径。

八、行业坐标系

这里要区分两个层面。DeepSeek 在 2026 年编程智能体格局中的行业位置，由DeepSeek Harness 定义而不是 Super Agent：DeepSeek Harness v0.1 于 8 月 13 日上线，9 月 29 日发布桌面端；官方 11 月 5 日披露，截至 11 月 4 日日活已达 154 万（统计范围为使用官方 API 的用户），日消耗 token 约 92 万亿，第三方插件约 3.5 万个，并宣布建设官方插件市场。社区分析把DeepSeek Harness 与 Claude Code 的差异概括为"成品工具与开发者底层工具"：DeepSeek Harness 的模型、工具、会话、调度皆由插件组合、可自由替换，Claude Code 的能力则是固化的外壳。Super Agent 不是 DeepSeek 面向行业的主产品，它是DeepSeek Harness 之上的一个编排模式，附带的原型代码是设计文章的参考实现。

下面的对照回答另一个问题：Super Agent 的编排设计，在已有产品中能找到多少先例。先把各家的触发方式摆齐："监听式 vs 手动唤起"的二分已经失效，事件触发是五家共同的底座。

维度	DeepSeek Super Agent	Claude Code	Devin	Cursor	GitHub Copilot
许可	MIT，可自托管	闭源商业	闭源商业	闭源商业	闭源商业
触发方式	事件监听（GitHub/飞书轮询）	交互 + GitHub Actions 事件与定时（cron）触发	GitHub/GitLab/Slack/Linear/Jira/PagerDuty 事件、webhook、定时、API	Automations：GitHub 多事件类型、Slack、Linear、webhook、cron、PagerDuty	issue 分配 / Chat 发起，Actions 云端异步
注意力组织（架构层）	1 个长期 router 会话持续分诊、授权、批处理 + 一次性 worker	交互会话为主，异步触发为任务级会话	批量委派 + 结果审查	前台交互 + 后台异步子代理混合	任务级异步 agent
成本结构	部署者直接承担 token 边际成本	订阅制	订阅制	订阅制 + 云 agent 用量	订阅制
基准	自评合成负载实验	厂商公布成绩	厂商公布成绩	厂商公布成绩	厂商公布成绩

五家全都支持事件触发：Claude Code 有官方 GitHub Actions 集成，Devin 的 Automations 覆盖 GitHub、GitLab、Slack、Linear、Jira、PagerDuty 到自定义 webhook 和定时任务，Cursor、Copilot 的异步能力也已是标配。监听不是 Super Agent 的差异所在。

"持久会话"也没有独占。Devin 的 Automations 里有一个 Auto-triage 动作（界面中列为 Triage Devin）：一个长期存活的父会话监控 Slack 频道，过滤噪声、合并重复报告，为值得调查的事项派生子会话，父子共享一块持久的 scratchpad（跨会话共享的工作记忆/暂存区）——这已是"持久父会话 + 派生子会话"的结构。该功能现为遗留状态，官方推荐新场景改用 Devin Oncall；Oncall 已上线，监控范围覆盖 Slack 与 Microsoft Teams 频道消息、PagerDuty 事件，比单个 Slack 频道更宽，但公开材料同样没有 router 那种授权白名单、观察模式、批处理与汇报节奏的文档级治理设计。Devin 的自动化动作里甚至有"向已有长期会话发消息"这一选项，持久会话在那里是一等概念。

真正剩下的差异有三处，都不在"有没有"，而在"范围多大、规则多细"。其一，事件源广度：Super Agent 的 router 对接 GitHub（issue、PR、CI 通知）与飞书的多源事件流并做统一分诊与优先级判断；Auto-triage 监控单个 Slack 频道，Oncall 扩展到 Teams 与 PagerDuty，但都限于 IM 与告警渠道，不覆盖代码托管平台事件。其二，治理职能的承载：router 的职责清单里包括授权白名单、观察模式、事件批处理、向人汇报的节奏控制，这些是文档级的设计；Devin 分诊会话的治理规则没有同等粒度的公开呈现。其三，worker 的隔离承诺：Super Agent 的 worker 被明确设计为独立目录、独立上下文、从不与人对话、做完即弃；子 Devin 的隔离粒度，公开材料没有给出同等细节。

"监听 vs 手动"和"持久会话 vs 任务级会话"这两根对比轴都已被行业共享。Super Agent 的差异集中在多源事件流上的一套治理层，而不是任何一个单点能力。

两行需要限定的对比：

成本结构那一行，揭示的不是"一个便宜、一个贵"。订阅制产品同样在大量消耗 token，只是成本由厂商承担、以订阅费转嫁给用户。这一行的真实差异是成本可见性与风险承担：Super Agent 的 token 消耗是部署者直接承担的边际成本，随用量线性可见；订阅制把边际成本内部化进厂商的定价策略，用户看到的是一个固定费率。两种经济逻辑不同，不能直接比单价。

注意力组织那一行，描述的是架构设计，不是实际使用中的人机交互形态。异步化之后，五家产品都能让人的注意力从会话中暂时抽离；Super Agent 的人也要在节点上 review PR、审批授权。真正的差异是注意力在时间上的分布：Super Agent 试图把人从"持续盯会话"改成"周期性审 router 的汇报"，Devin 式异步则把人从"实时交互"改成"提交任务后等待结果"。两类都在减少注意力的即时占用，但占用的时间结构不同。

功能对比之外还有两层没有展开，仅标注为问题：监听式触发在组织内遇到的阻力更多是流程与政治性的——谁授权 agent 读哪些频道、出错谁负责——而非技术性的；MIT 生态下若出现托管服务，审计责任如何划分尚无先例。

结语

这份蓝图把 agent 治理当作工程问题公开讨论：授权、观察模式、沉默原则都有文档级设计。它的边界也写得清楚：研究原型、自评实验、未落地的 Watchdog、单点 router。

这些条目之外，还有一类边界，表现为：注意力无法度量，router 的决策质量也无法度量。在度量存在之前，这套设计最核心的两个命题——省注意力、可靠委派——无法被验证，也无法被证伪。

参考链接

• 仓库：https://github.com/deepseek-ai/dsh-superagent-prototype
• 设计文章：《Exploring Super-agent Design: Towards a More Autonomous Agent System》（随仓库发布）
• Harness 运营数据（官方披露，2026-11-05）：https://www.thepaper.cn/newsDetail_forward_34418447
• Devin Automations 官方文档（触发源与 Auto-triage/Oncall）：https://docs.devin.ai/product-guides/automations 、 https://docs.devin.ai/product-guides/auto-triage 、 https://docs.devin.ai/product-guides/devin-oncall
• 实验数据多源核对：https://github.com/xbtlin/ai-berkshire/blob/main/reports/DeepSeek/DeepSeek-Super-agent-深度技术研究-20261102.md
• 中文技术解读：https://developer.aliyun.com/article/1778092 、 https://www.163.com/dy/article/LAJKIBBT0556C3J2.html 、 https://www.52nlp.cn/ainlp-8558277768df3105ffa1
• 架构图解：https://kingy.ai/blog/deepseek-super-agent-design-explained/ 、 https://agentspulse.github.io/tutorials/deepseek-super-agent-architecture/