目录
在如何搭建多智能体系统一文中，我们说过：“在增加智能体之前，先为每一次交接装上度量。”支撑这种生产环境中“度量”的技术，正是 AI 可观测性。它让你看清你的 LLM 与智能体在生产环境中究竟在做什么——调用了哪些工具、检索了什么、在哪里失败、花了多少成本。
与普通的应用监控不同，AI 有一个棘手的特性：一次请求可以返回“200 OK，50ms”，却依然一本正经地撒谎（幻觉）。换句话说，它可以又快又在线，质量却已经坏了。本文面向初学者，梳理可观测性的三大支柱、它与评估（evals）的区别、值得关注的指标，以及主要工具。
可视化一次请求的“执行树”
— trace 将输入、工具调用、检索与输出记录为一个个 span
* 本文中工具的特征与概念引用自公开资料与官方文档（截至 2026 年 6 月）。工具的评价会因用途与版本而异，请作为方向性参考阅读。
1. 什么是 AI 可观测性？
AI 可观测性是指让 LLM 与 AI 智能体在生产环境中的行为从外部可被观测。对每一次请求，你都记录“用什么提示词调用了哪个模型、用了哪些工具与检索、返回了什么、耗时多久、花了多少钱”——这样当出问题时，你就能回溯到原因。
与普通应用监控的决定性区别：传统监控查看的是“是否在线、是否够快？”但 AI 可能响应正常又快速，内容却是错的。AI 的多数故障不是基础设施故障，而是“质量故障”——幻觉、检索不力、不安全的答案、任务未完成、工具误用，以及提示词改动后的退化。
所以 AI 需要专门的观测。尤其在多智能体系统中，失败出现在多步因果链中，而非单次调用层面。“哪一步出了错、为什么”，只有在捕获了整个会话的 trace 之后才会显现。
2. 三大支柱：trace、metrics、logs
可观测性传统上以三大支柱来描述。AI 也是如此，而行业标准 OpenTelemetry（GenAI 规范）让你能用厂商中立的通用 schema 处理这三者。
Trace（轨迹）
将一次请求的执行路径记录为一棵 span 树。你能看到 LLM 调用、工具、检索与推理链是如何流转的。AI 观测的主角。
Metrics（指标）
将延迟、成本、token 数、错误率与吞吐量汇总为数值。可按模型/智能体追踪趋势。
Logs（日志）
单个事件的详细记录——完整提示词、错误细节——是深入排查的依据。
OpenTelemetry 的 GenAI 规范以标准格式记录提示词、模型响应、token 使用量、工具/智能体调用与提供方元数据。这意味着你不会被单一厂商绑定，并能把 AI 的 trace 接入 Datadog 或 Grafana 等现有监控后端。
3. 与评估（evals）的区别
初学者最容易混淆的，是“可观测性”与“评估（evals）”的区别。两者是不同的东西，而且只有成套使用才有意义。
🔭 可观测性
展示“发生了什么”：trace、成本、延迟、错误。容易测量，但单凭它无法告诉你“答案是否正确？”
✅ 评估（evals）
衡量“答案好不好”：准确性、groundedness、安全性。必须有明确的 evals——这是质量的守门人。
关键在于：“成本与延迟容易测，但答案质量不做明确评估就无从知晓。”正因如此，2026 年的主流工具不只展示 trace——它们还会给输出打分、在质量退化时告警，并把洞察反馈回开发。观测与评估，是同一辆车的两个轮子。
4. 该看什么：关键指标
要在仪表盘上追踪的指标，大致分为“运营类”与“质量类”。
⚙️ 运营类（容易测量）
- 成本：每次请求的 token 计费
- 延迟：响应时间（随输入大幅波动）
- Token 使用量：尽早发现臃肿的提示词
- 错误率 / 吞吐量：按模型/智能体分
🎯 质量类（需要评估）
- 幻觉：自信却错误的断言
- Groundedness（根据性）：对 RAG 最关键——是否有检索来源支撑？
- 安全性：PII 泄露、有害输出
- 任务完成度 / 工具使用是否正确
在质量指标中，对 RAG（检索增强生成）而言，“groundedness（忠实度，faithfulness）”是最关键的指标：答案究竟是有检索到的文档支撑，还是模型凭空编造？幻觉检测通常使用 LLM-as-a-judge（让 AI 来打分）、语义相似度与 groundedness 分数。
5. 主要工具对比
下面是 2026 年具代表性的 AI 可观测性工具。许多都在朝着把追踪与评估合二为一的方向发展。
| 工具 | 特征 | 适合用途 |
|---|---|---|
| LangSmith | 与 LangChain/LangGraph 契合度极高。详细追踪 + 评估 + 监控。开销小。 | 基于 LangChain 的生产环境 |
| Langfuse | 开源。可自托管，因此无需把数据发往外部 SaaS。 | 自托管 / 数据要求严格 |
| Arize Phoenix | 擅长 RAG 调试。善于可视化检索质量。 | RAG 调查与改进 |
| MLflow | 集中管理整个 GenAI 生命周期。 | 从开发到运维端到端 |
| AgentOps | 专注于监控自主智能体。多步会话追踪。 | 智能体运维 |
| OpenTelemetry | 标准规范。厂商中立；可连接 Datadog/Grafana 等。 | 与现有监控集成 |
来源：各类工具对比与官方信息引用（2026 年 6 月）。特征为倾向性描述，评价会因用途与版本而异。
拿不准时，先以符合 OpenTelemetry 的方式开始捕获 trace 是稳妥之选。你能避免厂商锁定，日后还可重新选型。若你用 LangChain，LangSmith 是便捷的入口；若想把数据留在自家，则选 Langfuse。
6. 如何起步，以及为何对智能体至关重要
不必想太复杂——从小处着手即可。要紧的是在上线生产之前就把观测落实到位。
尤其在多智能体系统中，观测并非“有则更好”，而是必需。由于失败藏在多步链条里，没有整个会话的 trace，你就永远不会知道“在哪里、为什么坏了”。在增加智能体之前先把观测做好——这是铁律。它也有助于安全事故的早期发现。
总结
AI 可观测性是“让生产中的 AI 可见”的运营基石。我们来回顾一下。
核心要点
- 🔭 让生产中 AI 的内部可见。三大支柱：trace、metrics、logs。
- ⚠️ 200 OK 也会撒谎。AI 的多数故障是质量故障，而非基础设施。
- 🔁 观测与评估并行。trace 看“是什么”，evals 看“好不好”。
- 🛠️ 工具：LangSmith/Langfuse/Phoenix/MLflow/AgentOps。标准是 OpenTelemetry。
- 🤖 对智能体不可或缺。多步失败只有在整个会话的 trace 中才看得见。
“又快又在线”不足以让人信任 AI。只有当你能看清内部、衡量质量时，它才算达到生产级。先以符合 OpenTelemetry 的方式捕获 trace，再接入 evals。关于搭建智能体，见这里；关于安全设计，见护栏。
FAQ
Q. 可观测性与评估（evals）有何不同？
A. 可观测性展示“发生了什么”（trace、成本、延迟）；评估衡量“答案好不好”。由于响应可能又快又在线却仍然出错，基本做法是把两者成套使用。
Q. 直接用普通的应用监控工具不行吗？
A. 它能测量在线率与速度，但测不出幻觉或 groundedness 等 AI 特有的质量。AI 需要专门的观测（或 OpenTelemetry GenAI 规范）来记录提示词、token 与工具调用。
Q. 该从哪里起步？
A. 先以符合 OpenTelemetry 的方式开始捕获 trace 是稳妥之选。你能避免厂商锁定，日后还能重新选择 LangSmith 或 Langfuse 等工具。接着可视化成本与延迟，最后接入评估。
Q. 为什么它对智能体格外重要？
A. 智能体的失败不是出现在单次调用中，而是藏在多步因果链里。没有整个会话的 trace，你就无法定位“哪一步出错、为什么”，从而让调试变得不可能。
