实测：Claude Code 单干 vs 三 Agent 团队——慢近一倍、便宜一点，但在大型安全任务上胜出

一位开发者公布了一组相当少见的实测数据：让 Claude Code 独自完成任务，正面对比一个由三个 Agent 组成的"团队"——Claude 任技术负责人做协调、廉价的 pi agent 写代码、Codex 做独立评审——在同一个 Rust 项目、同一起始提交上，用盲审（blind review）打分。结果与很多人的预期相反：多 Agent 工作流并不更快，甚至慢了近一倍；省下的钱也比想象中薄；但在最大的那个安全敏感任务上，团队版本是唯一通过评审的版本。

快速回答

• 速度方面：多 Agent 团队在三项测试中全部更慢——小任务约 28 分钟对 19 分钟，中任务 16.1 对 8.7 分钟，大任务 66.2 对 30.5 分钟（后两项慢了近一倍）。
• 成本方面：把写代码交给廉价模型后，Claude 的开销约下降 25%（中任务 1.54 美元对 2.05 美元）和 15%（大任务 3.30 美元对 3.90 美元）——但这还没算 Codex 评审的调用，而团队分支的 Codex 评审用量是单干分支的 2–3 倍。
• 质量方面：小、中任务两边都通过盲审（APPROVE）。大任务（涉及 MFA）中，团队版本获得 APPROVE，而 Claude 单干版本因漏掉一个 OpenAPI 契约偏差错误被打了 CHANGES_REQUIRED。
• 样本极小：全部结论来自作者 Brian Ng 自己项目上的 3 对测试——作者本人也强调这只是"初步信号"，不是确定结论。
• 作者现行策略：按风险分层——小任务 Claude 单干，普通功能交给廉价 Agent 写代码加一轮评审，涉及 auth、数据库或公开 API 的任务强制两轮独立评审。

这次实测测的是什么、怎么测的？

它在同一个现成的 Rust 项目上，对比两种组织 AI 编程 Agent 的方式：

• 单干分支：Claude Code 独自完成（按作者给出的配置：Opus 5.5、Medium 档）——自己理解需求、自己写代码、自己检查。
• 团队分支：Claude Code 任技术负责人（Tech Lead），运行廉价模型的 pi agent（DeepSeek V4.1 Flash、High 档）任主力开发写代码，Codex（GPT-6.1 Sol、High 档）任独立评审交叉挑错。整个过程由作者通过 Herdr TUI 界面实时观察。

测量方法刻意做了去偏设计，这正是这篇实测比同类文章更值得读的原因：

• 同一起点：每个任务都从同一起始提交拆出两个独立 worktree，每个分支都用全新会话。
• 用"任务合同"锁定：为防止 Agent"自己做自己夸"，每个任务都有一份合同，写明目标、允许改动的文件清单和测试命令；worker 报告"完成"还不算数——代码必须通过一个自动检查脚本（gate）才算完工。
• 盲审打分（blind review）：两个补丁被匿名成"版本 X"和"版本 Y"，交给不知道出处的评审者打分。
• 公平性说明：只有第 1 对是 100% 的 Claude 单干。第 2、3 对里，单干分支最后仍多了一步 Codex 评审，所以这两对真正测的是一个更窄的问题：把打字工作推给廉价模型，到底省多少钱、多花多少时间？成本由 token 日志按标价换算，用于相对比较。

三 Agent 团队都有谁？

角色	Agent / 模型（据作者）	职责
技术负责人	Claude Code（Opus 5.5 – Medium）	理解需求、编写任务合同、协调并验收结果
主力开发	pi（DeepSeek V4.1 Flash – High）	直接写代码、查文档、跑测试——因成本低而被选中
独立评审	Codex（GPT-6.1 Sol – High）	顾问与交叉挑错，不参与写代码

三个难度等级的结果

对	任务	时间：团队 vs 单干	成本：团队 vs 单干	盲审
1	给 health 接口加 version 字段（小）	约 28 分钟 vs 19 分钟	Claude 用量反而更高（输出 token 24,737 vs 22,232）	双方 APPROVE
2	新增管理 CLI 命令，改 6 个文件，约 400–500 行（中）	16.1 vs 8.7 分钟	1.54 美元 vs 2.05 美元（−25%）	双方 APPROVE
3	查看并解除 MFA 锁定，约 25 个文件，安全敏感（大）	66.2 vs 30.5 分钟	3.30 美元 vs 3.90 美元（−15%）	团队：APPROVE——单干：CHANGES_REQUIRED

逐对细看，图景并不是简单的"团队输了"：

• 第 1 对——小任务分工纯亏。协调开销远超任务本身的价值；团队那次运行还中途遇到基础设施故障，作者不得不手动敲命令提醒，把数据顶了上去。唯一的加分项：多步流程让评审抓到了一个单干分支漏掉的单元测试缺失。
• 第 2 对——钱开始降，时间仍然输。当 Claude 只做协调时，它的输出 token 从 33,009 大幅降到 18,730。两版都能跑通，但 pi 的模型较弱，用了两轮评审才过关——第一轮 Codex 就抓到了一个 pi 漏掉的真实逻辑 bug。
• 第 3 对——分出胜负的任务。核心安全逻辑上两边打平。差别在评审深度：单干版本让一个 OpenAPI 契约偏差错误漏过了内部评审，直到最后的盲审才被抓到；pi 版本则在第一轮评审就被拦下两个严重错误，被迫多轮修透，最终版本反而更干净。作者把团队版本部署到真实服务器跑了一遍：所有场景都顺畅，只有 OIDC 流程还没来得及测。这一对里 Claude 的输出 token 从 63,439 降到 37,595，上文峰值（peak context）从 240,402 降到 183,060。

三个最有价值的结论

1. 把活交给廉价模型，不会自动变便宜

即便把打字工作让给 pi，Claude 仍然吃掉账单的大头。第 3 对中，Claude 读取的数据有 77% 发生在交活之前——它必须先读完整个代码库，才有足够信息写出任务合同。这批数据随后一直躺在上下文窗口里，之后每一轮对话都要为重新读取它付费。再加上 pi 分支的 Codex 评审用量是单干分支的 2–3 倍（未计入那 15–25% 的节省），实际省下的钱比最初预期薄得多。

2. 对敏感功能，一轮 AI 评审不够

同一个模型、同一套提示模板，这个评审放过的错误，另一个评审却能抓到——这种现象在仅仅 3 对测试里就出现了。凡涉及身份验证（auth）、数据结构、迁移或公开 API 的部分，作者现在强制要求在最终版代码上做两轮独立评审才允许合并。

3. Agent 越多，运维负担越重

连的工具越多，断点就越多：从 hook 脚本，到 Agent 报告"已完成"实则卡死在一个隐藏提示上——每个小故障都曾毁掉作者的一次运行。就连作者自己写的自动检查（gate）脚本也有 bug，靠 Codex 评审了 7 轮才补完。

作者的现行策略：按风险分层

由于作者把代码安全和成本看得比等待时间更重，他仍以多 Agent 工作流为默认，但分层使用而不是机械套用：

• 小任务、改动位置明确：Claude 单干，最多加一轮独立评审，跳过繁重的代码侦察步骤。
• 普通功能任务：把代码侦察和写代码全部交给 pi，再加一轮评审。
• 涉及 Auth、数据库或公开 API 的任务：从合同设计阶段就让 Codex 交叉检查，最后再加两轮独立评审。

他正在尝试的下一步调优是：禁止 Claude 自己直接读太多代码，把侦察推给更便宜的 Agent，目标再砍至少 30% 成本；同时考虑把协调模型从 Opus 降到 Sonnet 以便价格减半——复测结果会再更新。

这次实测的局限

为了避免过度解读，请记住作者自己承认或方法本身隐含的局限：

• 样本量 n=3，只有一个 Rust 项目、一个操作者——足够提取信号，不足以推广到所有团队和语言。
• 单干分支在第 2、3 对并不完全"单干"，因为最后还有 Codex 评审，因此这两对比较的是"谁打字"，而不是"有没有评审"。
• 第 1 对数据有噪声：运行中途的基础设施故障（需要手动提醒 Agent）把时间和 token 都顶高了。
• 成本是相对换算：由 token 日志按最贵模型的标价折算，且没有完整计入团队分支每一轮评审的 Codex 开销。

常见问题

多个 AI Agent 会比一个 Agent 更快吗？

按这次实测：不会。三项任务中多 Agent 团队全部更慢——从 1.5 倍到 2 倍以上——因为协调、交接、评审往返和基础设施故障的时间吃掉了并行的优势。多 Agent 是用速度换经验证的质量和一部分成本。

为什么交给廉价模型只省了 15–25%？

因为最贵的部分不是打字，而是阅读理解：协调模型必须先装下几乎整个代码库才能写对任务合同（第 3 对 77% 的读取发生在交活之前），而这批数据之后一直躺在上下文窗口里，每轮对话都要重复计费。

这次实测中的盲审（blind review）是什么？

一种保证客观的打分方式：同一任务的两个补丁被匿名（版本 X、版本 Y），交给不知道作者是单干分支还是团队分支的评审者评估——避免按模型的"牌子"产生偏见。

什么时候该用多 Agent 工作流？

当任务足够大或足够敏感、评审的成本花得值时：涉及 auth、数据库、迁移、公开 API 的功能。反过来，小任务且改动位置明确时，一个强 Agent 单干、最多加一轮独立评审，经济得多。

任务合同和自动 gate 有什么用？

合同锁定工作范围（目标、允许改动的文件、测试命令），防止 Agent 跑偏和自宣完成；gate 脚本则是机器检查关卡，代码必须通过才算完工——两套机制都是为了对付 AI Agent"自己做自己夸"的毛病。

结语

这次实测的价值不在胜负比分，而在于它戳破了多 Agent 热潮里三个很少被说出的事实：协调是有代价的，廉价模型不会神奇地让账单变便宜，真正的质量来自多层独立评审而不是 Agent 的数量。对于正在搭建 AI 编程工作流的团队，作者的按风险分层公式——小的单干、大的和敏感的上多层验证——是比"什么都多 Agent"现实得多的起点。

来源：Brian Ng 在 Facebook 上的实测帖（2026 年 11 月 3 日），由 Wotech Electronics 编辑整理。文中所有数据均为作者在个人项目上的测量结果，并非任何模型厂商的官方数据。