Agent 评估体系
你将学到什么
- 为什么传统软件测试方法对 Agent 失效
- Agent 评估系统的 4 个核心组件（Task / Trial / Grader / Outcome）
- 如何处理非确定性（pass@k vs. pass^k）
- AI PM 的三层评估体系（模型层 / 产品层 / 业务层）
- 从零开始建立评估体系的路线图
为什么重要：评估是 AI PM 的核心技能。不会评估，就不知道产品好不好；不知道好不好，就无法做优先级决策。
核心观点：Agent 的非确定性和多轮级联错误，让传统的 assert output == expected 测试方法完全失效。需要全新的评估体系。
核心问题：为什么传统测试方法失效？
传统软件测试：输入确定 → 输出确定 → 断言通过 ✅
AI Agent 有两个让传统测试失效的特性：
特性 1：非确定性
同样的输入，今天对明天错。模型版本、上下文、采样参数的微小变化都会影响输出。
你不能用 assert output == expected 来测 Agent。
真实案例
某代码 Agent 的单元测试：
- 周一运行：10 个测试全部通过 ✅
- 周二运行：同样的测试，3 个失败 ❌
- 原因：模型输出的代码格式略有不同（多了空行），但功能完全正确
教训：不能用精确匹配来测试 Agent，要测"功能是否正确"而非"输出是否一致"。
特性 2：多轮级联错误
第1轮: 读取订单 ✅
第2轮: 计算退款（算错了 1 分钱）✅
第3轮: 更新数据库 ✅
...
第10轮: 生成财务报表 ❌ 对不上账第 2 轮的小错误，在第 10 轮引发大问题。早期错误会沿着多轮交互不断放大。
传统测试的问题：只测最终结果，无法定位是哪一轮出错。
评估系统的四个核心组件
1. Task（任务）：不是 Prompt，是"考题"
真正的 Task 需要有：
- 明确的初始状态：给什么数据
- 明确的成功标准：完成是什么样的
- 预期结果：可以用来打分
| 对比 | 简单 Prompt | 标准 Task |
|---|---|---|
| 描述 | "帮我订机票" | 初始状态：用户信息 + 航班数据库 成功标准：数据库有订单记录 + 用户收到确认邮件 预期结果：指定航班 + 座位号 + 价格 |
| 可评估性 | ❌ 无法自动判断成功 | ✅ 可以自动验证数据库和邮件 |
| 可复现性 | ❌ 每次环境不同 | ✅ 初始状态固定，可重复运行 |
2. Trial（试验）：跑一次不算，要跑多次
因为非确定性，单次测试可能是运气好/运气差。
| 用途 | 建议次数 | 原因 |
|---|---|---|
| 快速验证 | 3 次 | 快速发现明显问题 |
| 正式评估 | 10 次 | 得到统计意义上的成功率 |
| 关键功能上线前 | 100 次 | 发现低概率 Bug |
PM 建议：在产品设计时，就要考虑"这个功能需要多高的成功率"。
3. Grader（评分器）：需要多个维度打分
| 类型 | 方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 代码评分 | 精确判断（断言、正则） | 格式验证、数值计算 | 快速、准确 | 无法处理语义 |
| 模型评分 | 用更强的 LLM 判断 | 语义质量、逻辑合理性 | 灵活、接近人类判断 | 有成本、可能不稳定 |
| 人工评分 | 专家标注 | 最终基准，用于校准模型评分 | 最准确 | 慢、贵 |
瑞士奶酪模型
三种评分器组合使用，形成"瑞士奶酪"式防御——每层有漏洞，但组合起来几乎无懈可击。
- 代码评分：快速过滤明显错误（格式、必填字段）
- 模型评分：判断语义质量（是否回答了问题、逻辑是否合理）
- 人工评分：抽样验证（每周抽 10% 人工复核）
4. Transcript vs. Outcome：说的 vs. 做的
| Transcript（日志） | Outcome（结果） | |
|---|---|---|
| 是什么 | Agent 的执行过程 | 环境的真实变化 |
| 可信吗 | ❌ Agent 可能报告错误状态 | ✅ 数据库不会说谎 |
| 用来干嘛 | Debug、分析行为 | 验证任务是否完成 |
重要
一定要同时看 Outcome（实际结果），而不只看 Transcript（Agent 说它做了什么）。
真实案例：某 Agent 报告"已成功创建订单"，但数据库里没有记录。原因：Agent 调用 API 失败，但误判为成功。
互动练习：设计评估方案
场景：你的 Agent 负责"根据用户需求生成 SQL 查询"。
如何设计评估方案？需要哪些组件？
查看答案
Task 设计：
- 初始状态：数据库 Schema + 用户需求（"查询上个月销售额前 10 的商品"）
- 成功标准：生成的 SQL 能正确执行 + 返回正确结果
- 预期结果：具体的 SQL 语句 + 查询结果
Trial 设计：
- 每个 Task 运行 10 次（因为 SQL 生成有多种正确写法）
Grader 设计：
- 代码评分：SQL 语法是否正确（用 SQL parser 验证）
- 代码评分：执行 SQL，检查是否报错
- 代码评分：对比查询结果和预期结果（精确匹配）
- 模型评分：判断 SQL 的可读性和性能（是否用了索引、是否有冗余 JOIN）
Outcome 验证：
- 不只看 Agent 生成的 SQL，要实际执行并验证结果
- 检查数据库状态（确保没有意外的写操作）
处理非确定性：pass@k vs. pass^k
面对随机性，需要选择合适的评估模式：
| 指标 | 含义 | 计算方式 | 适用场景 | 示例 |
|---|---|---|---|---|
| pass@k | k 次中至少 1 次成功 | 10 次中成功 3 次 = 30% | 有人工验证，偶尔成功可接受 | 代码生成（人会选最好的） |
| pass^k | k 次全部成功 | 10 次全部成功 = 100% 1 次失败 = 0% | 全自动流程，必须稳定 | 自动化运维 Agent |
PM 决策：你的产品是"有人监督的工作流"还是"全自动执行"？这决定了用哪个指标。
面试加分点
能说出 pass@k 来自 OpenAI 的 Codex 论文，用于评估代码生成模型。这个指标后来被广泛应用于 Agent 评估。
四类 Agent 的评估重点
| Agent 类型 | 核心评估重点 | 关键指标 |
|---|---|---|
| 代码 Agent | 代码能否正确运行；有无安全漏洞；测试通过率 | 编译通过率、测试覆盖率、安全扫描结果 |
| 文档处理 Agent | 信息提取准确率；关键内容是否遗漏；格式是否正确 | 准确率、召回率、F1 Score |
| 工作流 Agent | 任务完成率；步骤正确性；错误恢复能力 | 任务完成率、平均步骤数、错误恢复成功率 |
| 对话 Agent | 回答相关性；一致性（前后不矛盾）；拒绝不当请求 | 相关性评分、一致性评分、安全拒绝率 |
AI PM 的三层评估体系
结合产品视角，Agent 评估应该覆盖三层：
第一层：模型层（离线评估）
在上线前，用测试集评估 Agent 的基础能力。
| 指标 | 含义 | 目标值 |
|---|---|---|
| 任务完成率 | 核心功能的成功率 | ≥ 90% |
| 准确率 | 结果是否正确 | ≥ 95% |
| 延迟 | 响应时间（TTFT + 完整生成时间） | ≤ 3 秒 |
| Bad Case 集合 | 持续回归测试 | 0 个已知 Bug 复现 |
第二层：产品层（在线监控）
上线后，监控用户的真实行为。
| 指标 | 含义 | 如何收集 |
|---|---|---|
| 用户接受率 | 用户是否采纳了 Agent 的建议/操作 | 埋点：用户点击"采纳"/"拒绝" |
| 追问率 | 用户是否因为结果不满意而重新提问 | 埋点：同一会话中重复提问 |
| 手动纠错率 | 用户多频繁修改 Agent 的输出 | 埋点：用户编辑 Agent 生成的内容 |
| 任务完成率 | 用户启动的任务最终有多少真正完成 | 埋点：任务状态（启动/完成/放弃） |
常见误区
不要只看模型层指标。很多产品"模型评估 95 分，用户满意度 60 分"，原因是模型层指标和用户真实需求不一致。
第三层：业务层（结果验证）
最终，要看 Agent 是否真正带来业务价值。
| 指标 | 含义 | 如何衡量 |
|---|---|---|
| 效率提升 | 使用 Agent 后的任务耗时变化 | 对比使用前后的平均耗时 |
| 错误率变化 | 和人工操作相比，Agent 的错误率 | 对比 Agent 和人工的错误率 |
| 用户满意度 | NPS / CSAT | 定期问卷调查 |
从零开始的评估路线图
第一步：20 个测试用例（先有再好）
↓
第二步：明确每个用例的成功标准
↓
第三步：用代码评分实现自动化
↓
第四步：加入模型评分覆盖模糊场景
↓
第五步：建立 Bad Case 收集闭环
↓
第六步：每次版本迭代前跑完整测试套件
↓
持续：新 Bad Case → 加入测试集 → 修复 → 回归关键原则：宁愿有 20 个粗糙的测试用例，也不要等待"完美的评估框架"。先动起来，逐步迭代。
快速启动建议
第一周：
- 选 1-2 个核心功能
- 每个功能写 10 个测试用例
- 用代码评分实现自动化（成本极低）
第二周：
- 收集真实用户的 Bad Case
- 加入测试集
- 修复并回归测试
第三周：
- 加入模型评分（覆盖语义质量）
- 建立每日自动化测试流程
检查点
在继续之前，确保你能回答：
- [ ] 能说出 Agent 评估的 4 个核心组件（Task / Trial / Grader / Outcome）
- [ ] 能解释 pass@k 和 pass^k 的区别和适用场景
- [ ] 能设计一个简单的 Agent 评估方案（包含 Task、Grader、成功标准）
- [ ] 能说出 AI PM 的三层评估体系（模型层 / 产品层 / 业务层）
- [ ] 能回答"为什么不能只看模型层指标"
面试应用
高频问题："如何评估一个 Agent 系统的质量？"
回答框架：
- 说明传统测试失效的原因：非确定性 + 多轮级联错误
- 介绍评估系统的 4 个核心组件：Task / Trial / Grader / Outcome
- 说明三层评估体系：模型层（离线）/ 产品层（在线）/ 业务层（结果）
- 给出具体方案：结合产品场景，说明如何设计 Task 和 Grader
- 提供数据支撑：引用 pass@k / pass^k 等指标
加分点：能说出"Transcript vs. Outcome"的区别，或提到"瑞士奶酪模型"。
PM 常见问题
Q：评估是工程师的事，PM 需要懂这些吗？
A：AI PM 需要能够提出评估方案、解读评估结果、基于数据做优先级决策。不需要自己写代码，但必须能和工程师对齐"什么是成功"。
Q：指标看起来很好，但用户投诉怎么办？
A：说明产品层指标（用户行为）和模型层指标（自动评估）不一致。需要回到产品层，重新设计更贴近用户真实体验的评估指标。
Q：预算有限，评估从哪里开始？
A：从最核心的 1-2 个功能开始，各建 10 个测试用例，用代码评分实现自动化。成本极低，但能快速发现大多数问题。