把 Agent 跑起来不难。难的是跑起来之后你怎么知道它到底在干什么、什么时候在悄悄出问题、什么时候在变好还是变差。
Langfuse Academy 发了一篇系统讲生产级 Agent 监控的文章，梳理得很清楚。
AI 工程循环里的监控位置
AI 工程循环是把生产发生的事（tracing、监控）和开发阶段的结构化迭代（数据集、实验、评估）连接起来。监控是从数据到理解的那一步。
Tracing 提供的是完整记录：每个请求、每次模型调用、每次工具使用。监控让你从这些数据里读出意义，给你两样东西：系统随时间表现如何的持续视图，以及一批值得调查的具体 trace。
两种完全不同的活动
把监控分成两块，因为它们回答的问题不一样。
聚合指标追踪：回答"整体是在变好还是变差"。成本、延迟、评估分数——这些成为你可以观察和推理的趋势。你能回答：上周二的 prompt 改动有效果吗？随着用量增长质量是否在漂移？
信号检测：回答"现在应该看哪里"。它把值得调查的单个 trace 推到面前：一次错误、重试聚集、用户对话中途放弃。信号有用是因为它连接到触发它的那条具体 trace，那条 trace 是你追问的起点。
反馈数据的两条路
用户反馈是信号最丰富的来源之一，但分两种，各有取舍。
显式反馈：点赞/点踩、星级评分、用户留言。信号明确，但响应率低，而且不满意用户比满意用户更可能反馈。
隐式反馈：从行为推导：用户是否重试、是否不同意系统、是否复制了回答、是否接受了建议、是否中途放弃对话。不需要用户额外操作，数据量大，但信号间接，需要解读。
用户放弃对话这个信号很有意思——这往往意味着 Agent 在某个节点让用户感到受挫或迷惑，但你没有收到任何反馈。可以把它纳入隐式反馈，用 LLM-as-judge 自动化地跑。
从哪里开始
不要一开始就设计一套宏大的监控体系。从真实数据开始。
第一步，手动读 trace。注意哪些类型的问题反复出现。在你知道自己在找什么之前，你设不出有用的监控规则。
第二步，用错误分析找到值得追踪的东西。错误分析给你一个结构化方法从 trace 里找规律，把值得自动化持续跑的重复性问题变成评估器。
第三步，想想你的应用具体怎么表现失败。用户不同意一个支持对话、流程自动化里出现修正——这些比通用分数更可操作，而且不需要人工标注就能暴露问题。
第四步，把它当作迭代过程。监控配置不是一劳永逸的。用法模式在变、模型在更新、新的失败模式在出现。持续打磨你的设置，才能穿过噪音持续聚焦在真正重要的事上。