AI Agent 应用精细化评测：从端到端结果定位到模块级缺陷
Agent 评测不能只问“最后完成了吗”。端到端结果适合判断用户任务是否达成，但无法说明失败来自感知、规划、记忆、工具调用还是数据来源。精细化评测的目标，是把一个总结果拆成可以定位、修复和回归的模块信号。
本文根据阿里技术《AI Agent 应用精细化评测：评测体系设计与工程实践》的公开摘要整理。摘要明确提到两条主线：端到端指标判断任务是否完成，模块指标定位具体缺陷；回答是否忠于检索材料，还要与检索来源本身是否正确分开评估。
一、端到端指标和模块指标不是替代关系
| 层级 | 主要问题 | 典型用途 |
|---|---|---|
| 端到端 | 用户任务是否完成，结果是否可用 | 上线准入、版本比较、业务效果 |
| 感知 | 输入是否被正确理解 | 图片、文本、语音、页面状态解析 |
| 规划 | 是否形成正确步骤和依赖 | 长任务、分支、重试和停止条件 |
| 记忆 | 是否取到正确历史与上下文 | 个性化、跨轮、项目事实 |
| 工具调用 | 参数、权限和结果处理是否正确 | API、数据库、浏览器、代码执行 |
| 输出 | 是否符合格式、事实和表达要求 | 用户交付、结构化消费、审计 |
端到端通过但模块指标异常，说明当前测试没有覆盖真实风险；模块都通过但端到端失败，说明模块之间的组合协议或任务编排存在问题。
二、先定义评测范围
评测范围要和产品承诺一致。一个知识问答 Agent 可能只需要检索、引用和回答质量；一个 Coding Agent 还要评估文件修改、命令执行、测试修复、权限和回滚；一个业务策略 Agent 则需要进一步观察线上实验和风险指标。
建议为每个场景建立范围表：
场景 → 用户目标 → Agent 能力 → 工具 → 数据 → 指标 → 埋点 → 责任人
没有范围表，评测会不断增加指标，却无法判断哪些指标真的影响交付。
三、数据集要覆盖失败模式
评测集不应只收集“正常问题”。至少要包含：
- 主流程样本；
- 边界和缺失输入；
- 多轮上下文；
- 工具失败和超时；
- 权限不足与恶意诱导；
- 真实线上 Bad Case；
- 新业务、新版本和分布变化样本。
测试集、调参集和最终验证集要隔离。若 Agent、Judge 和数据集同时迭代，却一直用同一批样本判断提升，最终得到的可能只是对评测集的适配。
四、埋点要能回答“哪一步错了”
模块化评测必须在运行时留下事件：输入版本、检索请求、候选文档、规划步骤、工具参数、工具响应、重试、最终输出和人工修正。每条事件要有 trace_id、run_id、版本号和时间戳。
一个“回答错误”的结论还不够。需要继续判断：
- 检索是否漏掉了正确来源？
- 召回来源是否本身错误或过期？
- Agent 是否正确理解了来源？
- 生成答案是否忠实引用，还是出现了额外幻觉？
五、忠实性与来源正确性必须分开
这是摘要中特别强调的一个关键点。回答忠实性评估的是“答案有没有超出材料”；来源正确性评估的是“检索到的材料是否真的支持问题”。
| 情况 | 结论 |
|---|---|
| 来源正确，回答不忠实 | 生成或引用环节出错 |
| 来源错误，回答忠实 | 检索或知识库出错 |
| 来源和回答都正确 | 链路通过 |
| 来源和回答都不正确 | 需要分别记录两个根因 |
把二者合成一个分数，会让团队误以为只改 Prompt 就能解决知识库错误。
六、从指标到优化动作
评测报告最好直接输出责任路由：
- 感知失败：补充输入解析样本或改感知模块；
- 规划失败：检查任务分解、依赖、停止条件和重试策略；
- 记忆失败：检查召回、写入门槛、时间有效性和冲突处理；
- 工具失败：检查 Schema、权限、超时和幂等；
- 忠实性失败：检查引用约束、上下文窗口和答案生成；
- 端到端失败：检查模块组合、业务目标和验收标准。
上线门禁
- 端到端指标与模块指标分别定义。
- 每个指标都能对应数据集和运行埋点。
- 来源正确性与回答忠实性分开评估。
- 真实 Bad Case 会回流测试集和回归集。
- 评测结果能够路由到明确的修复责任。
- 模型、Prompt、工具、数据和 Judge 均有版本记录。
来源与边界
原文：阿里技术｜AI Agent 应用精细化评测：评测体系设计与工程实践。本文依据奇舞周刊第 597 期摘要整理，未取得原文全文，因此不外推原文未公开的指标公式、实验数字或源码实现。