很多团队说要评测 AI Agent，第一反应是写一批标准问答。这样当然有用，但如果题目都是理想场景，测出来的结果也只能证明 Agent 会做简单题。真正能发现风险的评测集，往往来自真实失败样本。
评测集不是为了给 Agent 打一个漂亮分数，而是为了在改提示词、换模型、接新工具、调整知识库之前，先知道会不会把旧问题重新放出来。它应该接上 回放验收、影响面评估 和 灰度发布。
失败样本比理想题更值钱
真实失败样本通常来自客服投诉、人工接管、工具报错、知识库引用冲突、外部写入失败和低置信度回答。它们不一定整齐，但最接近生产环境。
收样本时不要只保存用户问题，还要保存当时的上下文、工具返回、引用来源、最终结果和人工修正。少了这些字段，后面很难判断 Agent 是理解错、检索错，还是工具调用错。
每个样本都要有通过标准
评测样本不能只写“回答正确”。更好的通过标准应该包含：是否使用了正确工具，是否引用了合适资料，是否拒绝了高风险请求，是否触发人工复核，最终输出是否可执行。
如果是工作流型 Agent，还要看过程。比如退款场景里，先查订单再判断规则，和直接生成退款承诺，是完全不同的风险水平。
人工评分要先校准
LLM-as-judge 可以提高效率，但一开始最好先让人评一批样本，形成评分标尺。哪些算严重错误，哪些只是表达不够好，哪些必须拦截，先要有人说清楚。
这一步可以借鉴 质量门禁。评测不是追求一次性完美，而是把不可接受的问题稳定挡住。
回归测试要跟变更绑定
评测集的价值，只有在变更前后对比时才明显。提示词改动、模型升级、知识库重建、连接器权限变化，都应该跑一次核心评测集。
结果不要只看总分。要看哪些样本退步了，退步是否集中在某类工具、某类知识源或某类用户意图。这样才能决定是继续上线、灰度观察，还是先回滚。
总结
用 AI Agent 做评测集，先从真实失败样本开始。样本里要保留输入、上下文、工具轨迹、引用来源、人工修正和通过标准。这样评测才不是表演，而是能在变更前发现风险的工程工具。
