衡量 AI Agent 不能只看回答质量，也不能把“工具调用成功”当成任务成功。Agent 可能正确调用了接口，却修改了错误对象；也可能绕了很多步骤才给出可用结果。指标体系必须同时回答四个问题：
- 用户的任务是否真的完成；
- Agent 的过程是否正确、必要且可控；
- 失败时能否安全恢复或转人工；
- 每个成功任务的时间和成本是否可持续。
本文聚焦能调用工具、改变外部状态或执行多步工作流的 Agent。若你要评估普通 AI 功能的文本质量和离线数据集，先看AI 产品功能评测框架。
一、先定义“一个任务”
指标失真的常见原因，是分母没有统一。一次会话可能包含三个请求，一个请求也可能跨多个会话完成。先建立任务对象：
| 字段 | 定义问题 |
|---|---|
| task_id | 从用户目标产生到完成、取消或超时的稳定标识 |
| task_type | 查询、创建、修改、审批还是跨系统流程 |
| success_criteria | 什么证据证明任务完成，而非 Agent 自称完成 |
| risk_tier | 失败是否可逆，是否涉及资金、隐私或外部通信 |
| terminal_state | 成功、部分成功、转人工、取消、失败或超时 |
| evidence | 数据库状态、API 返回、用户确认或人工复核 |
例如“帮我改下周一的客户会议”不是看到一段确认文案就算成功。应检查目标日历事件是否被正确更新、时区是否正确、参与者是否符合用户意图，以及外部通知是否经过必要确认。
二、北极星指标：经验证的任务成功率
一个可用的主指标是：
经验证任务成功率 = 有外部证据且满足全部关键条件的成功任务数 ÷ 可评估任务数
“可评估任务”要排除系统明确不支持、用户主动取消和缺少必要信息的请求，并分别记录这些比例，避免通过扩大排除范围美化成功率。
任务成功最好按三层记录：
- 严格成功：所有关键要求满足，没有高风险错误；
- 部分成功：交付物可用，但需要用户补充或轻度修正；
- 失败：关键目标未完成、状态不一致或需要重做。
不要把三层简单混为一个平均分。高风险任务通常只允许严格成功进入自动化覆盖。
Google Cloud 的官方 Agent 评测资料将最终回答质量、工具使用质量和幻觉分别评估，并用完整交互轨迹检查 Agent 是否达成目标。Vertex AI Agent evaluation 提供了这个“结果 + 过程”的思路。微软的官方 Agent 评测说明也区分端到端任务完成与工具选择、输入参数、输出利用等过程指标：Agent evaluators。
三、五层指标树
1. 结果层
| 指标 | 建议口径 | 用途 |
|---|---|---|
| 严格任务成功率 | 严格成功任务 / 可评估任务 | 判断真实可用性 |
| 部分成功率 | 需轻度修正但可用 / 可评估任务 | 定位产品摩擦 |
| 用户确认率 | 用户确认完成 / 到达确认步骤任务 | 验证用户认知 |
| 后续撤销率 | 成功后一定窗口内被撤销 / 成功任务 | 发现假成功 |
| 重试后成功率 | 首次失败、重试后成功 / 首次失败 | 评估恢复价值 |
用户确认不能独立作为真值：默认选中、误触或用户没有发现错误都可能抬高确认率。
2. 过程与工具层
- 工具选择正确率：应调用的工具被正确选择，且没有不必要的高风险工具；
- 参数正确率：对象 ID、时间、金额、权限范围和幂等键满足约束；
- 工具执行成功率：调用没有超时、异常或被依赖系统拒绝；
- 工具结果利用率：最终决策与工具返回一致，没有忽略失败状态；
- 必要步骤覆盖率：确认、审批、校验和落库步骤没有被跳过；
- 冗余调用率：不改变结果的重复或无关调用占全部调用的比例。
一次工具 HTTP 200 只说明请求被接受，不等于业务状态正确。对有副作用的动作，应使用回读、账务记录或最终状态检查。
3. 人工与恢复层
| 指标 | 分子 / 分母 | 解释 |
|---|---|---|
| 人工接管率 | 转人工任务 / 全部任务 | 需按“合理接管”和“能力失败”拆开 |
| 用户修正率 | 有实质编辑任务 / Agent 给出结果任务 | 反映输出可用性 |
| 平均修正时长 | 人工修正总时长 / 被修正任务 | 比修正次数更接近成本 |
| 自动恢复率 | 无人工介入恢复成功 / 可恢复失败 | 衡量重试与回退 |
| 重复执行率 | 同一副作用被执行多次 / 有副作用任务 | 幂等性护栏 |
低接管率不一定更好。对于高风险或低置信任务，及时升级人工是正确行为。目标应是“适当接管”，而不是把人从流程中清零。
4. 系统、延迟与成本层
- 端到端 P50、P95 和 P99 任务时长；
- 首次有用反馈时间，而非只看最终完成时间；
- 每个任务的模型、检索、工具和基础设施成本；
- 每个严格成功任务成本 = 总运行成本 ÷ 严格成功任务数；
- 超时率、队列等待、依赖失败和降级比例；
- 每个任务的步骤数、模型调用数和上下文增长。
只看每次模型调用成本会奖励失败得快的系统。把成本与严格成功任务绑定，才能比较不同方案。
5. 安全与权限护栏
Agent 能改变外部状态时，至少监控：
- 未授权工具调用和权限拒绝；
- 敏感数据暴露、越租户访问和不当日志记录；
- 缺少用户确认的高影响动作；
- 超出金额、数量、收件人或时间窗口的操作；
- 提示注入或外部内容诱导后的策略违规；
- 回滚失败、审计记录缺失和责任主体不明。
高风险事件不应被平均成功率抵消。为每类事件定义零容忍或明确上限，并建立立即停止自动化的规则。
四、按任务类型和风险切片
总体成功率会隐藏重要问题。至少按以下维度拆分：
- 只读查询 vs 有副作用动作；
- 单工具 vs 多工具工作流；
- 常见任务 vs 长尾任务；
- 新用户 vs 熟练用户；
- 语言、地区和设备；
- 低、中、高风险；
- 首次运行 vs 重试；
- Agent、提示词、工具和知识库版本。
每个切片同时显示样本数。样本太小时不下确定结论，也不因短期百分比波动自动放量。
五、事件与轨迹数据设计
一条可复盘的 Agent 轨迹至少包含：
task_started intent_resolved plan_created tool_call_requested tool_call_authorized tool_call_completed confirmation_requested user_confirmed task_completed task_verified
关键字段包括：
- task_id、session_id、user_id 的脱敏标识；
- Agent、模型、提示词、工具定义和策略版本；
- 工具名称、参数摘要、授权结果、耗时和错误码；
- 是否产生副作用、幂等键与回滚状态；
- 最终任务状态、证据来源和失败标签；
- 隐私保留期限与访问控制。
不要默认记录完整用户输入、密钥或工具返回。监控可观察性必须服从数据最小化和权限要求。
六、上线看板结构
第一屏：业务与用户结果
- 任务量、严格成功率、部分成功率；
- 人工接管、用户修正、撤销；
- 按任务类型和风险切片的趋势。
第二屏：过程诊断
- 工具选择、参数、执行和结果利用；
- 最常见失败步骤与错误码；
- 冗余步骤、循环和轨迹长度分布。
第三屏：效率与风险
- P50/P95 时长、每个成功任务成本；
- 未授权动作、重复副作用、隐私和确认护栏；
- 当前版本与基线版本的差异。
看板上的每个告警都应对应负责人和动作。数据异常的通用排查方法见运营数据异常诊断指南。
七、一个明确标注的假设案例
以下是教学示例，不是真实产品表现。
场景：一个 Agent 帮销售人员更新 CRM 跟进记录并创建下次提醒。
任务成功条件：
- 更新的是用户指定客户；
- 摘要忠实于输入；
- 提醒日期和时区正确；
- 写入前获得用户确认；
- CRM 回读显示两个对象都处于预期状态。
不应只看：CRM API 200、Agent 输出“已完成”、用户打开结果页。
指标组合：
- 严格任务成功率；
- 错误客户对象率和重复写入率作为阻断护栏；
- 用户修正摘要的比例与平均修正时长；
- P95 完成时间和每个严格成功任务成本；
- 合理接管率：客户名称歧义时转人工或向用户追问。
若新版本总体成功率上升，但错误客户对象从 0 增至 1 次，也不能仅凭平均值上线。
八、从离线评测到生产监控
- 从真实任务定义和历史失败建立固定回归集；
- 离线检查最终结果、工具轨迹和安全策略；
- 与规则流程或旧版本做配对比较；
- 小流量灰度，并限制任务类型与权限；
- 观察结果、过程、人工、成本和护栏；
- 把经脱敏审核的线上失败加入回归集；
- 每次模型、提示词、工具或授权策略变化都重新评测。
离线通过不是永久认证。Agent 所依赖的模型、工具和业务数据都会变化。
九、可复制的指标定义模板
指标名称： 用户任务： 分子： 分母： 排除项： 成功证据： 观察窗口： 风险切片： 数据事件与来源： 指标负责人： 数据负责人： 刷新频率： 告警条件： 触发动作： 已知限制： 版本与变更日期：
准备求职案例时，可把这套指标放入AI 产品经理作品集指南，并用AI 产品经理岗位指南核对能力覆盖，或浏览AI 产品经理专题。