我测了一下 dev-orchestra：每个请求的耗时，以及不同审查者人数下的问题数

前言

上一篇把计划拆分成 dev-orchestra 的工作单元，并行地实现了。

dev-orchestra 是一个 Claude Code / Codex / Antigravity 的插件，只需一句话的请求，就能跑完设计、实现、测试、多个 AI 的审查和修复。

在本系列中我说过“会多花时间和 token”，但一直没有给出实测的数字。所以这次我测了两件事：

一个请求要花多长时间
审查者为 1 人、2 人、4 人时，问题数以及其中可以采纳的数量会怎样变化

先说明一下：次数非常少（端到端的请求 1 次，每种审查者人数各审查 2 次），对象也只是一个小的 Python 包。请把它当作把握趋势的记录来读。

dev-orchestra 已在 GitHub 上开源（MIT 许可证）。如果觉得有用，欢迎给个 Star。

→ github.com/istb16/dev-orchestra

测量条件

项目	内容
dev-orchestra	1.2.1，预设 `standard`，`optimization.level` 为默认的 `balanced`
调用方	Claude Code 2.1.309（模型为 Opus 5.5）。用 `claude -p` 发出请求，计划的批准则在第二次的 `claude -p --resume` 中给出
各角色的模型	architect 为 Claude Fable，implementer 和 review_fixer 为 Claude Opus
审查者	`claude-general`（Opus）、`codex-general`（Codex CLI 0.163.0，gpt-6.1-sol）、`claude-security`（Sonnet）、`claude-test`（Sonnet）
对象	为测试而做的小 Python 包 `textkit`（1 个函数和 3 个测试）
环境	Windows 11，Python 3.14.7。配置放在与平时不同的文件夹（`DEV_ORCHESTRA_HOME`）中

请求是用日语写的，内容如下：

给 textkit 添加 truncate(text, width, suffix="…")。按显示宽度截断，全角字符（East Asian Width 为 W 或 F）算宽度 2，其他算宽度 1。截断时，包括 suffix 在内要控制在 width 以内。README 和测试也一起更新。

一个请求花的时间

从发出请求到最终报告，不算等待我批准计划的时间，共 6 分 12 秒。

区间	时间
请求 → 计划完成并请求批准	2 分 19 秒
批准 → 最终报告	3 分 53 秒
合计	6 分 12 秒

各阶段的明细保存在 dev-orchestra 的记录（state.json）中。各角色的运行时间如下：

阶段	负责	时间
设计	architect（Fable）	75 秒
实现	implementer（Opus）	45 秒
审查	claude-general（Opus）1 人	19 秒
修复（第 1 次）	review_fixer（Opus）	27 秒
修复（第 2 次）	review_fixer（Opus）	45 秒

5 次运行加起来是 3 分 31 秒。剩下的约 2 分 40 秒，是调用方的 Claude Code（编排者）用于选择阶段、运行测试、分拣问题和写报告的时间。

因为改动小，也没有触及高风险路径，设计审查被自动跳过了。

审查者不是 4 人而是 1 人

standard 的审查者有 4 人，但这次请求被减到了 1 人。审查记录中是这样写的：

note: low-risk change (4 file(s), 76 line(s)): 1 reviewer instead of the full panel (claude-general). Cross-model disagreement is what a second reviewer buys; raise optimization.level or the low_risk thresholds to keep it.

在 balanced 下，如果改动在 5 个文件、150 行以内且不触及高风险路径，就只用 1 名审查者（optimization.low_risk_max_files 和 optimization.low_risk_max_lines）。小请求之所以轻量，就是这个原因。反过来，如果即使是小改动也想让其他厂商的模型看一看，就提高 optimization.level，或者调低这两个值。

修复跑了 2 次的原因

审查提出了 2 个问题，编排者采纳了 1 个，驳回了 1 个。被驳回的是“组合字符和零宽字符应该算宽度 0”，因为它与请求中的“其他算宽度 1”相矛盾。

被采纳的是关于测试的问题，但其中也夹带了添加组合字符测试的建议。编排者记下了“限定范围后采纳”，但交给修复角色的指示（fix-brief.md）里原样写着审查者的建议，结果第 1 次修复连本应驳回的测试也加上了。编排者发现后，用写明了范围的指示让修复角色又跑了一次。

分拣时的备注不会进入修复角色的指示，这是 1.2.1 时的行为。部分采纳时，建议自己也看一下最后的差异。

token 和费用

dev-orchestra 调用的 5 次，可以用 tokens show 查看：

  stage              meas.     input    output     total    billed      cost   tools  tool out
  architect            1/1        34     5,890         -    14,703   $0.4737       5     2,368
  implementer          1/1        14     4,103         -    27,614   $0.3380      14    10,107
  review               1/1         2     1,517         -     7,364   $0.0778       0         0
  review_fixer         2/2        26     5,495         -    43,959   $0.5371      14     6,369
  ALL                  5/5        76    17,005         -    93,640   $1.4265      33    18,844

另外，调用方的 Claude Code 自身报告 2 次 claude -p 花了 $1.74。合计约 $3.2。两者都是 CLI 给出的按 API 价格换算的金额；如果用的是订阅，它表示的是额度的消耗量，而不是实际收费的金额。

审查者人数与问题数、采纳数

接下来，我把审查单独拿出来，改变审查者的人数。取上面那次运行在实现完成时的差异（4 个文件，新增 75 行、删除 1 行），每次都应用到全新的仓库上，让 1 人、2 人、4 人分别审查同一个差异。每种人数各 2 次，共 6 次。

dev-orchestra review snapshot
dev-orchestra review run --only claude-general codex-general --json
dev-orchestra review show --json

用 --only 指名审查者时，上面说的“减到 1 人”不会生效。人数的组合如下：

人数	审查者
1 人	claude-general
2 人	claude-general、codex-general
4 人	claude-general、codex-general、claude-security、claude-test

采纳的标准

我按照端到端运行中编排者所用的同一标准来分拣问题：

采纳：在请求和已批准计划的范围内，确实缺少的东西。如果只有一部分在范围内，就限定范围后采纳
驳回：与请求中的“其他算宽度 1”相矛盾的（把组合字符、零宽字符算作宽度 0，不在字素中间截断，等等），或不需要修改的
重复：主要内容与另一个已采纳问题相同的

dev-orchestra 对重复的合并很保守，这 6 次中自动合并的问题是 0 个。不过它会列出“可能重复”的组合，我参考这些来分拣。

结果

人数	次	问题	采纳	驳回	重复	时间	token
1 人	1	2	1	1	0	25 秒	6,992
1 人	2	2	1	1	0	23 秒	6,751
2 人	1	4	2	2	0	53 秒	16,529
2 人	2	4	1	3	0	48 秒	14,837
4 人	1	8	4	3	1	25 秒	27,795
4 人	2	9	4	4	1	38 秒	27,964

时间是从 review run 开始到结束；token 是审查者 billed token 的合计（包括 Codex 的部分）。

发现的事

问题数大致与人数成正比地增加。 1 人 2 个，2 人 4 个，4 人 8～9 个。

可采纳的问题也增加了，但增加的是关于测试的问题。 4 人时增加的采纳，几乎都来自 claude-test。比如“没有 suffix 的宽度正好等于 width 时的测试（truncate("abc", 1) 会得到 "…"）”“没有确认默认的 suffix … 被算作宽度 1”，都是确实缺少的测试。另一方面，应当作为代码缺陷来修改的问题，在任何人数下都是 0 个。

最多的，是与请求相矛盾的问题。 “把组合字符和零宽字符算作宽度 1”这个问题，6 次全都出现了。Claude（claude-general）和 Codex（codex-general）各自独立地指出了同一点，4 人时 claude-test 也以“缺少这个测试”的形式提到了同一点。一般来说这是对的，但这次请求中已经定了“其他算宽度 1”，所以我驳回了。端到端运行中也出现了同样的问题。即使是作为规格决定的事，在审查者看来也可能像缺陷。

Codex 每次都只提 1 个问题，内容总是这个“宽度的算法”。在这次的差异上，加入其他厂商并没有发现新的东西。2 人时采纳增加的那一次（第 1 次），是 Claude 提出的“docstring 与行为不一致”。

审查的时间由最慢的审查者决定。 审查者是并行运行的，所以 4 人也不会变成 4 倍。2 人时比 4 人还慢，是因为那几次 Codex 或 Claude 中有一方花了 45 秒以上。另一方面，token 与人数成正比地增加（1 人约 7,000，4 人约 28,000）。

claude-security 两次都是 0 个问题。这个差异不处理外部输入和机密信息，这是理所当然的结果。

这些数字的局限

对象只有 1 个，请求也只有 1 个。差异只有 76 行，规格也定得很清楚。更大的改动或规格模糊的请求，应该会得到不同的结果
每种人数只跑了 2 次。即使人数相同，每次的问题数和内容也有些变化
采纳和驳回是我决定的。标准如上所写，但不同的人分法可能不同
其他厂商的审查者（Codex）发挥作用的场景，即 Codex 发现 Claude 漏掉的真正缺陷，在这次的差异中没有出现。这不能说明“没有用”，只是“这次没能测到”

也写一下缺点

会多花时间和 token。 这次的请求不算等待批准约 6 分钟，按 API 价格换算约 $3.2。我没有和直接交给单个 AI 的情况比较，但它调用了 5 次 AI，相应地要花时间和 token
审查者越多，要驳回的问题也越多。 4 人时，8～9 个问题中有 4～5 个是驳回或重复。分拣由编排者来做，但最后确认的是你自己
代码会被发送给各审查者所属的厂商。 2 人以上的配置中，差异被同时发送给了 Anthropic 和 OpenAI。审查者也能读取差异周围的文件，所以发送的不一定只有差异。不能外传的代码如何处理，我在介绍文章中写过

总结

用 dev-orchestra 1.2.1 提了一个小功能的请求，不算等待批准共 6 分 12 秒，按 API 价格换算约 $3.2
其中各角色的运行是 3 分 31 秒，其余是编排者的判断、测试和报告
对于小改动，balanced 会把审查者从 4 人减到 1 人
让审查者审查同一个差异，问题数为 1 人 2 个、2 人 4 个、4 人 8～9 个；采纳数为 1 个、1～2 个、4 个
人数增加后多出来的采纳是关于测试的问题，代码缺陷的问题在任何人数下都是 0 个
最多的是与请求中决定的规格相矛盾的问题，在审查者看来像是缺陷
次数和对象都很少的测量，请当作把握趋势的记录

下一篇（预计 2026 年 11 月 7 日发布）试一试 1.3.0 新增的、在最后把整个变更再审查一次的功能。

GitHub： istb16/dev-orchestra（给个 Star 就是对我最大的鼓励）

本系列的文章可以在“dev-orchestra”文章列表中集中阅读。