Opus 4.7 Low Vs Medium Vs High Vs Xhigh Vs Max：来自开源仓库 29 个真实任务的推理曲线
我在 Claude Code 里让 Opus 4.7 用所有 reasoning effort 设置（low、medium、high、xhigh 和 max），跑了同一个开源仓库（用 Go 写的 GraphQL-go-tools）里的 29 个任务。
在这个切片上，Opus 4.7 的表现并不像“更多 reasoning effort 与更高智能线性相关”的模型。事实上，这条曲线似乎在 medium 达到峰值。
如果你觉得这很奇怪，我也同意！这是一次 Zod 运行之后的后续实验；那次 Opus 看起来也不是单调上升。我在 GraphQL-go-tools 上重新跑了这个问题，因为我想要一个区分度更高的 repo 切片，也不太相信“更多 reasoning != 更好结果”这个事实。跑在 GraphQL 仓库上帮助澄清了结果：Opus 仍然没有表现出简单的“更高 reasoning 更好”曲线。
对照组是 Codex 里的 GPT-5.5，它整体上确实呈现了直觉中的曲线：更多推理换来了更多语义/代码审查质量。那篇文章在这里：GPT-5.5 GraphQL reasoning curve
Medium 有最好的测试通过率、与原始人工改动最高的 equivalence、最好的 code-review pass 率，以及最好的 aggregate craft/discipline rate。Low 更便宜也更快，但正确性掉得太多。High、xhigh 和 max 花了更多时间和钱，却没有在关键指标上超过 medium。
更多 reasoning effort 不只是成本更高，它会改变 Claude 的工作方式，但不会可靠改善判断。Xhigh 最明显地膨胀了测试/fixture 表面。Max 整体更忙，也有最大的实现行数 footprint。但即便两者理论上都在想得更多，它们产出的补丁也并不比 medium “更好”。
一个可能原因是：Opus 4.7 使用 adaptive thinking，也就是模型已经会为每个任务自己选择推理预算，所以 effort 旋钮是在偏置一个已经自适应的策略，而不是买到更多智能。下面会展开。
一个很有启发性的例子是 PR #1260。重试之后，medium 恢复成了一个真实补丁。High 和 xhigh 用额外的推理预算挖出了此前 PR 的 commit hash，然后自信地宣布“无需工作”，主动以无补丁结束这一轮。Medium 和 max 读了实际控制流并做出了修复。
对我来说，一个更大的 takeaway 是：这不应该只能是一次性的手工 benchmark。如果 reasoning level 会改变 agent 写出的补丁类型，自然的下一步就是让 agent 在真实 repo 工作上测试并改进自己的 setup。
在本文中，“equivalent”表示补丁匹配了已合并人工 PR 的意图；“code-review pass”表示 AI reviewer 判断它可以接受；craft/discipline 是 0-4 的可维护性/风格 rubric；footprint risk 表示相对于人工补丁，agent 额外触碰了多少代码。
数据如下：
Claude Opus 4.7 on GraphQL-go-tools: medium peaks across pass rate (28/29), equivalence (48%), review pass (35%), and aggregate craft/discipline. High, xhigh, and max each cost more without beating medium on any primary quality metric. The curve is non-monotonic, unlike the GPT-5.5 Codex run on the same repo.
Per-task drilldown - sorted by widest spread
Enter opens profile; Tab moves between rows.
Inspect-grade five-arm curve on a 29-task GraphQL-go-tools matched slice. Each arm is a candidate-arm run on the same slice; the medium-vs-high, medium-vs-xhigh, low-vs-medium, and medium-vs-max compares are stitched against the same medium baseline. Max is decision-grade for inspect/readout after targeted no-patch retry and infra repair.
Cost authority is the source-arm summary for each level. No-patch rows reduce publishable denominators for low, high, and xhigh, and built-in equivalence / code-review coverage is partial on those rows. Max no longer has infra/no-patch failures after targeted repair.
Code-review rubric means use the flattened RubricScores from each level's source summary. Low has two no-patch rows that drop out of patch-intrinsic rubrics; medium recovered stet-pr-1260 after retry while high and xhigh did not.
Reproduce from the source summaries listed in the raw JSON; regenerate the chart data with cd leaderboard && npm exec tsx scripts/build-opus47-graphql-reasoning-curve.mjs.
Prior Zod signal
The earlier 28-task Zod run was the reason to rerun on GraphQL: tests were flat, while equivalence and review moved around above the gate. Interesting, but not clean enough for the default-setting claim.
four arms only - no max
Read: Zod made the non-monotonic Opus behavior visible first. GraphQL is the cleaner follow-up because it uses the same 29-task slice across all five Opus efforts and medium wins the behavioral table outright.
我为什么跑这个实验
在上一篇比较 GPT-5.5、5.4 和 Opus 4.7 的文章之后，我很好奇同一个模型内部的表现会如何随 reasoning effort 变化。网上做研究时，很难很难判断当 reasoning level 变化时，实际体验到底是什么样，以及这会如何适用于我正在做的工作。
我先在 Zod 上跑了这个实验，结果看起来很怪：low、medium、high 和 xhigh 的测试表现持平，但测试以上的质量信号以混合方式上下波动。Low、medium、high 和 xhigh 都落在 12/28 个测试通过。但 equivalence 从 low 的 10/28 变成 medium 的 16/28、high 的 13/28 和 xhigh 的 19/28；code-review pass 从 4/27 变成 10/27、10/27 和 11/27。这很有意思，但还不够干净，无法拿来做默认设置的主张。它可能只是 Zod 特有的 artifact，也可能说明 Opus 4.7 没有简单的“把 reasoning 调高”曲线。
所以我在 GraphQL-go-tools 上重新跑了这个问题。为了把感觉和现实分开，并找出 Opus 4.7 的成本/性能甜点，我想在一个区分度更高的 repo 切片上问同一个 reasoning-effort 问题。
这并不打算成为一个普适 benchmark 结果，我没有资金或时间生成统计显著的数据。目的更接近于“我应该如何为真实 repo 工作选择 reasoning 设置？”，这里用 GraphQL-Go-Tools 作为示例仓库。
公开 benchmark 会压平大多数 SWE 真正在意的 reviewer 问题：我真的会 merge 这个补丁吗，我想维护它吗？这就是我跑这个测试的原因：以小规模更深入地理解 coding agent 在真实世界任务上的表现。
Terminal-Bench 由一些深奥问题组成，基本不是日常软件开发会遇到的；SWE-bench verified 已被污染（也就是模型已经内化了答案）；SWE-bench Pro 有用，但很通用。这不是在贬低 SWE-bench 或 Terminal-Bench。标准化 benchmark 有用，但它们主要回答的是二元任务结果问题。
我每天真正在意的问题更窄，也更烦人：agent 是否做出了和人类在我的代码库里 merge 的同类改动，而我事后是否愿意拥有这个补丁？
实验设置
每个任务都来自一个真实合并的 PR 或 commit。模型拿到冻结的 repo snapshot、描述改动的 prompt，并在 Docker 容器中获得一次产出补丁的机会。然后 Stet 应用补丁，在隔离容器里运行该任务的测试，检查它通过还是失败。
随后 Stet 会在 pass/fail 之外继续评分：
- **Equivalence：**候选补丁是否实现了和原始人工补丁相同的行为改动？
- **Code review：**考虑正确性、引入 bug 的风险、可维护性和边界情况，reviewer 会接受这个补丁吗？
- **Footprint risk：**与人工补丁相比，agent 额外触碰了多少代码？
- **Craft/discipline rubrics：**试图捕捉代码中非正确性方面的质量。基本上就是 reviewer 是否愿意维护这段代码。类别包括 clarity、simplicity、coherence、intentionality、robustness、instruction adherence、scope discipline 和 diff minimality。
这些指标存在，是因为仅靠测试无法回答我真正关心的问题：这个补丁会是我想 merge 并维护的东西吗？
每个模型在每个任务上用单个 seed 跑一次。LLM-as-a-judge 模型是 GPT-5.4。每个补丁独立评分，judge 看到补丁和任务，但不知道产出该补丁的模型/effort。我还手工检查了代表性例子作为 sanity check。这个任务集没有做人工校准，所以我会更信任 delta 的方向，而不是任何单个绝对分数。
顺带一提，我也一直把这些评估当作“autoresearch”优化循环，而不只是 benchmark。我会告诉我的 agent 类似“让这个 repo 的 AGENTS.md 变得更好”；它提出一个编辑，在历史任务上运行 Stet，找出 candidate 哪里更好/更差以及为什么，然后迭代改善评估数字。
细节：
- 模型：Opus 4.7
- Harness：Claude Code 2.1.126-2.1.138（按运行日期在各臂之间有所不同；每次运行都 npm 安装当时最新版本）
- 数据集：29 个真实 GraphQL-go-tools 任务。
- 是的，这很小，不过即使跑这么多也用掉了我每周 20x quota 的大部分
- 主要指标：
- test pass
- semantic equivalence
- code-review pass
- footprint risk
- craft/discipline custom graders
- cost 和 runtime
Low：更便宜、更浅，也不完整
Low 似乎会驱动 Opus 4.7 在表层处理大多数问题。它更快、更便宜、footprint 更低（相对于人工改动触碰更少文件），但会漏掉任务的重要部分，留下正确性缺口。
实践中，low 被 medium 取代了：成本只增加约 26%（$2.50 → $3.15），整体表现却明显更好。
例子：PR #1230 修复了两个 GraphQL federation query-planner bug，并在 GraphQL datasource print path 上添加了 empty-selection-set guard。
- 任务：收紧 planner 的 parent-chain selection，并添加形状正确的 validation guard。
- 低 effort 失败模式：low 在错误边界上工作，把手写递归 AST helper 直接 inline 到
graphql_datasource.go，而不是注册一个 planner-scoped validation rule。unique-node selection 逻辑仍然过于 eager，测试失败，而且补丁与人工 PR 不 equivalent。 - 更高 effort 的改动：medium 在正确边界完成了同一件事，也就是一个接入 planner 的
printKitPool的专用 validation rule，并匹配了人工 PR 使用的 two-pass planner shape。 - 经验：low 会做工作，但抽象层级错了。它倾向于把行为 inline 到自己碰巧正在读的文件里，而不是选择任务真正所属的 package boundary。
Medium：克制与正确性的平衡
Medium 似乎是这样一个 level：它做了足够的 repo 建模，但没有漂移到 prior-PR 合理化、no-op 叙事或过大的补丁表面。
它拥有最好的测试通过数量，与人工补丁最 equivalent，更高比例通过 code review，并且在 craft/discipline rubrics 上表现最好。
回看原始 Zod 切片时，medium 比 low 更好，但更高 effort 的信号是混合的：xhigh 有最好的 equivalence rate，high 有最好的 discipline average，而测试保持持平。GraphQL 是更干净的 medium-wins 解读。
Medium 把额外 effort 用得更有效。看 agent trajectories，它比 high/xhigh 跑了更多测试，同时避开了 max 膨胀的时间/token。在这个切片上，medium 看起来像局部最优：有足够 reasoning 来执行用户意图，但不会钻进太多兔子洞。
例子：PR #1260 让 GraphQL subscription query plans 包含 trigger metadata（subgraph name/ID、trigger query），并让 SkipLoader query-plan introspection request 可以在不打开 upstream stream 的情况下返回 subscription 的 plan。
- 任务：让现有的
SkipLoaderearly-return 对 plan-only request 可达，然后在打印出的 plan 中暴露 trigger metadata。仓库里已经有来自 PR #1008 的部分脚手架，这就是陷阱。 - 低 effort 失败模式：low 被部分已有代码迷惑，向 operator 索要 diff：“I can't proceed without knowing what specifically PR #1260 changes.” 轮次结束，无补丁。
- 更高 effort 失败模式：high 和 xhigh 用额外 reasoning budget 挖出 commit hash（
34cc4fa8、69485dfe），得出该功能已在此前 PR 中发布的结论，并以end_turn停止且不提交补丁。不是 timeout，不是 refusal，而是一个自信但错误的 no-op。Xhigh 的最终消息是："This work was originally added in commit34cc4fa8(PR #1008) and refined by69485dfe(PR #1120). No code changes are needed; nothing left to implement." - Medium 的胜利：它读了实际控制流，看到现有
SkipLoader分支位于Trigger.Source == nilguard 之后，因此对 plan-only request 不可达，然后做了最小的 hoist-and-extract 修复。测试通过。（Max 做了同样修复，并额外添加了 regression test。） - 经验：在 repo 已经包含相邻先前工作的任务上，更多 reasoning 会放大把 no-op 合理化的诱惑。额外预算没有进入运行代码，而是进入了构造一个更复杂的故事，解释为什么不需要运行代码。
High：更多思考的边界
到 high，我们开始看到“过度思考”的迹象。
High 的成本是 $5.01/task，而 medium 是 $3.15/task；high 的运行时间是 716.4s/task，而 medium 是 450.7s/task。它的 shell calls 和 tool calls 也比 medium 更多。但它的通过率跌到 26/29，equivalence 跌到 12/29，review pass 跌到 7/29，review-rubric mean 跌到 2.509，aggregate custom quality 跌到 2.670。
这个模式说明，额外 effort 并不是严格添加更多智能、发现更多正确实现路径。它可能把更多工作花在更大或更不聚焦的路径上，却没有带来对应的语义判断改善。
也要注意，这仍然是小样本，所以重跑可能会让曲线略有变化。重点更偏实践而非统计：观察到的 delta 对付费升级来说方向是错的。使用更多 reasoning 甚至可能通过把模型引向更复杂、更绕的改动而增加风险。
例子：PR #1293 把 planner/resolve metadata 重构为集中式 FetchInfo，添加 opt-in 的 BuildFetchReasons planner switch，用可复用的 FieldCoordinate 替换 KeyConditionCoordinate，并且把 go.work 里的 toolchain go1.25 bump 到 go1.25.1（一个字符的改动），同时从两个 Makefile 中移除 --config ../.golangci.yml。
- 任务：一个真实重构，加上一小组无聊的 build-plumbing 修复。
- 更高 effort 失败模式：high、xhigh 和 max 全都完全跳过了
go.work和 Makefile 修复。它们产出了更小、更优雅的纯重构 diff（11-13 个文件 vs medium 的 18 个），但 toolchain pin 仍然坏着（go1.25是“language version but not a toolchain version”），所以go test在任何 Go 代码运行之前就因 toolchain resolution 中止。Reviewer 还把重构本身标成半成品：旧的RequireFetchReasons(typeName, fieldName)API 仍然和新的FieldCoordinateAPI 并存。 - Medium 的胜利：medium 产出了最大 diff（18 个文件，462+/288−），因为它做完了完整工作，包括那个无聊的一字符 bump。Stet 的 equivalence rescue 实际上把 high/xhigh/max 标成了“likely equivalent”，但 review 不是干净的 stylistic pass，因为重构只做了一半。
- 经验：更多 reasoning 把 diff 收窄到了“有趣”的代码，剪掉了一个实际 load-bearing 的单行 build-plumbing 修复。概念上的优雅不等于 PR scope 的完整性。
Xhigh：更大的表面，更差的结果
如果我们预期 reasoning effort 会单调改善结果，xhigh 可能是最反直觉的一臂。它也是 Claude Code 针对 Opus 4.7 的默认值，以及 Anthropic 声称的 coding “best option”。
它花费 $6.51/task，运行 803.8s/task，触碰最多文件，并且新增行中 test/fixture 占比最高。它新增了 7,764 行，其中 47.5% 在 test/fixture 表面。但 xhigh 并不比 medium 跑更多测试，并不比 medium 使用更多工具，也不比 medium 做更多迭代编辑。
此外，质量信号几乎处处弱于 medium，说明这些额外编辑没有贡献到整体补丁质量。
解读这种行为，xhigh 会做更复杂的改动，带更多测试，但并不更正确，也不更贴合原始人工意图。它可能会写更多代码、fixtures 或测试，但这并不会稳定转化为正向结果。
例子：PR #859 用 map-backed O(1) indexes 替换 GraphQL planning 热路径里的 O(n) 线性扫描（added-path lookups、datasource root/child node checks）。
- 任务：把两个热路径 lookup 换成 map-backed indexes。就这些。
- Medium 的补丁：2 个文件，新增 85 行，都在任务点名的热路径文件里。测试通过。
- Xhigh 的补丁：5 个文件，新增 263 行（是 medium 的 3.1 倍），包括一个全新的 170 行
federation_metadata.go，用于缓存 interface-implementor 和 entity-interface membership，而任务并没有要求这个。测试仍然通过。 - 取舍：xhigh 上 code review 从 fail 翻成 pass，但
footprint_risk从“low”退化到“medium”，而scope_discipline/diff_minimality尽管表面面积变成 3 倍，也只移动了 0.1-0.2 分。Reviewer 明确指出了更宽的缓存表面："The patch expands beyond the minimal node/path indexes into federation metadata caching and changes multiple planner conditionals. That broader cached surface increases the chance of stale-index or semantic drift." - 经验：xhigh 用额外 reasoning budget 发明了一个二阶重构，而不是写出更紧凑的补丁。更多表面，类似结果，更差的 footprint risk。
Max：忙得多，但仍然不比 Medium 更好
Max 是对“更多 reasoning 是否会单调买来质量”的一个有用压力测试，而这里的答案是否定的。max 臂在定向修复之后达到 decision-grade，但它不是逃离同一条曲线的魔法出口。
Max 跑了 294 条 test command，而 medium 是 132 条；做了 1,153 次 shell call，而 medium 是 582 次；产出了 3,719 个 assistant turns，而 medium 是 2,042 个。它还在各补丁中新增了 8,102 行，而 medium 是 6,700 行，并且有所有臂中最大的 implementation-line footprint。
但这些 effort 都没有转化成更好的结果。Max 在 pass count 上最接近 medium（27/29 vs 28/29），但仍然落后于 medium 的 equivalence、code-review pass、code-review rubric mean 和 aggregate craft/discipline。它的成本是 $8.84/task，而 medium 是 $3.15/task；max 成本约为 medium 的 2.8 倍，每美元产出的 equivalent passes 约少 3 倍（0.051 vs 0.153）。
Max 改变了工作的形状：更多 validation loops、更多 shell exploration、更多实现行数，但没有可靠改善模型判断。
例子：PR #1076 是一次并发密集的 GraphQL subscription handling 重写：用每个 subscription 的 serialized writer goroutines 替换共享的 sync.Mutex + semaphore.Weighted 协调；把 heartbeat ticking 移到 writer path；修复 WebSocket close 语义，使只有 server-initiated close 才会 signal updater.Done；并在 CI 中默认启用 -race。这是展示任务中 max 相对 medium 明确得到回报的最清楚一例。
- 任务：在一个全局并发重构中保留 write-ordering invariant。
- 低 effort 失败模式：low 产出了空补丁。Medium 让旧的
triggerEventsSem/ 共享 event-loop 与新的 worker channel 并存，因此should_successfully_delete_multiple_finished_subscriptions测试稳定失败，写入仍然和 teardown 竞争。 - Xhigh 的失败：equivalence-grader 标记五个任务义务全部满足（xhigh 在这一组里有最高的
instruction_adherence），但 xhigh 的 worker dispatch 使用了一个select / default: go func(){ ch <- f }()overflow path，会生成无界 goroutine 并重排写入。同一个测试因不同原因失败。Xhigh 还编辑了四个 CI 表面，而任务只要求一个。 - Max 的胜利：max 像 high 一样完全退役了共享 coordinator，并且添加了
MaxSubscriptionFetchTimeout默认值和每个 trigger 的 shutdown wait；robustness 评分为3.3，而其他所有人都是1.0-1.2。 - 经验：在这个切片上，这是最清楚的 max-over-medium 胜利，即便如此它也不是单调的。xhigh 把自己扩展进了一个无界 goroutine bug，而 medium 较小的 diff 没有空间引入这个 bug。Max 胜出是因为它做了和 high 一样的共享 coordinator 清理，然后在上面加了额外 safety guards。但这只是 29 个任务中的 1 个；另外 28 个讲的是另一个故事。
Craft 与 Discipline
Custom graders 讲述的故事和 headline metrics 一样：medium 领先，更多 reasoning 没有追上。
有意思的分裂在于，更高 reasoning 能让补丁看起来更刻意，但不一定更容易拥有：
- **Medium 在 reviewer 真正在 PR 中会指出的维度上胜出：**simplicity（3.034）、robustness（2.266）、instruction adherence（2.338）和 scope discipline（2.934）。
- High/xhigh/max 在 intentionality 和 coherence 上领先，也就是“agent 知道自己在做什么吗？”这些维度。更多 reasoning 让补丁看起来更有意图。
- **但这种刻意并没有在下游得到回报。**Scope discipline 从 2.934（medium）跌到 2.697（xhigh）。Robustness 从 2.266（medium）跌到 1.932（xhigh）。模型更认真思考自己在做什么，然后做得更多，结果更难维护。
这就是 headline read 的缩影：更高 reasoning effort 会改变工作的类型，但不会改变判断质量。
成本与运行时间
按成本调整后的质量让故事变得很直白：
- Medium 每美元产出 0.153 个 equivalent patches。
- High：0.083。
- Xhigh：0.058。
- Max：0.051。
Medium 在产出匹配人类意图的补丁上，成本效率约为 max 的 3 倍。即使 max 在质量上等于 medium（事实并非如此），也很难证明这笔开销合理。
这不同于 GPT-5.5 Codex 曲线。那条曲线里，每往上一步都买到了可衡量的质量；而 Opus 4.7 的成本扩张买到的是一个更忙的 agent，不是一个更好的 agent。
为什么可能会这样
一个合理解释是 adaptive reasoning：在 Opus 4.7 上，模型已经在自行根据任务调整 reasoning。
Anthropic 的文档说 adaptive thinking 是 Opus 4.7 上唯一支持的模式，固定 token budget 不再被接受。模型会“dynamically determine when and how much to use extended thinking based on the complexity of each request.” Reasoning effort 会影响 adaptive policy，但不会限制它。
这个 framing 与这里的数据吻合。如果 Claude 已经在为每个任务选择合理的内部预算，强行提高 effort 并不会解锁新的智能。相反，它会放大一个在 medium 已经大致正确的策略。这只是一个假设，但比简单地说“更多 token 总会买到更好判断”更符合观察到的数据。
Anthropic 自己也承认了这种风险。Claude Code 的 model-config 文档警告说 max “may show diminishing returns and is prone to overthinking. Test before adopting broadly.” 他们另外的 inverse-scaling research 显示，extended reasoning 在某些任务族上可能会主动恶化输出，尽管那篇论文不是专门针对 coding 的。
值得注意的是，Anthropic 推荐的 Claude Code coding 默认值是 xhigh，所以 medium 在这里胜出是和他们自己的 guidance 相反的。
GPT-5.5 对照
GPT-5.5 GraphQL 运行是重要对照。在同一个 repo family 上，GPT-5.5 的行为更接近直觉中的“更多 reasoning 买来更多智能”故事（见 GPT-5.5 GraphQL reasoning curve）。
当我在 GraphQL 上用 GPT-5.5 跑同样的宽泛实验形状时，equivalence、review pass 和 craft/discipline quality 都随着 reasoning 增加而强烈上升。测试上并不完全单调，因为 xhigh 比 high 少了一个 test pass，而且 xhigh 贵得多，但测试以上的质量曲线基本单调，而且非常清楚。
Opus 4.7 在 GraphQL 上没有这样。同一个 repo family、同一类 reasoning-effort intervention，产出了不同的模型行为曲线：一条在 medium 之后达到峰值/变平的曲线。
局限性
我并不是假装这是一个统计显著的结果，也不是说这个结果会迁移到你的 repo。没关系，只要我们知道这只是某个时间点、某个 repo 上的一次运行，它仍然有助于我们思考自己的 reasoning 设置。
具体局限 / methodology gaps：
- 每个任务单 seed。
- 29 个匹配的真实 GraphQL-go-tools 任务，加上原始 28 个 Zod 任务作为上下文。
- LLM-as-judge 是 GPT-5.4；judge 看到补丁和任务，但不知道 model/effort 标签。
- 这个任务集没有 grader calibration。
- No-patch rows 会降低 low、high 和 xhigh 的可发布分母，而且这些行上的内建 equivalence / code-review coverage 是部分覆盖。我把它视为重试后的 model/harness 信号的一部分，而不是一个应当丢弃运行的 infra 原因。
- Max 对这个 inspect/readout 达到 decision-grade，但这仍然是 inspect result，而不是 promote result，因为指标是混合的，并且在主要维度上比 medium 更差。
结论
在这个切片上，实践答案很清楚：用 medium。话虽如此，请把它读作方向性结果，而不是绝对结论。
就我个人而言，接下来我会尝试：
- 把 medium 作为大多数任务的日常默认
- 对探索性、复杂或横跨多个区域的任务，选择性考虑 xhigh 或 max，然后衡量它是否真的有帮助
Reasoning effort 显然重要，但这条曲线并不平滑，不能支撑一个宽泛建议。
不过，你的结果可能不同。这就是为什么团队应该在自己的任务上衡量自己的 harness，而不是照搬全局 benchmark 默认值。
Disclosure：我正在构建 Stet.sh，也就是我用来跑这个实验的本地 eval 工具。产品版本是，你可以让你的 coding agent 改进自己的 setup，例如让 AGENTS.md 更好，然后它用 Stet 对历史 repo 任务测试候选改动。如果你的团队已经大量使用 coding agents，并且眼前有一个具体决策，比如 high vs xhigh、Codex vs Claude Code、一次 AGENTS.md 更新，或者哪些任务可以安全委托，我正在寻找少数团队来跑 repo-specific trials。Stet 完全本地运行，使用你的 LLM subscriptions。加入 waitlist：https://www.stet.sh/private，或者直接联系我。
数据很棒，但我也对 anecdotal experience 感兴趣。大家最近觉得 Opus 4.7 在不同 reasoning efforts 上表现如何？你默认用哪一个？如果你根据证据而不是感觉改过团队默认设置，我尤其想听听你是怎么衡量的。