分数究竟衡量了什么
一次基准测试运行并不是对模型的测量。它是至少四样东西的联合分布中的一个样本：模型权重与解码设置、提供给模型的工具定义、模型运行所受到的运行时限制，以及这些工具所触及的环境。改动其中任何一项，数字就会变。大多数公开的排行榜固定了第一项，却把其余几项留作隐含条件——这就是为什么两个实验室用同一个模型跑同一个基准测试，报告出来的结果却可能相差一个远大于被比较模型之间差距的幅度。
这不是对基准测试设计的抱怨。基准测试大体上没问题。问题在于 harness——把模型变成 agent 的那套脚手架——被当作实现细节，而它实际上是决定 agent 究竟能尝试什么的那个自变量。一个四步就能规划好的模型，和一个要折腾二十步的模型，在步数上限为二十五、重试预算为五的条件下是无法区分的。在模型被提问之前，harness 就已经替它回答了问题。
把 harness 当作产物的一部分。一条 eval 记录应当以哈希固定工具 schema、以摘要固定运行时镜像，并固定重试次数、步数上限、墙钟时间与 token 预算，以及沙箱网络策略。缺少这些字段，分数就只是一个带小数点的传闻。
harness 掩盖的失败模式
宽松的步数限制会奖励蛮力重试而非规划。如果一个 agent 能用略有不同的查询调用同一个搜索工具十一次，那么一个从不制定计划的模型仍然能得出答案，而且看起来和一个只规划一次、干净执行的模型一模一样。把上限收紧到四步，排名就会反转。两种配置都没有错；两者都是合理的产品。但一个公开的数字无法同时代表两者，而读者会默认它代表的是自己那一种。
相反的失败同样悄无声息。严格的上限会惩罚那些恢复能力强的模型。一个能检测到格式错误的工具响应、修复自己的参数并在第二次尝试中成功的 agent，做的正是生产系统所需要的工作，而它却被记为比一个碰巧一次就做对的模型更慢、更贵。如果重试策略没有公开，读者就无法判断这个分数奖励的是能力还是运气。
沙箱网络策略是最具影响力的隐形设置。禁用出网的运行衡量的是对工具的规划与推理，而不是工具使用。启用出网的运行衡量的是模型能否扛住真实延迟、部分失败和不一致的 schema。这是两种不同的产品。当厂商报告一个工具使用分数却不说明网络策略时，读者无从知道衡量的是两者中的哪一个，而这两者并不可比。
确定性的工具桩是另一个相关的陷阱。把搜索 API 打桩成返回一份固定文档，就消除了生产 agent 实际面对的歧义——被截断的结果、过期的索引、速率限制、schema 漂移。桩让 eval 可复现，这很有价值；同时也让它不具代表性，而这是你必须明确说明、而不是默默吞下的取舍。诚实的做法是两者都跑：一套打桩的套件用于回归检测，一套实时的套件用于能力声明，作为两个独立的数字发布，各自附上 harness 清单。
eval 结果的发布契约
如果一个分数要被引用，它就应该连同产生它的条件一起交付。一份可行的契约包含四个部分。
随分数交付 harness 清单。 至少包括：工具 schema 哈希、运行时镜像摘要、步数与时间预算、重试次数、网络策略、解码参数和种子集。清单应当机器可读，这样读者就能对比两个结果，立刻看出它们是否可比。没有清单的分数只是轶事。
报告方差，而不是点估计。 跨种子运行，并至少跨两种 harness 变体——一个紧预算、一个松预算——并公布分布范围。如果一个模型的分数在步数上限从二十降到八时崩塌，这是你能告诉读者的最有用的信息，而单一均值会把它完全掩盖。
让事故回放能针对同一 harness 版本重新运行。 当 agent 在生产中行为异常时，只有当回放针对产生该行为的那个 harness 运行时，回归才能被归因。像给模型做版本管理一样给 harness 做版本管理，并保持旧版本可运行。这是团队会跳过的那部分，也正是把 eval 套件从发布产物变成工程仪器的那部分。
说明你接受了什么取舍。 每一个 harness 选择都是用代表性换取可复现性，或者反过来。说清楚你选了哪一边。一套打桩、网络隔离、预算紧张的套件完全可以发布，只要标签上写明了这一点。
为什么这是工程问题，而不是报告问题
诱惑在于把 harness 披露当作一项文档任务——在附录里加一张表就完事。并非如此。一旦 harness 被版本化，它就变成了一样你可以测试、回归和推理的东西，而这会改变系统的构建方式。工具 schema 像 API 契约一样被评审。重试策略依据实测的恢复率而非直觉来调优。步数上限成为一个有明确理由的产品决策，而不是从框架示例里继承来的默认值。
代价是真实的：维护多个 harness 变体、保持旧运行时镜像可运行、让每套套件跨种子集运行，都会成倍增加算力和工程时间。只有一个模型、一个产品的团队会觉得这比他们需要的更重。诚实的立场是：完整的契约在你跨模型或跨实验室比较时才会回本——而那恰恰是这个数字最有可能被断章取义引用的时刻。
关于这些比较目前是如何被报告的、以及缺口在哪里，参见这篇关于 agent 评估实践的近期讨论。
基准测试并不是你缺失的那个变量。harness 才是，而它是你今天就能做版本管理的那个。
