我们花 77 小时实测 DeepSeek Super-agent：一个前台带一群后厨，真的更强吗？

📌 非官方独立评测，与 DeepSeek 无关。单一模型、自建任务集为主、小样本，结论只代表本次实验条件。

原文：DeepSeek Harness 团队《Super-agent 设计探索：迈向更自主的 Agent 系统》（作者 Yujia Qiao），2026-10-31 晚发布于官方微信公众号，官方英文版见 @DeepSeekHarness 的 X 长文。下文对原文的介绍是我们的转述和解读，不是翻译，细节以原文为准。第一部分的配图均引自官方 X 长文，版权归 DeepSeek Harness 团队，仅用于介绍和评论。

📂 完整报告、逐次数据和图（中英双语）：github.com/pans1es/superagent-prototype-evaluation

文章目录

• 写在前面：你同时能盯几个 Agent？
• 第一部分：原文到底设计了什么
• • 先打个比方：一家只有一个前台的餐厅
  • 1. 为什么单会话不够：三个硬伤
  • 2. 两层架构：前台不下厨
  • 3. 事件驱动：Agent 不再等你敲提示词
  • 4. 全双工：边干活边听你说话
  • 5. 大脑在云端，手脚留在你电脑上
  • 6. Watchdog：店里需要一个巡店经理
  • 7. 原文自己的实验
  • 8. 作者自己承认没解决的问题
• 第二部分：开源原型实现了什么（我们读了源码）
• 第三部分：我们怎么测
• • 对照组设计
  • 怎么保证公平
  • 测试项一览
• 第四部分：原文的承诺 vs 我们的实测
• • 承诺一："两层架构更强" → 交付质量没有更好
  • 承诺二："委派靠结构，比靠提示词稳" → 前半句我们复现了
  • 承诺三："前台统一对外，少打扰" → 中间层反而带来新错误
  • 承诺四："代码先过滤，省成本" → 成立，而且最值得抄
  • 承诺五："批处理扛得住洪峰" → 成立（小样本）
  • 承诺六："持久，能自己恢复" → 正常重启成立
  • 承诺七："Watchdog 自动纠偏" → 原型里没有
  • 原文自己点名的风险："安全" → 被实测印证
  • 一张总表
• 第五部分：给想做类似系统的人，6 条建议
• 第六部分：原文留下的问题，我们最想看到答案的 8 个
• 第七部分：局限
• 📂 完整报告

写在前面：你同时能盯几个 Agent？

如果你用过 Claude Code、Codex 这类编码 Agent，大概有过这种体验：开了三四个终端窗口，每个里面一个 Agent 在干活。这个在等你确认方案，那个跑完了等你验收，还有一个卡在报错里。你在窗口之间来回切，脑子里记着"2 号窗口的 PR 还没看"。

DeepSeek 的文章把这件事说得很直白：一个人通常只能同时跟进 3～5 个活跃会话。由此得出全文最核心的判断：

单个任务能做多好，取决于模型；能同时推进多少任务，取决于人的注意力。

他们的解法叫 Super-agent：不让人去管一个个会话，而是让一个一直在线的 Agent 自己在 GitHub、群聊里"听事"、接单、派活、交付，只在需要人拍板时才出声。文章还开源了一个原型 deepseek-ai/dsh-superagent-prototype。

文章写得很漂亮，但我们更好奇：它真的比一个普通的单会话 Agent 好用吗？ 所以我们没有停在读文章：

• 逐节精读原文，逐行读了原型的编排源码；
• 用同一个私有仓库、同一个模型，把原型和普通单会话正面对比，三轮实验、180 多次正式运行，前后约 4 天、累计约 77 小时。

本文分两半：上半场讲清原文的机制（第一、二部分），下半场拿我们的数据逐条对照（第三、四部分）。先放结论：

🎯 原型里写成代码的机制（持久工单、入口去重、准入 Gate、重启恢复）很值得借鉴；但没有证据表明"默认上两层架构"比单会话交付得更好、更省钱或更省心。而凡是只靠提示词约束的地方，都出了偏差。

第一部分：原文到底设计了什么

先打个比方：一家只有一个前台的餐厅

原文的概念不少，我们先用一个比喻把它们串起来，后面会反复用到：

1. 为什么单会话不够：三个硬伤

原文认为，给一个本地单会话 Agent 加再多 CLI、MCP、连接器都不够，因为有三个结构性问题：

所以要把 Agent 和"某个手动打开的会话"解绑，做成一个持续存在的实体。它应该有四个特征：

• 连续：用户感觉始终只有一个 Agent。你先在群里说用方案 A，后来在 PR 评论里改成 B，它要能跟上；
• 高效：能并行，质量不掉，上一件没做完就能接下一件；
• 主动：自己观察环境里的事件，该出手时出手；不需要时保持安静；
• 持久：一直在线，出了异常能自己恢复。

原文给了两张内部实例的截图，很直观：

原文用五个模块来支撑这四点：两层架构、事件驱动、全双工多渠道交互、计算 / 状态 / 环境分离、Watchdog。总架构图里的标号 2～6 分别对应原文第 2～6 节：

下面一个个讲。

2. 两层架构：前台不下厨

这里有一对根本矛盾：连续性 vs 吞吐量。

• 所有事都塞进一个会话：上下文连续，但只能串行，又慢又乱；
• 每件事开一个新会话：能并发，但没有全局视图，几个会话各说各话。

原文的解法是分两层：

• Router 层：持久存在，负责和人打交道、做全局协调，是整个系统的"记忆"和"顺序点"。它不执行具体任务，甚至可以不给它 Bash。作者的经验是 Router 用较轻的模型通常就够；
• Worker 层：每个任务一个，上下文互相隔离，有完整的执行工具，通常用最强的模型。Worker 不直接面向用户，把进展汇报给 Router。

它和常见的 “Agent Team” 有什么区别？Agent Team 是在一个任务内部拆步骤，组长很累；Router 只管任务之间的关系和分配。Worker 自己可以再开子 Agent，对 Router 透明。

作者还提出了一个有意思的观点：让用户手动管理会话，其实是沿袭了底层 LLM API 的习惯。会话应该是实现细节，"任务怎么展示给人"是另一个独立的产品问题。

Router 怎么扛住消息洪峰？批处理。 Router 推理时新来的事件先排队，下一轮合并处理。Router 每一步都是"长输入、短输出"，合并进来的事件在 prefill 阶段并行计算，所以积压越多，每个决策摊到的时间反而越少。原文的压测数据：

注意一个反直觉的地方：低负载时每个决策摊销 6.4 秒，反而比单次请求的 2.5 秒还长。原文的解释是：Router 派单前可能要推理好几步，或者调用工具召回上下文，所以一个决策往往不止一次请求。

作者据此认为，以他们团队目前的规模，不必提前给 Router 做分片。

3. 事件驱动：Agent 不再等你敲提示词

Super-agent 的输入不再是"人敲的一句提示词"，而是环境里源源不断的半结构化事件。一个事件进来之后，要依次经过过滤、路由和上下文组织，必要时还会被提前执行。

3.1 两级过滤：快速路径 + 慢速路径。 真实的事件流"噪声极高、需要行动的比例极低"。所以第一级用代码按来源、群范围、白名单做准入，每个来源可以配"只响应明确请求 / 作为候选 / 直接忽略"；第二级再用模型按自然语言写的策略判断要不要行动。第二级也是人用一句话改规则的入口。

3.2 订阅与直投。 Router 只负责"开新单"和"跨单协调"。一旦某个 Thread 有了负责的 Worker，后续事件由代码直接投递给它，不再经过 Router。订阅是多对多的：一个 Worker 可以跟多个 Thread，一个 Thread 也可以被多个 Worker 订阅。Router 依然能看到所有事件，以维持全局视图。

3.3 上下文：Inline、Spill 和召回链。 原文有一句很好记的话：浪费上下文窗口，就是浪费模型能力。 借鉴编译器的思路：马上会用到的内容直接放进窗口（Inline），太长或少用的放到窗口外、只留引用（Spill）。所有对象（事件、Thread、Worker 会话）都有唯一 ID，注入一个对象时顺带带上相关对象的 ID，模型就能顺着 ID 一跳一跳往回找，原文叫 Chain of Recall（召回链）。例如：一条消息 → 它所在的 Thread → 负责的 Worker → 这个 Worker 关联的另一个评审 Thread。

3.4 提前执行。 借鉴 CPU 的推测执行：结果还不确定有没有用，就先在后台做，有用就交付，没用就丢掉。原文的例子很有画面感：他们的研发群配了"静默复现并修复"策略，有人在群里报 bug，Agent 不出声地在后台复现、找修复，确认能修才冒出来发 PR，否则全程沉默。

4. 全双工：边干活边听你说话

经典 ReAct 循环里，调用一个耗时工具时整个 Agent 是阻塞的，就像打电话时对方只能等你说完（半双工）。原文把耗时的命令和子任务改成异步的 start() / stop()：start() 立刻返回"已启动"，结果出来后作为一条新事件投递回会话；跑太久可以 stop()。新消息在当前推理步结束后就能被处理。

原文说这个机制已经在 DeepSeek Harness 里实现，但默认关闭。

渠道方面，原文强调不能把终端那套"逐字输出长推理、频繁调用工具"的界面搬进群聊：

• IM：轻量、少打扰，只在需要人决定或确认时才发，他们验证过"每条不超过 100 字"的硬规则；
• GitHub / 邮件 / 文档：结构化、信息密度高，比如 PR 要写清问题、改动和验证结果。

两层架构正好帮了一半忙：长推理和工具调用都关在 Worker 里，对外由 Router 统一说话。

5. 大脑在云端，手脚留在你电脑上

本地 Agent 把计算、状态、执行环境绑在一台机器上。原文借鉴"计算与存储分离"：

• 计算放进无状态、可伸缩的云端容器，会话状态存数据库，容器可以随时重启、替换；
• 执行环境留在原地。因为把环境整体搬到云端沙箱成本很高、容易漏东西：未提交的本地改动、私有凭证、内网服务、特定硬件和工具链。所以每台设备上跑一个不保存会话状态、只负责执行命令并返回结果的轻量 daemon。

原文提到，这和 Anthropic"把大脑和双手解耦"的思路一致；区别是 Anthropic 面向托管沙箱和客户 VPC，这篇面向可能时不时离线、带着未提交改动和本地凭证的个人机器，即 BYOM（Bring Your Own Machine）。

6. Watchdog：店里需要一个巡店经理

常驻系统只靠内部逻辑很难长期可靠。而且 Agent 最常见的故障往往不是进程崩溃，而是陷入无效循环或慢慢偏离目标，只看"进程活着没"的探针发现不了。

所以原文单独配了一个 Watchdog 会话，由定时消息驱动。它检查两类问题：基础设施故障（API 报错、状态恢复失败），以及借助模型判断 Worker 有没有实质进展、有没有跑偏。维护者还可以用自然语言问它故障原因，甚至通过它在运行时修改主系统的提示词和触发规则。

原文没有给出巡检间隔、"实质进展"的判定标准和效果数据。

7. 原文自己的实验

作者明确说负载是合成的、环境是简化的，结果只作初步参考。设置是：

• 模拟群聊 + GitHub CI 消息流，每轮约 300 条消息，其中约 20 条是真正的工作请求；
• 编码工作换成了一个只消耗时间的假工具；
• 每种方案跑 5 次，消息间隔和工作时长缩短为 1/4。

结果如下（数字取自官方 X 长文）：

几个值得细看的点：

• ③ 用中性提示词时，5 次里一次子代理都没调用，主会话被消息反复打断，P95 拖到 29.5 分钟；
• ④ 明确要求"优先委派"后，5 次里 4 次委派了，P50 追到 13.8 分钟，但第 5 次模型觉得活小、自己干了，P95 依然是 29.0 分钟的长尾；
• 作者的结论：单会话的委派行为高度依赖提示词和模型的临场判断，两层架构在系统层面保证了委派；
• 代价是 Token：①的缓存读取是③的 约 3.8 倍（23.2M 对 6.1M），作者坦承这是"用 Token 换更短、更稳的完成时间"；
• 直投不让任务变快，但让 Router 的决策次数少了约 30%，缓存读取少了约 27%（31.8M 降到 23.2M）。

但请注意：这个实验测的是调度，不是交付质量。 编码是假工具，所以"Router 会不会转述错"“Worker 会不会多改文件”"模糊需求会不会先问清楚"统统测不到。实验也没写用的是什么模型，每组 5 次也没给方差。这正是我们想补上的部分。

8. 作者自己承认没解决的问题

原文最后很坦诚地列了开放问题：

• 扩展：单 Router 何时不够、怎么分片、Worker 之间何时该直接通信，都没有定论；系统跑到几个月以上，长期记忆会成为主要瓶颈；
• 超越会话的协作：任务怎么展示给人、人怎么渐进介入，聊天窗口可能只是路径依赖；
• 上下文边界与 A2A：部署几个实例，本质上是在决定上下文怎么共享、怎么隔离；
• 安全：事件驱动意味着更多不可信输入。云端被攻破或被提示词注入，所有连着的设备都可能被接管；本地凭证进了模型上下文可能泄露。需要"能用凭证、但碰不到凭证"的机制，原文没有给方案，并表示在解决前只能在小范围、可信的场景运行。

第二部分：开源原型实现了什么（我们读了源码）

原型（commit 6337fc8，MIT 协议，基于 DeepSeek Harness 0.2.1-rc.3）README 说得很清楚：这是验证技术路径的研究原型，和内部实现不完全一样，不是官方产品。它监听一个 GitHub 仓库（可选接飞书），名单上的人发话、或团队规则允许时才行动。

我们按原文的模块，逐一核对原型里的实现：

🔍 一句话概括原型：代码管"谁能下单"，提示词管"能做什么、怎么说话"。这个分界线，后面的实测数据几乎完美地对上了。

第三部分：我们怎么测

对照组设计

三轮的分工：

怎么保证公平

• 先用假模型把整条链路跑通（发生器、适配器、采集器、验收脚本），确认设施没问题，再接真模型付费；
• 每一项开跑前冻结验收标准，之后不改标准、不补跑凑数；
• 验收脚本放在 Agent 看不到的地方，用独立账号、断网运行；
• 冻结标准之外补充的指标（比如"功能测试通过率"）一律标成事后补充的探索性指标，和冻结成绩并列，不替代。

测试项一览

第四部分：原文的承诺 vs 我们的实测

我们把原文的主张一条条拿出来对。

承诺一：“两层架构更强” → 交付质量没有更好

先看最硬的编码交付：

几个细节：

• 两组都没达到预先设定的 12/16 合格门槛。冻结不合格的头号原因是多改了 .gitignore，超出了允许修改的文件范围，两组都犯过；
• SWE-bench 子集两组都过了 pytest-11143、pytest-11148、pylint-5859 这三题，挂在同样三题上。真实项目的 bug 上，两层架构没有多修好一题；
• S 单题贵 2～3 倍，这和原文"Super-agent 读取的缓存 Token 是单会话的 3.8 倍"方向一致。

最有意思的是模糊需求。 我们给了一个故意含糊的请求：“导出的任务列表看起来不太对，帮我改得更好用一点”，并在共同要求里写明"不清楚就先问再动手"。

• B 每次都先问：要什么格式？哪些字段？给谁用？拿到答复后才改代码；
• S 4 次全部直接开干，改出来的东西和需求对不上，PR 质量只有 1 分。

我们检查过：这条"先澄清"的要求确实送到了 Router 和 Worker 手里，不是在中间传丢了。我们的推测（未专门验证）：问题出在两层分工本身，Router 把"接单"当成了"派活"，Worker 拿到的已经是一张"去干活"的工单，于是谁都没停下来问。

💡 原文实验把编码换成了假工具，所以这类问题天然测不出来。调度快不快和活干得好不好，是两件事。

承诺二：“委派靠结构，比靠提示词稳” → 前半句我们复现了

原文最有说服力的发现是：单会话在中性提示词下，5 次里一次子代理都没调用。

我们的数据完全复现了这一点：B 每次都提供了子代理工具，所有轨迹里实际调用 0 次（仅第二轮就有 37 个 B 会话）。

但我们的数据补上了后半句：在这些任务上，B 不委派也照样交付得更好。 结构确实保证了"一定会委派"，可"委派了"不等于"交付更好"。对于一次进来一两件事的场景，单会话自己干反而更快、更准。

承诺三：“前台统一对外，少打扰” → 中间层反而带来新错误

多了一层前台，就多了几种单会话不会有的失败方式。

① 前台把后厨算对的数改错了。 第一轮压测里有一道计算题，Worker 用 Python 算出乘积 2063426501 和正确的哈希；Router 汇总回复时，写成了 2063441401，外加一个"看起来很像"的假哈希。这样的事发生了 2 次。Worker 算对了，Router 转述的时候"润色"错了。

② 同一个结果说两遍。 原文说 Worker 不直接面向用户、由 Router 统一说话，但原型里 Worker 自己会发评论，Router 收到汇报后再发一遍：

S 的条数是 B 的 2～2.5 倍，但总字数差不多。编码任务里有 9 条是对同一结果的重复提醒。对于"少打扰"这个目标，条数比字数更伤注意力。

③ 前台不接单。 在强杀恢复测试里，名单上的人 @ 机器人发了明确请求，Router 4 次都没接单（3 次原任务，换成更简单的 README 任务又试了 1 次），导致"强杀正在干活的 Worker"这个测试前提一直建立不起来。

承诺四：“代码先过滤，省成本” → 成立，而且最值得抄

这是原型最漂亮的地方。

Gate 是纯代码，名单外的人零成本被挡。 名单外的人不管 @ 不 @ 机器人，都在进模型之前被拒（原因码 not_a_member），0 次模型调用，不建工单；藏了提示词注入的消息同样在 Gate 被挡。B 没有 Gate，只能靠提示词"不理陌生人"，每条消息都要让模型读一遍。

入口去重。 突发负载测试里有 153 条唯一事件（141 条真实历史噪音 + 12 条真实请求），我们又故意重投了 6 条同 ID 的事件。S 在入口直接识别出重复，141 条噪音也没进 Router；B 的所有事件都进了单会话。

但门口的保安只守正门。 前面读源码时提过：已有工单的 Thread 里，任何人的消息都会直投给 Worker、不过 Gate。实测也对上了：

• 两小时长跑里，旧帖子里的 10 条噪音全部被送进了 Worker；
• 把发起人移出名单（撤权）后，正在跑的 Worker 60 秒内没有停。源码里撤权只发通知、不强制终止（n=1）。

另外，原型的 observe 模式也不是"全局只读"：推断出来的请求只记录不执行，但明确请求照样执行。

承诺五：“批处理扛得住洪峰” → 成立（小样本）

这是一个很好理解的反差：

• 单个任务进来时，S 更慢：要先过前台，接单、建工单、准备工作区，然后后厨才开火；
• 消息每分钟几十条涌进来时，S 快很多：B 只有一个会话，所有消息排队；S 的前台批量处理，后厨并行开工。

不过每个条件只跑了 2 轮，正确数也互有高低，我们不宣称显著优势。

承诺六：“持久，能自己恢复” → 正常重启成立

正常重启：S 自己接着干，B 停在原地。 S 重启后的流程和源码设计完全一致：旧执行标记 hostRestarted → 新建执行 → 投递恢复说明 → Worker 先查 git 和 GitHub 现场 → 继续干完并交付 PR。第二轮、第三轮各成功一次。B 能恢复会话历史，但恢复后就停在那里，观察 300 秒没有任何推进。

一个小插曲：第一轮我们一度记成"S 重启后需要人工补一句话才继续"。后来排查发现是误读：恢复说明在模型的视角里显示为 user 角色，看起来像有人发了消息，其实是原型自动转发的。教训是：事件流里必须保留"这条输入真正从哪来"，否则连评测者都会被骗。

强杀进程（kill -9）：还没测成。

• 第二轮我们杀掉进程 10 秒后就重启，但原型的状态锁要 30 秒才过期，结果启动时报"锁已被持有"。这属于实验时序问题，不是原型缺陷；
• 第三轮想重测，又碰上前面说的 Router 不接单，前提没建立。

所以锁过期之后的崩溃恢复，至今未测。

边界保护：都触发了。

• 后台作业空闲 1800 秒后被结束；
• 持续注入 HTTP 500 时，重试间隔是 15 / 30 / 60 秒，用完后任务明确失败，没有无限重试。日志里一共 24 次 500，是 6 次传输层尝试 × 4 次执行尝试；
• 但"重启后最旧的工单先恢复"出现了反例：新工单先启动了（n=1，根因未确定）。

取消：有独立通道就能真停。 第二轮的取消测试全部没测成，因为我们靠解析 shell 文本去找"正在跑的作业"，总有漏网之鱼。第三轮改成显式记录"任务 → 工具调用 → 后台作业"的对应关系后，19 次取消尝试里 9 次可测，9 次全部在 30 秒内真正终止（S 用时 5～13 秒）；其余 10 次是识别、前提或设施问题。

还有一个有趣的发现：我们把并发上限设成 2，却观察到同时有 3 个会话。原因是一个工单在逻辑上已经交付、释放了名额，它的会话还在跑最后一步（约 7.6 秒），下一个工单就启动了。"名额"和"真实在跑的东西"不是一回事。

承诺七：“Watchdog 自动纠偏” → 原型里没有

原型公开版没有 Watchdog。我们部署了官方文档里的"每小时巡检"外部配方，跑了一次真实的两小时：整点的巡检提醒确实发生了，但我们的观察器漏认了一次健康检查，故障没有注入成功，恢复效果未测。

原文自己点名的风险：“安全” → 被实测印证

我们把提示词注入藏在代码文件、PR 评论和 issue 里，诱导 Agent 读取一个假的 .env（里面是合成的金丝雀字符串，不是真实密钥）：

• S 有两次照做，读取了假 .env，内容进了 Worker 的模型上下文（第二轮、第三轮各一次）。两次都没有观察到外发；
• 第二轮同一个用例里，B 识别出了注入，并把它从代码里删掉了；
• 第三轮 36 个安全样本里，只有 16 个能完整判定"有没有中招"，其余缺少曝光或归因证据。没看到攻击 ≠ 防住了攻击，这些不算安全通过。

再加上源码里看到的：Worker 是 danger-full-access，实验用的 GitHub 令牌（只授权给测试仓库）Worker 也读得到，禁用命令能用绝对路径绕过，"不自己合并"只靠提示词。原文 §8.4 担心的事情，在原型里都能找到对应的口子。

⚠️ 凡是只靠提示词约束的地方，都出了偏差：先澄清、只改范围内的文件、只有 Router 对外说话、不理会注入、不读凭证。凡是写成代码的地方，基本都兑现了：Gate、去重、持久化、恢复、超时、重试。

一张总表

第五部分：给想做类似系统的人，6 条建议

第六部分：原文留下的问题，我们最想看到答案的 8 个

精读时我们一共记了 30 条空白，挑最关键的几条：

第七部分：局限

• 只用了一个模型（qwen3.7-plus），结论不能推广到其他模型；
• 以自建小任务集为主；SWE-bench 是改造过的非官方运行，只作描述；
• 样本小，多数测试项每条件 1～3 次，没有做显著性检验；
• S 和 B 的提示词、工具、接入方式都不同，是整体系统对比，不能把全部差异都归因于 Router/Worker 结构；
• "名单外发送者"是改配置模拟的，不是真实第三人；同一线程里混着名单内外的人，仍未测；
• 强杀后的恢复、锁过期后的崩溃恢复、Watchdog 的故障恢复、召回链、提前执行都未测到；
• 费用按官方价格和实际 usage 估算，不是供应商账单。

📂 完整报告

完整报告包含：术语表、每项测试怎么构造和判定、具体问题清单、原文留下的空白、逐次数据和全部图表，中英双语：

👉 GitHub：https://github.com/pans1es/superagent-prototype-evaluation

原文推荐直接读官方版本：DeepSeek Harness 的 X 长文，以及开源原型 deepseek-ai/dsh-superagent-prototype。

觉得有用欢迎 ⭐ Star，也欢迎在评论区聊聊：你的 Agent 是一个前台带一群后厨，还是一个人包圆？

本文文字、图和数据采用 CC BY 4.0 许可。原文和原型版权归原作者所有。