可观测性 (Observability)

Agent 最大的维护难点之一，就是它很像个黑盒。

它答错了以后，你第一反应通常不是“错了”，而是“到底哪一层错了”：

• 是检索没拿到对的资料
• 是模型推理跑偏了
• 是工具调用失败了
• 还是程序根本把状态传错了

如果没有可观测性，这些问题大多只能靠猜。

#1. 什么是 Tracing？

Tracing 最简单的理解就是：把一次请求在系统里走过的全过程记录下来。

在 Agent 里，一次完整请求通常会包含：

• 一次或多次 LLM 调用
• 若干工具调用
• 检索动作
• 状态更新
• 最终输出

这些步骤里，每一段都可以看成一个 span。

一个典型的 Trace 视图：

text复制
Run: "帮我查一下 Google 股价" (Total: 3s)
├── Retriever: search_docs (0.5s) -> 找到 "Google 财报.pdf"
├── LLM: GPT-4o (1.5s)
│   ├── Input: "根据 Google 财报..."
│   └── Output: "Thinking: 我需要调用工具..."
├── Tool: get_stock_price("GOOGL") (0.8s) -> 返回 $175
└── LLM: Final Answer (0.2s) -> "Google 股价为 $175"

#2. 主流工具

#3. 实战：接入 LangSmith

LangSmith 很常见，因为接入成本低，尤其如果你本来就用了 LangChain。

bash复制
export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_API_KEY=your_api_key

一旦开启，你能看到的不只是“结果”，还包括：

• 每次请求用了多少 token，花了多少钱
• 每个 prompt 的输入输出
• 哪一步调用了什么工具
• 哪个节点报错，耗时多少

这类信息在调试阶段价值非常大，因为你终于不用只看最终 answer 猜中间过程。

#4. 关键监控指标

只有 trace 还不够。trace 更像显微镜，适合排查单次问题；而指标更像仪表盘，适合看整体是否变坏。

我更建议至少盯这几类指标：

#延迟

• 平均延迟
• P95 / P99 延迟
• 哪一层最耗时，是检索、模型还是工具

很多 Agent 线上体验差，不是答错，而是等太久。

#成本

• 单次请求 token 消耗
• 高成本请求占比
• 哪个 prompt 或节点最烧钱

如果不监控这一层，Agent 很容易在你没注意时把预算吃穿。

#错误率

• 工具调用失败率
• 解析结构化输出失败率
• 检索空结果率

这几类指标通常比“用户感觉不太对”更早暴露问题。

#用户反馈

• 点赞 / 点踩
• 人工改写率
• 用户中途放弃率

这部分虽然不够精确，但很接近真实体验。

#5. 生产环境里最有用的不是“看到”，而是“能定位”

可观测性的终极目标不是堆日志，而是帮助你快速回答下面这些问题：

• 为什么今天错误率突然升了
• 哪个模型版本导致了回归
• 哪个工具最近响应变慢
• 哪种问题类型最容易失败

所以一个真正有用的 observability 体系，通常还会做：

• request 维度的 trace
• session / user 维度的聚合
• 按工具、模型、prompt 版本切分的统计
• 异常告警和阈值监控

只有这样，它才不只是“能看日志”，而是真的能定位系统问题。

#6. 一套足够实用的落地建议

如果你现在准备给 Agent 接可观测性，我建议优先级这样排：

1. 先接基础 trace，至少能看到 LLM / 检索 / 工具链路
2. 再接 token、延迟、错误率这三类核心指标
3. 给关键节点打上版本号，比如 prompt 版本、模型版本、检索策略版本
4. 最后再补报警、抽样回放和用户反馈联动

不要一开始就想做满分监控。先保证系统出事时你知道是哪里出事，已经能解决大部分问题。

#小结

可观测性对 Agent 来说，不是锦上添花，而是基本生存能力。

• 开发阶段，它帮你调 prompt 和链路
• 生产阶段，它帮你抓成本、性能和错误
• 系统出问题时，它决定你是“靠猜”还是“能定位”

Agent 不可怕，可怕的是出了问题以后完全不知道它怎么错的。