2026-10-31，DeepSeek Harness 团队发布架构文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，同日开源原型 deepseek-ai/dsh-superagent-prototype（MIT / TypeScript）。三天 1.36 万 star。
大多数转述停在了"AI 会自己找活干了"。我做了点不一样的事：把仓库 README 和 docs/000/002/007 逐文件拉下来读（钉死在唯一 commit 6337fc8），再把官方公众号原文逐字核定了一遍。这篇文章讲三个转述里看不到的东西：原型里真正跑起来的授权链长什么样、文章的实验数字应该怎么读、以及一个重要落差------文章的主角 Watchdog 在原型里没有实装。
一、30 秒版本
- 立论："单任务的上限取决于模型能力，多任务的上限取决于人的注意力"------团队观察到一个人通常只能同时跟进 3 到 5 个活跃 Session；
- 方案：Router/Worker 双层 + 事件驱动（两级过滤）+ 异步多信道 + 存算分离（BYOM）+ 外部 Watchdog，五个模块支撑"连续/高效/主动/持久"四个特征；
- 落差 ：开源原型实装的是授权门禁（准入表 + Mandate + 影子模式），文章里的 Watchdog、存算分离等设计属于 future direction；
- 态度：三重自我限定写得很足，实验自述"仅作为初步参考"。
二、原型里真正实装的：一条授权链
原型目前只面向单个 GitHub 仓库（可选接飞书机器人）。它的主流程是一条严密的授权状态机：
几个设计点值得工程师细看：
1. Mandate 不可变。 accept 时固化 Policy 版本、范围（scope）、强度（strength）和匹配规则。要扩大工作范围？开新 Ticket、签新 Mandate------旧凭证永远不改。撤销只有两条路：人显式 stop，或 revalidation 失败（匹配规则被禁用 / 发送者被移出白名单 / 模式回退）。恢复执行前强制重验。
2. 权限与内容隔离。 文档原话：
"Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions."
消息内容再怎么构造（包括提示注入），只能影响"这一单怎么干"，改不了"这单为什么被授权"。把 prompt injection 的防御从"过滤恶意内容"上移到"内容在授权模型里根本没有那个权限位"。
3. 执行者不可自证。
"An Executor cannot declare that a person asked it to stop."
停止指令的权威来源是人，不是执行者自己。这条很小，但它堵住的是"Agent 替用户做决定"的一整类边界情况。
4. 主动行为默认影子模式（observe）。 白名单内、但没人显式 @ 的推断类请求，默认只记录"would accept"------记账，不执行。人工复核记录后才能切 auto。这就是"先影子、后放行"的灰度启用思路。
5. 两级过滤。 事件先过程序层 Fast Path（来源 / 群组 / 白名单等确定性条件，纯代码），再进语义层 Slow Path（LLM 按提示词策略研判）。值得注意的哲学：规则没允许的，不动------"哪些消息算数"是写死的代码，不是提示词里的一句话。
三、实验怎么读：数字全部要带着设置看
原文第 7 节的实验设置（原样搬运）：合成负载，每次约 300 条消息、约 20 条工作请求，编码工作用一个只消耗时间的工具代替（衡量调度能力而非编码能力），每种方案跑 5 次。原文自述："由于实验基于合成负载与简化环境，部分设置还可以更加严谨，以下结果仅作为初步参考。"
| 指标 | Super-agent | 单 Session（中性提示） | 单 Session（提示优先委派） |
|---|---|---|---|
| p50 完成时间 | 12.4 min | 未单列 | 有缩短 |
| p95 完成时间 | 15.7 min | 29.5 min | 仍慢于双层，有长尾 |
| 委派行为 | 架构强制（Router 不干活） | 5 次运行 0 次委派 | 5 次中 4 次委派 |
最值得看的不是 Super-agent 多快，而是中性提示下模型 5 次一次都没调用 Subagent------所有工作都在主 Session 里干、不断被新消息打断。结论：靠提示词和模型临场判断分不分工是不稳定的，双层架构把"分工"焊进了系统层。
消融实验（订阅直通） ：去掉直通后，完成时间与完整版基本一致，但 Router 决定数 +约 30%，读缓存 token 从 2323 万涨到 3177 万（约 +37%）。直通不提高完成质量与速度，省的是调度开销------一个很诚实的消融结论。
Router 压测：Trigger 从 1 条/分提到 40 条/分，平均 batch 1.0→2.8，单次请求 2.5s→3.9s，单个决定分摊推理时间 6.4s→1.6s。事件突发拥堵时靠批处理合并积压提吞吐，团队规模下"无需过早对 Router 层做水平切分"。
成本提醒：Super-agent 单次实验读缓存 token 高于单 Session------多会话并行是用 token 换完成时间的稳定性。自托管的话这是真实账单。
四、文章的主角 Watchdog，原型里没有
文章第 6 节的 Watchdog 是全文最有想象空间的部分：主系统外部的独立 Watchdog Session，定时消息驱动，构成外部 Control Loop------除了管基础设施故障，还"由模型判断各个 Worker 是否有实质进展、方向是否偏离整体目标"，发现异常及时介入；维护者可以用自然语言向它询问故障原因，甚至让它在线修正主系统行为（增删提示词、调整触发规则）。
但 docs/007 里没有这个组件。这与 README 自述一致（部分设计是 future direction）。文章终审稿人崔添翼在知乎也确认：部分设计"想在 dsh 里实现还有非常多工作要做"。
所以引用这份材料时建议区分三个词：
- 文章级（五思路，架构探讨）------可以讨论、可以对标；
- 仓库级（授权门禁，已实装）------可以运行、可以复现；
- 产品级------不存在，"并非 DeepSeek 的正式产品"是文末原话。
另一个容易混淆的点：Watchdog 盯的是"有没有进展、方向偏没偏"------这是可靠性监察 ；原型实装的授权门禁是权限约束 。两者都不是对"Agent 是否越权、是否可审计"的权力监察------后者在文章里被诚实列为开放问题（安全与隐私，8.4 节）。对做 Agent 治理的人来说，这个空位比已实现的部分更有信息量。
五、工程上真正可抄的三件事
不谈架构图，谈今天就能用的：
- 先影子后放行：任何"主动型" Agent 上线，第一版都只记账不执行（observe），人工复核记录后再逐步放权。原型把这套做成了默认值。
- 准入规则写成代码，不写进提示词：来源白名单、群组范围这类确定性判断走 Fast Path，LLM 只裁语义。"规则没允许的，不动"应该是一条硬约束。
- 授权凭证不可变 + 恢复前重验：会话恢复、扩权、模式切换都走重验，而不是信任上一次的授权状态。执行者不能自我认证任何来自用户的指令。
六、核验说明
- 仓库：GitHub API 对 README + docs/000/002/007 逐文件核定，快照钉死 commit
6337fc8（仓库唯一提交，无 release/tag，演进快，引用请注意时效）；
- 文章：官方公众号原文（2026-10-31 20:29，一作 Yujia Qiao）逐字核定，与四个媒体全文转载交叉一致；
- star：13,632 / fork 1,435（2026-11-03 GitHub API 实测，引用时请重新实测）；
- 声明：独立第三方分析，与 DeepSeek 无关联；实验数字均随附原文自设限定（合成负载 / 5 次 / 仅作初步参考）。
如果你也在做 Agent 监察 / 治理方向，欢迎交流。我维护一个开源的 AI 执行与监察治理规范：ZhangRui987/agent-oversight-framework------本文的"文章级 vs 仓库级"核验方法就来自它的证据纪律。