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 的过程中，反而理清了长期模糊的产品定义。
评测的价值是复利：前期每一分钟的投入，后期都会在回归测试、模型迁移、团队协作中持续产生收益。最好的开始时间是三个月前，次好的是现在。