dsh-superagent 讲透：当瓶颈从模型能力变成人的注意力

先看一个日常场景：你让 Claude Code 修一个 bug，切去另一个终端让 Codex 升级依赖，再切回来回答 agent 的提问——第三个 session 的进度你又想不起来了。模型写代码越来越快，跟不上节奏的变成了你自己。DeepSeek Harness 团队最近开源的 dsh-superagent，就是冲着这个问题去的：它不是"更聪明的 agent"，而是一套管理一群 agent session 的结构。

本文基于 MarkTechPost 的报道、DeepSeek 的设计文档转述和 dsh-superagent 的 README 信息写成。数据全部来自 DeepSeek 自报的模拟实验，且经二手转述——这点后面专门有一节讲怎么打折着读。

一、superagent 的 super，指什么

先把事实摆齐：dsh-superagent v0.1.0，MIT 许可，TypeScript 写的一个 bundle，定位是研究原型——整个 release 只有 1 个 commit，原型味很足。

它面向单个 GitHub 仓库，行为一句话说得完：

• 监听 GitHub 事件（可选接入飞书）；
• 当"允许的人"向它提出请求时，开一个工作项，叫 Ticket；
• 每个 Ticket 在自己的 session 和目录里执行，互不干扰；
• 结果回到原来的对话里，通常是一个 pull request；
• 本地 Web 面板只列需要人处理的事——没轮到你的，不烦你。

那 super 在哪？主流编码 agent 的基本单位是 1 个 session：你开一个对话，盯着它跑完。dsh-superagent 的基本单位是一群被管理的 session：一个常驻的 Router 负责接话和分发，一群隔离的 Worker 各自埋头干活。说它是"管理 agent 的 agent"，就是这个意思。

二、为什么要做它：瓶颈搬家

DeepSeek 团队的论证起点是一个观察：主流 agent 把 1 个 session 当作基本单位，而一个人同时能主动跟住的 session 只有 3 到 5 个。

这个数字是人的认知上限，不是工具的。于是链条变成了这样：模型能力涨、并行任务涨、session 越开越多——人的注意力成了多任务的瓶颈。以前我们说 agent 跑不动是模型不行，现在多任务场景里先趴下的是盯着屏幕的人。

README 里那条核心规则，就是对这个瓶颈的直接回应：

take as little human attention as possible, and give as much value as possible.

占用尽量少的人的注意力，产出尽量多的价值。设计文档把它落成了具体行为守则：确认一次，干活时闭嘴，只在有结果、有问题、有失败时再说话。

对照一下我们平时的体验：agent 每执行一步都汇报一句"好的，我现在查看文件……好的，文件已读取……"——每句话都在花你的注意力，而且大部分不值得花。在 dsh-superagent 的设计里，注意力是预算，花之前先问值不值。这不是礼貌问题，是架构问题，下一节看它怎么落实。

三、Router-Worker：两层结构怎么省注意力

研究团队把架构描述成两层：长期运行的 Router 负责交互和分发，隔离的 Worker session 负责实际干活。

用后端的眼光看这是老熟人——调度中心和执行器分离。Router 是前台接待员：常驻、话多、但工具集刻意做小（跑的是 dsh-superagent-router preset）；Worker 是后厨：每张工单一个独立 session（跑 dsh-superagent-worker），炒完菜端出去就关火。接待员不碰灶台，后厨不接客——会话容易被吵死的和需要大工具集的，被拆到了两边。

拆完之后，从"仓库里发生了一件事"到"结果回到对话里"，整体流程长这样：

GitHub / 飞书事件
│
▼
Router（常驻：听消息、做判断、派活）
│ Eval：这一批 Trigger 要不要开工？
│ 开 Ticket（带不可变的 Mandate）
▼
Worker × N（每张 Ticket 一个隔离 session + 独立目录）
│
▼
结果 → 回到原对话（通常是一个 PR）
└─ 后续评论走 Subscription 自动回到原来的 Worker

落到领域模型，是四步：

Source → Trigger。 GitHub 或飞书产生事件。有人 @ 它、issue 被分配、CI 挂了——这些先变成 Trigger。

Eval。 Router 判断：这一批 Trigger 是不是在要新工作？注意是攒一批再判断，不是来一条处理一条——这是它扛消息流的第一个手段。

Ticket。 判定要干活，就开一张 Ticket。定义里最关键的一个词：Ticket 是 a unit of authorized work——一份被授权的工作。每张 Ticket 带一份不可变的 Mandate，白纸黑字写清"它凭什么可以干这件事"。这个设计值得多看一眼：agent 不是"想做就做"，它的执行权被一份不可篡改的说明框住——事后追溯"当初为什么放行这件事"，有据可查。

Subscription。 工作做到一半，有人在 PR 上追评了一句，但没再 @ 它——这条评论靠订阅关系自动路由回原来的那个 Worker，不需要人重新点名。相当于会话粘性：活没干完，对话不散。

还有一个不起眼但很见功力的细节：Worker 里的 shell 命令超过 5 秒就转入后台执行。为什么？Worker 要持续接收消息，一条卡 10 分钟的构建命令如果占着前台，Worker 就聋了。5 秒转后台，消息循环不断——和后端"别让慢调用阻塞主循环"是同一个道理，只是这里阻塞的代价是漏消息，不是超时。

数一数这些设计分别省了谁的注意力：Eval 攒批省的是 Router 的处理量（Router 背后终究连着人）；Ticket 的独立 session 省的是人切换上下文的成本；Subscription 省的是"每次跟进都得重新点名"的重复输入；5 秒转后台省的是盯梢。每一处都在兑现第二节那句话。

四、主动工作怎么管住：observe 就是影子模式

到点该不该自己干活，是 agent 类系统最危险的开关。dsh-superagent 的授权文档给了三档 accept mode：

• off：不主动接活；
• observe（默认）：照常判断、照常记录"如果我放行，我会接受哪些请求"——但不真干；
• auto：真主动干。

关键在默认值。团队没有把"主动"当卖点直接打开，而是先让它跑在影子模式里：所有本会接受的请求都记下来，人回头看这份记录，觉得判得准了，再切 auto。做过灰度发布或影子流量的读者会秒懂：主动行为先影子跑，观察够了再放量——这套流程在流量系统里验证过无数遍，搬进 agent 一点不违和。

这其实是全文最值得带走的设计：你要在自己的系统里给自动化加"主动行为"时，off/observe/auto 三档加一个默认 observe，就是现成的答案。

五、数据怎么看：验证了架构，没验证代码质量

DeepSeek 用模拟的群聊和 GitHub CI 消息流做实验：每轮约 300 条消息，其中约 20 条是真实工作请求，每个方案跑 5 次。结果：

大约 1.9 倍的差距。但读这组数字之前，先做三件诚实的事：

第一，基线可能没发挥。 报道明确指出：中性 prompt 下，基线在 5 次运行里一次都没调用 subagent。所以这组对比实际上是"纯单 session"对"superagent"，而不是"最佳实践单机"对"superagent"。1.9 倍要打折看。

第二，工具是模拟的。 实验用的是合成消息和模拟工具，真实编码质量没有测量。15.7 分钟跑完的是"模拟任务"，不是"真 bug"。

第三，数字自报且二手。 所有数字来自 DeepSeek 自己的报告，且本文经 MarkTechPost 转述，误差无法独立核验。

打完折，这组数据还能读出什么？两条，而且都挺有信息量：

消融实验说"事件直通"值钱。 把"事件直通给 Worker"这条路去掉后，Router 的决策量涨了约 30%，cache 读 token 从 23.23M 涨到 31.77M（约 +37%）。反过来读：直通设计省下的是实打实的 token 开销——能直通的事不走 Router 决策，便宜。

压测说 Router 这个单点还撑得住。 到达率从每分钟约 1 条拉到 40 条，批大小从 1.0 涨到 2.8（负载高了攒得更狠，符合直觉），单请求延迟从 2.5 秒涨到 3.9 秒——涨了但没崩。Router 是常驻单点，它的极限在哪，这个实验给出了一角的量级感。

所以正确的读法是：这份报告验证的是"这套结构在嘈杂消息流里撑得住、且确实省注意力"，验证不了"它写出来的代码好"。原型阶段做到这一步是合格的，但把 15.7 分钟当成生产性能数字引用，就过了。

六、和其他 GitHub 编码 agent 比，差异在哪

三处差异最值得说：

并行隔离 session 是它的独有主张。 别家这一格全是"未披露"——没法证实就当没有，这是读对比表的基本纪律。1 Ticket 1 隔离 session 是 dsh-superagent 的架构核心，不是功能开关。

主动工作的默认档位。 都支持主动触发，但 dsh-superagent 默认 observe——先影子后放量，这个默认值本身就是设计态度。

跑在你自己的机器上。 Copilot 在 GitHub 后台，Claude Code 在 Actions runner，Codex 在云上；dsh-superagent 是你自己机器上的一个 Harness profile——代价是运维和安全都归你：它以完整 OS 用户权限运行，上手前先做隔离（专用用户或容器），这句不是免责套话，是安装清单的一部分。

七、想上手、想借鉴，各取所需

环境清单（来自 README）：Node.js 22.19+ 或 24+、git 2.32+、Python 3.8+、tmux、GitHub CLI 2.48+；模型由 Harness profile 的配置决定，bundle 本身不绑定模型。

团队在设计文档里也列了原型之外的设想：外部 Watchdog（盯着 agent 的 agent）、存算分离、异步 ReAct 循环——方向都是把这套结构的边界再往外推。

比起直接上手，我更建议把三件东西抄进自己的系统，它们不依赖 DeepSeek 的栈：

• Ticket + 不可变 Mandate：授权不是口头允许，是一份写死的"为什么可以干"——放在任何需要审计的自动化里都成立；
• observe 默认：主动行为先影子记录、后放量，这是把灰度纪律搬进 agent；
• Subscription 粘性路由：后续跟进不需要人重新点名，省的就是重复注意力。

收尾

三句话收束：

superagent 的 super 不在模型，在结构。 模型还是 profile 里配的那个，变的是外面套的这层 Router-Worker——管理 agent 的组织方式，成了新的性能来源。

瓶颈搬家了。 模型能力上来之后，多任务场景最先触顶的是"人只能同时盯 3-5 个 session"。谁先把人的注意力省下来，谁的多任务就先跑起来。

那句 README 值得贴在所有自动化系统的门口。 占用尽量少的人的注意力，产出尽量多的价值——不止是说给编码 agent 听的。

数据与事实出处：MarkTechPost 报道（marktechpost.com）、DeepSeek 设计文档 Exploring Super-agent Design: Towards a More Autonomous Agent System 的转述、dsh-superagent README。全部性能数字为 DeepSeek 自报的模拟实验结果。