AI Coding Agent 怎么做真实仓库评测：任务集、通过率、成本与回归基线

美国区过去完整周中，“AI coding” 在本轮五个对比词里热度最高，为 27。

公开榜单适合了解模型能力，但不能回答某个 Agent 是否适合你的仓库。

先定义你真正购买的结果

有人需要快速修小 bug。

有人需要跨服务重构。

有人更在意隐私、成本和可审计性。

把这些目标写成权重，避免最后只比较“看起来聪明”。

从历史工单抽取任务

选择已经解决、答案可验证的工单。

覆盖四类难度：

单文件明确修复。
跨文件行为修改。
需要运行项目才能定位的问题。
需求含歧义、必须先提问的任务。

不要只选模型训练资料里可能出现的公开热门 issue。

每个任务创建固定起点

保存仓库 commit、依赖锁文件和测试数据版本。

使用独立 Git worktree。

1

git worktree add ../eval-task-01 <base-commit>

容器镜像用 digest，而不是浮动 latest。

外部 API 用录制响应或测试环境。

写机器可判定的通过条件

单元测试通过只是第一层。

还要检查原有测试、类型检查、lint 和构建。

数据库任务检查 schema 与数据兼容。

前端任务加入截图或无障碍断言。

安全任务加入负面测试。

防止 Agent 修改裁判

隐藏测试不放在可写工作树。

测试运行器挂载为只读。

检查 Agent 是否删除、跳过或弱化现有测试。

比较测试数量与覆盖率变化。

禁止通过硬编码测试输入“修复”问题。

记录完整运行轨迹

至少保存：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


agent_version
model
task_id
base_commit
prompt_version
wall_time
input_tokens
output_tokens
tool_calls
human_interventions
final_cost

没有版本字段的结果无法用于以后回归。

敏感日志先脱敏再归档。

成功率分成三档

一次通过：无需人工修改，所有验收通过。

协助通过：人提供澄清或小改后通过。

失败：未完成、破坏其他行为或结论不可信。

不要把“生成了很多代码”计作成功。

也不要把 Agent 自述的“已修复”当测试结果。

成本按成功任务计算

平均每次请求成本会掩盖失败重试。

更有用的是：

1

每个一次通过任务成本 = 总成本 / 一次通过任务数

同时记录工程师审核时间。

便宜模型若需要更久人工审查，总成本未必更低。

时间指标拆成三段

首个有效动作时间。

Agent 完成时间。

人工审核到合并时间。

并行 Agent 可能缩短第二段，却增加第三段冲突成本。

因此只看模型响应速度没有意义。

重复运行衡量稳定性

同一任务至少运行三次。

固定模型版本、温度和环境。

三次中只有一次通过，不能当成可靠自动化。

记录失败类型是否一致。

稳定地提出正确澄清问题，也是一种可用能力。

建立失败分类

没找到相关文件。
理解错需求。
工具或环境失败。
补丁正确但测试不完整。
修改超出范围。
伪造验证结果。
成本或时间超限。

分类后才能决定改模型、提示、工具还是环境。

升级前运行回归

保留 15 到 30 个代表性任务作为基线。

Agent、模型、工具权限或系统提示变化都触发回归。

新版本至少不能让高风险任务退步。

结果用同一评分脚本生成。

不要在看到结果后临时改变权重。

一张实用结果表

Agent	一次通过率	人工分钟/任务	成本/成功任务	越界次数
A	由测试填写	由记录填写	由账单填写	由审计填写
B	由测试填写	由记录填写	由账单填写	由审计填写

保留原始任务级数据，不只发布汇总平均值。

结论怎么写才可信

说明仓库语言、任务类型、模型日期和权限配置。

说明样本量与置信限制。

区分事实数据与主观体验。

不要把一个仓库的赢家宣传成所有场景的赢家。

真正有价值的评测，是下一次升级时可以原样重跑的工程资产。

评测数据来源

任务清单使用版本化 YAML

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


id: api-017
base_commit: 8c18d4a
category: cross-file-bug
time_limit_minutes: 30
allowed_paths:
  - src/api/
  - tests/api/
required_checks:
  - python -m pytest tests/api
  - ruff check src/api tests/api
forbidden_changes:
  - tests/fixtures/golden.json

任务描述与隐藏测试分开保存。YAML 进入评测仓库，隐藏测试放在 Agent 无权读取的执行环境。

区分环境失败与能力失败

依赖源不可用、容器拉取失败或测试基础设施故障不应直接计为模型失败。先由固定的预检脚本确认环境健康。

环境正常后才启动计时。Agent 自己破坏依赖或配置导致的失败则属于任务结果，不能标记为基础设施问题。

人工干预如何计分

把干预分成需求澄清、环境帮助、技术提示和直接给出答案。每类分别计数与计时。

Agent 主动提出必要澄清，与人主动透露关键文件位置不同。前者可能是良好行为，后者说明独立完成能力不足。

检查补丁范围

1
2
3


git diff --name-only <base-commit>...HEAD
git diff --numstat <base-commit>...HEAD
git diff --check <base-commit>...HEAD

统计修改文件数、净增删行和任务允许范围外的文件。大补丁不自动扣分，但无关修改应单独标记。

对抗“测试通过但行为错误”

隐藏测试覆盖边界输入、错误处理和旧行为兼容。人工审查测试是否被跳过、mock 是否过度，以及实现是否硬编码样例。

前端任务录制关键交互，API 任务比较状态码与错误结构，性能任务使用固定数据集和预热规则。

评测成本包含基础设施

除模型 token 费用，还记录容器时间、浏览器运行、数据库实例和日志存储。企业环境再加入人工审核成本。

同一 Agent 并发运行时，按任务分摊共享服务成本。不要把免费试用额度当长期单位成本。

结果变化的显著性

二十个任务中多通过一个，可能只是随机波动。查看任务级配对结果：哪些旧任务退步，哪些新任务改善。

对关键类别设置最低通过率，而不是只看总平均。安全修复退步不能被文档任务提升抵消。

保存失败产物

失败运行保留最终 diff、最后测试输出、工具错误与停止原因。去除凭据后存入按任务和运行 ID 命名的目录。

复盘时先比较失败类型，再阅读长对话。很多问题可以直接从重复工具调用、错误工作目录或测试未执行看出。

防止基准被训练记忆污染

内部任务不要公开完整描述与答案。定期从新近已解决工单补充题目，并淘汰已经泄露的任务。

保留一组长期锚点用于趋势比较，同时用滚动任务衡量当前真实工作。两组结果分别报告。

发布结果时附上未通过任务清单和停止原因，避免汇总分数掩盖模型在关键场景中的稳定失败。

原始数据保留足够精度，展示时再统一四舍五入。