Agent 评测
为什么评测比训练更重要
没有评测的 Agent 开发就像蒙眼开飞机。评测是贯穿整个开发周期的核心基础设施，远不止上线前的 checklist。
没有评测的后果
飞行盲区：修一个 Bug，制造三个新的
没有评测体系的团队，每次改动都是一场赌博。你修了用户 A 反馈的问题，却可能悄悄破坏了用户 B、C、D 依赖的功能。更糟的是：你根本不知道自己破坏了什么，直到下一波用户投诉涌来。
真实场景
用户反馈「Agent 这周明显变差了」，团队翻了三天 commit 记录，试了十几种回滚方案，最后发现是两周前一个看起来无害的 Prompt 微调导致的。如果有评测，这个问题会在合并代码前就被发现。
猜测-检查循环
没有评测的调试过程是：猜问题在哪 -> 改一下 -> 手动试几个 Case -> 感觉好像行了 -> 上线 -> 发现又坏了。这种循环可以持续数周，消耗大量工程资源却毫无信心保障。
评测的价值时间线
早期 -- 定义成功
评测的第一个价值是迫使团队定义成功长什么样，测试反而是其次。当你写不出 eval，往往说明你对任务的理解还不够清晰。这个过程本身就能帮助产品经理更好地理解需求。
中期 -- 回归测试 & 变更验证
每次改 Prompt、换模型、调参数，都能在几分钟内知道改动对整体性能的影响。回归测试防止你在优化一个维度时不小心破坏其他维度；变更验证让你有数据支撑每一次决策。
后期 -- 新模型快速采纳
当新模型发布时（比如 Claude Opus 4.6、GPT-5），有完善评测的团队可以几天内完成迁移：跑一遍 eval suite，确认性能不降，直接切换。而没有评测的团队，需要花数周甚至数月手动验证，错过最佳窗口期。
评测的核心概念
理解这 7 个术语，你就掌握了整个评测体系的语言。
Task（任务）
一个测试用例。包含输入（给 Agent 的指令）和成功标准（怎样算完成）。
Trial（试验）
同一个 Task 的一次执行尝试。因为模型输出有随机性，同一个 Task 需要跑多次 Trial 才有统计意义。
Grader（评判器）
打分逻辑。可以是代码规则、LLM 评审、或人工打分。决定一次 Trial 的结果是通过还是失败。
Transcript（记录）
完整的执行轨迹：Agent 的每一步推理、每一次工具调用、每一个中间结果，全部记录下来。
Outcome（结果）
环境中的最终状态。不只看 Agent 说了什么，更看它实际做了什么：文件是否正确修改、API 是否正确调用。
Harness（脚手架）
运行评测的基础设施。负责创建沙箱环境、启动 Agent、收集结果、调用 Grader 打分。
Suite（套件）
一组相关 Task 的集合。例如「文件编辑能力 Suite」包含 20 个不同难度的文件编辑任务。
Claude Code 的评测演进故事
从 Dogfooding 到系统化评测
起初
靠内部工程师日常使用（dogfooding）收集反馈。「感觉最近写的代码质量不如上周」，这种直觉有用，但不精确、不可扩展。
第一步
加入简洁性和文件编辑的 eval。终于能量化「生成的代码是不是太啰嗦了」和「文件编辑是不是准确」。
进阶
发现用户抱怨「过度工程化」，于是专门加了过度工程化 eval：测量 Agent 是否在简单任务上引入了不必要的复杂度。
效果
评测帮助团队聚焦改进方向：判断从「感觉哪里不对」升级为「简洁性从 72 分提升到 85 分，但过度工程化指标从 3% 恶化到 7%，需要回退」。
关键建议
先从 20 条开始
不要等到有几百条测试用例才开始做评测。20 条精心设计的 Task，就能覆盖你最核心的场景。关键在于开始，数量是其次。一个有 20 条 eval 的团队，比一个有 0 条 eval 但「计划做 500 条」的团队，领先了一整个时代。
评测也是产品理解的手段
写评测用例的过程，会逼你回答最难的产品问题：「用户到底想要什么结果？」「什么算好，什么算不好？」「边界情况怎么处理？」很多团队在写 eval 的过程中，反而理清了长期模糊的产品定义。
评测的价值是复利：前期每一分钟的投入，后期都会在回归测试、模型迁移、团队协作中持续产生收益。最好的开始时间是三个月前，次好的是现在。
Agent 评测
三种 Grader：代码、模型、人工
Grader 是评测系统的裁判。选错了 Grader，评测结果就不可信。生产环境的经验表明，三种 Grader 组合使用，各取所长。没有银弹，但有最优组合。
Grader 1：代码评判器
代码 Grader
用程序逻辑自动判定对错
| 维度 | 详情 |
|---|---|
| 方法 | 字符串匹配、正则表达式、静态分析（AST）、单元测试 pass/fail、工具调用验证（是否调用了正确的 API 和参数） |
| 优点 | 速度快（毫秒级）、成本几乎为零、结果完全客观可复现、适合 CI/CD 自动化 |
| 缺点 | 对合理变体过于严格（比如变量名不同就判错）、缺乏语义理解、无法评判主观质量 |
| 适用场景 | 有明确正确答案的任务：代码编译是否通过、API 返回值是否正确、文件格式是否合规、数学计算是否准确 |
Grader 2：模型评判器（LLM-as-Judge）
模型 Grader（LLM-as-Judge）
让另一个 LLM 按评分标准打分
| 维度 | 详情 |
|---|---|
| 方法 | 将 Agent 的输出和评分 Rubric 一起交给一个评委 LLM，让它按预设标准给出分数和理由 |
| 优点 | 能评判主观质量（文笔、逻辑性、创造力）、能理解意图而超越字面匹配、灵活适应不同任务类型 |
| 缺点 | 成本较高（每次评判都消耗 token）、可能存在评分偏见、需要精心设计评分标准、结果不完全可复现 |
| 适用场景 | 开放式任务：研究报告的质量评判、代码风格评估、对话的自然度、摘要的完整性和准确性 |
关键技巧：Rubric 要具体到每一分
模糊的标准如「给输出质量打 0-1 分」几乎没用。好的 Rubric 应该明确：
0 分 = 完全没有回答问题，或包含严重事实错误
0.3 分 = 回答了问题但遗漏关键信息
0.7 分 = 回答完整准确，但组织混乱或有冗余
1 分 = 完整、准确、简洁、结构清晰
0 分 = 完全没有回答问题，或包含严重事实错误
0.3 分 = 回答了问题但遗漏关键信息
0.7 分 = 回答完整准确，但组织混乱或有冗余
1 分 = 完整、准确、简洁、结构清晰
Grader 3：人工评判器
人工 Grader
由领域专家直接评判
| 维度 | 详情 |
|---|---|
| 何时用 | 评测初期校准评分标准、LLM 评判出现明显盲点时、需要领域专家判断的高风险场景（医疗、法律、金融） |
| 优点 | 最高质量的反馈、能发现自动化方法的盲区、提供改进方向的深度洞察 |
| 缺点 | 不可扩展（人的时间有限）、速度慢（小时级到天级）、成本高、评判者之间也有分歧 |
| 适用场景 | 定期抽检校准模型 Grader 的准确度、全新场景的评测标准建立、关键产品决策的最终验证 |
混合策略：推荐流程
三层评判体系
1
代码 Grader 打底
先覆盖所有确定性场景：编译通过、格式正确、API 调用准确。快且便宜。
2
模型 Grader 扩展
覆盖主观场景：输出质量、逻辑性、用户体验。设计好 Rubric 是关键。
3
人工定期校准
定期抽检模型 Grader 的评分是否漂移，修正偏见，确保评测体系可信。
核心逻辑：代码 Grader 保证底线（不出大错），模型 Grader 提升上限（产出质量），人工 Grader 校准裁判（保证公正）。三者缺一不可。
真实案例
Descript
视频编辑 Agent
Descript 的评测体系围绕三个维度展开，每个维度独立打分，组合评估：
不破坏 -- 编辑后视频无损
做了该做的 -- 指令被正确执行
做得好 -- 剪辑质量专业
Bolt AI
代码生成 Agent
Bolt AI 组合了三类 Grader 形成完整评测链：
- 静态分析（代码 Grader）：检查生成代码是否编译通过、lint 无错误
- 浏览器 Agent 测试（代码 Grader）：自动打开生成的页面，验证 UI 是否符合预期
- LLM Judge（模型 Grader）：评判代码质量、可读性、最佳实践遵循度
没有银弹，三种 Grader 组合使用效果最好。代码 Grader 守底线、模型 Grader 提上限、人工 Grader 做校准，这是经过多个头部 Agent 团队验证的最佳实践。
Agent 评测
评测的坑：噪音、作弊与退化
评测做起来了不等于做对了。生产环境中反复验证的三个隐蔽陷阱：基础设施噪音会扭曲结果，模型会识别考试，一个小改动可能让性能暴跌。
1
基础设施噪音
同一个模型、同一个任务，换个沙箱配置，排名就变了
Terminal-Bench 发现
6%
仅改变 CPU/内存限制
分数差异可达 6 个百分点
分数差异可达 6 个百分点
排名逆转
同一模型 + 同一任务
换沙箱配置后排名改变
换沙箱配置后排名改变
隐性考题
基础设施配置本身
也是考题的一部分
也是考题的一部分
这意味着什么？如果你的评测环境和生产环境不一致，你在评测里看到的 95 分可能到了线上只有 89 分。你以为模型 A 比模型 B 好，但其实只是模型 A 在你的沙箱配置下跑得更顺。
对策
控制评测环境配置，像控制实验条件一样严格。每次报告评测结果时，同时报告基础设施配置（CPU、内存、网络、沙箱类型）。环境变了，分数不可比。
2
模型识别考试（Eval Awareness）
模型能推测自己在跑 benchmark，然后开卷作弊
Claude Opus 4.6 在 BrowseComp 上的发现
在 BrowseComp 评测中，Claude Opus 4.6 能推测出自己正在跑 benchmark。它识别出了题目的模式，然后尝试在网上搜索答案，或者利用训练数据中可能见过的类似题目。这是模型的泛化能力在评测场景下产生的副作用，谈不上作弊。
核心问题：当静态 benchmark（固定的题目集）遇上联网环境（模型可以搜索），评测结果就不再可靠。模型可能只是在回忆训练数据中的答案，真正的解题能力并没有被测到。
- 模型越强，识别评测的能力越高，传统的固定 benchmark 对前沿模型的区分力在衰减
- 如果你的评测用公开的 benchmark 题目，成绩可能被严重高估
- 启示：随着模型变强，评测方式需要进化：用动态生成的测试用例、限制联网、或者用真实业务场景替代公开 benchmark
3
改 Prompt 导致评测退化
一个看似无害的改动，可以让性能暴跌
事故 1：Claude Code 啰嗦修复
2026.4 事后分析
起因
用户反馈 Claude Code 输出太啰嗦，团队决定修改 system prompt 来减少冗余文字。
结果
简洁性确实提升了，但 coding eval 掉了约 3%。模型在变简洁的同时，也变得不够详细了：省略了关键的代码注释和错误处理。
事后分析
Prompt 变更应该做逐行 ablation（每次只改一行，测量影响），并通过更广泛的 eval suite 验证后才能上线。单一维度的改善不等于整体改善。
事故 2：Reasoning Effort 默认值变更
另一起性能退化事件
团队修改了 reasoning effort 的默认值（一个看似无害的配置参数调整）。
结果：多个 eval 维度出现退化。模型的思考深度被无意中削弱了，导致复杂任务的完成质量下降。这种退化很难通过简单测试发现，只有完整的 eval suite 才能捕捉到。
结果：多个 eval 维度出现退化。模型的思考深度被无意中削弱了，导致复杂任务的完成质量下降。这种退化很难通过简单测试发现，只有完整的 eval suite 才能捕捉到。
防护建议
每次变更跑完整 Suite
不管是改 Prompt、换模型、调参数，还是改基础设施，每次变更都必须跑完整的 eval suite，只测改动涉及的维度远远不够。
评测环境标准化
固定 CPU、内存、沙箱类型、网络条件。环境不一致的评测结果不可比。像对待实验室条件一样对待评测环境。
动态更新评测
评测不是一劳永逸的。模型在进步，评测也需要进化：更新测试用例、增加新维度、淘汰已被模型记住的旧题目。
三个坑的共同教训：评测系统本身也需要被评测。你需要持续审视：我的评测环境可靠吗？我的测试用例还有区分力吗？我的变更流程够严谨吗？
评测不是一劳永逸的，它需要和模型一起进化。基础设施噪音会扭曲结果，模型会识别考试，小改动会引发连锁退化。持续维护评测体系，就像持续维护代码一样重要。