AI 开始自己排班:拆解 DeepSeek 的 Super-agent,以及我的一次实测

上周三凌晨，一个团队在群里讨论某个接口的报错。讨论到第 47 分钟，有人发现：修复分支已经建好、问题复现脚本已经跑通、一个 PR 已经挂在那里等评审了。

提这个 PR 的不是人。

是那个一直没说话、只在群里看着的 AI。它判断这件事值得做，就默默做完了，做不成就不出声。

这是我见过最接近"数字同事"的东西。10 月 31 日晚，DeepSeek Harness 团队放出了这套架构的设计文档，同时开源了原型 dsh-superagent-prototype（MIT，两天 6000+ star）。我把它 clone 下来跑了一遍，这篇既讲它怎么设计的，也讲我实际踩到的坑。

一、先说三个结论

二、真瓶颈不是模型，是你的注意力

文档里有一句很扎人的话：

一个人通常只能同时跟进 3 到 5 个活跃 Session。

这句话解释了很多事。你同时开五个对话窗口，每个都塞满了上下文，来回切的时候要重新回忆"这个窗口聊到哪了"。单任务的上限取决于模型，多任务的上限取决于人的注意力。

现有 Agent 的基本单位是 Session，而 Session 之间彼此隔离。你想并行推进三件事，就得自己当调度器：切窗口、搬上下文、记住谁在等谁。

Super-agent 的野心是把这个调度器做进系统里，让用户面对的永远是"一个 Agent"，而 Session 变成实现细节。

它给出四条特征：连续（IM 里改方案、PR 里再改，它知道是同一件事）、高效（不等上一条跑完就能接新指令）、主动（盯环境事件，不需要时闭嘴）、持久（常驻在线，异常自愈）。

三、双层架构：Router 为什么故意不配 Bash

要同时做到"连续"和"并发"，就得在会话组织上做一次拆分。

Router 层统一对外，Worker 层隔离并发，汇报走虚线

最反直觉的一点：Router 层甚至可以不配备 Bash。理由是——一旦它开始自己动手，就会变成性能瓶颈，也会变成"该派活的时候自己在干活"。

这跟常见的 Agent Team 差在哪？Team Lead 要拆解子任务、盯每一步、高频协调，推理负载极重。Router 只处理任务之间的高层关联，不介入单个任务内部的拆解。文档说得很直白：Router 层用轻量模型往往就够。

四、一条群消息要过四道工序

输入从"人打的提示词"变成"环境事件"，这是主动性的来源。

Trigger 的四道工序：程序过滤、语义判定、订阅直通、Worker 执行

第一道，程序层过滤（Fast Path）。 真实群聊是"高噪音、低触发率"，每条都调模型判断，延迟和成本都撑不住。所以先用代码筛：来源、群范围、白名单。稳、快、免费。

第二道，语义层判定（Slow Path）。 过了初筛的才交给 LLM，用提示词里的策略判断该不该动。这层也是给人留的扩展口——想调行为就改提示词。

第三道，订阅直通。 这一步是整个设计里最实用的。一个 PR 的初始事件经 Router 建了 Worker 之后，Worker 直接订阅这个 Thread；同一 PR 下的后续评论不再经过 Router，程序直接投给那个 Worker。Router 只盯着"还没被订阅的新事件"。

数据很能说明问题：去掉直通，任务完成时间几乎不变，但 Router 的决策量多了 30%，读缓存 token 从 2323 万涨到 3177 万，多了 37%。也就是说，直通不提升质量，纯粹是省 Router 的钱。

第四道，投机执行。 群里还在讨论方案，它已经在后台复现问题、找修复思路。有结果才交付，没结果就当没发生过。文档里管这叫"用额外的后台算力，换人的等待时间"。

五、怎么做到"一直在"

本地 Agent 有个天然的软肋：电脑一关机，它就死了。

计算在云端、状态在数据库、环境留在原地，外加一个旁挂的 Watchdog

它们做了两层解耦。第一层，把推进 Agent 循环的计算做成云端无状态容器，会话状态进数据库——这样计算可以随意扩容重启，连续性靠存储保证。

第二层更关键：不要把执行环境搬上云。真实的开发环境里有未提交的改动、私有凭据、内网依赖、特定工具链，复制成本高还容易漏。它们的做法是在端侧只放一个不保存状态的轻量 daemon，负责执行命令、返回结果，环境留在原地。这跟 Anthropic 说的"脑手分离"是一个思路。

最后是 Watchdog——主系统之外的一个独立控制回路，本身也是一个完整 Agent，定时被唤醒。它不只盯进程死没死，还要判断各个 Worker 到底有没有实质进展、方向有没有跑偏。因为长跑的 Agent 最常见的故障不是崩溃，而是无效循环。

六、他们的实验数据，和它的边界

p95 完成时间与 token 消耗对比

约 300 条消息、5 次重复的消融实验里，Super-agent 的 p50 / p95 是 12.4 / 15.7 分钟；换成"单会话 + Subagent 工具"，中性提示下模型五次里一次都没调用 Subagent，全部自己做、不断被新消息打断，p95 冲到 29.5 分钟。

换成"明确要求优先委派"的提示词后好一些，但仍有 1 次模型判断"这活很小"自己干了，形成长尾。这个细节比结论更有意思：靠提示词让模型自律，不稳定；靠架构让职责固定，才稳定。

但这组数据要打折看，作者自己也承认：合成负载、简化环境，编码工作只是"一个只消耗时间的假工具"。它测的是调度能力，不是真交付能力。

七、我把它跑起来之后

这部分是我自己的实测，文档里没有。

克隆、装依赖、编译、跑测试，前面都很顺：pnpm typecheck 通过，构建产物 693 KB。然后测试结果出来——1197 条通过 1196 条。

挂的那条正好在飞书链路上：测试期望"事件流里出现坏行（非 JSON）时，健康状态要变成 error"，实际结果仍是 ready。我单独复跑，稳定失败。

翻源码，根因是两个流在赛跑：stderr 的 [event] ready 和 stdout 的解析异常上报没有顺序保证，而健康状态是"后写覆盖先写"，于是"就绪"把"故障"盖掉了。后果是：事件流真的坏了，面板还显示健康。

对准备拿它接飞书的团队来说，这是个必须知道的坑——它恰好落在"你最想用的那条路"上。

另外三个工程层面的坑：

跑通之后的状态是扎实的：插件层正确合成（配置树从 1231 行涨到 1407 行），本地数据库里老老实实躺着七张表——trigger、thread、ticket、decision、disposition、effect、outbox。这套领域模型是它比"多智能体框架"更工程化的证据。

启动它只要三行：

八、它和常见 Agent 框架的真正差别

九、什么值得抄，什么别急着抄

值得抄的三条：

别急着抄的：Router 单点、长程记忆、脱离 Session 之后的协作界面、以及安全——文档自己也承认，云端一旦被提示词注入攻破，它连着的所有端侧设备都危险。

写在最后

这套东西最打动我的不是架构，是那句"用尽可能少的注意力，换尽可能多的价值"。它把"一条消息该不该发"当成设计问题，而不是当成礼貌问题。

大多数 AI 工具还在想"怎么多干点"，它已经在想"什么时候该闭嘴"。

下一篇我想写：把这种"事件驱动 + 观察期"的思路，落到一个真实的研发流程里——比如缺陷收敛。不聊概念，聊怎么在一周内拿到可信的判断准确率。

参考资料

关于作者

橙子味的大榴莲。专注 AI 技术分享，只写跑过的东西。