本文是对 AI Agent 评估与反馈相关知识的学习整理，涵盖评估方法体系、业务指标设计、可观测性建设、反馈回流闭环等核心主题。
一、为什么 Agent 评估这么难？
传统软件的正确性相对容易判断：接口返回 200、数据符合预期、功能按需求文档实现。但 Agent 不一样——系统正常运行，不代表 Agent 正确运行。
HTTP 可以是 200，工具调用可以成功，大模型也可以正常返回，甚至整条 Trace 都没有任何异常，但 Agent 最后就是给了用户一个错误答案。
Agent 评估的本质难点在于：
- 很多输出没有标准答案（比如”帮我写一个适合高级程序员的简历”）
- 用户的”好”在不同业务中定义完全不同
- 一个指标单独看可能骗人（对话轮数增加是好事还是坏事？）
二、基础评估方法
2.1 测试集（Test Set）
最基础的方式：准备一批测试用例，每次修改后重新运行，观察指标变化。
测试用例来源：
| 来源 | 特点 | 适用阶段 |
|---|---|---|
| 手写 | 效率低，但精确 | 早期验证 |
| AI 生成 | 参考已有用例批量生成，可加人工监督 | 规模扩展 |
| 线上回流 | 自动回流 + 手工回流，最有实战价值 | 持续迭代 |
优势：稳定、可重复、适合版本对比。
局限：测试集是自己准备的，难以完全模拟真实用户千奇百怪的输入。
2.2 LLM as Judge
对于没有标准答案的输出，调用一个大模型充当 Judge，根据正确性、完整性、约束满足程度等标准进行评价。
成本优化策略：
- 使用批量接口
- 业务低峰调用
- 使用 mini/flash 等轻量模型
优势：便宜、可大规模自动评估。
适用：离线评估、语义化评估。
2.3 专家评审
找真正懂业务的人来看——法律 Agent 找律师，金融 Agent 找金融从业者。
优势：评价质量最高。
局限：贵、慢。
实践做法：
- 专家撰写和评审业务规则
- 抽样审核
- 用专家结果校准 LLM as Judge
2.4 用户显式反馈
点赞、点踩、五星评分、满意/不满意。
价值：真实用户亲口告诉你的。
问题：反馈率往往很低。很多用户不满意时不会点踩，而是直接关闭页面再也不用。
2.5 用户隐式反馈
| 行为 | 可能含义 |
|---|---|
| 重新生成答案 | 对当前回答不满意 |
| 反复修改问题 | Agent 没理解用户意图 |
| 说”不是这个意思” | 明确的负反馈 |
| 继续使用 Agent | 正向信号 |
| 执行 Agent 建议 | 信任度高 |
| 完成最终任务 | 任务成功 |
数据量巨大，但难点在于解释行为背后的真实含义。例如用户连续聊了十轮，可能说明 Agent 很好聊，也可能说明前九轮一直没解决问题。
通常和 LLM as Judge 结合使用。
2.6 A/B Test
线上同时运行两个版本，比较任务完成率、用户纠正率、转化率、留存率等。
扩展形式：多臂老虎机（同时测试多个版本，选出最好的）。
核心价值：让真实用户替你判断哪个版本更好。
2.7 Pairwise 对比
同时给出 A、B 两个结果，让评审者直接回答”哪个更好”。
比让评审者分别打 83 分和 87 分更容易判断。可以是真人选，也可以是 LLM Judge 选。
三、业务指标设计方法
3.1 核心思路
不要从”我能采集什么数据”出发设计指标，而应该从”用户为什么使用我的 Agent”反推指标。
用户体验指标本质上是通过用户行为揣测用户心理。
3.2 三个关键问题
- 用户为什么来使用你的 Agent？（核心目标）
- 如果用户觉得 Agent 好用，接下来会做什么？（正向行为）
- 如果用户觉得 Agent 很蠢，可能会做什么？（负向行为）
3.3 三组指标体系
| 指标类型 | 含义 | 示例 |
|---|---|---|
| 目标指标 | 反映用户最终目标 | 下单转化率、任务完成率 |
| 过程指标 | 用户正在朝目标前进 | 点击率、加购率 |
| 护栏指标 | 防止优化把系统带偏 | 退货率、用户纠正率 |
一个好的优化：核心目标指标提升，同时护栏指标没有明显恶化。
3.4 不同业务的指标差异
| 业务类型 | 正向指标 | 负向指标 |
|---|---|---|
| 电商 Agent | 点击率、加购率、下单率 | 退货率、退款率 |
| 客服 Agent | 任务解决率、平均解决轮数 | 转人工率、用户纠正率 |
| 社交 Agent | 对话轮数、次日留存 | 用户沉默率 |
| 教育 Agent | 独立完成率、知识点掌握率 | 直接看答案比例 |
关键洞察：同样是”平均对话轮数”，在社交 Agent 中越高越好，在客服 Agent 中越低越好。
3.5 电商 Agent 指标链示例
1 | 推荐商品点击率 → 详情页停留时间 → 收藏率 → 加购率 → 下单转化率 |
每一步都可以计算转化率。但要注意：Agent 可能通过推荐低价爆款来提高转化率，所以需要护栏指标（退货率、退款率）。
四、可观测性建设
4.1 Agent Trace 需要记录的核心信息
| 信息类型 | 说明 |
|---|---|
| 用户输入理解 | Agent 将输入理解成了什么 |
| 意图和槽位 | 识别出的 Intent、Slot、硬约束 |
| Context 变化 | 当前注入了哪些上下文 |
| Plan 状态 | 当前计划、执行到哪一步 |
| 工具调用 | 选择了什么工具、参数是什么、返回了什么 |
| 中间推理 | Agent 如何处理 Observation |
| 异常处理 | 有没有 Retry、Replan、Rollback |
| 最终输出 | 生成了什么答案 |
4.2 Agent 特有指标
| 指标 | 含义 |
|---|---|
| 任务成功率 | 最终成功完成用户任务的比例 |
| 用户纠正率 | 用户出现纠正行为的比例 |
| 约束违反率 | 违反用户硬约束的比例 |
| 意图识别准确率 | 意图识别正确的比例 |
| 工具选择准确率 | 选择的工具是否符合当前目标 |
| 工具调用成功率 | 工具调用成功的比例 |
| 检索空结果率 | 检索没有召回有效结果的比例 |
| 证据覆盖率 | 关键结论有 Evidence 支撑的比例 |
| ReAct 平均循环次数 | 一次任务经历多少轮 Think/Action/Observation |
| Replan 触发率 | 触发 Replan 的任务比例 |
| 端到端耗时 | 从输入到返回结果的整体耗时 |
| 单任务成本 | 完成一次任务的平均成本 |
4.3 根因定位方法
Checkpoint 检查：找到最后一个可信的 Checkpoint 和第一个不可信的 Checkpoint，错误就在两者之间。
二分法：不是严格二等分，而是优先检查：
- 最容易出错的”前科”节点
- 关键节点（Context 变化、中间结果、执行路径切换、工具调用、Replan）
- 直觉告诉你可能出问题的节点
五、反馈回流闭环
5.1 什么数据值得回流
优先关注强负反馈或异常样本：
- 用户点踩
- 用户要求重新生成
- 用户明确说”你理解错了”
- 同一问题反复修改追问
- 多次 Replan
- 工具调用连续失败
- 最终任务失败或中断
- LLM Judge 给出明显低分
- 核心业务指标出现异常
主动寻找异常：根据指标主动寻找 Agent 可能出错的地方，不只是等用户反馈。
5.2 Evaluation Agent
专门启动一个监督 Agent，周期性读取各项指标，自动分析异常。
流程：
- 发现异常（如用户纠正率从 5% 上涨到 10%）
- 抽取相关会话
- 寻找共同特点
- 自动初步归因
- 生成新的 Prompt（但不直接替换线上版本）
- 进入评估流程验证
5.3 自动演进的谨慎使用
两道保险：
- Guardrail Metrics：核心指标提升的同时，其它关键指标不能明显恶化
- 人工审批：高风险变更（System Prompt、工具权限、安全策略、资金操作）必须经过人工审批
核心问题：连”怎么评价一个 Agent 好不好”本身都还没有完全解决，如果评价指标本身就是错的，越自动化，Agent 可能越容易朝着错误方向狂奔。
六、评估方法组合
实践中合理的组合：
| 方法 | 职责 |
|---|---|
| 测试集 | 稳定回归 |
| LLM as Judge | 语义化评估 |
| 专家评审 | 校准 |
| 用户反馈 | 验证线上真实效果 |
| A/B Test | 验证优化是否有真实收益 |
七、面试准备要点
- 针对 Agent 每个环节设计评测机制：意图识别、规划、上下文管理、检索、生成，每个环节都要有评估方案
- 准备核心指标数据：任务成功率、用户纠正率、工具成功率、Replan Rate、平均循环次数
- 说明优化前后的变化：没有数据就很难证明优化真的有效
- 强调闭环：评估不只是看报表，而是形成”评估 → 发现问题 → 优化 → 验证 → 灰度 → 再评估”的闭环
