Agent运维监控实战（9章140页）

Agent 上线之后，真正难的不是让它跑起来，而是让它一直跑下去。模型调用变慢、工具接口超时、上下文越滚越大、账单突然翻倍——这些问题不会在本地 demo 里出现，只会在真实流量里冒头。这门《Agent运维监控实战》盯的就是这一段：把 Agent 当成一个需要被观测、被计量、被约束的线上系统来对待，而不是一个"能回答就行"的黑盒。

先确认你是否真的需要补这一块

如果你符合下面任意一条，这门课的内容大概率对得上你的缺口：

• 用 LangChain、LlamaIndex 或自研框架搭过 Agent，能跑通流程，但说不清它每分钟消耗多少 token、哪一步最慢。
• 做过传统服务的 Prometheus + Grafana 监控，但不知道怎么把 LLM 调用、工具调用、检索命中这些自定义指标接进去。
• 遇到过"昨天还好好的，今天回答质量突然下降"，却只能靠翻日志猜原因。
• 团队开始关心 Agent 的月度成本，而你手上只有云厂商的总额账单，拆不到具体会话或具体工具。

如果你的 Agent 还停留在单机脚本阶段，没有并发、没有多用户、没有成本压力，那可以先放一放——这门课的很多设计取舍，只有在有流量和账单压力时才看得出意义。

它讲的是监控，但落点在三类可观测信号

课程围绕 Agent 特有的观测对象展开，而不是泛泛谈"加个日志"。一是链路层面：一次用户请求在 Agent 内部会经过规划、工具选择、工具执行、结果拼接等多跳，需要把这些跳串成可追踪的调用链，才能定位到底是模型慢还是工具慢。二是指标层面：把延迟、错误率、token 消耗、工具调用次数、重试次数这些量化成时间序列，用 Prometheus 采集、Grafana 呈现，并且区分清楚哪些是计数器、哪些是直方图，避免后期算分位数时返工。三是日志与成本层面：结构化日志要能反查到具体会话，成本跟踪要能落到每次调用、每个工具、每个租户，而不只是月底看一个总数。

成本跟踪是这门课比较稀缺的部分

大部分 Agent 教程讲到"接入监控"就停了，这门课专门拿出章节做成本跟踪与预算管理。它关心的具体问题是：如何给一次 Agent 运行打上可归因的标签，让 token 消耗能按功能、按用户、按实验分组统计；当预算接近阈值时，是在入口限流、降级到更便宜的模型，还是直接中断；缓存和提示词压缩对成本曲线的影响该怎么量化。这些问题在真实项目里往往比"监控大盘好不好看"更早被追问，而能给出可操作答案的资料并不多。

看完你应该能回答的问题

• 给你的 Agent 加上监控，第一个该埋的指标是什么，为什么不是总调用量？
• 一次 Agent 请求跨越模型和多个工具，你怎么把它的耗时拆开归因？
• Prometheus 的指标命名和标签设计上，哪些做法会在数据量涨上来之后变成灾难？
• 怎样在不改动业务代码逻辑的前提下，把成本数据采集出来并接到告警？
• 质量下降但错误率没涨，这种"静默劣化"你打算用什么信号发现？

对应的练习建议不要只读文档：拿你手上已有的一个 Agent，先补上调用链和 token 计数，让它跑一天，再看采集到的数据里有什么是你没预料到的。带着这份真实数据回来对照课程里的指标设计和成本拆分方法，比空对空看目录有效得多。