Codex Harness与SWE-bench：模型评测的可复现性为何如此重要

如果你最近在 Hugging Face 上复现过一个热门模型在代码任务上的分数，八成会经历一种很微妙的困惑：官方给出一个看起来很高的数字，你用同一个模型、同一个评测集跑，居然拿到了更高的分。两边好像都没错，但你很清楚，这个结果已经不能直接回答“这个模型到底有多强”。就在这个背景下，OpenAI 发布了一份和 Hugging Face 平台相关的技术报告，讨论自己在大规模运行 SWE-bench 评测时遇到的问题。与其说这是一次平台公告，不如说它把“评测自动化”和“能力可信度”之间那条容易蒙混过关的缝隙，正式打开给我们看了。

这件事表面上是“模型厂商 + 模型托管平台”的一次公开互动，实际上接触到一个所有做模型评测的人早晚都会撞上的核心问题：当评测流程可以从手工变成全自动，分数的含义就变了。这篇文章想拆清楚三件事：这次事件里到底发生了什么；Codex Harness 这个开源评测工具为什么会让分数产生波动；作为普通开发者，面对这些高分数字时该怎么判断、怎么落地、怎么避免被误导。

1. 一场关于“分数对不上”的公开事件，到底发生了什么

1.1 从开源评测工具到平台复现热潮

先说背景。OpenAI 之前开源过一个叫 Codex Harness 的评测工具，仓库地址就在 GitHub 上。它不是一个模型，而是一个用于运行代码类任务的评测框架。设计目标很明确：把模型在 SWE-bench 这类代码基准上的运行过程标准化，让评测可以自动化、可重复、可对比。开源之后，社区很快开始在 Hugging Face 上组织复现，用同一套工具跑同一批模型。

问题就出在这里。社区跑出来的分数，和官方此前公布的数字出现了明显差异。而且不是低，是更高。按理说，能复现出更高的分数应该是好事，说明模型能力不弱。但这件事真正值得关注的不是“谁更强”，而是“为什么同一个模型、同一个评测集，在不同人手里跑出来的结果会差这么多”。

OpenAI 随后发布了一份技术报告，专门讨论这次事件。报告没有回避问题，解释了自己在评测中使用的具体配置：给模型较长的尝试窗口、允许一次重试、通过回放和额外的验证脚本来确认补丁是否真正解决了问题。这些配置合在一起，会让评测更宽松，也更容易拿到高分。

注意：这里说的“更宽松”不是贬义。评测目标不同，配置就可以不同。问题在于，评测配置变了，数字就不能直接拿来横向对比。

1.2 官方报告里真正承认的评测口径问题

报告里最有价值的部分，不是给某个分数辩解，而是承认了评测口径本身会影响结果。以前大家默认“模型跑 SWE-bench 的分数”是一个近似固定的值，只要模型一样、数据一样，分数就应该差不多。Codex Harness 和这次 Hugging Face 复现事件把这件事打破了：同一个模型，在“一次机会、短超时”和“多次机会、长超时”两种配置下，分数完全可以拉开几个百分点。

这就像同一个学生参加两场难度不同的考试，一场限时 30 分钟，一场限时 24 小时且允许改错一次。两次成绩不能说明学生能力变了，只能说明考试规则变了。模型评测也是这个道理。官方评测往往要在“可控性”和“能力上限”之间取舍，而社区复现时往往会把约束放得更松，结果就是更容易触发模型在更长探索过程中找到正确答案。

这次事件真正被打开的，是“官方数字”和“可复现数字”之间那条原本说不清的缝。对做工程的人来说，这比谁多一个点、谁少一个点更重要。

2. 为什么 Codex Harness 会把评测门槛拉低，又把口径拉高

2.1 它把“运行一次评测”变成了可复现的本地流程

在 Codex Harness 出现之前，想在 SWE-bench 上跑一个新的代码模型，流程并不轻松。你需要准备环境、处理数据集格式、写评测脚本、处理模型输出、再跑验证。每一步都可能出错，而且很难判断是模型问题还是流程问题。

Codex Harness 做的事情，是把这一整条流程封装成相对统一的命令行工具。它用容器隔离运行环境，把任务输入、模型输出、验证器执行这些环节拆开，让每一步都可以单独查看。从工程角度来说，这是一个很典型的基础设施思路：把“模型跑得怎么样”变成一个可以重复执行、可以存档、可以对比的流程。

这里要泼一盆冷水：工具开源不等于评测就变成“一键出分”。Codex Harness 降低的是“跑起来”的门槛，但没有降低“跑得对”的门槛。它把以前藏在脚本里的隐式逻辑，比如超时、重试、验证器选择，显式暴露成了配置项。配置一旦暴露出来，不同的人就会有不同的设置，分数自然就不一样。

2.2 真正决定分数的不是工具，而是评测约束

很多人第一次看到 Codex Harness 的配置项时会觉得问题不大，不过就是几个参数。实际上，这些参数直接影响最终数字。以常见实践为例，下面几个字段起的作用就完全不同：

同样是 SWE-bench，超时从 30 分钟改成 24 小时，分数差异可能非常明显。这不能说哪边“作弊”了，只能说评测目标不同。官方希望测量的可能是在复杂环境下解决真实问题的上限能力，所以愿意给更长探索时间；社区复现时如果使用默认配置，往往会得到一个“在有限时间里的能力表现”。两边的数字本来就不应该直接放在一起比。

但问题就在这里：大多数普通用户不会去读配置项，只会看到两个分数，然后得出一个“官方分数不靠谱”或者“社区分数造假”的结论。这两种判断都太简化了。分数差异的背后是约束差异，不是模型能力差异。

3. 社区分数和官方数字不一致，核心原因不是“作弊”而是“约束条件”

3.1 “作弊”是最省事的解释，但通常不是真的

每次出现“社区复现分数比官方高”的讨论，都会有人提出质疑：是不是官方故意压低？还是社区为了博眼球改了数据？从这次事件的技术报告和相关讨论来看，这两类解释都站不住脚。

真正的原因，是评测约束条件不同。模型不是一个人在“考试”，而是在一套由超时、重试、验证器、上下文窗口、工具权限共同组成的规则里完成任务。规则不同，成绩就不同。这就像一个模型可以调用终端、可以查看日志、可以反复试错，它的“分数”就已经不是单纯的“代码生成能力”，而是“在这个特定探索环境里完成任务的能力”。

这也解释了为什么同一个模型在官方报告和 Hugging Face 复现中会得到不同结果：不是有人动了手脚，而是两套评测规则本身就不等价。谁高谁低，取决于规则是更严格还是更宽松。

3.2 评测口径的三个典型变量：尝试次数、超时、验证方式

如果要把“评测口径”这件事讲清楚，最核心的三个变量分别是尝试次数、超时时间和验证方式。

尝试次数好理解。允许失败一次再重来，和只能跑一次相比，模型有更大机会修正自己的错误。这在代码任务里非常关键，因为代码修复往往不是一次写完就成功的，而是需要看报错信息、改下一轮。社区复现时如果默认允许重试，分数就会系统性地往上走。

超时时间影响的是探索深度。有些问题，模型在 10 分钟内找不到答案，但给它 2 小时，它可能通过反复阅读错误信息、搜索仓库结构、逐步缩小范围找到解法。超时越长，体现的越不是“反应速度”，而是“持久探索能力”。后者当然也是一种能力，但它和很多商业场景里的“限时完成任务”不是一回事。

验证方式是最容易被忽略的一环。同一个补丁，用简单测试命令验证和用完整回放验证，结论可能完全不同。官方报告中提到的补丁回放和额外校验，本质上是更严格的质检：不仅要让新增测试通过，还要确保原有功能没有被破坏。社区复现中如果只跑目标测试用例，就可能会漏掉破坏其他功能的场景。这种做法会产生“虚高”的结果。

记住一个原则：看到任何代码模型的高分，先问三件事——它尝试了几次？它有多少时间？补丁是怎么验证的？这三个问题不搞清楚，分数只能说明“在某些条件下它行了”。

4. 如果你也想用 Codex Harness 评测自己的仓库，建议从这个小流程开始

4.1 最小可用流程：先跑通一条样例

如果你的目标是评测一个模型在自家仓库上的表现，而不是复现某个公开排行榜，建议先从最小可用流程开始。不要一上来就接几百个 issue，先准备一个已被人工确认过的任务，跑通整个链路，确认输入、输出、日志、验证器都正常。

比较稳妥的落地顺序是：

1. 先安装好 Codex Harness，并确认它能在本地启动。
2. 准备一个最小的任务文件，把你仓库里的一个真实 issue 转成模型输入。
3. 跑一次单任务评测，保存完整运行日志。
4. 确认模型生成的补丁能被验证器接受，或者至少能看到明确的失败原因。
5. 检查结果里的“尝试次数”“耗时”“验证器输出”这几项信息。

这里有一个常见误区：觉得单任务跑通就万事大吉。单次跑通只能说明流程没有断，不能说明评测配置合理。你需要再跑第二个、第三个任务，直到能稳定地复现出“该过的能过，该挂的会挂”。

4.2 用小批量任务对比不同配置，而不是直接拉满并发

很多人拿到 Codex Harness 之后，第一件事就是想办法把并发数调高，觉得这样速度快。这种做法在资源充足时没有问题，但前提是你已经理解了配置对结果的影响。如果你连默认配置跑出来的结果都还没核对过，就急着批量执行，最后只会收获一堆“不知道为什么这样就过了”或者“不知道为什么这样就挂了”的日志。

更推荐的做法是：先跑一个小批量，比如 5 到 10 条任务，记录结果。然后只改变一个变量，比如把重试次数从 0 改成 1，再跑同一批任务，对比前后差异。用这种“单变量对比”的方式，你才能真正理解当前模型的边界在哪里。

从我的工程经验看，绝大多数评测落地问题都出在“对配置缺乏感知”。模型一换、数据集一换、超时时间一换，分数立刻变。如果不记录配置，就等于没有复现能力。

4.3 记录完整上下文，而不是只记录分数

这一点可能是整个流程里最容易被忽略的。很多人评测完只保留一个数字：通过率多少。等到过两周想复盘，发现自己根本不记得这次跑的时候模型是什么版本、prompt 长什么样、超时设了多少、验证器是什么。

一份好的评测记录，至少要包含这些信息：

• 模型名称和版本，包括完整的 repo id 或模型卡信息。
• 评测集的确切 commit，不要只写“用了 SWE-bench”。
• 评测脚本和 Codex Harness 的版本。
• 所有关键配置项，包括超时、重试、并发、验证器。
• 每次运行的日志，至少保留输入任务、模型输出、验证结果。
• 运行环境的描述，比如 GPU 型号、容器镜像、依赖版本。

如果你愿意多花一点时间，把以上信息整理成一个简单的 JSON 或 Markdown 记录，后续做对比会非常方便。否则，你手上只有一个“看起来很高”的数字，没有任何解释力。

{ "model": "example/model-name", "repo_id": "huggingface/example-repo", "dataset_commit": "abc123", "harness_version": "0.1.0", "timeout_seconds": 7200, "retries": 1, "concurrency": 4, "pass_rate": 0.72, "log_path": "runs/2025-11-01/example-run" }

这只是示例结构，实际字段要以你用的工具版本为准。但“把评测过程记录下来”这个习惯，和工具无关，早养成早受益。

5. 在 Hugging Face 上下模型跑评测，还需要把安全边界一起带上

5.1 模型来源和文件完整性比运行参数更容易被忽略

评测一个模型之前，第一件事不是调参数，而是确认你下载的模型文件确实来自预期来源。Hugging Face 上有大量的模型仓库，但仓库名、作者、commit 记录、文件内容都可能出现意外。社区里出现过模型文件被换成其他版本、或者原本不存在的版本号突然出现的情况，这类问题在跑评测时尤其危险：你以为是模型 A，实际跑的是模型 B，最后得出的结论根本没有意义。

所以，建议在下载模型之前做三件事：

1. 确认仓库作者和 org 是否正确，不要只看模型名称。
2. 查看仓库的 commit 历史，确认你下载的是哪个版本。
3. 如果有官方提供的文件哈希，下载后做一次校验，确保文件完整。

这一步看起来和数据无关，但在“用公开模型做评测”的场景里，它能救你很多次。尤其是那些需要下载权重到本地、再交给代码评测框架的任务，权重文件一旦损坏，跑出来的分数可能很难解释。

5.2 一个好的评测记录应该包含哪些信息

顺着上面这个思路继续往下走，一个真正可复现的评测，不只是记录分数和配置，还应该把“模型从哪来”锁定下来。推荐在记录里额外保存以下信息：

• 模型仓库的完整 URL 或 repo id。
• 下载时的 commit sha。
• 权重文件的哈希值，至少记录一个关键文件的哈希。
• 模型卡里声明的基础模型和适用任务。

这些信息在平常跑一两个样本时可能觉得没必要，但一旦你要对比多个模型、或者隔段时间回看结果，它们就能帮你快速判断“这次跑的是不是我以为的那个模型”。

建议把模型来源、评测配置、运行日志这三部分信息打包保存。只记分数，等于没记；只记模型，等于没锁版本；只记配置，等于没留证据。

6. 别把基准数字当结论，真正该维护的是一套可复现的评测流程

6.1 基准分数的正确用法是“做对比”，而不是“做绝对值”

这次开源评测工具和平台复现事件，给普通开发者的提醒其实很简单：一个模型在公开基准上的分数，不是一个可以直接迁移到你业务场景里的绝对值。

官方评测分数说明的是：在特定的数据集、特定的评测配置、特定的时间限制和验证规则下，这个模型做到了什么程度。你业务里的任务分布、上下文结构、允许尝试的次数、判定标准，都和公开评测不一样。直接拿公开分数去预测“这个模型在我这里能解决多少问题”，大概率会产生偏差。

正确的用法，是把公开基准当作一个批量对比的筛选工具。先用统一口径跑一批模型，筛出最值得深入测试的那一两个，再拿到自己的真实任务上做小批量验证。不要在公开分数上过度解读，更不要因为某个模型在某次评测里多了一两个点，就认定它全面更强。

6.2 一个简单的评测流程框架，可以长期复用

如果你希望这次的教训不只是一篇新闻，而是能沉淀成自己的工作习惯，可以试试下面这个流程框架。它不复杂，但覆盖了从选模型到得出结论的关键环节：

1. 固定输入：确定评测集或真实任务集，锁定版本和 commit。
2. 固定环境：统一容器镜像、依赖版本、硬件环境。
3. 露出配置：记录超时、重试、并发、验证器，并默认使用同一套基准配置。
4. 保留日志：保存输入、输出、报错、验证结果，不只看最终分数。
5. 单变量对比：一次只改一个参数，理解它对结果的影响。
6. 结论边界：区分“该模型在 X 条件下通过了 Y 任务”和“该模型很擅长 Z”。

这套流程看起来不惊艳，但非常实用。它能帮你避免一个很容易犯的错误：把某个评测配置下的分数，当成模型能力的绝对上限。

回到开头那个场景，如果你再在 Hugging Face 上看到一个代码模型的高分，先不要急着感叹或者质疑，去翻一下报告和配置。你会发现，那些分数背后藏着的不是模型有多强，而是一整套“在什么条件下、花了多少时间、尝试了几次、最后怎么验证”的过程记录。模型能力当然在其中，但评测配置同样重要。

真正值得长期关注的，不是某个模型又涨了多少分，而是整个行业开始认真面对“评测可复现”这件事。当一个评测工具开源、当模型托管平台被卷入评测流程、当技术报告愿意解释分数差异，我们离“知道一个模型到底行不行”就更近了一点。而作为开发者，你要做的不是记住某个数字，而是把“怎么评测、怎么记录、怎么对比”这一整套方法，放进自己的工具箱里。