AI 编程 Agent 内部基准设计
很多团队在评估 AI 编程 Agent 时，第一反应是去看公开排行榜。但公开 benchmark 的价值，更多是帮助你了解大方向，而不是替你做产品决策。真正影响你线上效果的，往往不是“某模型在榜单上高 3 分”，而是它在你的仓库、你的工作流、你的代码规范里，到底能不能稳定完成任务。
这就是为什么内部基准比外部榜单更重要。一个好的内部基准，不只是比较谁更强，而是持续回答四个问题：这个 Agent 能不能完成我们的真实任务？升级后有没有回归？失败主要出在哪一类环节？哪些提升值得上线，哪些只是实验室里的漂亮数字？
一、内部基准要服务业务，而不是模仿排行榜
很多团队做内部评测时，最容易犯的错是照抄公开 benchmark 的题型，然后发现结果和线上体验并不一致。原因很简单：公开基准关注的是通用可比性，而你的团队关心的是具体工作流。
设计内部基准前，先回答下面三个问题：
| 问题 | 解释 |
|---|---|
| 你要评什么 | 是单文件补丁、跨文件修改，还是完整任务闭环 |
| 你要替代什么 | 是替代人工初稿、替代 code review 还是替代调试排查 |
| 你最怕什么 | 是错误代码进主干、任务超时，还是成本失控 |
如果这三个问题没定清楚，后面的评分和结论都会很飘。比如你明明关心“多文件改动后的稳定性”，却把大量样本放在单函数算法题上，最后优化出来的只是一个会刷题的 Agent。
二、任务集要覆盖真实工作流，而不是只收集“好看题”
内部基准最核心的资产，不是评分脚本，而是任务集。一个实用的任务集通常至少包含四类样本：
- 小修复：改 1–2 个文件，验证基本编辑能力
- 中等任务：涉及多个文件、测试和命令执行
- 调试任务：从报错、日志或失败测试定位问题
- 受约束任务：必须遵守风格、接口或安全限制
建议任务来源优先选这几类：
- 真实 bug 修复记录
- 最近 3 个月的低风险需求
- 团队反复出现的重构动作
- 常见但容易踩坑的脚手架任务
这和LLM 评测 Golden Set 构建方法的思路是一致的：题不在多，而在能稳定代表你的真实工作。千万不要只收“Agent 最容易发挥”的样本，那样只会把评测做成营销材料。
三、把一次任务拆成多个可评分阶段
“是否完成任务”当然重要，但如果只打一个最终分，你很难知道 Agent 到底输在哪里。更实用的做法是分阶段评分：
| 阶段 | 关注点 | 典型失败 |
|---|---|---|
| 理解阶段 | 是否读对需求和代码上下文 | 误解目标、漏看约束 |
| 规划阶段 | 是否拆出合理步骤 | 跳步、遗漏依赖 |
| 执行阶段 | 是否产生正确修改 | 改错文件、引入副作用 |
| 验证阶段 | 是否主动运行测试和检查 | 不验证就结束 |
| 收尾阶段 | 是否输出清楚结论 | 不说明风险与残留问题 |
这种拆法有一个巨大好处：你可以更清楚地判断该优化 prompt、工具链、模型，还是运行时框架。很多“模型不行”的问题，最后发现其实是工具权限、上下文注入或验证门禁没设计好。
四、评分维度里，成功率不是唯一指标
内部基准至少要同时看四类指标：
| 指标 | 为什么重要 |
|---|---|
| 任务成功率 | 代表最终完成度 |
| 首次通过率 | 看是否一次完成，而不是靠多次碰运气 |
| 平均修复成本 | 衡量每次成功背后的 token、时间和人工代价 |
| 回归风险 | 看是否会引入新 bug 或破坏既有约束 |
很多 Agent 看上去“成功率还不错”，但实际是靠多次重试和超长上下文堆出来的，这种结果线上通常不可接受。你需要把成功和成本放在一起看，这一点和AI Agent 多租户成本归因以及AI Agent 单会话成本监控实现是连着的。
五、基准里必须有“会诱导犯错”的样本
如果所有任务都干净、边界清楚、测试齐全，那么评测结果通常比线上乐观很多。更贴近真实环境的做法，是故意加入一些“脏样本”：
- 提示里混有不完整描述
- 项目里存在多个近似文件名
- 测试报错并不直接指向根因
- 需要在旧约束和新需求之间做权衡
这些样本的价值，不在于拉低平均分，而在于逼出 Agent 的脆弱点。很多团队上线后真正吃亏的，不是 Agent 不会写 CRUD，而是它在有歧义、有限制、有历史包袱的代码库里做出了看似合理但实际危险的改动。
六、自动评分之外，一定要保留人审切面
纯自动评分适合规模化回归，但不适合发现所有高风险问题。尤其在编程 Agent 场景里，有些错误很难靠单一测试捕捉，比如：
- 改动虽然通过测试，但破坏团队约定
- 结果能运行，但可维护性明显下降
- 提交方式正确，解释却误导后续操作者
因此，建议给高价值样本加一层轻量人审。最简单的方法是把任务分成两层：
- 基础层：全自动跑，覆盖大量回归样本
- 关键层：少量高价值题目，保留人工复核
这类分层和AI Agent 评测方法总览以及Claude vs GPT 工具调用准确率对比里提到的做法很接近：自动化负责跑广度，人审负责守住高风险判断。
七、内部基准最好分成“离线”和“准在线”两档
如果只有离线题集，评测容易和真实使用脱节；如果直接拿真实生产任务做试验，风险又太高。更平衡的做法是分成两档：
离线基准
在固定仓库快照、固定工具权限下反复跑，适合做模型升级和框架变更前后的横向对比。
准在线基准
用接近真实环境的沙箱仓库、CI、权限和运行时，验证 Agent 是否能在“接近生产”的约束里工作。比如它是否会主动读测试文件、是否能正确使用终端、是否在失败后合理回退。
对编程 Agent 来说，准在线基准的参考价值通常比纯离线更高，因为很多问题只会在“工具可用但受限”的环境下暴露。
八、回归门禁要写成制度，而不是临时决定
内部基准的终点不是出一份 PPT，而是形成发布门禁。建议至少约定三类规则：
release_gates:
success_rate_drop: "不得低于最近稳定版本 3%"
critical_task_failures: "P0 任务不得新增失败"
cost_increase: "平均单任务成本涨幅不得超过 15%"
human_review_required:
- tool_permissions_changed
- planning_prompt_changed
- sandbox_policy_changed只要把门禁写成制度，评测结果才会真正影响上线决策。否则内部基准就会退化成“偶尔跑一下、没人真正依赖”的参考资料。
九、什么时候说明你的基准已经有用了
一个内部基准是否成熟，不看题量多大，而看它能否持续帮助团队做下面这些判断：
- 新模型升级后，哪些任务真的变好了
- 某次 prompt 或工具变更是否带来隐藏回归
- 哪些失败是模型能力问题，哪些是系统设计问题
- 线上投诉最多的场景，是否已经被纳入样本集
- 团队是否能基于数据做上线和回滚决策
如果评测结果只能说明“这版分数比上版高 2 分”，却回答不了这些问题，那说明你的基准还不够贴近真实工作。
十、相关阅读
如果你要同时比较多种模型或接入方案，YoTradeApi 可以作为统一 API 接入层，方便你在同一套评测框架里做日志采集、路由控制和成本统计。