AI Agent 工程实践（33）：Agent 如何监控
摘要：本文针对 AI Agent 上线后“服务活着却在胡说”的监控盲区，梳理了只看存活、只看成本、不盯幻觉三种常见错误，提出 Agent 监控应在传统指标之外额外关注成功率、Tool Error、Latency、Cost、Token、Memory Hit、Hallucination 七个 LLM 专属维度，并给出七指标看板、Mermaid 架构图、Prometheus 打点与离线 eval 示例，最后按“可用性必告警、质量类观察为主”的分级原则避免告警疲劳。
系列：AI Agent 工程实践
上一篇：第 32 篇《Agent 如何上线》
下一篇：第 34 篇《企业 AI Agent 架构》
一、开场：agent 变傻了，没人知道
运营说"最近 agent 答得不对"。工程师去查，发现三天前某个模型版本更新后，特定问题开始胡说。但因为没有监控，谁也说不清：是哪天开始的？哪个场景？哪个模型？影响多少用户？只能靠用户投诉反推。
上篇（32）讲"安全上线"，这篇讲"上线后怎么知道它好不好"——监控。
二、问题背景：传统监控不够
只看服务存活：
# 健康检查只返回 200 @app.get("/health") def health(): return {"status": "ok"} # 服务活着 ≠ agent 答得好Agent 挂了（HTTP 500）你会知道，但它活着却在胡说，传统监控毫无感知。Agent 监控 = 传统指标+ LLM 专属指标。
三、错误尝试：三种监控盲区
错误 1：只看 CPU/内存/存活
服务没崩就以为没事，质量劣化完全盲区。等到发现，已经是大量错误回答被用户看见了。
错误 2：只看成本
成本没超就安心，但成本和质量是两个轴——可能又贵又烂，省钱但答非所问。
错误 3：不盯幻觉
"LLM 偶尔胡说正常"，不量化幻觉率，等到客诉才暴露，信誉损失已发生。
四、关键观察：Agent 要盯七个指标
传统服务的指标（QPS、错误率、延迟）只是底座。Agent 额外要盯7 个 LLM 维度：
- 成功率：请求完整跑完、未异常中断的比例。
- Tool Error：工具调用失败率——Agent 最常见的硬错误。
- Latency：端到端延迟（P50/P95）——用户体感。
- Cost：单请求成本 + 日/月总成本趋势。
- Token：输入/输出 token 消耗，成本与上下文膨胀的前兆。
- Memory Hit：记忆命中率——命中低说明"记不住用户"，体验差。
- Hallucination：幻觉率——靠 eval 集 + 用户反馈打分量化。
前 5 个可直接打点，后 2 个要靠"埋点 + 评估 + 反馈"间接度量。缺任何一个，你对系统的认知就有盲区。
五、最终方案：七指标看板
| 指标 | 定义 | 为什么必须看 | 异常信号 |
|---|---|---|---|
| 成功率 | 未异常中断的请求占比 | 系统基本可用性 | 突降 |
| Tool Error | 工具调用失败次数/总调用 | Agent 主要硬错误源 | 持续 >2% |
| Latency | P50/P95 端到端耗时 | 用户体感 | P95 翻倍 |
| Cost | 单请求 + 周期总成本 | 烧钱速度 | 日均超预算 |
| Token | 输入输出 token 量 | 上下文膨胀/成本前兆 | 陡增 |
| Memory Hit | 命中长期记忆比例 | "是否记住用户" | 持续偏低 |
| Hallucination | 幻觉回答占比 | 质量底线 | 上升 |
监控数据流向：Agent 运行时打点 → 日志/链路收集 → 指标聚合 → 看板 + 告警。
六、架构图（Mermaid）![]()
七、代码与配置示例
用计数器打点（伪 Prometheus）：
from prometheus_client import Counter, Histogram REQ = Counter("agent_requests_total", "总请求") TOOL_ERR = Counter("agent_tool_errors_total", "工具失败") LAT = Histogram("agent_latency_seconds", "端到端延迟") @LAT.time() def handle(req): REQ.inc() try: return run_agent(req) except ToolError: TOOL_ERR.inc() # 工具失败单独计数 raise幻觉率靠离线 eval：
# 每日跑 eval 集，统计答非所问比例 bad = sum(1 for c in eval_set if not is_correct(c)) hallucination_rate = bad / len(eval_set) # 趋势监控八、设计权衡：告警 vs 观察
| 指标 | 建议 | 理由 |
|---|---|---|
| 成功率/Tool Error | 必告警 | 直接影响可用 |
| Latency P95 | 告警 | 体感硬指标 |
| Cost/Token | 观察+预算线 | 趋势性，不必秒级 |
| Memory Hit | 观察 | 体验指标 |
| Hallucination | 周级观察 | 需 eval，滞后 |
反过度告警：什么都告警 = 告警疲劳，真正异常被淹没。分级——可用性必告警，质量类观察为主。把告警留给"不处理就出事"的指标。
九、总结
- ✅ 服务活着 ≠ agent 答得好，传统监控对质量劣化盲区。
- ✅ 三种盲区：只看存活、只看成本、不盯幻觉。
- ✅ Agent 监控 = 传统指标 + 7 个 LLM 维度（成功率/Tool Error/Latency/Cost/Token/Memory Hit/Hallucination）。
- ✅ 前 5 直接打点，后 2 靠 eval + 用户反馈间接度量。
- ✅ 分级：可用性必告警，质量类观察为主，防告警疲劳。
下一篇，把前面所有零件画成一张企业全链路图。（34）
参考资料（带用途说明）
- 本系列（32）Agent 如何上线：本文监控指标是（32）灰度/全量判断的依据。
- 本系列（27）日志系统：监控的打点数据来自（27）的日志字段设计。
- 本系列（28）可观测性：Trace/Span 是本文链路追踪的理论基础。
- 本系列（30）Agent 如何做测试：幻觉率评估复用（30）的 Golden Dataset。
- Prometheus 文档（prometheus.io）：指标打点与聚合的实现参考。
本文是 AI Agent 工程实践系列的第 33 篇（第四阶段第十三篇）。
系列导航
上一篇：第 32 篇《Agent 如何上线》
下一篇：第 34 篇《企业 AI Agent 架构》