GPT-5.5 low vs medium vs high vs xhigh：在开源仓库 26 个真实任务上的推理曲线
我在同一个开源仓库（用 Go 写的 GraphQL-go-tools）的 26 个任务上，用所有 reasoning effort 设置（low、medium、high 和 xhigh）跑了一遍 GPT-5.5 Codex。
Low 和 medium 在测试上打平，都是 21/26，但 medium 在与原始人工 PR 的语义等价性上好得多，review 质量也更高。High 看起来像实践中的甜点位。Xhigh 产出了最好的等价性/review 分数，但成本高得多。
Reasoning effort 似乎改变的不只是测试通过率，而是 Codex 产出 patch 的_类型_。
Low → medium：更少启发式/局部实现，更多 repo/domain 建模。
Medium → high：实践中的关键跃升。更多任务变得完整、集成得当、可 review，而且不需要 xhigh 级别的成本。
High → xhigh：质量模式。复杂任务表现更好，但昂贵且慢。
对我来说，一个更大的 takeaway 是：这不应该只是一次性的手工 benchmark。如果 reasoning level 会改变 agent 写出的 patch 类型，自然的下一步就是让 agent 在真实 repo 工作上测试并改进自己的 setup。
数据先放这里（后文会继续展开）：
本文中的“equivalent”指 patch 匹配了已合并人工 PR 的意图；“code-review pass”指 AI reviewer 判断它可以接受；craft/discipline 是 0-4 分的可维护性/风格 rubric；footprint risk 衡量 agent 相对于人工 patch 多触碰了多少代码。
GPT-5.5 Codex on GraphQL-go-tools: tests say low and medium tie, but equivalence climbs 15% -> 42% -> 69% -> 88%. High is the best cost-quality point; xhigh buys more review quality but costs 3.7x low and regresses on tests versus high.
Per-task drilldown - sorted by widest spread
Enter opens profile; Tab moves between rows.
Inspect-grade stitched four-arm curve. Medium/high come from a completed but insufficient-evidence rules compare; low and xhigh are clean candidate-arm runs on the matched 26-task slice.
Xhigh aggregate cost/cache values are preserved from clean pre-regrade evidence because the post-regrade xhigh summary has null per-task task_cost and cache-token fields.
Xhigh code-review rubric means are recovered from task-level validation.json artifacts because the post-regrade xhigh summary preserved review pass/fail signals but dropped flattened code_review RubricScores.
Cost skew: Top two xhigh-cost tasks account for 39.6% of xhigh matched-slice cost. Mean cost is therefore worth reading next to median cost.
Reproduce from the source summaries listed in the raw JSON; regenerate the chart data with npm --prefix leaderboard exec tsx scripts/build-gpt55-graphql-reasoning-curve.mjs.
为什么我跑了这个实验
在上一篇对比 GPT-5.5 vs 5.4 vs Opus 4.7 的文章之后，我很好奇同一模型内部的表现会如何随 reasoning effort 变化。在 X/Reddit/HN 上，我看到过不少关于 GPT-5.5 哪个 reasoning effort 最优的猜测（有人认为 low/medium 比 high/xhigh 更好，因为 high/xhigh 会“想太多”；这是 5.4 和 5.3-codex 的已知失败模式）。
为了把氛围判断和现实分开，也为了弄清 GPT-5.5 的成本/性能甜点位在哪里，我跑了这个实验。
这并不打算成为一个通用 benchmark 结果。我没有资金或时间去生成具有统计显著性的数据。它的目的更接近于回答“我应该如何为真实 repo 工作选择 reasoning 设置？”，并以 GraphQL-Go-Tools 作为示例 repo。
公开 benchmark 会抹平大多数 SWE 真正在意的 review 问题：我真的会合并这个 patch 吗？我愿意维护它吗？这就是我跑这个测试的原因：在一个小规模实验里，更深入地观察 coding agents 在真实世界任务上的表现。
Terminal-Bench 主要是偏冷门的 coding 问题，SWE-bench verified 已经被污染（模型基本已经把答案吃进去了），SWE-bench Pro 有用但很泛。这不是在否定 SWE-bench 或 Terminal-Bench。标准化 benchmark 很有用，但它们主要回答的是一个二元的任务结果问题。
我日常真正关心的问题更窄，也更烦人：agent 做出的改动是否和人类在我的 codebase 里合并的改动属于同一种变化？之后我是否愿意拥有这个 patch？
实验设置
每个任务都来自一个真实已合并的 PR 或 commit。模型拿到一个冻结的 repo snapshot、一段描述改动的 prompt，以及一次在 Docker container 中产出 patch 的机会。然后 Stet 应用这个 patch，并在隔离 container 中运行该任务的测试，检查它通过还是失败。
之后 Stet 会在 pass/fail 之外继续给结果打分：
- Equivalence: candidate patch 是否完成了与原始人工 patch 相同的行为变化？
- Code review: 如果考虑正确性、引入 bug 的风险、可维护性和边界情况，reviewer 是否会接受这个 patch？
- Footprint risk: 与人工 patch 相比，agent 多触碰了多少额外代码？
- Craft/discipline rubrics: 试图捕捉代码中非正确性层面的方面。基本问题是 reviewer 是否愿意维护这段代码。类别包括 clarity、simplicity、coherence、intentionality、robustness、instruction adherence、scope discipline 和 diff minimality
每个模型在每个任务上用单个 seed 跑一次。LLM-as-a-judge 模型是 GPT-5.4。每个 patch 都独立评分：judge 看到 patch 和任务，但看不到产出 patch 的 model/effort 标签。我也手工检查了有代表性的例子作为 sanity checks。这个任务集上没有做人类校准 pass，所以相比任何单个绝对分数，我更信任 delta 的方向。
顺便说一句，我也一直把这些 evaluation 当成一种“autoresearch”优化循环，而不只是 benchmark。我会对 agent 说类似“把这个 repo 的 AGENTS.md 变得更好”；它提出一个 edit，在历史任务上跑 Stet，弄清 candidate 在哪里更好/更差以及原因，然后迭代来提高 evaluation 数字。
细节：
- 模型: GPT-5.5
- Harness: Codex 0.128.0
- 数据集: 26 个匹配的真实 GraphQL-go-tools 任务。
- 是的，这个规模很小，不过就连跑这一点也用掉了我每周 20x quota 的约 50+%
- 主要指标:
- 测试通过
- semantic equivalence
- code-review pass
- footprint risk
- craft/discipline custom graders
- 成本和运行时间
Low 到 Medium：从启发式到领域建模
我们直接看数据！
Low 和 medium 都在 21/26 个任务上通过测试。如果测试是唯一指标，low 和 medium 看起来会是打平。
然而，当我们看语义等价性时，从 low 到 medium 的跃升是 4/26 到 11/26。类似地，code-review pass 从 3/26 跳到 5/26，aggregate craft/discipline 分数从 2.311 升到 2.604。
在这个切片里，只看测试会错过大部分 reasoning-effort 差异。
只衡量测试的 coding-agent evals 会抹平人类 review patch 时在意的差异。
从一个职业软件工程师的角度说，我希望 AI 合并进团队 codebase 的代码不只是通过测试。它还要清晰、可维护、处在正确的抽象层次，并遵循 codebase 的标准。
例子：PR #1297 要求 agent 验证 GraphQL Federation 中可空的外部 @requires 依赖。如果一个可空的 required field 返回 null 并带有错误，依赖它的下游 fetch 不应该收到这个被污染的 entity。
- 任务：建模一个微妙的 federation 数据依赖规则，而不只是增加一个 validation 分支。
- 低 effort 失败模式：low 通过了测试，但因为使用启发式的 required-field/error 匹配，并漏掉了结构化的可空
@requiresmetadata，所以它不等价且 review 失败。 - 高 effort 变化：medium 变得等价、通过 review，追踪 tainted objects，过滤下游 fetch inputs，并把 craft/discipline 质量从
1.350提高到3.225。 - 经验：medium 不再猜测，而是开始表示真实的 federation 行为。High 和 xhigh 保持在同一个质量带里，所以这主要是一个 low-to-medium 的例子。
High 看起来是实践中的甜点位
High 对 medium：
High 是最干净的实践升级。它提升了显性的指标，也提升了语义/review 指标，同时成本有明显上升但并不荒唐。
High 似乎是额外 tokens 开始换来真实收益的点，也就是集成细节更经常正确的点。
我们看几个例子：
PR #1209 要求 gRPC datasource 在 response JSON 中尊重 GraphQL aliases，提前验证引用的 protobuf message types，并更新 union/interface mutation paths 的 mapping coverage。
- 任务：把 alias/response-key 语义贯穿 planning、marshaling 和 gRPC mapping coverage。
- 低 effort 失败模式：low 和 medium 都通过了测试，但仍然不等价且 review 失败。Medium 处理了很多 alias serialization 和 missing-message validation，但漏掉了
createUsermutation mapping update，并把 response-key 语义塞进了JSONPath。 - 高 effort 变化：high 成为第一个 strict pass。它引入了显式 response-key/alias handling，把 aliases 贯穿 planning 和 JSON marshaling，并把 custom quality 提高到
3.625。 - 经验：high 不只是多加了代码。它准确抓住了 integration obligation。Xhigh 也通过了，但没有改善这个任务层面的理解，而且在重新生成的 summary 中慢得多（
790.7sagent duration，相比 high 的314.0s）。
PR #1155 是一个宽泛的 gRPC datasource hardening 任务：支持 repeated scalar fields，避免 null/invalid message panics，传播 gRPC status codes，允许禁用 datasource，并支持 dynamic clients。
- 任务：跨 gRPC datasource 行为硬化多个生产边界。
- 低 effort 失败模式：low 和 medium 测试为绿，但不等价。Medium 提升了 robustness，但仍然把 invalid repeated fields 序列化为空数组，漏掉了 aliased-root planning behavior，并存在 dynamic-client lifecycle 风险。
- 高 effort 变化：high 变得等价并通过 review，具备更安全的 nil/invalid handling、status-code propagation、disabled-datasource behavior 和 dynamic client-provider coverage。
- 经验：这也是一个 high-vs-xhigh 反转。Xhigh 仍然通过测试，但因为 disabled datasource semantics 和 invalid-list behavior 错误，变得不等价且 review 失败。
Xhigh 质量更好，但不明显是更好的默认值
Xhigh 对 high：
Xhigh 似乎买来了语义和 review 质量，但它不是一个简单的“把旋钮拧高，一切都会变好”的故事。它很贵，而且测试不是单调提升的。
看起来 xhigh 产出的代码更贴近人类意图，覆盖更多方面，改动也更完整，代价是多得多的 tokens。Review-rubric mean/median 也讲了同一个故事：xhigh 得到 3.365 mean / 3.500 median，而 high 是 2.817 mean / 2.750 median。Median 高于 mean 这件事很重要：这不是只有一两个特别好的 xhigh patches 把平均值拉上去。
一个注意点：xhigh 看起来语义上更完整，但相对于人工 patch，它也倾向于触碰更多代码，从而提高 footprint risk。这是这次运行中有意思的张力：xhigh 更可能在语义上匹配人工 PR，但也更愿意扩大 patch surface。
我检查了额外 surface 主要是测试还是生产逻辑。用一个简单的 file-path split 覆盖 26 个匹配任务，xhigh 总共新增 13,144 行：5,918 行 implementation 和 7,226 行 test、fixture 或 expected-output。与 high 相比，xhigh 多增加了 2,631 行，其中 2,436 行额外新增行位于 test/fixture/expected-output files。所以 footprint 增长不只是“模型写了一大堆生产代码”。很大一部分是 xhigh 在构建更多验证和 fixture coverage。尽管如此，这仍然是真实的 review surface：有人也必须阅读并维护这些测试、fixtures 和 expected-output updates。
一些例子：
PR #1076 重构 subscription handling 以避免 shared-mutex race conditions：per-subscription serialized writes、per-subscription heartbeat control、race detector coverage，以及修正的 WebSocket close semantics。
- 任务：从 subscription delivery 中移除 concurrency risk，同时不破坏 close/unsubscribe behavior。
- 低 effort 失败模式：medium 通过了测试，但不等价且 review 失败。High 变得等价并遵循指令，但仍然 review 失败，因为新的 worker queue 可能阻塞 global subscription event loop，shutdown 可能卡在 stuck worker 后面，hung updates 没有边界，client-level unsubscribe 仍然跳过 internal subscriptions。
- 高 effort 变化：xhigh 是第一个 strict pass，并把 custom quality 提高到
3.475。 - 经验：这是 xhigh 作为质量模式的最佳例子。在一个 concurrency-heavy 任务中，额外开销买来了 review-risk cleanup，而更简单的信号没有完全捕捉到它。
PR #1308 实现 GraphQL @oneOf input objects：增加 built-in directive，通过 introspection 暴露它，验证 operation literals 和 runtime variables，并改进 undefined-variable source locations。
- 任务：跨 schema、introspection、operation validation 和 runtime variables 实现一个横切的 GraphQL validation feature。
- 低 effort 失败模式：medium 和 high 都通过了测试，但仍然不等价且 review 失败，因为它们漏掉了关于 runtime variables、nullable variables、provided-null payloads 或 introspection shape 的重要
@oneOfsemantics。 - 高 effort 变化：xhigh 是第一个 strict pass，robustness 为
3.7，instruction adherence 为4.0，custom quality 为3.525。 - 经验：差异不是表面的润色。Xhigh 处理了系统多个部分的 edge-case coverage。
PR #1240 要求 agent 把 GraphQL AST field-selection merging 和 inline-fragment selection merging 合并进一个 normalization walk。
- 任务：在不改变 executable merge semantics 的前提下，重构重复的 normalization behavior。
- 低 effort 成功：low 和 high 是 strict passes。
- 高 effort 失败模式：xhigh 在 semantic-grader 层面仍然等价，但 review 失败，因为它仍然保留了 prioritized subpasses，改变了
AbstractFieldNormalizerordering，并留下了废弃的 field-merge registration。 - 经验：更高 reasoning 可能产出一个更复杂、看起来合理的 refactor，但仍然漏掉测试和 reviewer 真正在意的准确 executable behavior。
Craft 与 Discipline
Custom graders 展示了和 review rubric 一样的整体提升。Xhigh 的 all-custom 分数是 3.071 mean / 3.087 median，而 high 是 2.736 mean / 2.688 median。Craft 和 discipline 的 median 也都更高，这支持了一个判断：xhigh 通常提升了 patch 质量，而不是只产出少数几个特别突出的例子。
从这里我们可以解读出：
- Low 的 robustness 和 instruction adherence 偏弱。
- Medium 在没有提高 aggregate test pass 的情况下，修复了相当一部分这类问题。
- High 提升了实践正确性和 robustness。
- Xhigh 几乎提升了每个维度，包括 scope 和 diff discipline。
成本和运行时间
Low 的成本分布是偏斜的，xhigh 尤其明显。Xhigh 的 median 仍然更贵，但 mean 被少数昂贵任务拉高。Runtime 大体跟随 mean，因此成本故事比时间故事更偏斜。Xhigh 在 median 上仍然明显更慢。
- High 每个任务的成本大约是 medium 的 1.43x。
- Xhigh 每个任务的成本大约是 high 的 2.18x。
- Xhigh 成本被 outliers 拉偏，但它的 median task cost 仍然高于 high。
局限性
我并不是在假装这是一个有统计显著性的结果，也不是说这个结果会迁移到你的 repo。没关系！
只要我们意识到这只是一次运行、一个时间点、一个 repo 上的结果，我们仍然可以用它来获得 insight，思考自己的 reasoning settings，这就有帮助。
具体的局限 / methodology gaps：
- 每个任务单个 seed。
- 26 个匹配的真实 GraphQL-go-tools 任务。
- LLM-as-judge 是 GPT-5.4；judge 看到了 patch/task，但没看到 label（所以理论上不知道模型）。
- 这个任务集上没有 grader calibration。
相关先例
Voratiq 当前的真实工作 leaderboard 指向了同一个方向，尽管 methodology 很不一样。在他们的榜单上，GPT-5.5 xhigh 是 1994，GPT-5.5 high 是 1807，rating 提升 +187 点 / +10.3%；成本是 $4.23 vs $2.52（+67.9%），duration 是 11.9m vs 7.8m（+52.6%）。我的 Stet 切片在等价性（+19.2pp，相对 +27.8%）和 code-review pass（+30.8pp，相对 +80.0%）上显示了更大的 high → xhigh 提升，但 craft/discipline aggregate 的提升非常接近（+12.2%）。
不过，Voratiq 是一个围绕持续工作的 preference/selection-style leaderboard，而这里是一个跨多个 reasoning level 的 26 任务 repo 切片，所以两者不能直接比较。但它确实让这个形状没那么令人意外。Xhigh 似乎更多买来的是 reviewer-preferred / quality outcomes，而不是一个干净的 test-pass default。
结论
数据支持在模糊、横切、concurrency-heavy 或 high-review-risk 的工作上使用 xhigh。实践建议是把 high 作为默认日常档位；在成本更重要、任务常规或范围清楚时，使用 medium/更低设置。
Reasoning effort 显然重要，但这条曲线在单个任务层面并不平滑，也不是单调的。随着 reasoning 增加，aggregate quality 通常提高，但单个任务仍然会出现 high 胜过 xhigh、或更高设置做出看似合理但错误的实现选择的反转。
具体来说：
- Medium 比 low 更可靠地开始建模 repo/domain semantics。
- High 看起来是这个 dataset 上最好的实践设置。
- Xhigh 看起来是质量模式，而不是默认值。
我之后会这样做：继续把 high 作为日常默认档位；对于探索性/复杂工作，使用 xhigh。
不过，你的结果可能不同。这就是为什么团队应该在自己的任务上衡量自己的 harnesses，而不是照搬全局 benchmark 默认值。
披露：我正在构建 Stet.sh，也就是我用来跑这个实验的本地 eval 工具。产品版本的思路是，你可以让 coding agent 改进自己的 setup，例如把 AGENTS.md 变得更好，然后它会用 Stet 对历史 repo 任务测试 candidate changes。如果你的团队已经重度使用 coding agents，并且面前有一个具体决策，比如 high vs xhigh、Codex vs Claude Code、一项 AGENTS.md 更新，或哪些任务可以安全委派，我正在寻找少数团队来跑 repo-specific trials。Stet 完全在本地运行，使用你的 LLM subscriptions。你也可以直接联系我。
数据很重要，但我也很想听 anecdotal experience。大家最近在不同 reasoning efforts 下使用 GPT-5.5 的体验如何？哪一个是你的默认设置？如果你已经基于证据而不是氛围调整了团队默认值，我尤其想听听你们是怎么衡量的。