AI 简明手册先定义“做对了”：Agent 评测入门
定义
评测是贯穿 Agent 开发周期的核心基础设施，不是上线前的 checklist。没有评测的团队每次改动都在赌博，无法知道破坏了什么。评测的价值从早期定义成功标准开始，贯穿回归测试、变更验证和新模型迁移。
先搭一个心智模型
评测不是发布前的一次考试，而是 Agent 的仪表盘：任务集代表真实路况，Grader 读取可观察信号，轨迹解释为什么得分，回归集防止修好一处又撞坏另一处。
说明
没有评测时，修一个问题可能悄悄破坏其他能力。基本术语可以这样区分：Task 是带输入和成功标准的用例；Grader 是评分逻辑；Transcript 是执行轨迹；评测执行器（eval harness）负责批量运行；Suite 是相关 Task 的集合。这里的 eval harness 不等于 Agent 运行时编排层。
评测应从定义成功标准开始，并随着产品演进覆盖回归、变更验证和模型迁移。规模不是第一目标，先让少量代表性用例稳定、可重复，再根据线上失败扩充。
起步时选择一小组覆盖核心路径、边界和高风险失败的 Task，并保存输入、环境、轨迹与评分版本。具体数量应由场景复杂度和风险决定。
跟着一个例子走
给退款助手建立最小评测闭环
团队想知道新版提示词是否真的减少误退款，而不是只让回复看起来更流畅。
- 先写可观察的成功条件
是否找到正确订单、是否引用适用条款、是否在执行前取得确认。
- 保存完整轨迹
记录模型看见的上下文、选择的工具、参数、结果和最终答复。
- 用失败样本做回归
修复一个错误后，把对应案例加入固定任务集，后续版本必须继续通过。
边界与误区
为什么写评测用例的过程本身就有价值： 写评测用例逼团队回答最难的产品问题：用户想要什么结果、什么算好什么算不好、边界情况怎么处理。很多团队在写 eval 过程中理清了模糊的产品定义。
从多少条评测用例开始比较合适： 没有通用数字。先覆盖最重要的成功路径和高风险失败，并确保用例可重复；之后根据缺陷和线上轨迹逐步扩充。