AI Agent 可观测性实战：别等出事才想起日志

为什么 Agent 比传统服务更难观测

传统 API 的失败是显式的：返回 500、超时、异常堆栈。而 Agent 的失败是隐式的——它可能”成功”返回了一段看似合理、实则错误的内容，还消耗了 10 倍预算。

更麻烦的是，一次 Agent 请求背后是几十次 LLM 调用、多轮工具调用、动态分支。你看到的只是一个最终答案，中间发生了什么全是黑盒。没有可观测性，就等于闭着眼睛调优。

三根支柱：轨迹、成本、质量

支柱一：轨迹追踪（Tracing）

核心是记录每一次 LLM 调用、工具调用、决策分支，形成一棵可回放的调用树。

关键要埋的字段：

• trace_id / span_id：串起整条链路
• 每一步的 input_prompt、output、token_usage
• 工具调用的入参、出参、耗时、错误
• 决策点的候选与最终选择（比如路由到了哪个模型）

选型上，OpenTelemetry 的 GenAI 语义约定正在成为事实标准，Langfuse、LangSmith、Phoenix（Arize）都支持 OTLP 导入。能导出到自建 OTEL Collector 的，长期更安全，避免被单一厂商锁定。

支柱二：成本归因

成本必须能按 trace、按用户、按功能模块拆分。否则你只知道”这个月花了很多钱”，却不知道是谁花的。

落地做法：

• 每次调用落库 model、input_tokens、output_tokens、cached_tokens
• 用一张汇率表把 token 换算成钱
• 按 feature_tag 聚合，找出成本大头

很多团队一上归因就发现：80% 的成本集中在某 2 个高频短任务上，而这些任务用便宜模型完全够用。没有归因，优化就是猜。

支柱三：质量看板（Evals in Prod）

离线评测不够，要在生产里持续采样打分：

• 规则分：格式是否合规、是否触发了禁用词、工具是否调用成功
• 模型裁判：用强模型给弱模型输出打分（注意裁判自身的偏差）
• 人工抽检：每天固定抽 N 条，标注真实好坏

把这三个分数放进同一个 dashboard，按天看趋势。质量下滑往往是渐进的，趋势比单点更有价值。

一个最小可用栈

不需要一步到位，按这个顺序搭：

1. 先接 OTEL + Langfuse：一周内拿到完整轨迹
2. 再接成本归因：把 token 落库换成钱
3. 最后接质量采样：规则分 + 模型裁判

三件事做完，你就从”盲调”进入”数据驱动调优”。

常见坑

• 只记日志不记结构：一堆文本日志，无法聚合分析。要结构化。
• 采样率设太高：全量 trace 存不下也查不动，生产建议采样 10%–20%，错误链路 100%。
• 忽略 PII：轨迹里会带用户输入，记得脱敏再落库，合规红线。

一句话总结

Agent 的可观测性不是”看日志”，而是轨迹、成本、质量三条线同时可见。先接 OTEL 拿到轨迹，再做成本归因，最后上质量看板——没有度量，就没有可靠的 Agent 生产系统。