编码 Agent 评测
编码 Agent 评测使用一组可验证的开发任务，比较不同方案的质量与成本。被比较的对象可以是 Agent、模型、提示或工具配置。团队效能度量则关注真实开发中交付速度和缺陷的变化。
本文先说明怎样构建可复现的任务集，再解释重复试验和代码检索的对照方法。最后讨论代码生成率的统计口径，以及怎样结合质量和成本判断团队收益。
1. 面试核心
先记住这几条，再读正文- 缺陷与回归验证。 缺陷修复任务用原本失败的测试检查修复效果，用原本通过的测试检查是否引入回归。卡 · 构建任务集
- 对照实验。 对照实验固定任务、环境和其他配置，只改变待比较的变量，并对每个任务重复运行。
- 成功概率与稳定性。
pass@k衡量 k 次尝试中至少一次成功的概率，pass^k衡量 k 次全部成功的概率。卡 · 多次尝试与重复成功率 - 检索效果。 代码检索需要同时评估相关文件的召回、最终任务成功率和执行成本。卡 · 指标与对照
- 研发效能。 AI 代码生成率衡量参与程度，交付周期、缺陷、返工和总成本共同反映开发效能。卡 · 团队效能度量
2. 构建任务集
任务集需要同时回答两个问题：Agent 要完成什么，评测端怎样判断完成。SWE-bench 提供了一个参考：从真实仓库的问题及已合并的修复 PR 中构建任务。Agent 接收问题描述和修复前代码，再由评测端用测试检查候选补丁。
构建内部任务集时，需要完成以下五项准备：
- 选择任务：从历史缺陷和小需求中选择行为要求清楚的任务，覆盖不同模块、语言和难度。这样才能观察方案在哪类工作上有效。
- 固定环境：记录仓库提交、依赖和测试环境，用容器等方式复现。测试入口整理成一条命令，减少每次运行的差异。
- 准备验收测试：一组测试在修复前失败，用来检查缺陷是否解决。另一组原本通过，用来检查补丁是否破坏已有功能。
- 人工检查题目：确认问题描述足以推导出正确行为。测试应接受满足要求的合理实现，避免只认可参考补丁的写法。
- 隔离评测答案：开发集用于调整方案，留出集保留到最终评估。参考补丁和隐藏验收答案要与 Agent 可读取的文件分开。
现有仓库测试可以供 Agent 调试，隐藏验收测试则由评测端运行，并防止被修改。这样既保留正常开发中的反馈，又能独立检验最终补丁。
公开仓库的历史修复如果进入过训练数据，模型就可能已经见过答案，使评测结果偏高。这种情况称为数据污染。内部代码或较新的任务能降低污染风险，但仍需检查参考补丁和验收答案是否泄漏。
2.1 运行隔离与失败归因
重复试验要避免前一次运行影响后一次结果。因此，每次都从相同代码和干净环境开始，并按实验设计初始化缓存、数据库和临时文件。Agent 修改过的测试文件还需单独审查，确认验收要求保持一致。
失败记录需要区分任务、环境和评测器：
- 任务失败指补丁没有实现要求，或破坏了已有行为。
- 环境失败指任务缺少执行所需条件，比如依赖下载超时。
- 评测器失败指检查程序自身出错，未能给出有效判断。
因此，依赖下载超时不能直接归因为补丁逻辑错误。报告应保留各类失败的数量和处理方式，说明哪些重跑、哪些纳入统计。
3. 指标与对照
判断一个方案是否更好，需要同时看最终结果、执行过程和资源消耗。下表列出了这些评测维度。
| 类别 | 指标 |
|---|---|
| 结果 | 任务通过率、回归通过率 |
| 稳定性 | 重复运行结果、pass@k、pass^k |
| 检索 | 相关文件或符号的 Recall@K |
| 过程 | 步数、工具错误、测试改动 |
| 成本 | Token、费用、耗时、索引维护成本 |
| 人工 | 接管比例与评审修改量 |
对照实验每次只改变一个变量。比如，比较有无代码索引时，固定模型快照、提示、工具权限和运行预算。模型快照指固定发布版本，使用它可以减少模型更新造成的差异。比较新旧仓库指令时则只替换指令，比较模型时才改变模型配置。
模型输出和执行路径会波动，所以每个任务需要运行多次。报告应展示各次结果的分布和估计的不确定范围，判断方案差异是否超过运行间的波动。
评估代码索引时，要区分检索层与任务层：
- 检索层标注任务需要阅读或修改的文件、函数，再统计 Recall@K。它表示前 K 个检索结果找回了多少比例的已标注相关项。
- 任务层比较有索引与无索引方案，比如以只用 grep 搜索作为对照。最终检查补丁是否完成任务，并比较读取文件数、执行步数和人工修正量。
找到目标文件后，Agent 仍会因理解错误或修改错误而失败。所以，需要记录每次执行轨迹，也就是各轮读取、调用和修改的过程。检查失败路径时，再区分是没有找回相关代码，还是找到后使用错误。
成本比较采用预先确定的质量门槛。通过率保持不变时降低读取量和成本，或者成本相近时提高通过率，才能说明方案有所改善。索引的构建、更新和维护成本也应计入，并检查索引是否对应当前代码版本。
3.1 多次尝试与重复成功率
同一任务尝试多次后，需要区分“找到一个可用答案”和“每次都可靠”。这两种目标分别对应 pass@k 与 pass^k。
pass@k 表示 k 次尝试中至少一次成功，适合先生成多个候选，再验收选择的场景。pass^k 表示 k 次尝试全部成功，用来观察重复运行的可靠性。
假设各次尝试相互独立，成功概率都为 p。全部失败的概率是 (1-p)^k，所以至少一次成功的概率为 1-(1-p)^k。全部成功则要求每次成功，概率为 p^k。任务难度不同或尝试相互影响时，应按任务统计，避免直接套用同一个 p。
增加尝试次数会提高找到可用补丁的机会，同时消耗更多预算。因此，报告须同时给出 k、总成本和候选筛选方法，说明最终怎样选出补丁。
4. 团队效能度量
离线任务通过率说明 Agent 在评测中的表现，团队收益还要看真实交付。生成了多少代码、用了多少 Token，都需要结合下表中的质量与成本指标判断。
| 维度 | 指标 |
|---|---|
| 交付 | 周期、开发耗时、完成任务量 |
| 质量 | 缺陷、回滚、返工、评审修改量 |
| AI 参与 | 生成代码留存、人工接管比例 |
| 成本 | 模型费用、工具费用和人工时间 |
统计代码生成率前，需要明确以下三个口径：
- 确定分母采用最终提交的全部代码行，还是只采用新增行。
- 明确人工修改后的代码归属，可以单独统计，或按约定的修改比例折算。
- 将生成后被删除、未进入最终提交的内容排除在统计之外。
比如，以最终提交的新增行作分母，再计算其中保留的 AI 生成行所占比例。工具的生成记录与最终 diff 可以用于核对。这样得到的是参与程度，生成很多代码后又大量返工，仍然会降低开发效率。
质量指标还应包含测试通过率，AI 使用情况可以补充一次生成成功率。成本则要计入 Token 消耗、模型与工具费用，以及人工处理时间，再计算单任务成本。
判断提效时，比较同类需求使用 AI 前后的交付周期与缺陷变化，或设置同时期的对照组。对照还需控制任务难度、人员和时间窗口，因为项目与团队变化也会影响结果。最终同时展示速度、质量和成本，才能判断节省的时间是否被返工或费用抵消。
5 · 面试题卡片
本页题目与参考回答
5.1 如何构建一个评测编码 Agent 的 benchmark？
考察重点
- 说明怎样用测试验收任务、复现环境，并检查题意和测试是否一致。
- 解释对照实验需要固定哪些条件，以及每个任务为什么要运行多次。
参考回答
编码 Agent 的基准需要代表性任务、可复现环境和可执行的验收标准。
任务从真实仓库的历史缺陷与小需求中选择，覆盖不同模块、语言和难度。每个任务包含修复前代码、问题描述和验收测试。原本失败的测试检查修复效果，原本通过的测试检查回归。人工再确认描述充分，测试接受满足要求的替代实现。
每次从干净环境运行，用容器固定依赖，并提供统一的测试命令。现有测试可以供 Agent 调试，隐藏验收测试和参考补丁则由评测端保护。内部或较新的任务有助于降低训练数据污染风险，留出集用于最终评估。
比较方案时只改变目标变量，固定其他配置与预算。每个任务重复运行，再报告通过率、重复成功率、步数、Token 和耗时。失败需要区分任务、环境与评测器原因，避免把环境故障当成补丁错误。
5.2 如何评测一个 Codebase Index 或检索方案对编码 Agent 的效果？
考察重点
- 解释检索层命中为什么还需要用最终任务结果验证。
- 在相同任务与预算下比较通过率、执行成本和索引维护成本。
相关内容：指标与对照。
参考回答
代码索引需要同时评估检索召回和最终任务结果，才能判断它是否帮助 Agent 完成工作。
检索层标注需要阅读或修改的文件、函数，统计前 K 个结果的召回率。任务层在同一任务集比较有索引方案和只用 grep 等无索引方案。固定模型、其他工具和预算后，多次运行观察波动。
比较指标包括成功率、读取文件数、步数、Token、耗时和人工接管比例。通过率保持不变而成本降低，或成本相近而通过率提高，才支持索引有效的结论。索引构建与更新成本也需计入，并确认索引与代码版本同步。失败轨迹用于区分没有找到相关代码，以及找到后理解或修改错误。
5.3 AI 代码生成率怎么统计？它能代表研发效率吗？
考察重点
- 明确代码生成率的分母，以及删除代码和人工修改代码怎样统计。
- 区分 AI 参与程度与开发效率，并结合质量和成本评价收益。
相关内容：团队效能度量。
参考回答
代码生成率可以用最终新增代码中保留的 AI 生成行占比统计，它衡量参与程度，无法单独证明研发提效。
分母和归属规则需要事先约定。生成后删除的内容排除，人工大幅修改的部分单独统计，或按约定的修改比例折算。再用工具生成记录和最终 diff 核对结果。
生成代码多但返工和缺陷也多时，开发效率反而会下降。因此，应对同类需求比较交付周期与开发耗时，同时检查缺陷率、回滚率和评审修改量。模型、工具和人工成本也需计入。对照组或使用前后的比较还要考虑人员与任务难度变化，才能解释效率差异。
5.4 pass@k 与 pass^k 有什么区别，为什么要同时报告尝试预算？
考察重点：区分多个候选中至少一次成功与重复运行全部成功，并解释尝试次数对成本的影响。
相关内容：多次尝试与重复成功率。
参考回答
pass@k 衡量 k 次尝试中至少一次成功，pass^k 衡量 k 次尝试全部成功。
各次独立且成功概率同为 p 时，两者分别为 1-(1-p)^k 和 p^k。前者适合生成多个候选后再验收，后者反映重复执行的可靠性。任务难度不同或尝试相互影响时，需要按任务统计。
多次尝试提高找到可用补丁的机会，也增加成本。所以，比较时必须固定 k 或总预算，并报告实际用量和最终补丁的筛选方法。