hello 我是逆境
传统后端通常使用 QPS、P95/P99 延迟、错误率和可用性判断服务是否健康。AI Agent 引入了模型推理、知识检索、工具调用和多步规划，仅靠接口指标无法判断任务是否真正完成。
本文整理一套可以落地的 Agent 后端指标体系，覆盖系统性能、Agent 执行、RAG 检索、工具调用、回答质量、成本和安全。
1. 为什么 HTTP 200 不等于 Agent 任务成功
假设用户要求：“查询订单状态，并把结果发送到邮箱。”Agent 成功调用订单接口，也返回了一段文本，但没有执行邮件发送。
这次请求可能同时满足：
- HTTP 状态码为 200；
- LLM 调用成功；
- 订单查询工具执行成功；
- 用户任务失败。
因此需要区分三种口径：
| 系统成功 | 接口是否正常响应，服务是否报错 |
| 调用成功 | 模型、检索和工具是否正常返回 |
| 任务成功 | 用户目标是否完整实现 |
Agent 可观测性需要覆盖完整执行轨迹，而不是只记录入口 API。
2. 流量、性能与稳定性指标
2.1 流量指标
| QPS | 每秒接收或处理的请求数 |
| 峰值 QPS | 流量高峰时的最大吞吐量 |
| 并发数 | 同时执行中的 Agent 任务数量 |
| 队列长度 | 等待执行的任务数量 |
| 限流率 | 被限流请求数 ÷ 总请求数 |
TPS 在 Agent 系统中容易产生歧义，可能表示每秒事务数，也可能表示每秒生成 Token 数。使用时必须明确口径。
2.2 延迟指标
至少记录 P50、P95 和 P99：
- P50 反映多数请求的正常体验；
- P95 用于发现慢请求；
- P99 更容易暴露模型抖动、队列堆积和第三方依赖超时；
- TTFT 表示从请求发出到返回首个 Token 的时间；
- Token/s 表示模型每秒生成的 Token 数。
端到端延迟可以拆成：
Agent 总耗时 = 排队耗时
+ 模型推理耗时
+ 知识检索耗时
+ 工具调用耗时
+ Agent 编排耗时
总耗时适合观察用户体验，阶段耗时用于定位瓶颈。
2.3 稳定性指标
常用指标包括请求成功率、错误率、超时率、重试率、熔断次数、降级率、服务可用性、MTTR 和 MTBF。
错误建议按以下类型拆分：
model_error
retrieval_error
tool_error
parameter_error
timeout_error
permission_error
rate_limit_error
system_error
3. Agent 执行效果指标
3.1 任务成功率
任务成功率 = 成功完成用户目标的任务数 ÷ 总任务数
任务成功必须根据业务结果判定。例如：
- 客服 Agent：工单是否真正解决；
- 代码 Agent：代码是否通过编译和测试；
- 数据 Agent：SQL 是否执行成功，结果是否满足约束；
- 邮件 Agent：邮件是否实际发送到正确收件人。
3.2 首次成功率
首次成功率 = 无重试、无人工介入的成功任务数 ÷ 总任务数
两个 Agent 的任务成功率可能相同，但模型调用次数和重试次数差异很大。首次成功率能同时反映执行质量、延迟和成本。
3.3 过程指标
| 平均执行步数 | 完成一个任务经历的推理和工具步骤数 |
| 平均模型调用次数 | 单任务调用 LLM 的次数 |
| 循环率 | 重复思考或重复调用相同工具的任务占比 |
| 最大步数触发率 | 因超过执行上限而终止的任务占比 |
| 人工接管率 | 需要人工继续处理的任务占比 |
| 澄清率 | Agent 需要向用户补充提问的任务占比 |
| 状态恢复成功率 | 中断后从检查点继续执行的成功比例 |
执行步数不能孤立判断。步数增加并不一定是坏事，但如果步数上涨而任务成功率没有提高，通常意味着规划、状态管理或停止条件存在问题。
4. RAG 检索指标
4.1 Recall@K 与 Precision@K
Recall@K = 前 K 条中召回的相关文档数 ÷ 全部相关文档数
Precision@K = 前 K 条中的相关文档数 ÷ K
提高 K 值通常有利于召回率，但可能降低精确率、增加上下文噪声和 Token 成本。
4.2 Hit Rate、MRR 与 nDCG
| Hit Rate@K | 前 K 条中是否至少命中一条相关文档 |
| MRR | 第一条相关结果的排名是否足够靠前 |
| nDCG@K | 同时衡量相关程度和排序位置 |
| 空结果率 | 没有返回任何检索结果的查询占比 |
项目初期可以优先建设 Hit Rate@K，因为它的标注成本低于完整 Recall@K。
4.3 回答阶段指标
文档召回正确，不代表最终回答正确。完整评估链路应该检查：
查询问题
-> 是否召回正确文档
-> 正确文档是否进入上下文
-> 模型是否使用相关内容
-> 最终回答是否正确
-> 引用是否支持对应结论
建议同时监控：
- 引用正确率；
- Groundedness；
- 上下文相关率；
- 幻觉率；
- 无依据陈述比例。
Recall@K、Precision@K 等离线指标需要人工标注的标准数据集。没有 Ground Truth，就无法计算可信的召回率。
5. 工具调用指标
工具调用建议拆成三层：
常用指标如下：
| 工具选择准确率 | Agent 是否选择了正确工具 |
| 工具调用成功率 | 工具正常执行并返回结果的比例 |
| 参数正确率 | 调用参数满足业务约束的比例 |
| 工具调用延迟 | 单次工具调用耗时 |
| 无效调用率 | 不必要或无法推动任务的调用占比 |
| 重复调用率 | 使用相同参数重复调用同一工具的比例 |
| 工具结果采用率 | 工具返回结果被后续步骤使用的比例 |
重复调用率异常升高时，应检查 Agent 状态是否更新、模型是否理解工具返回值，以及停止条件是否可靠。
6. 回答质量指标
| Correctness | 回答是否正确 |
| Completeness | 是否覆盖任务要求 |
| Relevance | 回答是否与问题相关 |
| Instruction Following | 是否遵守用户指令和格式约束 |
| Faithfulness | 回答是否忠实于给定上下文 |
| Hallucination Rate | 无依据或错误内容的比例 |
| 格式正确率 | JSON、SQL 等结构化结果能否解析 |
| 代码通过率 | 生成代码能否编译、运行或通过测试 |
| 用户重问率 | 用户因回答无效而重新表达需求的比例 |
能确定性验证的结果，应优先使用程序验证。例如 JSON Schema、SQL 执行结果和自动化测试。开放式回答可以组合使用规则检查、LLM 评审和人工抽检。
7. Token 与成本指标
需要记录 Prompt Token、Completion Token、总 Token、单任务模型调用次数、上下文利用率、缓存命中率和高成本请求比例。
相比单请求成本，更推荐使用单成功任务成本：
单成功任务成本 =
（模型成本 + 检索成本 + 工具成本 + 基础设施成本）
÷ 成功完成的任务数
更换小模型后，如果任务成功率下降、重试率上升，单成功任务成本可能不降反升。因此成本指标需要和任务成功率、首次成功率一起观察。
8. 安全与合规指标
| Prompt Injection 检测率 | 检测到提示词注入的请求占比 |
| 注入防御成功率 | 成功阻止注入攻击的比例 |
| 敏感信息泄露率 | 输出中出现凭证、隐私等信息的比例 |
| 越权调用率 | Agent 尝试执行无权限操作的比例 |
| 高风险操作拦截率 | 删除、转账、发布等操作被正确拦截的比例 |
| 人工审批触发率 | 高风险动作进入人工确认的比例 |
| 审计完整率 | 模型和工具调用是否留下完整记录 |
高风险操作的权限校验应该放在工具层，不能只依赖模型判断。
9. 建议优先建设的核心指标
如果项目刚开始建设 Agent 可观测性，可以先落地以下指标：
建议使用 agent_name、agent_version、model、tool_name、scenario、tenant 和 error_type 等维度进行切分。
不要把完整 Prompt、用户 ID、会话 ID 等高基数字段直接作为 Prometheus 标签。详细上下文应进入经过脱敏的日志或 Trace 系统。
10. 总结
Agent 指标可以分成四层：
系统层：QPS、延迟、错误率、可用性
执行层：任务成功率、步骤数、循环率、工具正确率
质量层：召回率、引用正确率、Groundedness、幻觉率
经营层：单成功任务成本、人工接管率、业务转化率
单个指标只能描述局部现象。任务成功率下降时，需要继续关联检索命中率、工具错误率和执行步数；成本上涨时，则要检查 Token、模型调用次数、重试次数和工具成本。
只有把请求、模型、检索、工具和业务结果串成一条 Trace，监控系统才能从“看到异常”走向“解释异常”。
