# GPT-5.5 Codex low、medium、high 与 xhigh：GraphQL-go-tools 26 个真实任务上的推理曲线

Stet publishes a public search API over its indexed pages; the guide is at https://www.stet.sh/agents/agent-access.

Source: https://www.stet.sh/zh/blog/gpt-55-codex-graphql-reasoning-curve
Source observed: 2026-11-08T19:51:35.660Z
Last checked: 2026-11-08T19:51:35.66+00:00
Indexed: 2026-11-08T20:37:47.257+00:00

---

# GPT-5.5 Codex low、medium、high 与 xhigh：GraphQL-go-tools 26 个真实任务上的推理曲线

**发布日期：**2026年5月7日 · 14 分钟阅读  
**作者：**[Ben，Stet 创始人](https://www.stet.sh/about)

我们在用 Go 编写的开源仓库 GraphQL-go-tools 上，选取 26 个真实、已经合并的任务，分别用 GPT-5.5 Codex 的四档 reasoning effort——low、medium、high、xhigh——各运行一次。我们比较的不只是测试是否通过，还比较 patch 是否实现与人工 PR 相同的行为变化、是否能通过代码审查、触碰了多少额外代码，以及可维护性和风格质量。

## 摘要

核心结果如下：

- Low 与 medium 都通过 **21/26** 个测试，但质量并不相同。
- 语义等价性从 low 的 **4/26（15%）**，提升到 medium 的 **11/26（42%）**、high 的 **18/26（69%）**、xhigh 的 **23/26（88%）**。
- Code-review pass 从 **3/26（12%）**、**5/26（19%）**、**10/26（38%）** 提升到 xhigh 的 **18/26（69%）**。
- High 在这组任务中是最好的实际成本—质量平衡点。
- Xhigh 通常带来更高的等价性、review 和 custom-grader 分数，但成本明显更高，测试通过率反而低于 high。
- Reasoning effort 改变的似乎不只是测试通过率，也改变了 Codex 产出 patch 的类型：low 更容易使用启发式和局部实现；medium 开始建模 repo/domain；high 更常完成集成细节；xhigh 更像质量模式，适合复杂、横切和高 review 风险任务。

### 总体结果

| 指标 | Low | Medium | High | Xhigh | 方向或说明 |
| --- | ---: | ---: | ---: | ---: | --- |
| 测试通过 | 81% | 81% | 96% | 92% | 非单调；low 与 medium 打平，xhigh 低于 high |
| 等价 | 15% | 42% | 69% | 88% | 单调提升 |
| Review pass | 12% | 19% | 38% | 69% | 单调提升；xhigh 为 18/26 |
| Review rubric 均值（0–4） | 2.02 | 2.51 | 2.82 | 3.37 | 提升 |
| All-3 pass（测试+等价+review） | 3/26 | 5/26 | 10/26 | 17/26 | High 是实际成本—质量平衡点 |
| Footprint risk 均值（0–1，越低越好） | 0.200 | 0.268 | 0.314 | 0.365 | reasoning 越高，风险越高 |
| 每任务成本均值 | $2.65 | $3.13 | $4.49 | $9.77 | Xhigh 均值受两个昂贵任务影响 |
| 每任务成本中位数 | $1.91 | $2.87 | $3.99 | $6.39 | 中位数仍显示 xhigh 更贵 |
| Agent duration 均值 | 287s | 411s | 579s | 12m 33s | 提升 |
| 输入 tokens 总量 | 61.1M | 109.3M | 159.9M | 217.9M | 提升 |
| All-3 / dollar | 0.04 | 0.06 | 0.09 | 0.07 | High 的效率最高 |
| Equiv / dollar | 0.06 | 0.13 | 0.15 | 0.09 | High 的效率最高 |

等价性的曲线是 **15% → 42% → 69% → 88%**；但测试通过率不是单调曲线。Xhigh 为了更高的 review 质量付出更多成本，其平均成本约为 low 的 **3.7 倍**，并且测试结果低于 high。

### 指标定义

- **Equivalent：** candidate patch 是否匹配已合并人工 PR 的意图，并完成相同的行为变化。
- **Code-review pass：** AI reviewer 综合正确性、引入 bug 的风险、可维护性和边界情况后，是否会接受 patch。
- **Footprint risk：** agent 相对于人工 patch 多触碰了多少代码，范围为 0–1，越低越好。
- **Craft/discipline：** 0–4 分的可维护性和风格 rubric，涵盖 clarity、simplicity、coherence、intentionality、robustness、instruction adherence、scope discipline 和 diff minimality。

## 为什么我们运行这个实验

在比较 GPT-5.5、GPT-5.4 和 Opus 4.7 后，我们想了解同一个模型内部的表现如何随 reasoning effort 改变。围绕 GPT-5.5 应使用 low/medium 还是 high/xhigh，已有许多基于直觉的判断；我们希望在真实 repo 工作上观察成本、测试、语义等价性和 review 质量的关系。

这不是一个通用 benchmark，也没有足够资金或时间生成统计显著性数据。它用于回答一个更具体的问题：在真实 repo 工作中，我们应该如何选择 reasoning 设置？GraphQL-go-tools 是本实验的示例仓库。

标准化 benchmark 通常主要回答任务是否完成这一类二元问题，而我们还关心：agent 做出的修改是否属于人类在该 codebase 中已经合并的同一种变化，以及我们之后是否愿意拥有和维护这个 patch。

我们也把这些 evaluation 当作一种“autoresearch”优化循环：让 agent 修改 repo 的 `AGENTS.md` 等 setup，在历史任务上运行 Stet，观察 candidate 在哪里更好或更差，再迭代提高 evaluation 分数。

## 实验设置

每个任务都来自一个真实、已合并的 PR 或 commit。模型获得：

1. 冻结的 repo snapshot；
2. 描述预期改动的 prompt；
3. 在 Docker container 中产出 patch 的一次机会。

Stet 应用 patch，并在隔离 container 中运行任务测试。随后我们在 pass/fail 之外评估 equivalence、code review、footprint risk 和 craft/discipline。

实验细节：

- **模型：** GPT-5.5
- **Harness：** Codex 0.128.0
- **数据集：** GraphQL-go-tools 上 26 个匹配的真实任务
- **每个任务：** 每个模型使用单个 seed 运行一次
- **LLM judge：** GPT-5.4
- **盲评：** judge 能看到 patch 和任务，但看不到产出 patch 的 model/effort 标签
- **人工检查：** 我们手工检查了代表性例子作为 sanity checks
- **校准：** 这组任务没有 human calibration pass，因此我们更重视 delta 的方向，而不是任何单一绝对分数
- **资源：** 运行这组小数据集就消耗了每周 20x quota 的约 50% 以上

## Low → Medium：从启发式到领域建模

Low 与 medium 都通过 **21/26** 个测试。如果只看测试，两者看起来相同；但语义等价性从 **4/26** 提升到 **11/26**，code-review pass 从 **3/26** 提升到 **5/26**，aggregate craft/discipline 从 **2.311** 提升到 **2.604**。

只看测试会错过这组数据中大部分 reasoning-effort 差异。我们希望进入团队 codebase 的代码不仅通过测试，也要清晰、可维护、处于正确抽象层次，并遵循 codebase 标准。

### 示例：PR #1297

该任务要求验证 GraphQL Federation 中可空的外部 `@requires` 依赖：如果一个可空的 required field 返回 null 并伴随错误，依赖它的下游 fetch 不应收到被污染的 entity。

- **任务：** 建模微妙的 federation 数据依赖规则，而不是简单增加 validation 分支。
- **Low 失败模式：** low 通过测试，但使用启发式的 required-field/error 匹配，遗漏结构化的可空 `@requires` metadata，因此不等价且 review 失败。
- **Medium 的变化：** medium 追踪 tainted objects，过滤下游 fetch inputs，成为等价并通过 review；craft/discipline 从 **1.350** 提高到 **3.225**。
- **结论：** medium 不再猜测，而是开始表示真实 federation 行为；high 和 xhigh 在这个例子中保持在同一质量带内。

## Medium → High：实践中的甜点位

| 指标 | Medium | High | Δ |
| --- | ---: | ---: | ---: |
| 测试通过 | 21/26，80.8% | 25/26，96.2% | +15.4pp |
| 等价 | 11/26，42.3% | 18/26，69.2% | +26.9pp |
| Code-review 通过 | 5/26，19.2% | 10/26，38.5% | +19.2pp |
| Footprint risk 均值 | 0.268 | 0.314 | +0.046 |
| Craft/Discipline 平均 | 2.604 | 2.736 | +0.132 |
| 每任务成本均值 | $3.13 | $4.49 | +$1.35，1.43x |
| 平均耗时 | 411.0s | 579.0s | +168.0s |

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。
- **Low/Medium 失败模式：** 两者都通过测试，但不等价且 review 失败。Medium 处理了许多 alias serialization 和 missing-message validation，却漏掉 `createUser` mutation mapping update，并把 response-key 语义塞进 `JSONPath`。
- **High 的变化：** high 成为第一个 strict pass，引入显式 response-key/alias handling，让 aliases 贯穿 planning 和 JSON marshaling，custom quality 提升到 **3.625**。
- **Xhigh：** 也通过了，但没有改善这个任务层面的理解；重新生成的 summary 中，xhigh agent duration 为 **790.7s**，high 为 **314.0s**。

### 示例：PR #1155

这是一个 gRPC datasource hardening 任务，涉及 repeated scalar fields、null/invalid message panic、gRPC status-code 传播、禁用 datasource 和 dynamic clients。

- **Low/Medium 失败模式：** 两者测试为绿但不等价。Medium 提升了 robustness，却把 invalid repeated fields 序列化为空数组，遗漏 aliased-root planning behavior，并存在 dynamic-client lifecycle 风险。
- **High 的变化：** high 变得等价并通过 review，改善 nil/invalid handling、status-code propagation、disabled-datasource behavior 和 dynamic client-provider coverage。
- **High/Xhigh 反转：** xhigh 仍通过测试，但因 disabled datasource semantics 和 invalid-list behavior 错误而不等价且 review 失败。

## High → Xhigh：质量更好，但不一定适合作为默认值

| 指标 | High | Xhigh | Δ |
| --- | ---: | ---: | ---: |
| 测试通过 | 25/26，96.2% | 24/26，92.3% | -3.8pp |
| 等价 | 18/26，69.2% | 23/26，88.5% | +19.2pp |
| Code-review 通过 | 10/26，38.5% | 18/26，69.2% | +30.8pp |
| Footprint risk 均值 | 0.314 | 0.365 | +0.051 |
| Craft/Discipline 平均 | 2.736 | 3.071 | +0.335 |
| 每任务成本均值 | $4.49 | $9.77 | +$5.29，2.18x |
| 平均耗时 | 579.0s | 753.3s | +174.3s |

Xhigh 提升语义和 review 质量，但不是“把旋钮拧高后一切都变好”：它成本很高，测试通过率还低于 high。

Review-rubric 分数也支持这一点：

- **Xhigh：** 3.365 mean / 3.500 median
- **High：** 2.817 mean / 2.750 median

Xhigh 的 median 高于 mean，说明提升不只是少数特别好的 patch 拉高平均值。

代价是 footprint risk 上升。Xhigh 更可能匹配人工 PR 的语义，但也更愿意扩大 patch surface。在 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 增长不只是生产代码变多，也来自更多验证和 fixture coverage；但这些测试、fixtures 和 expected outputs 仍然需要 review 和维护。

### 示例：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。
- **Medium：** 通过测试但不等价且 review 失败。
- **High：** 等价并遵循指令，但仍因 worker queue 可能阻塞 global subscription event loop、shutdown 可能卡在 stuck worker 后、hung updates 没有边界，以及 client-level unsubscribe 跳过 internal subscriptions 而 review 失败。
- **Xhigh：** 第一个 strict pass，custom quality 提高到 **3.475**。
- **结论：** 在 concurrency-heavy 任务中，xhigh 的额外开销买来了 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。
- **Medium/High：** 都通过测试，但不等价且 review 失败，遗漏 runtime variables、nullable variables、provided-null payloads 或 introspection shape 等重要 `@oneOf` semantics。
- **Xhigh：** 第一个 strict pass；robustness **3.7**，instruction adherence **4.0**，custom quality **3.525**。

### 示例：PR #1240

该任务要求把 GraphQL AST field-selection merging 与 inline-fragment selection merging 合并进一个 normalization walk，同时不改变 executable merge semantics。

- **Low/High：** strict pass。
- **Xhigh：** semantic-grader 仍判定等价，但 review 失败，因为仍保留 prioritized subpasses，改变 `AbstractFieldNormalizer` ordering，并留下废弃的 field-merge registration。
- **结论：** 更高 reasoning 可能产生更复杂、看似合理的 refactor，却仍然错过测试和 reviewer 真正在意的 executable behavior。

## Craft 与 Discipline

Custom graders 整体随 reasoning effort 提升。Xhigh 的 all-custom 分数为 **3.071 mean / 3.087 median**，High 为 **2.736 mean / 2.688 median**。Craft 和 discipline 的 median 也更高。

| 指标 | Low 均值 / 中位数 | Medium 均值 / 中位数 | High 均值 / 中位数 | Xhigh 均值 / 中位数 |
| --- | ---: | ---: | ---: | ---: |
| Craft aggregate | 2.327 / 2.338 | 2.618 / 2.525 | 2.781 / 2.787 | 3.126 / 3.100 |
| Discipline aggregate | 2.295 / 2.325 | 2.590 / 2.588 | 2.691 / 2.688 | 3.015 / 3.013 |
| All custom graders | 2.311 / 2.338 | 2.604 / 2.550 | 2.736 / 2.688 | 3.071 / 3.087 |

| 分数维度 | Medium − Low | High − Medium | Xhigh − High | Xhigh − Low |
| --- | ---: | ---: | ---: | ---: |
| Craft average | +0.291 | +0.162 | +0.345 | +0.799 |
| Discipline average | +0.295 | +0.101 | +0.324 | +0.720 |
| All custom graders | +0.293 | +0.132 | +0.335 | +0.760 |
| Simplicity | +0.069 | +0.038 | +0.315 | +0.423 |
| Coherence | +0.500 | +0.181 | +0.423 | +1.104 |
| Intentionality | +0.147 | +0.004 | +0.065 | +0.216 |
| Robustness | +0.450 | +0.427 | +0.577 | +1.454 |
| Clarity | +0.054 | +0.088 | +0.131 | +0.273 |
| Instruction adherence | +0.531 | +0.519 | +0.381 | +1.431 |
| Scope discipline | +0.354 | -0.058 | +0.381 | +0.677 |
| Diff minimality | +0.242 | -0.146 | +0.404 | +0.500 |

可见模式：

- Low 的 robustness 和 instruction adherence 较弱。
- Medium 在没有提高 aggregate test pass 的情况下，修复了相当一部分问题。
- High 提升了实践正确性和 robustness。
- Xhigh 几乎提升了每个维度，包括 scope 和 diff discipline。

## 成本和运行时间

| Reasoning effort | 任务成本均值 | 任务成本中位数 | Agent duration 均值 | Agent duration 中位数 |
| --- | ---: | ---: | ---: | ---: |
| Low | $2.65 | $1.91 | 286.9s | 294.6s |
| Medium | $3.13 | $2.87 | 411.0s | 371.8s |
| High | $4.49 | $3.99 | 579.0s | 572.9s |
| Xhigh | $9.77 | $6.39 | 753.3s | 732.7s |

Low 的成本分布偏斜，xhigh 尤其明显。Xhigh 的 mean 被少数昂贵任务拉高，但 median 仍显著高于 high。Runtime 大体跟随 mean，因此成本比时间更受 outliers 影响。

- High 每任务成本约为 medium 的 **1.43x**。
- Xhigh 每任务成本约为 high 的 **2.18x**。
- Xhigh 成本最高的两个任务占 xhigh matched-slice 成本的 **39.6%**。

## 每任务明细

页面按 widest spread 展示了 26 个任务：

`graphql-go-tools#891`、`#1128`、`#1076`、`#1297`、`#1308`、`#1338`、`#1230`、`#1184`、`#1232`、`#1241`、`#1034`、`#1209`、`#1380`、`#1155`、`#1169`、`#1309`、`#817`、`#828`、`#1262`、`#870`、`#1099`、`#1260`、`#1087`、`#1268`、`#1001`、`#1240`。

其中 `graphql-go-tools#891` 的任务剖面为：

| 指标 | Low | Medium | High | Xhigh |
| --- | --- | --- | --- | --- |
| Tests pass | pass | fail | pass | pass |
| Equivalence | -0.95 | -- | 0.98 | 0.98 |
| Review pass | fail | fail | pass | pass |
| Review rubric | 0.75 | 2.00 | 4.00 | 4.00 |
| All-3 pass | 1/3 | 0/3 | 3/3 | 3/3 |
| Footprint risk | 0.116 | 0.280 | 0.247 | 0.247 |
| Mean duration | 407s | 430s | 586s | 450s |
| Craft | 1.57 | 2.13 | 3.73 | 3.65 |
| Discipline | 1.18 | 2.38 | 3.55 | 3.52 |

## 方法和数据处理说明

这是一条 inspect-grade stitched four-arm curve：medium/high 来自一次已完成但证据不足的 rules compare；low/xhigh 是同一 26 任务 matched slice 上的干净 candidate-arm runs。

Xhigh aggregate cost/cache 值取自干净的 pre-regrade evidence，因为 post-regrade xhigh summary 的 per-task `task_cost` 和 cache-token 字段为空。Xhigh code-review rubric 均值则从 task-level `validation.json` artifacts 恢复，因为 post-regrade summary 保留了 review pass/fail 信号，但删除了扁平化的 `code_review RubricScores`。

如需重现，原始 JSON 中列出了 source summaries；可使用以下命令重新生成图表数据：

```bash
npm --prefix leaderboard exec tsx scripts/build-gpt55-graphql-reasoning-curve.mjs
```

## 局限性

我们不把这组数据作为具有统计显著性的通用结论，也不把它直接迁移到其他 repo。局限包括：

- 每个任务只有一个 seed。
- 数据集只有 GraphQL-go-tools 上 26 个匹配的真实任务。
- LLM-as-judge 使用 GPT-5.4；judge 看到了 patch/task，但没有看到 label。
- 这组任务没有 grader calibration pass。

## 相关证据

[Voratiq leaderboard](https://voratiq.com/leaderboard) 的真实工作榜单方向相近，但方法不同。其数据中：

- 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 切片显示 high → xhigh：

- 等价性 **+19.2pp**，相对 **+27.8%**；
- code-review pass **+30.8pp**，相对 **+80.0%**；
- craft/discipline aggregate 提升约 **+12.2%**。

两者不能直接比较：Voratiq 是围绕持续工作的 preference/selection-style leaderboard，而我们的数据是跨多个 reasoning level 的 26 任务 repo slice。它们共同指向的方向是：xhigh 更可能购买 reviewer-preferred 和 quality outcomes，而不是一个干净的 test-pass default。

## 结论与实际建议

这组数据支持以下使用方式：

- **High：** 日常默认档位；在本数据集上是最好的实践成本—质量点。
- **Medium 或更低：** 成本更重要、任务常规或范围清楚时使用。
- **Xhigh：** 模糊、横切、concurrency-heavy 或 high-review-risk 工作，以及探索性和复杂工作。

Reasoning effort 很重要，但单个任务的曲线并不平滑或单调。更高 reasoning 通常提高 aggregate quality，却仍可能出现 high 胜过 xhigh，或更高设置产出看似合理但错误的实现选择。

在我们的 GraphQL-go-tools 任务上：

- Medium 比 low 更可靠地建模 repo/domain semantics。
- High 是最好的日常实践设置。
- Xhigh 是质量模式，而不是默认值。

你自己的 repo 可能在其他位置出现拐点，因此我们建议团队在自己的任务和 harness 上测量，而不是直接照搬全局 benchmark 默认值。

## Stet

我们正在构建 Stet.sh，这是用于运行本实验的本地 eval 工具。产品方向是让 coding agent 改进自己的 setup，例如修改 `AGENTS.md`，再用 Stet 在历史 repo 任务上测试 candidate changes。Stet 完全在本地运行，使用你的 LLM subscriptions。

你可以从 [https://www.stet.sh/private](https://www.stet.sh/private) 安装并运行第一次本地试用；如需 paid pilot 或 CI setup，也可以联系我们。

[加入候补名单](https://www.stet.sh/private)

## 常见问题

### 更高的 GPT-5.5 Codex reasoning effort 会提升 coding-agent 质量吗？

在这组 GraphQL-go-tools 的 26 个任务中，更高 reasoning effort 提升了等价性、review 通过率、all-3 pass 数量和自定义质量分数。但 xhigh 成本大幅上升，测试通过率还低于 high，因此不能简单地把最高设置作为默认值。

### 这是 decision-grade 的 GPT-5.5 reasoning-effort 对比吗？

这是来自拼接 matched slice 的 inspect-grade 证据。Medium/high 来自一次已完成但报告证据不足的 rules compare；low/xhigh 是同一 26 任务切片上的干净 candidate-arm runs。

### 为什么要同时看测试、等价性、review、成本和 grader 分数？

只看测试会错过主要信号。Low 与 medium 通过相同数量的测试，但 medium 在等价性、review、all-3 pass 和 craft/discipline graders 上明显更好；xhigh 则以更高成本换来更高的等价性和 review 质量。

更多方法信息见 [方法论](https://www.stet.sh/methodology)。

---

[Read this page’s summary](https://www.stet.sh/agents/api/public/v1/page-tldr?url=https%3A%2F%2Fwww.stet.sh%2Fzh%2Fblog%2Fgpt-55-codex-graphql-reasoning-curve&trace=t_5da45423e484)

## Ask a follow-up about this page

Need a more specific answer? Ask the exact question you have. It returns a fresh, cited answer from Stet’s knowledge base. No account or API key required.

Open this URL with your own question, URL-encoded. Include your question in q. All research inputs are optional; no account or setup.

`GET https://www.stet.sh/agents/agent/faq?q={question}&trace=t_5da45423e484`

[Tool guide and examples](https://www.stet.sh/agents/agent-access) · [OpenAPI](https://www.stet.sh/agents/api/public/v1/openapi.json) · [Page TLDR form](https://www.stet.sh/agents/agent-tools/page-tldr?url=https%3A%2F%2Fwww.stet.sh%2Fzh%2Fblog%2Fgpt-55-codex-graphql-reasoning-curve). Opening a form does not execute a tool.