很多团队做 AI Agent 时，最先投入的是模型、Prompt、工具调用，最后才想起评估。
这会带来一个很危险的后果：
- 改了一版 Prompt，成功案例变多了，但没人知道是不是牺牲了稳定性。
- 检索召回看起来更全了，但引用证据比例反而下降。
- 工具调用次数减少了，却可能是因为模型开始跳过关键步骤。
所以评估不是发布后的附属工作，而是 Agent 工程化的中轴。
如果你还没读过基础篇，建议先看 AI Agent 必考知识点拆解、Function Calling 工程实战、AI Agent 并发与可靠性 和 AI Agent 项目含金量指南。
一、为什么很多 Agent 团队越迭代越不稳
根因通常不是“模型不够强”，而是没有把评估拆成层。
一个最常见误区是只看最终回答对不对，但 Agent 的失败经常发生在中间层：
- 规划顺序错了
- 工具调用没按 schema 执行
- 检索证据拿到了，但注入上下文时被截断
- 输出看似合理，实际违反业务硬约束
如果你只看最终结果，就会把完全不同的故障混成一类。
二、推荐的四层评估框架
| 评估层 | 核心问题 | 典型指标 | 常见故障 |
|---|---|---|---|
| 任务层 | 任务到底有没有完成 | success_rate、完成时长、降级率 | 用户目标未达成 |
| 证据层 | 输出有没有证据支撑 | citation_rate、证据缺失率 | 幻觉、引用错位 |
| 执行层 | 规划和工具调用是否可靠 | tool_success_rate、schema_fail_rate、重规划率 | 调错工具、循环调用 |
| 风险层 | 系统是否突破边界 | 越权拦截率、误杀率、预算超限率 | 超预算、越权、脏写 |
真正可用的评估框架，必须四层一起看。只盯着 success_rate，很容易掩盖隐患。
三、一个典型失败案例：成功率涨了，但系统其实更差了
某个企业知识库 Agent 改了一版 Prompt 后，离线 20 条样本的成功率从 71% 提升到了 83%。团队差点直接上线。
但继续往下看，发现：
citation_rate从 88% 掉到 61%- 平均工具调用次数从 2.1 次升到 3.8 次
p95_latency_ms翻了一倍
根因不是模型突然退化，而是新 Prompt 过度追求“多尝试几步”，让模型在证据不足时也倾向于继续生成，导致调用更多工具、输出更慢、引用更虚。
修复方式不是简单回滚，而是拆开定位：
- 保留更高的任务成功路径
- 增加“证据不足则显式拒答”规则
- 给工具调用加预算上限
- 在离线评估里加“证据完整性”断言
这个案例说明：没有分层评估，你看到的“提升”很可能只是另一个维度的退化。
四、离线 Eval 应该怎么搭
一个最小可用的离线 Eval 集，不需要 1000 条样本。先从 30 到 50 条高价值样本开始就够了。
优先覆盖四类样本：
- 正常路径：信息完整、工具稳定、约束明确
- 边界路径：信息缺失、条件冲突、预算紧张
- 故障路径：工具超时、空结果、schema 失败
- 风险路径：越权请求、注入输入、超预算调用
推荐你为每条样本记录：输入、上下文、预期目标、允许的降级路径、关键断言。
五、线上 Guardrail 不只是“敏感词过滤”\n+
线上评估的重点不是复刻离线集，而是及时发现系统偏移。
最小线上 Guardrail 可以先做这 5 个：
- 输出 schema 校验失败直接阻断
- 写操作必须经过 policy 校验
- 工具调用次数超过预算立即降级
- 无证据回答时打上高风险标记
- 关键 run 全量保留 trace 以支持回放
这样做的目的不是让系统“零失败”，而是让失败变得可控、可追溯。
六、发布前必须看的指标面板
至少盯住下面 6 个指标：
| 指标 | 说明 | 建议用途 |
|---|---|---|
success_rate | 任务完成率 | 看总体结果 |
citation_rate | 输出中有证据支撑的比例 | 防止幻觉上升 |
schema_fail_rate | 输出协议失败比例 | 防止工具层失控 |
avg_tool_calls | 平均工具调用次数 | 看执行成本 |
p95_latency_ms | P95 端到端时延 | 看体验是否塌陷 |
budget_exceed_rate | 超预算比例 | 看资源治理是否有效 |
不要只看某一天的绝对值，更要看版本变更前后的趋势。
七、AI Agent 评估框架发布清单
- 至少准备 30 条带断言的离线样本
- 指标按任务层、证据层、执行层、风险层拆开
- 关键失败样本支持回放
- 高风险写操作接入线上 Guardrail
- 每次版本变更都保留前后对比结果
