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