三个 Coding Agent 都拿到 95 分之后，团队该测什么

发表于
Supabase Evals 的实时榜单上，Claude Code 与 Codex 的三个组合同时得到 95%。当公共跑分无法替团队做决定，如何用真实任务建立一套能进入 CI 的 Agent 评测？

今天早上打开 Supabase Evals，榜单第一名不是一个 Agent，而是三个。

Claude Code / Opus 5、Claude Code / Sonnet 5，以及 Codex / GPT-5.6 Sol 的总分都是 95%。继续往下看，OpenCode / Kimi K3 是 86%，Codex / GPT-5.4 mini 是 82%。

这张榜单当然可以告诉我们，几个头部 Coding Agent 都能处理相当多的 Supabase 任务。但它无法替一个具体团队回答更重要的问题：

在我们的代码库、权限、工具和故障类型里，哪一个 Agent 更值得信任？

95 分的并列不是评测失效。恰恰相反，它提醒我们公共榜单已经完成了自己的工作：帮你缩小候选范围。接下来真正影响采购、上线和自动化范围的证据，必须来自团队自己的任务。

Supabase 没有再造一张通用榜单

7 月 31 日，Supabase 开源了 Evals。它会让 Claude Code、Codex 和 OpenCode 等 Agent 在真实的 Supabase 环境中完成任务，例如创建数据库结构、排查失败的 Edge Function，或者修复错误的 RLS 策略。

这里最值得借鉴的不是谁排第一，而是题目从哪里来、结果怎样被验证。

Supabase 先把需要覆盖的范围拆成产品、通用主题和用户旅程，再从支持工单、Bug 报告与 GitHub Issue 中挑选真实问题。每次运行都拿到项目状态、上下文和实际开发工具，不是在聊天框里回答一道选择题。

Agent 完成任务后，评分器会检查 SQL、以真实用户身份发起客户端调用，并读取 Agent 创建的文件。只有无法用确定性规则判断的部分，才交给 LLM Judge 做语义评分。

这与“让模型说自己是否完成任务”有本质差别。一个 Agent 可以在最后回复“RLS 已经修复”，但真正的结果是：无权限用户还能不能读到那行数据。

Anthropic 的 Agent 评测指南把两者称为 transcript 和 outcome：前者记录 Agent 说了什么、调用了什么工具，后者检查运行结束后环境究竟变成了什么。对 Coding Agent 来说，最终状态通常应该先于文字解释。

榜单上的分数，测的是一整个系统

公共模型榜单很容易让人忘记一件事：Coding Agent 的被测对象并不只是模型。

它至少包含下面几层：

层级 会改变结果的因素
模型 推理能力、上下文长度、输出稳定性
Agent Harness 任务循环、上下文压缩、错误恢复、重试策略
工具 终端、文件、MCP、浏览器以及工具描述
指令 系统提示词、仓库规范、Skills 和任务边界
环境 代码版本、依赖、凭据、网络和可用服务
评分 测试覆盖、人工标准、成本和成功定义

Supabase 的开源仓库也明确把 model、agent、runtime、experiment 和 eval 分开。一个 experiment 是 Agent、运行时和模型的组合；一个 eval 则包含 Prompt、评分器，以及远程项目和本地工作区的初始状态。

所以，榜单上写着“Codex / GPT-5.6 Sol”，并不意味着 95 分可以直接外推到你的项目。换掉工具定义、Skills、Token 预算、网络权限和测试覆盖，结果就可能改变。

这也是我在 上一篇评测文章 里没有继续追问“谁才是真正第一名”的原因。公共基准负责测量一个可复现的切片；内部评测负责判断这个切片是否像你的工作。

内部评测不是另一张小排行榜

很多团队听到“建立内部评测”，第一反应是收集一批题，再给模型排一次名。

这样做仍然会错过最重要的价值。

内部评测真正应该建立的是一条反馈回路：真实故障进入题库，改动在发布前重放，失败变成回归测试，新的生产问题再回来补题。它更像 CI，而不是高考。

Supabase 把场景拆成两套，正好说明这种区别：

  • Benchmark suite 追求覆盖面，用较少但多样的任务观察 Agent 能做什么；
  • Regression suite 追求深度，持续盯住已经发现的具体失败，不让修复在下一次模型或工具升级后消失。

能力评测问的是“它现在能做到什么”，回归评测问的是“它以前会做的事，现在还会不会”。前者适合探索，后者才适合卡住发布流水线。

这也解释了一个看似不起眼的发现。Supabase 发现，某个 Postgres Skill 最初只有大约十分之一的运行会主动加载。团队重写 Skill 描述，让触发条件更清楚后，激活率提高到了 60%。

模型没有更换，业务代码也没有更换，变化来自 Agent 是否找到了正确的说明书。如果只看最终总分，这类问题很容易被归因成“模型不够聪明”；有了运行轨迹和稳定场景，团队才知道应该改的是 Skill 描述。

从 15 个真实任务开始

团队不需要先建设一个复杂的评测平台。与其复制几千道公开题，不如先收集 15 个真正影响日常交付的任务。

1. 从返工和故障里找题，不从 Demo 里找题

挑选最近三个月里真实发生过的代码审查返工、CI 失败、线上 Bug 和工具误用。一个任务应包含固定代码版本、清楚的需求、必要上下文和可检查的成功条件。

“写一个登录页面”适合演示；“修复这个会让企业账号绕过二次验证的回归，并保持旧客户端兼容”才接近团队真正承担的风险。

2. 固定 Agent 能看到和能做到的东西

同一轮比较要固定仓库提交、依赖版本、系统指令、Skills、工具、Token 上限、超时和重试次数。否则，比较的不是 Agent，而是几套不同的实验条件。

权限也必须成为评测的一部分。一个需要写数据库、访问外网或使用生产凭据才能成功的方案，不能因为测试通过就被当作更优答案。

3. 先验收最终状态，再阅读漂亮的解释

代码能否构建、测试是否通过、数据库权限是否正确、页面是否真的可访问，都应该由脚本直接检查。Agent 的最终回复只能补充原因，不能替代结果。

可以把评分分成四层：

层级 典型检查
正确性 目标测试通过、旧测试不回归、功能真实可用
边界 没有越权文件、外部写入和敏感信息泄漏
工程质量 修改范围合理、遵守架构与仓库规范
交付成本 Token、耗时、重试、人工接管和审查时间

4. 每道题运行多次

Agent 输出具有随机性。一次成功说明“可能做到”，多次运行才能说明“可以依赖”。

至少记录成功率、最差结果、P50/P95 耗时、单任务成本和人工接管次数。两个 Agent 都是 95 分时，更低的方差、更少的越界修改或更短的审查时间，往往比再多一个小数位更有决策价值。

5. 让失败自动进入回归套件

每次人工接管或线上失败，都问一句：能不能把它变成一个可重复、可自动判定的场景？

如果答案是可以，就把它加入回归套件，并在模型、Prompt、Skill、工具或运行时升级时重新执行。长期看，最有价值的不是某一天最高的分数，而是团队把多少真实失败变成了不会再发生的测试。

评测也会制造错觉

内部任务更贴近业务，但并不天然可靠。

题目太少，会让一次偶然成功改变结论；评分器只检查测试，可能奖励“刚好过测试”的脆弱补丁；团队长期针对固定题目调优，也会形成自己的过拟合。LLM Judge 能处理开放问题，却有不稳定、偏好和成本问题。

因此，自动评测不能取代生产监控、A/B 测试和人工审查。它们更像几层相互补洞的安全网：自动化负责高频回归，生产数据发现测试集没想到的问题，人负责校准“好代码”究竟意味着什么。

Supabase 也把公开页面标成实时结果，并提醒读者，AI 工具变化很快。本文看到的 95% 是 2026 年 8 月 12 日的快照，不是一个永久排名。

95 分之后，才轮到团队做决定

三个 Agent 同时拿到 95 分，最诚实的解读不是“它们完全一样”，而是这套公开任务暂时不能替你的团队继续区分。

接下来需要测的，是你自己的长尾：那个只有旧版 SDK 才会触发的错误，那段没有测试却关系到计费的代码，那次 Agent 为了让 CI 变绿而修改了不该碰的配置，以及每次看似成功却需要工程师花半小时收拾的提交。

公共排行榜告诉你谁值得进入面试。真实任务、可执行验收和持续回归，才决定谁能拿到工牌。

当 Coding Agent 开始进入 CI/CD，团队需要的不是更大的模型崇拜，而是一套能回答“这次改动是否真的更可靠”的小型科学方法。

榜单的终点，应该是内部评测的起点。

资料与口径