Claude Opus 思考级别深度测评：性能与成本权衡

这是分析结果的快照；每当有新实验值得纳入时，都会在以下位置更新：https://github.com/adrianco/retort/blob/main/levels-blog.md

发布于 2026-07-31 · 更新于 2026-07-31 — Adrian Cockcroft

--effort low|medium|high|xhigh|max 是 retort 最新、影响最大的成本调节项，也是最不为人理解的一个。versions-blog.md 已经证实它会增加成本；本文关注的是模型究竟如何利用额外时间。结论来自归档的 Agent 日志，而不是根据汇总数据推断得出。

简单来说：在档位升至最高之前，Opus 5 会编写更多内容。到了最高档，它不再继续写，而是开始修订——重新阅读自己的代码、重新运行自己的测试、编辑已经写好的内容。正是在这个转折点上，成本曲线开始脱离时间曲线；而对于常规任务，这些额外投入并没有带来任何门禁指标能够观察到的收益。

数据来自：adrianco/experiment-55，使用 Claude Opus 5 和 GPT-5.6 Terra，语言为 python 和 go，覆盖五个 effort 档位；常规任务（bookshop）每档重复 2 次，困难任务（brazil）每档重复 1 次。下文的所有数据均根据每次运行的数据库和归档的 _agent_stdout.log 文件重新计算得出。

Claude Opus 5 在常规任务上使用 python 时，每个档位 2 次重复实验的平均值：

所有指标都单调增长——时间、成本、轮次、token、代码行数、测试数量。唯一始终不变的，是项目真正用于评分的那一列：每个档位的 requirement_coverage 都是 1.00。这个任务只用两分钟、花费 0.76 美元便已完整实现；而在额外花费 33 分钟和 19 美元之后，它依然只是同样的完整实现。

注意，各条曲线的形状并不相同。从 low 到 max，实际耗时增长了 17 倍，成本增长了 25 倍，token 数量增长了 35 倍。成本增长快于时间，并不只是因为轮次增加了，还因为每一轮的工作强度也在提高。

行为转变：从编写转向修订

汇总数据无法说明究竟发生了什么变化，但工具调用的构成可以。对于同一批运行，每次运行的平均工具调用次数如下：

从 low 到 xhigh，行为模式一直稳定且平淡无奇：Opus 编写文件，运行几次测试，然后停止。Write 的数量大约是 Edit 的 3 倍。提高 effort 只意味着重复更多相同的工作——high 写了 12 个文件，而 low 写了 5 个。

到了 max，工作的形态发生了变化。Edit 的数量变成 Write 的 2.4 倍，Read 激增 18 倍（2 → 36），Bash 调用则增长 6 倍（14 → 86）。此时它已经不再是在产出解决方案，而是在审计已有的解决方案——重新阅读自己的模块、重新运行测试套件，并进行调整。每轮的工具调用次数也从约 0.95（从最低档一直到此前各档，基本都是每轮执行一个操作）上升至 2.02，这意味着它开始批量并行执行操作。

也正是在这里，模型自行增加的额外工作首次出现，而且只出现在这里。在十次 python 运行中，mutation testing、subagent delegation，以及手写 OpenAPI 文档，都只出现在两次 max 运行中——从 low 到 xhigh 一次也没有出现。这与最慢的那次成功运行所包含的内容一致：为了一个图书 CRUD API，它创建了一个包含七个模块的 package，主动运行了未经要求的 ruff linting，还执行了 mutation testing。

行为转变的触发点取决于任务难度，而不是档位本身。在困难任务上，同样的转变提前了两个档位发生：

对于 bookshop，Opus 只在 max 才开始修订；对于 brazil，它在 medium 时就已经开始修订。档位并不会直接设定行为——它设定的是预算；当模型已经投入足够多、手里有了值得修订的成果时，才会切换到修订模式。

这些额外投入是否反映在可测量的结果中？

只有当指标仍有提升空间时才会。比较 go 在相同档位下的结果；使用 go 时，测试覆盖率评分尚未达到上限：

Python 从 0.98 起步，几乎已经没有提升空间——额外投入的 33 分钟只让它提高了 0.01。Go 从 0.73 起步，提高了 15 个百分点，这是实实在在且单调递增的改善。因此，诚实的结论并不是“effort 毫无收益”，而是：覆盖率不足时，effort 确实可以买来更高的覆盖率；覆盖率已经不缺时，它什么也买不到。

其他所有指标要么持平，要么变得更差。全部十个单元格中的 requirement_coverage 都是 1.00。可维护性并没有随着 effort 提高——在 python 中，它从 low 的 0.96 降至 max 的 0.89，因为 944 行代码需要维护的内容显然比 192 行更多。

相同的五个名称，在不同厂商那里含义不同

在 GPT-5.6 Terra 上执行完全相同的档位扫描，几乎看不出这个调节项产生了什么影响：

Terra 整个区间的成本只有 0.12～0.29 美元——它的 max 成本是 medium 的 2.4 倍。Opus 5 的 max 成本则是 low 的 25 倍。两者在全部十个单元格中得分都是 1.00。

两个 CLI 接受完全相同的五个单词，这很容易让人误以为它们是可以直接比较的因素。但事实并非如此：max 对一家厂商只是温和的推动，对另一家厂商却意味着工作模式的彻底改变。任何跨厂商比较都必须明确固定档位，并且仍需报告成本，因为名称相同并不意味着行为相同。

实际应该如何使用这个调节项

对于常规工作，保持在 low。十个单元格中有十个都得到了 1.00；low 只用两分钟和 0.76 美元便完成了任务。所有更高档位，本质上都是在为一个已经正确的答案继续修订付费。

当某个可测量的结果仍有提升空间时，可以调高档位——go 的覆盖率提升是真实存在的。这足以成为使用 xhigh 的理由，而且在 xhigh 时收益就已经出现，不必再升到 max。

应该把 max 视为一种不同的模式，而不是只比上一档更高一级。到了这个档位，模型会开始审计自身，成本会呈超线性增长，而且它会去做一些根本没人要求的工作。

样本量很小。bookshop 的每个单元格有 2 次重复实验，brazil 的每个单元格只有 1 次。go 的 max 行只有一个样本（13.3 分钟，4.21 美元），结果反而低于它自己的 xhigh（18.4 分钟，6.70 美元）——这几乎肯定是因为缺少一次重复实验，而不是真实的趋势反转。因此，上文的任何结论都没有使用 go 的 max 数据。

brazil 的档位扫描并不完整。Opus 5 完成了 low、medium 和 high 的运行，随后账号触及用量上限；xhigh 和 max 从未运行。brazil 表格只能展现前三个档位的形态，成本最高的两个单元格均为空缺。

这里还需要记录一个测量陷阱，因为本次分析确实踩中了它。一个 Claude Code JSONL 日志中可能包含不止一条 result 记录——这里的 24 次 Opus 运行中有 2 次就是如此。如果只从最后一条记录读取 num_turns，会低估实际轮次：那次耗时 45.6 分钟的 max 运行，用这种方式读取会得到 94，但真实总数是 116 + 94 = 210。较早版本的 tasks-blog.md 和 experiments-blog.md 曾发布过 94 这个数字，目前两处均已修正。直接统计 tool_use block 的数量（该次运行共 256 个）是更可靠的测量方式，上文的工具构成表采用的正是这个指标。

如需采取进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。