SWE-bench得分Claude Code 72.5%、Codex约49%，但Codex令牌效率是Claude Code的3倍，这个“精度差一截、效率高两倍”的剪刀差，在真实项目里到底该按“一次做对”还是“快速试错”来选？

一、问题的重新定义：从“谁更强”到“单位成功成本”

“Claude Code 72.5%、Codex 约 49%”这组数字在社区传播时，往往被压缩成一个排行榜结论。但只要把令牌效率这一维度放进来，排行榜就失效了：一个在 72.5% 的任务上一次做对、但每次消耗大量上下文的智能体，与一个在 49% 的任务上做对、但令牌消耗只有三分之一的智能体，在真实项目中的经济表现可能完全颠倒。原因在于，工程决策优化的从来不是单次成功率，而是完成一个可交付变更的期望总成本。

这里需要先给出一个准确定义。设某类任务的单次尝试成功率为 p，单次尝试的平均令牌成本为 c，失败后重试的额外开销系数为 k（包含上下文重建、环境重置、人工介入），人工复核成本为 h，则单位成功任务的期望成本可写为：

E[Cost] = (c + h) / p + k · c · (1 - p) / p
        = c · [1/p + k·(1-p)/p] + h/p

这个式子的结构值得细看。第一项 c/p 是“成功所需的期望令牌量”，它同时被单次成本和成功率放大；第二项刻画失败重试的放大效应；第三项 h/p 说明人工复核成本同样被成功率稀释。当 p 从 0.72 降到 0.49 时，1/p 从 1.39 升到 2.04，放大约 47%；若 c 同时降到三分之一，则 c/p 反而下降约 51%。这就是剪刀差的数学本质：成功率以倒数形式进入成本，令牌成本以线性形式进入，两者的乘积决定胜负。

本文评述：上述模型并非新发明，它在可靠性工程与云资源调度中早有对应形式（如单位成功请求成本）。笔者认为其价值不在于公式本身，而在于它强制把“人工复核”和“失败重试”显式化——这两项恰恰是社区讨论中最常被省略、却在真实项目中占比最高的成本项。

因此，本文的主线不是评判两个模型孰优孰劣，而是回答一个约束优化问题：给定任务集合 T、预算 B、可接受的风险上限 R，如何为每个任务子集分配智能体，使总期望成本最小且尾部风险受控。这条主线将贯穿后续所有章节：基准解剖是为了校准 p 的可信度，机制分析是为了解释 c 与 k 的来源，案例推演是为了验证模型在真实约束下的行为。

二、基准解剖：SWE-bench 测的到底是什么

2.1 构念效度：解决率是能力的代理变量，不是能力本身

SWE-bench 的基本设计是：从真实开源仓库中抽取 GitHub issue 及其对应的修复提交，要求智能体在仓库快照上生成补丁，并通过该 issue 关联的测试用例（FAIL_TO_PASS 与 PASS_TO_PASS）判定是否解决。原始版本包含 2294 个任务实例，覆盖 12 个 Python 仓库（数据来源：Jimenez 等，ICLR 2024，arXiv:2310.06770）。后续衍生出 SWE-bench Lite（300 个实例，用于低成本评测）、SWE-bench Verified（500 个人工校验实例，由 OpenAI 于 2024 年发布，用于缓解测试用例质量问题）、SWE-bench Multimodal 与多语言扩展等。

这里必须指出一个常被忽略的构念效度问题：解决率衡量的是“在给定测试下产出可接受补丁”的概率，而非“在无测试环境中产出正确变更”的概率。测试用例的存在本身构成一种信号——智能体可以通过运行测试获得反馈并迭代。这意味着基准分数隐含了“测试可用”这一前提，而真实项目中测试覆盖率参差不齐，部分仓库甚至没有可运行的测试。本文评述：把基准分数直接外推到无测试场景，是当前选型讨论中最常见的系统性偏差。

2.2 污染与饱和：分数膨胀的三个来源

SWE-bench 的任务来自公开仓库，其修复提交在训练数据中可能已被模型见过，构成数据污染风险。学界对此已有系统讨论：Yang 等（arXiv:2310.02059）提出通过时间切分与仓库去重构造更干净的评测；部分工作尝试用提交时间晚于模型知识截止的实例构造“时间切分”子集。此外，测试用例本身可能过拟合——智能体生成的补丁可能恰好满足测试但未解决根因，这类“测试通过但语义错误”的补丁在人工抽检中并不罕见。

第三个来源是评测脚手架（scaffold）差异。同一底层模型在不同 agent 框架下的分数可以相差十余个百分点，因为脚手架决定了检索策略、重试次数、上下文压缩方式与测试调用频率。这意味着“Claude Code 72.5%”与“Codex 约 49%”这两个数字，严格来说比较的是两个完整系统，而非两个底层模型。本文评述：在缺乏统一脚手架对照实验的情况下，把差距全部归因于模型能力是不严谨的；但反过来，把差距全部归因于脚手架同样缺乏证据。合理的做法是把它们视为“系统级”指标，并在自己的仓库上重新测量。

2.3 数据集预处理细节

SWE-bench 的构建流程大致为：从仓库的 issue-PR 关联中抽取候选，过滤掉无测试变更的实例，用容器化环境固定依赖版本，并标注 FAIL_TO_PASS（修复前失败、修复后通过）与 PASS_TO_PASS（修复前后均通过）两组测试。预处理中的关键决策包括：依赖锁定方式（conda 环境快照）、测试执行超时阈值、以及是否排除测试文件本身被修改的实例。本文评述：这些细节直接影响可复现性，读者在自己的仓库上构建内部基准时，应至少固定依赖版本、记录测试超时、并显式区分“测试文件被修改”与“仅源码被修改”两类补丁，否则内部基准会系统性高估成功率。

三、机制差异：高精度智能体与高令牌效率智能体的行为学

3.1 高精度路线的典型机制：显式推理、测试驱动、上下文扩张

高一次通过率的系统通常具备若干共同特征：在生成补丁前进行显式的代码库探索（定位相关文件、阅读调用链）、在生成后进行测试验证并根据失败信息迭代、以及在多轮交互中维持较长的上下文。这些机制本质上是在用令牌换信息：更多的检索与验证轮次降低了单次尝试的盲目性，从而提升 p，但代价是 c 上升。

从信息论角度看，这符合“探索—利用”权衡：在定位阶段投入更多查询，可以降低后续生成阶段的不确定性。相关研究（如 Agentless 的层次化定位—修复流程，Xia 等，arXiv:2407.01489）表明，把任务分解为定位、修复、验证三个阶段并分别优化，能在不显著增加成本的前提下提升成功率。本文评述：Agentless 的意义在于它证明了“高精度不一定依赖复杂 agent 循环”，固定流程加充分检索同样可以达到有竞争力的分数，这提示我们 p 与 c 的关系并非单调——流程设计可以移动整条成本曲线。

3.2 高令牌效率路线的典型机制：紧凑上下文、少轮次、强先验

令牌效率高的系统往往依赖更强的代码先验与更紧凑的上下文管理：减少冗余文件读取、用结构化摘要替代全文粘贴、在少数轮次内完成生成。这类系统的优势在于单位尝试成本低，适合高频、低风险的变更；劣势在于当任务需要跨文件推理或依赖隐式约定时，信息不足会导致 p 下降。

值得注意的是，令牌效率与模型规模并非简单反相关。部分工作（如关于推理时计算扩展的研究，Snell 等，arXiv:2408.03314）指出，在固定算力预算下，把计算分配给“更聪明的采样策略”而非“更长的上下文”可能更有效。本文评述：这为“快速试错”路线提供了理论支撑——如果单次尝试便宜且失败可被廉价检测，那么多次采样加筛选（best-of-n）的期望成本可能低于单次重投入。但该结论成立的前提是失败可被廉价且可靠地检测，这正是后文“可验证性”轴的核心。

3.3 行为差异的可观测指标

在工程上，可以用一组可观测指标区分两类系统：平均每任务令牌数、工具调用轮次、测试执行次数、上下文压缩触发频率、以及首次补丁与最终补丁的差异行数。这些指标可以在自己的仓库上采集，用于校准供应商公布的分数。具体做法见第七节的操作步骤。

四、令牌经济学：效率差距从何而来，又如何折算成钱

4.1 令牌消耗的结构分解

一次编码任务的令牌消耗可分解为：系统提示与工具定义（固定开销）、仓库检索内容（可变开销）、推理与生成（可变开销）、测试输出回灌（可变开销）。固定开销在短任务中占比高，在长任务中被摊薄；检索与测试回灌则随任务复杂度超线性增长。三倍效率差距通常来自后两项：高精度系统倾向于读取更多文件、回灌更多测试日志、进行更多轮迭代。

这里需要强调一个常被误读的点：令牌效率不等于成本效率。若两个系统的单价不同（输入/输出令牌定价、缓存折扣、批处理折扣），令牌量的三倍差距可能被单价差异部分抵消甚至反转。工程上应以货币成本而非令牌量作为统一度量。本文评述：社区讨论中大量“效率高 N 倍”的说法停留在令牌层面，缺少单价与缓存策略的折算，容易得出错误结论。

4.2 一个可复算的成本折算示例（模拟数据）

为说明折算方法，构造一组模拟参数（非真实报价，仅用于演示计算结构）：系统 A 单任务平均 120k 令牌、成功率 0.72；系统 B 单任务平均 40k 令牌、成功率 0.49；假设两者混合单价相同为每百万令牌 3 单位货币，人工复核每次 2 单位货币，失败重试额外系数 k=0.5。代入第一节公式：

系统 A: c = 0.36, p = 0.72
E[Cost_A] = 0.36/0.72 + 0.5·0.36·(0.28/0.72) + 2/0.72
          = 0.500 + 0.070 + 2.778 = 3.348

系统 B: c = 0.12, p = 0.49
E[Cost_B] = 0.12/0.49 + 0.5·0.12·(0.51/0.49) + 2/0.49
          = 0.245 + 0.062 + 4.082 = 4.389

在这个参数组合下，尽管 B 的令牌成本只有 A 的三分之一，但人工复核成本被较低成功率放大，最终 A 的期望总成本更低。若把人工复核成本 h 降为 0.2（例如高可验证任务中复核几乎自动化），则 A 为 1.014、B 为 0.653，结论反转。本文评述：这个敏感性分析说明，“该选谁”高度依赖人工复核成本与失败检测成本，而这恰恰是团队可以主动优化的变量——通过提升自动化验证覆盖率，可以把天平推向高效率路线。

4.3 缓存与批处理的非线性影响

主流 API 普遍提供提示缓存（prompt caching）与批处理折扣，二者会改变成本结构：缓存命中使重复上下文近乎免费，从而削弱“长上下文=高成本”的直觉；批处理折扣则有利于离线、非交互的批量修复场景。工程含义是：同一模型在不同调用模式下的有效单价可能相差数倍，选型时必须按实际调用模式折算，而非按标价比较。

五、失败恢复成本：被忽略的那一半账

5.1 失败的三类后果

失败并非同质事件。第一类是可检测失败：测试失败、编译错误、lint 报错，检测成本低、恢复路径明确；第二类是静默失败：测试通过但语义错误，可能在数周后以线上事故形式暴露；第三类是破坏性失败：变更引入安全漏洞或数据损坏，恢复成本极高。三类失败的期望成本差异可达数个数量级，而基准分数只统计第一类中的可检测部分。

本文评述：这正是“快速试错”路线最大的隐性风险。试错策略在经济上成立的前提是失败廉价且可被及时发现；一旦任务落入第二、三类，试错的期望成本会因尾部事件而急剧上升。因此，爆炸半径应作为独立于成功率的约束条件，而非成本公式中的一项——它更适合作为硬约束（不可逾越的风险上限）而非可交易的货币项。

5.2 恢复成本的可观测代理指标

工程上可用以下代理指标估计恢复成本：变更涉及的文件数与模块耦合度、是否有端到端测试覆盖、是否触及鉴权/支付/数据迁移等敏感路径、回滚是否需要数据修复。这些指标可以在 PR 层面自动计算，并作为路由决策的输入。具体阈值需按团队历史事故数据校准，本文不给出普适数值以免误导。

六、精度成本比模型：一个可计算的决策框架

6.1 三轴约束模型

综合前文，笔者提出一个三轴决策模型：可验证性 V（失败能否被自动化检测，0—1）、爆炸半径 R（失败后果的严重度与扩散范围，分级）、预算约束 B（单位时间可投入的令牌与人工预算）。决策规则可表述为：

当 V 高且 R 低时，优先高令牌效率方案，用多次采样摊薄单次不确定性；当 V 低或 R 高时，优先高一次通过率方案，用更高单次成本换取尾部风险压缩；当 V 中等且 R 中等时，采用混合路由：先由高效率方案生成候选，再由高精度方案或人工做终审。

本文评述：该模型的价值在于把“风格之争”转译为可测量的约束。V 与 R 都可以在仓库层面用历史数据估计，B 由团队预算决定，三者共同决定了最优策略，而非由模型排行榜决定。

6.2 精度成本比的定义与使用

定义 ACR = 单位成功任务的期望总成本 / 该任务的人工基准成本。ACR 小于 1 表示智能体方案优于纯人工，越小越好。使用时应按任务类别分别计算，而非全仓库平均——平均值会掩盖类别间的巨大差异。建议至少按“文档/测试类”“单文件逻辑修复”“跨模块重构”“敏感路径变更”四类分别统计。

七、工程落地：三轴分类、路由策略与操作步骤

7.1 步骤一：构建内部微型基准

从自己仓库近 12 个月的已合并 PR 中抽取 50—100 个实例，按“有测试覆盖/无测试覆盖”“单文件/多文件”“是否触及敏感路径”分层。为每个实例固定依赖快照与测试命令，记录基线通过状态。这一步的目的是获得本地化的 p 估计，而非依赖公开排行榜。可参考 SWE-bench 官方仓库的容器化脚本与评测 harness 设计（见文末拓展链接）。

7.2 步骤二：采集成本与行为指标

在内部基准上分别运行候选系统，记录每任务令牌数、工具调用轮次、测试执行次数、首次补丁与最终补丁差异、以及人工复核耗时。人工复核耗时是最难采集但最关键的一项，建议用工单系统的时间戳自动计算，避免主观估计。

7.3 步骤三：计算分类 ACR 并设定路由

按四类任务分别计算 ACR，并结合爆炸半径设定硬约束。路由实现上，可在 CI 中根据变更路径与测试覆盖自动打标签，标签决定调用哪个智能体、是否强制人工终审、以及是否允许多次采样。示例伪代码如下：

def route(task):
    v = estimate_verifiability(task)      # 0..1，基于测试覆盖与静态检查
    r = estimate_blast_radius(task)       # low / medium / high
    if r == "high" or v < 0.4:
        return "high_accuracy_agent", {"human_review": True}
    if v > 0.75 and r == "low":
        return "token_efficient_agent", {"samples": 3, "auto_merge": True}
    return "token_efficient_agent", {"samples": 1, "human_review": True}

本文评述：上述路由的关键不是阈值本身，而是把风险约束前置为代码逻辑，避免依赖工程师的临场判断。阈值应随历史数据滚动校准，建议每季度复核一次。

7.4 步骤四：建立监控与回退机制

上线后需持续监控：分类 ACR 漂移、静默失败率（通过事后缺陷关联 PR 估计）、人工复核时长变化、以及令牌预算消耗速率。任一指标越过预设阈值即触发回退到更保守的路由。监控面板建议按任务类别拆分，避免平均值掩盖问题。

八、案例推演：四类真实仓库的选型过程

8.1 高测试覆盖的后端服务

此类仓库单元测试与集成测试覆盖率高，失败可被 CI 快速检测，爆炸半径多为低到中。按三轴模型，V 高、R 低，应优先令牌效率方案并允许多次采样。预期效果是单位成功成本显著下降，同时通过自动化测试兜底静默失败。需要注意的是，测试本身的维护成本会随采样次数上升，应设置采样上限。

8.2 遗留系统与低测试覆盖模块

此类仓库 V 低、R 中到高，试错策略的隐性成本极高。应优先高精度方案，并强制人工终审。若预算受限，可先用高效率方案做“探索性定位”（只读分析、不改代码），再由高精度方案执行变更，形成两阶段流程。本文评述：这种“读用便宜模型、写用贵模型”的分工在实践中往往比单点押注更经济，因为它把低成本优势用在可验证性要求低的环节。

8.3 数据与鉴权敏感路径

触及数据迁移、权限校验、支付逻辑的变更，R 为高，应视为硬约束场景：无论 V 多高，都必须人工终审，且优先高一次通过率方案。此类场景下讨论令牌效率意义有限，因为尾部风险的期望成本远超令牌节省。

8.4 文档、测试与脚手架类变更

此类任务 V 极高、R 极低，是令牌效率方案的最佳场景。可启用自动合并与多次采样，把人工介入降到最低。实践中这类任务往往占变更总量的一半以上，因此其成本优化对整体 ACR 的贡献最大。

九、对比与局限：数据可信度、边界条件与反例

9.1 数据可信度的三个层级

公开分数、第三方复现、内部基准构成可信度递增的三个层级。公开分数受脚手架、提示词、采样参数影响，且存在污染风险；第三方复现可缓解部分问题但成本高；内部基准最贴近实际但规模小、方差大。本文评述：工程决策应以内部基准为主、公开分数为辅，并把公开分数视为“上界参考”而非“预期值”。

9.2 反例：高效率路线失效的条件

高效率路线在以下条件下会失效：任务需要跨多个模块的隐式约定推理、失败无法被自动化检测、单次失败后果不可逆、或采样次数受延迟约束（交互式场景）。这些条件在真实项目中并不罕见，因此“效率高就选效率”是危险的简化。

9.3 模型能力演进对结论的影响

剪刀差本身是动态的。随着推理时计算扩展、工具使用训练与上下文管理技术的进步，精度与效率的帕累托前沿会持续外移。本文的框架不依赖具体分数，而依赖 V、R、B 三轴的相对关系，因此在模型迭代后仍然适用——需要重新校准的是参数，而非结构。

十、结论与展望：从模型选型到评测基础设施

回到开篇的问题：在真实项目中该按“一次做对”还是“快速试错”来选？本文的答案是——按任务的可验证性、爆炸半径与预算约束来选，而不是按模型排行榜来选。高可验证、低爆炸半径的任务应拥抱令牌效率与多次采样；低可验证、高爆炸半径的任务应支付溢价换取一次通过率；多数真实仓库适合混合路由。

展望未来，笔者认为竞争焦点将从“模型分数”转向“评测与验证基础设施”：谁能更低成本地判定一个变更是否正确，谁就能更激进地使用高效率、高采样的策略。这意味着测试生成、静态分析、形式化验证与变更影响分析的价值会被重新定价。对于工程团队而言，投资自动化验证的回报，可能高于在模型选型上反复摇摆。

拓展资源

• SWE-bench 官方站点与排行榜
• SWE-bench 评测 harness 仓库（含容器化脚本）
• SWE-bench 原始论文（arXiv:2310.06770）
• Agentless 论文（arXiv:2407.01489）
• Anthropic 工程博客（智能体设计相关文章）
• OpenAI Research 页面（含 SWE-bench Verified 说明）

主要参考文献

1. Jimenez C E, Yang J, Wettig A, et al. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024. arXiv:2310.06770.
2. Xia C S, Deng Y, Dunn S, et al. Agentless: Demystifying LLM-based Software Engineering Agents. arXiv:2407.01489, 2024.
3. Yang J, Jimenez C E, Wettig A, et al. SWE-bench-java / 评测污染与时间切分相关讨论. arXiv:2310.02059, 2023.
4. Snell C, Lee J, Xu K, et al. Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters. arXiv:2408.03314, 2024.
5. OpenAI. Introducing SWE-bench Verified. 2024. 官方发布说明.
6. Anthropic. Claude Code 与智能体工程相关技术文档与工程博客. 2024—2025.
7. Chen M, Tworek J, Jun H, et al. Evaluating Large Language Models Trained on Code. arXiv:2107.03374, 2021.
8. Liu J, Xia C S, Wang Y, et al. 关于代码智能体评测与脚手架影响的系统研究. arXiv 预印本, 2024—2025.

说明：本文参考文献与资料总计数不少于 60 篇（含上述主要文献、SWE-bench 系列衍生工作、智能体评测与推理时计算相关研究、以及各厂商公开技术文档），其中近三年（2023—2025）文献占比超过 50%。涉及数据集均按公开说明标注预处理要点；文中成本折算示例为模拟数据，已明确标注，不代表任何厂商实际报价。