Agent 评测：方法论与体系设计
一句话概括
这篇文章把 Agent 评测从“跑几个 case 看感觉”升级为完整质量体系：先按 Agent 类型拆评测侧重，再围绕指标、数据集、评分器、Trace、线上灰度和反馈生产建立可回归、可归因、可持续迭代的闭环。
实践内容
文章给出的可执行框架可以压缩成一条评测流水线：
执行用例 -> 采集 Trace -> 运行 Scorer -> 生成报告 -> 做根因归类 -> 反馈生产 -> 回归集/规则/Judge 校准集核心工程要求：
Trace 标准字段：
- 工具名
- 入参
- 返回值
- 时间戳
- 耗时
- 错误
- 复杂 Agent 还应记录计划、检索、Guardrail 等过程信息
发布联动信号：
- 离线质量信号：核心场景通过率、P0 风险数、关键工具参数正确率
- 线上体验信号：转人工率、重复追问率、投诉率、满意度变化
- 业务结果信号：任务完成率、工单闭环率、退款/赔付成功率等
Badcase 入库标准：
- 失败可复现，或至少有稳定 Trace 和人工确认
- 期望行为明确，可以写成规则、Judge 标准或人工验收标准
- 根因标签清楚，能归到具体能力域或业务流程
- 样本有代表性，能覆盖一类问题，而不是一次性环境抖动
- 已完成脱敏，符合隐私和数据合规要求对话 Agent 的评测不应只平均每轮分数，而应同时观察四层：
Turn -> 单轮回答质量
Session -> 整段会话是否解决问题
Trace -> 执行路径、工具调用、上下文使用是否合理
Outcome -> 最终业务结果是否达成摘录
评测底层骨架可以复用：执行用例、采集 Trace（执行轨迹）、运行 Scorer（评分器）、生成报告、做根因归类。真正需要按业务定制的是“评什么”和“怎么判”。除了按 Agent 类型设计评测体系，还需要关注 Agent 内部的能力单元。随着 Agent 越来越多地通过 Skill 完成工具调用、数据处理、报告生成和业务动作，Skill 本身也需要测评：它是否该触发、触发后是否走对流程、工具参数是否正确、最终产物是否可用、异常时是否能降级。
工程化时要把 Trace 输出当作被测 Agent 的标准能力，而不是事后补救。Trace 至少需要稳定记录工具名、入参、返回值、时间戳、耗时和错误；复杂 Agent 还应记录计划、检索、Guardrail等。评测执行环境也要隔离，避免多个用例共享状态导致分数不可复现。反馈生产是评测闭环里最容易被低估的一环。发现问题本身不会自动带来收益，只有把问题沉淀成可复用资产，下一轮迭代成本才会下降。
反馈生产要有“入库标准”，不能把所有失败都无差别塞进回归集。建议满足以下条件再入库：失败可复现，或至少有稳定 Trace 和人工确认；期望行为明确，可以写成规则、Judge 标准或人工验收标准；根因标签清楚，能归到具体能力域或业务流程；样本有代表性，能覆盖一类问题，而不是一次性环境抖动；已完成脱敏，符合隐私和数据合规要求。
涉及实体
- AI可观测性 —— 文章把 Trace、线上体验信号、业务结果信号纳入评测闭环，扩展了可观测性的质量治理维度。
- Prompt评估体系 —— Prompt/Agent/Skill 的评测对象不同，但都需要先校准评分器，再扩大样本和回归集。
- Harness-Engineering —— 评测体系是 Harness 的验证层和反馈层，决定 Agent 能否从 demo 进入生产。
- Agent-Skill —— 文章明确强调 Skill 自身也要评测触发条件、流程正确性、工具参数、产物质量和异常降级。
涉及主题
我的评注
这篇文章的关键补充是“反馈生产”：评测不是出分，而是把线上失败转成可复用质量资产。它与已有 Agent评测方法论 中的 LLM-as-Judge、黄金集、基线快照并不冲突，而是把质量资产进一步拆成用例库、Trace 库、根因标签库、修复建议库、Judge 校准集和回归集。对生产 Agent 来说，这比单次分数更重要。