如何评测 AI 编程 Agent：我们自用的同任务方法
评测 AI 编程 Agent 的方法：让每个候选 Agent 跑同一个小而可验证的任务，按固定 schema 记录每次运行，然后让记录——而不是 demo——做决定。方法就这么多；功夫全在细节里：任务要小到可验证、又大到迫使 Agent 读你的代码；prompt 在工具之间一个字不能改；计时边界必须显式声明；不完整的运行要靠规则而不是靠心情排除。本页公开我们自家基准使用的完整协议，包括为了把它做对而踩过的坑。
第 1–2 步：任务与 prompt
我们的典范任务：在一个小型 TypeScript API 里，新增返回服务状态和时间戳的带校验 /health 端点，加一个证明其响应的单元测试，然后运行测试并总结 diff 和假设。它小到一个人几分钟就能验证结果，又足以逼出区分 Agent 和自动补全的行为：读现有文件、改代码、跑命令、如实汇报。无论你选什么任务，措辞要冻结。你为某个工具改写 prompt 的那一刻，测的就是你的 prompt，而不是 Agent。
第 3 步：记录 schema
| 字段 | 它告诉你什么 |
|---|---|
| toolVersion + checkedAt | Agent 每周都在变；不带日期的结果就是传闻 |
| usefulResultTimeMinutes | 到达真正可用结果的时间——不是首个输出的时间 |
| 人工介入数 + 审查修正数 | 最能预测 Agent 日常团队成本的两个指标 |
| readRelevantFiles / producedReviewableDiff / ranTests | 行为而非声明：它像 Agent 一样行动，还是像聊天机器人一样猜 |
| firstAttemptPassed + humanIntervention | 闭环是否无人值守完成，以及它需要多少个你 |
| rawEvidencePath | 没有原始记录和 diff 就不得引用——这是防编造字段 |
第 4–5 步：计时边界与发布门
两条规则让数字保持诚实。第一，声明计时包含什么。在我们自己 2026-07-10 的实测里，有一条记录只从实现补丁计到验证完成，而其他记录包含完整 agent 会话——这个计时边界差异让这些耗时互不可比，所以我们发布的表格在说明里直接写明，而不是指望没人注意。环境摩擦是真实的（一个工具开跑前需要重新设备授权；另一个得从零安装并登录），它们都不属于任务时钟。第二，按完成度设门：记录只有标记 complete、日期合法、指向原始证据才算数。我们的校验器刻意拒绝把部分完成转成正面排名——而失败的首次尝试在记录了修复路径和审查负担后，仍然可以作为证据发布。
第 6 步：我们自己的实测教了我们什么
我们的四 Agent 典范任务实测，以全员首次通过、零介入收场。这是个好结果，也是个坏基准：一个所有 Agent 都能通过的任务没法给它们排名。它仍然产出了真实信息——四者都无人值守地闭合了读-改-测循环，其中一次运行给出了 $0.28 按量成本的具体数据点——但区分力没有了，所以我们协议的下一轮迭代会升级任务难度，直到 Agent 之间拉开差距。你那边也会一样：把任务校准到至少有一个候选者会失败的难度，因为评测的价值就藏在失败里。还有一条诚实的限制：单次运行没有统计效力。它胜过厂商 demo 和二手截图，但每个数字都该当作一次观察，而不是一个分布。
常见问题
怎样公平地对比 AI 编程 Agent？
同一任务、逐字相同的 prompt、同一记录 schema、显式计时边界，以及决定哪些运行算数的完成度门槛。任何一项在工具间发生变化，对比就悄悄变成了在测你的配置，而不是 Agent。
评测编程 Agent 时哪些指标最重要？
有效结果耗时（而非首个输出时间）、人工介入次数、审查修正次数，比原始速度更能预测日常成本。行为检查——是否读了相关文件、是否产出可审查 diff、是否跑了测试——能把 Agent 和聊天机器人区分开。
评测任务应该多大？
小到人可以在几分钟内验证结果，大到必须读现有代码。然后向上校准：如果所有 Agent 都通过，任务就没有区分力——把难度升到至少一个候选者失败，然后去读那个失败。
该相信公开的 AI 编程基准吗？
相信那些公开 prompt、计时边界、逐次记录和原始证据、并承认其任务测不出什么的基准。任何不说明计时边界或样本量就给 Agent 排名的基准，都只是带表格的营销——包括它恰好夸了你喜欢的那个工具的时候。
结论：Agent 评测是一个小型工程项目，不是凭感觉打分。一个任务、一条冻结的 prompt、一套 schema、一道门——然后让记录去争论。如果这页你只带走一样东西，就带走我们学得最贵的两条规则：声明你的计时边界，把任务升级到有人失败为止。