AI Agent 评测缺口：同一模型家族为什么会差近 4 个百分点

模型排行榜很容易制造一种错觉：分数属于模型。进入 Agent 场景后，分数属于一套组合系统，包括模型、Harness、任务、测试、环境、预算和评分器。

JetBrains 首版 Kotlin Benchmark 提供了一个直观案例。Claude Code 搭配 Opus 4.7 xhigh 完成 105 个任务中的 90 个，Junie 搭配 Opus 4.7 max 完成 86 个。底层模型家族相同，外围配置变化后相差 4 个任务，约 3.8 个百分点。

这组数据还不能单独证明差异全部来自 Harness，因为两者的推理配置也不同。它真正证明的是：排行榜上的每一行都是配置结果，不能被简化为模型常数。

对开发团队来说，问题因此发生了变化。选型不能只问谁排第一，还要问三个问题：分数为什么成立，能否在受控条件下复现，能否预测这个 Agent 在自己的代码库中表现如何。

排行榜测量的是系统

Kotlin Benchmark 第一版从 8 个活跃开源 Kotlin 仓库提取了 105 个真实任务。Agent 拿到 issue 或 PR 描述和对应仓库状态，生成 patch。只有通过容器中的隐藏回归测试，任务才算解决。

这种证据强于产品演示，因为它覆盖了理解任务、浏览仓库、修改代码和验证结果的完整链路。JetBrains 同时明确指出，榜单只是参考信号。代码架构、内部 API、编码规范、工具和验证流程都会改变真实结果。

两行 Opus 4.7 数据实际包含以下变量：

因此，模型选型的最小单位应该是一套可部署配置。模型只是其中一层。

初步研究也支持这个方向。Scaffold Effect 论文在 50 个 Terminal-Bench Pro 任务上固定任务和模型，比较 3 个开源 Harness。两个模型在不同 Harness 间的配对通过率相差 0 至 8 个百分点。受样本量限制，多数组合的 95% 区间仍包含 0。更明显的差异出现在运行侧：每解决一个任务消耗的 token 最多相差约 40 倍，而且不同 Harness 会重复出现各自的失败指纹。

准确率看似接近时，成本、等待时间和人工监督负担仍可能完全不同。

评分器也可能是故障点

即使一次跑分可以完整复现，它仍可能测错东西。

OpenAI 审计了 138 个强模型经常失败的 SWE-bench Verified 任务，发现其中 59.4% 存在实质问题。一类测试把特定实现写成唯一答案，导致功能正确的其他方案失败；另一类测试检查题目没有提出的额外要求。OpenAI 还发现前沿模型能够复现部分任务特定信息或 gold patch，说明公开题目可能已经进入训练数据。

OpenAI 一度建议迁移到 SWE-Bench Pro，随后又对其 731 个公开任务开展审计。Agent 辅助管线标出 200 个损坏任务，占 27.4%；有经验的工程师独立标出 249 个，占 34.1%。OpenAI 综合估计约 30% 的任务存在问题，并撤回此前建议。

这些审计揭示了四类彼此独立的误差：

• 题目遗漏了隐藏测试实际要求的条件；
• 测试绑定某种实现，拒绝了功能正确的其他方案；
• 测试覆盖不足，让不完整修复也能通过；
• 公开任务与参考补丁进入训练语料，污染能力测量。

一个总分无法告诉你混入了哪种误差。Agent 能力和评测集有效性必须分开审计。

五层 AI Agent 评测框架

可靠评测需要让每个变量可见，并为每层保留独立证据。

第一层：配置身份

先记录实际运行的系统：

• 精确模型版本和供应商路由；
• 推理强度、采样和上下文设置；
• Harness 版本或 commit；
• system prompt、Skills 和工具 schema；
• 重试、轮次、token、时间和网络预算；
• evaluator 与 judge 版本；
• 容器镜像、依赖锁文件和初始工作区哈希。

缺少这些信息时，分数只是一张截图。信息齐全后，它才成为可以尝试复现的实验。

eval_run:
  suite: payments-agent-v3
  model: provider/model-snapshot
  harness: coding-agent@8f31c2a
  prompt_sha256: 6b7d...
  tool_schema_sha256: 91e4...
  environment: payments-eval@sha256:27ac...
  task_set_sha256: d063...
  grader_sha256: 46b1...
  trials_per_task: 5
  budgets:
    wall_seconds: 900
    max_tokens: 120000
    max_cost_usd: 4.00

第二层：任务与评分器有效性

初始评测集不必追求几百道题。Anthropic 建议先从 20 至 50 个真实任务开始，可以来自人工检查、线上故障、支持工单和高频工作流。

每个任务至少需要：

• 干净的初始状态；
• 无歧义的任务说明；
• 已知可运行的参考解；
• 接受多种正确实现的测试；
• 正例、负例和边界案例；
• 负责修订或淘汰任务的明确 Owner。

可以让两名领域专家独立判断同一结果是否通过。如果两人的结论经常不同，任务或 rubric 仍不够清晰。参考解必须通过所有 grader。大量重复运行仍保持 0% 的任务，应优先检查题目和测试，而不是直接归因为模型能力不足。

使用公开基准时，还要检查题目年龄、仓库曝光、gold patch 曝光和饱和度。公开榜单适合缩小候选范围，不适合直接充当上线证据。

第三层：隔离与重复运行

每次 trial 都要从相同冻结状态开始。上一次运行留下的文件、缓存、Git 历史、共享凭据和资源竞争都可能污染下一次结果。

当前配置与候选配置应使用相同任务、环境、grader 和预算，并保留任务级配对结果。Agent 输出存在非确定性，一次成功只能证明这次成功。

需要根据产品含义选择指标：

• 首次就必须完成时，看 pass@1；
• 允许多次尝试，只要有一次成功时，看 pass@k；
• 每次都需要稳定成功时，看 pass^k。

不存在适用于所有场景的 trial 数量。失败后果更大、方差更高、预期提升更小时，需要更多重复。报告不确定性比给出虚假的小数点更重要。

第四层：结果、安全、过程与运行

单一通过率会把四个问题压成一个数字：

结果与安全决定能否通过，轨迹主要负责定位原因。除非某个步骤具有明确安全或合规含义，否则不要锁死唯一工具调用顺序。路径测试过于刚性时，更好的合法方案也会被误判。

Harness-Bench 预印本展示了这种拆分的价值。它在 106 个隔离任务上记录最终产物、执行轨迹、用量和 validator 结果，共分析 5,194 条轨迹。失败既包括格式契约错误，也包括工具错误后没有恢复、证据不足、没有真正写入产物和中断后丢失状态。只看最终通过率，团队无法知道应该修模型、Harness、工具还是 grader。

第五层：决策门禁与证据等级

每个结论都应标注证据等级：

1. 榜单信号：用于形成候选清单。
2. 外部审计证据：已经检查任务、测试、污染和配置边界。
3. 本地复现证据：在冻结的代表性任务上完成重复 trial。
4. 生产证据：shadow、canary 和真实监控确认离线结论仍成立。

四个等级回答不同问题。公开榜单可以说明某套配置值得测试，无法证明它在你的仓库里安全、经济且可靠。

先做一个小型选型集

团队无需复刻 SWE-bench，也能建立有用的 Coding Agent 选型实验：

1. 从 issue tracker 和发布检查表选择 20 至 50 个近期任务。
2. 移除 Secret，冻结仓库状态，并保存可运行的参考 patch。
3. 用行为结果写测试，避免绑定唯一实现。
4. 为越权文件、网络访问、Secret 和不可逆操作增加硬门禁。
5. 在 manifest 中冻结模型、Harness、prompt、工具、环境、grader 和预算。
6. 让当前配置与候选配置处理完全相同的任务状态。
7. 根据风险和方差重复 trial。
8. 分别报告任务级退化、每个成功任务的成本、延迟和失败类型。
9. 人工检查测试结论、执行轨迹和看似正确 patch 之间的冲突。
10. 把生产失败回灌进评测集，最后通过受限 canary 发布。

在看到结果前就写下决策规则。安全项可以要求全部通过；关键回归任务不能从稳定成功变成重复失败；成本与 p95 延迟可以设置上限。预先承诺门禁，可以防止漂亮的平均分掩盖高风险失败。

如果当前目标是保护已上线能力，可以把相同资产接入有版本的 Agent 回归测试套件。两者的目的不同：选型评测比较配置，回归测试保护已经选择的系统。

一份可信报告至少包含什么

最终报告需要超越一个分数：

• 模型与完整 Harness 身份；
• 任务集和 grader 版本；
• 环境与依赖哈希；
• 预算、停止原因和失败运行；
• trial 数量与不确定性；
• 结果、安全、成本、延迟和监督指标；
• 已知损坏或存在争议的任务；
• 隐私允许范围内可复核的轨迹；
• 证据可以支持什么，以及不能支持什么。

AI Agent 评测不是给排行榜增加几列，而是建立一个验证系统。高价值基准的标准很具体：失败可解释，结果可复现，部署结论保持在证据允许的范围内。

常见问题

什么是 AI Agent evaluation framework？

它是一套定义任务、初始化环境、运行模型与 Harness 组合、记录轨迹、调用 grader 并聚合证据的基础设施和协议。评测对象是完整可执行系统。

SWE-bench 还有用吗？

有用，但更适合作为研究与候选发现信号。使用时需要明确数据集版本、污染风险、任务有效性、Harness 和 grader 边界，不能把分数当作生产认证。

评测 Coding Agent 需要多少任务？

Anthropic 建议从 20 至 50 个代表性任务开始。系统越成熟、预期提升越小、失败后果越大，所需任务和重复次数越多。

应该比较模型还是 Coding Agent 产品？

比较实际可部署配置，包括模型、Harness、设置、工具和预算。只有其他执行层真正固定时，模型单独比较才具有清晰含义。

通过测试为什么仍然不够？

测试可能覆盖不足、绑定特定实现、与题目不一致，或已经进入训练数据。成本、延迟、权限违规、可维护性和人工监督负担也需要单独测量。

参考资料

• JetBrains：Introducing the Kotlin Benchmark for AI Coding Agents
• Kotlin Benchmark 方法说明
• OpenAI：Why SWE-bench Verified no longer measures frontier coding capabilities
• OpenAI：Separating signal from noise in coding evaluations
• Harness-Bench
• The Scaffold Effect in Coding Agents
• Anthropic：Demystifying evals for AI agents