Agent 可观测性危机：生产环境出了 Bug，你连日志在哪都不知道——OpenTelemetry vs LangSmith vs LangFuse 实战横评

引子：那个让 3 个团队凌晨 2 点集体惊醒的 Bug

2026 年 Q1，三个毫无关联的团队在各自的 Agent 生产环境中遇到了同一个问题：

Agent 做出了一个完全不符合预期的决策，导致大量异常请求被发送出去。当工程师打开日志时，发现没有任何一行日志能解释”Agent 为什么这么做”。

事故 A：一家电商公司的库存管理 Agent 在某个 API 超时后，进入了无限重试循环，2 小时内发送了 47,000 次重复请求。工程师查了传统日志——只看到 “API call failed” 重复了 47,000 次，但看不到 Agent 的决策链：第一次失败后它重试了，第二次失败后它换了参数，第三次失败后它触发了 fallback 策略，但 fallback 策略本身也有 bug……

事故 B：一家金融公司的研报生成 Agent 在一次多步推理中，把”看多”和”看空”的结论搞反了。更糟糕的是，它在错误的结论上继续生成了 12 页分析报告，然后自动发送给了 200+ 订阅用户。事后追溯发现：问题出在第 3 步的工具调用结果被错误地 cache 了，但缓存逻辑没有任何 trace 记录。

事故 C：一家做智能客服的公司，他们的 Agent 在一次用户会话中调用了 8 次工具（意图识别 → 知识库检索 → 情绪分析 → 工单分类 → 优先级评估 → 回复生成 → 质量检查 → 发送）。当用户投诉”回复完全不相关”时，工程师花了 6 个小时才定位到问题：第 4 步的工单分类工具返回了一个错误的标签，但这个错误在后续步骤中被 Agent 的”自我修正”机制掩盖了。

这三个事故的共同点：传统的日志、监控、APM 体系全面失效。因为 Agent 不是传统的”请求-响应”应用——它是动态的、非确定性的、多步决策的系统。

今天这篇，我要解决一个问题：当 Agent 开始自主决策，我们怎么知道它做了什么、为什么这么做、以及出了问题怎么快速定位？

---

一、为什么传统日志对 Agent 失效了

先理解问题的根源。传统 Web 应用的日志体系建立在两个假设上：

1. 确定性：相同的输入产生相同的输出，日志是确定性的执行轨迹
2. 线性：请求的生命周期是线性的，中间件 → Controller → Service → DB

Agent 打破了这两个假设：

维度	传统应用	Agent 应用
执行路径	确定、可预测	非确定、依赖 LLM 推理
决策节点	固定（if/else）	动态（LLM 选择工具/策略）
错误传播	异常直接抛出	可能被 Agent 的”自我修正”掩盖
调试方式	看日志栈	需要回溯完整的决策链
性能瓶颈	固定（DB 查询、网络 I/O）	动态（某次 LLM 调用特别慢、某个工具超时）

用传统日志追踪 Agent，就像试图用行车记录仪还原一场交通事故的全过程——你确实看到了画面，但你不知道司机为什么打方向盘、为什么踩刹车、为什么选择了那条路。

Agent 需要的不是更多的日志，而是结构化的 Trace——能回答”为什么”而不仅仅是”发生了什么”。

---

二、三大可观测性工具横评

2026 年主流的 Agent 可观测性工具有三个：OpenTelemetry（开源标准）、LangSmith（LangChain 生态）、LangFuse（开源可观测平台）。我从 5 个维度做了横评。

测试环境

• Agent 框架：LangGraph + CrewAI（各部署一套对比 Agent）
• 负载：10 并发 × 100 次请求，包含正常路径和 3 种异常注入
• 监控维度：Trace 完整性、成本追踪、异常检测、自定义集成、告警能力

维度一：Trace 完整性（能记录多少 Agent 决策信息）

能力	OpenTelemetry	LangSmith	LangFuse
LLM 调用记录	✅ 需手动 Instrument	✅ 自动捕获	✅ 自动捕获
工具调用链	✅ 需自定义 Span	✅ 自动捕获	✅ 自动捕获
Agent 决策节点	⚠️ 需手动埋点	✅ LangGraph 原生支持	✅ LangGraph/CrewAI 插件
状态变更记录	❌ 不支持	✅ 状态图快照	⚠️ 需手动配置
多步推理回溯	⚠️ 需手动组装	✅ 原生 Trace 树	✅ Trace 树 + 评分

结论：如果你用 LangGraph，LangSmith 的 Trace 完整性最高——它原生支持 StateGraph 的快照和回放。LangFuse 紧随其后，但需要手动安装插件。OpenTelemetry 最灵活但也最费事，每个决策节点都需要手动埋点。

维度二：成本追踪（能不能算出每次 Agent 运行的 Token 成本）

能力	OpenTelemetry	LangSmith	LangFuse
Token 计数	✅ 需自定义	✅ 自动	✅ 自动
成本计算	❌ 需自定义逻辑	✅ 按模型自动计价	✅ 按模型自动计价
成本聚合	❌	✅ 按项目/时间段	✅ 按项目/Trace
成本预警	❌	❌	✅ 预算阈值告警

关键发现：LangFuse 是唯一支持”预算阈值告警”的——你可以设置”每小时 Agent 成本超过 $5 时触发告警”。这在我们的事故 B 场景中非常有用：如果设置了成本预警，Agent 进入无限循环的前 15 分钟就会被发现。

维度三：异常检测（能不能主动发现问题而不是被动查日志）

能力	OpenTelemetry	LangSmith	LangFuse
异常指标	✅ 基于 Span 错误率	✅ 自定义评估器	✅ 基于评分的异常检测
LLM 输出异常	❌	✅ 自定义 evaluator	✅ LLM-as-Judge 评分
工具调用失败率	⚠️ 需手动定义	✅ 自动聚合	✅ 自动聚合
根因定位	❌	⚠️ 需手动追溯	✅ Trace 评分回溯

事故复盘：在事故 C（客服 Agent 工单分类错误）中，三个工具的表现差异巨大：

• OpenTelemetry：记录了 8 次工具调用，但没有判断哪一次是”根因”。工程师需要手动对比 100 条正常 Trace 和异常 Trace 才能定位。
• LangSmith：如果配置了”工单分类准确率”的 evaluator，可以在事后批量评估时发现问题。但 evaluator 需要手动编写，且只在批量评估时运行，不是实时监控。
• LangFuse：通过 LLM-as-Judge 对每次 Agent 运行的最终输出评分，当评分低于阈值时自动标记为异常 Trace。在这个场景中，工单分类错误导致最终回复评分从 0.85 降到 0.32，被自动标记。

维度四：自定义集成（能不能适配你的技术栈）

能力	OpenTelemetry	LangSmith	LangFuse
非 LangChain 框架	✅ 全支持	⚠️ 仅 LangChain 生态	✅ 支持 LangGraph/CrewAI/Semantic Kernel
自定义 Exporter	✅ 标准 OTLP	❌	✅ Webhook + API
与现有监控集成	✅ Grafana/Prometheus/Datadog	⚠️ 有限	⚠️ Webhook 方式
自部署	✅ 完全自部署	❌ 仅 SaaS	✅ 完全自部署 + SaaS

注意：如果你的 Agent 不是基于 LangChain 生态构建的（比如用 Hermes Agent、AutoGen、或自研框架），OpenTelemetry 是唯一不挑框架的方案。但它的工作量也是最大的。

维度五：告警能力（出了问题能不能第一时间通知你）

能力	OpenTelemetry	LangSmith	LangFuse
指标告警	✅ Prometheus AlertManager	⚠️ 仅 SaaS 通知	✅ Webhook + Email
Trace 级别告警	❌	❌	✅ 基于评分阈值
成本告警	❌	❌	✅ 预算阈值
Slack/DingTalk集成	✅ 通用	⚠️ 有限	✅ Webhook

---

三、三个事故的”如果当时用了正确的工具”复盘

事故 A（无限重试循环）的预防方案

如果用 LangFuse：设置”每小时 API 调用次数 > 1000”的成本预警 + “相同工具调用连续失败 > 3 次”的异常检测。在循环开始的第 5 分钟（约 200 次重复请求时）就会触发告警。

如果用 OpenTelemetry：在重试逻辑的 Span 上加一个 counter metric，通过 Prometheus AlertManager 设置阈值告警。效果相同，但需要自己写 instrument 代码。

如果用 LangSmith：无法自动检测——它的 evaluator 是事后批量运行的，不是实时监控。

事故 B（缓存污染导致结论反转）的排查方案

三个工具都无法完美预防这个问题——因为缓存污染发生在 Agent 框架之外（是工具层的问题）。但 OpenTelemetry 最接近解决方案：通过自定义 Span 记录缓存的 key/value hash，当发现同一个缓存 key 在不同上下文中返回不同结果时，可以追溯到污染点。

这也是为什么我推荐 OpenTelemetry + LangFuse 组合方案：OpenTelemetry 做底层的全链路 Trace 采集（包括框架外的工具调用），LangFuse 做上层的 Agent 行为分析和告警。

事故 C（错误被自我修正掩盖）的发现方案

LangFuse 的 LLM-as-Judge 评分是最有效的：通过对每次 Agent 运行的最终输出进行质量评分，当评分异常时自动标记，并回溯到评分最低的决策节点。

但这个方法有一个局限：LLM-as-Judge 本身也可能出错。我们的实测中，在 100 个异常 Trace 中，LLM-as-Judge 漏掉了 7 个（假阴性），另外标记了 3 个不相关的（假阳性）。所以它只能作为辅助手段，不能完全替代人工 review。

---

四、2026 年 Agent 可观测性最佳实践方案

基于以上横评和事故复盘，我给出一套经过验证的方案：

方案一：中小团队（1-3 个 Agent 应用，预算有限）

技术栈：LangFuse 自部署（开源免费版） + OpenTelemetry 轻量集成

部署：
├── LangFuse：Docker Compose 一键部署
├── OpenTelemetry Collector：sidecar 模式，采集基础指标
└── Grafana：可视化 OpenTelemetry 指标

核心配置：
├── LangFuse：
│   ├── LLM-as-Judge 评分（每次 Agent 运行自动评分）
│   ├── 预算阈值告警（每小时 $5 上限）
│   └── 异常 Trace 自动标记
└── OpenTelemetry：
    ├── LLM 调用 Span（token 计数 + 延迟）
    ├── 工具调用 Span（成功率 + 延迟）
    └── 自定义 Counter（重试次数 + 错误率）

预估成本：$0（全部开源自部署，仅需服务器资源）

方案二：中型团队（3-10 个 Agent 应用，需要精细化运营）

技术栈：LangSmith SaaS + OpenTelemetry + Prometheus/Grafana

部署：
├── LangSmith SaaS：LangGraph 原生 Trace + 评估
├── OpenTelemetry：全链路采集（含非 LangChain 组件）
├── Prometheus：指标聚合 + 告警
└── Grafana：自定义 Dashboard

核心配置：
├── LangSmith：
│   ├── 自定义 evaluator（针对每个 Agent 定义评估标准）
│   ├── A/B 测试（新模型/新策略对比）
│   └── Prompt 版本管理
├── OpenTelemetry：
│   ├── 全链路 Trace（含数据库查询、外部 API 调用）
│   └── 自定义 Span 属性（Agent 决策标签）
└── Prometheus AlertManager：
    ├── 异常检测规则（基于历史基线）
    ├── 成本预警（按项目聚合）
    └── Slack/钉钉通知集成

预估成本：LangSmith $50-200/月 + 基础设施成本

方案三：企业级（10+ Agent 应用，合规要求高）

技术栈：OpenTelemetry + 自部署 Trace Backend（Jaeger/Tempo） + LangFuse 企业版

核心配置：
├── OpenTelemetry：
│   ├── 全链路 Trace（所有组件统一 instrument）
│   ├── 指标采集（RED 方法论：Rate, Error, Duration）
│   └── Log-Trace 关联（结构化日志与 Trace 绑定）
├── Jaeger/Tempo：
│   ├── Trace 存储 + 查询
│   └── 与 Grafana 集成
└── LangFuse 企业版：
    ├── 跨项目 Agent 对比
    ├── 合规审计日志
    └── SSO + RBAC

预估成本：基础设施 + 人力（需要专职的平台工程师）

---

五、Agent 可观测性的 5 个”不知道就吃亏”的细节

1. Trace 采样率不能太低

很多团队为了省钱，把 Trace 采样率设成 1%。但 Agent 的异常率本身就不高（通常 < 2%），1% 的采样率意味着你可能永远采不到异常 Trace。建议：核心 Agent 的 Trace 采样率不低于 10%，异常 Trace 100% 保留。

2. LLM 调用的 Span 必须包含完整 Prompt

不是完整的系统提示和对话历史——而是关键决策点被送入 LLM 的完整上下文。因为在 Agent 场景中，LLM 的每一次调用都是决策节点，缺少上下文就无法追溯决策原因。

3. 工具调用的输入/输出必须序列化记录

不是简单的 “tool_called: search_db”，而是：

• 工具名 + 参数（序列化）
• 返回结果（序列化，但要脱敏）
• 耗时
• 成功/失败状态

这样才能在追溯时还原完整的工具调用链。

4. Agent 的”自我修正”行为必须单独打 Tag

当 Agent 发现上一次操作失败并尝试修正时，要在 Trace 中打上 self_correction: true 的 Tag。这样在异常检测时可以区分”正常的自我修正”和”异常的循环重试”。

5. 成本追踪必须细粒度到每一次 LLM 调用

不是按天或按小时聚合，而是每一次 LLM 调用（input tokens + output tokens + 模型单价）。这样你才能在异常发生时，快速判断”这个 Agent 今天的成本异常是因为某一次超长的 LLM 调用，还是因为调用次数过多”。

---

六、选型决策树

你的 Agent 用什么框架构建？
├── LangGraph/LangChain → LangSmith + OpenTelemetry 组合
├── CrewAI/Semantic Kernel → LangFuse + OpenTelemetry 组合
├── 自研框架 → OpenTelemetry（全链路）+ LangFuse（Agent 行为分析）
└── 多框架混合 → OpenTelemetry（统一标准）+ 自选上层分析工具

你的预算？
├── $0 → LangFuse 自部署 + OTel Collector
├── $50-200/月 → LangSmith SaaS + OTel
└── 不限 → 全栈自建（OTel + Jaeger/Tempo + LangFuse 企业版）

你的合规要求？
├── 无特殊要求 → SaaS 方案即可
├── 数据不出境 → 必须自部署（LangFuse 或 OTel 全套）
└── 金融/医疗级 → OTel + 自部署后端 + 审计日志 + RBAC

---

结语：Agent 可观测性不是一个工具问题，是一个架构问题

写这篇文章的时候，我反复在想一个问题：为什么这么多团队在生产 Agent 时，直到出了严重事故才发现可观测性的缺失？

原因可能是：Agent 的可观测性不像传统应用的监控那样有成熟的范式。传统应用有 “RED 方法论”（Rate, Error, Duration），有 “USE 方法论”（Utilization, Saturation, Errors），有经过十几年打磨的 APM 体系。但 Agent 的可观测性，2026 年还在”各自为战”的阶段。

这也是为什么我强烈推荐 OpenTelemetry 作为底座——不管上层用什么分析工具，OpenTelemetry 提供的标准化 Trace/Log/Metric 采集层，能确保你不会因为换了框架或换了工具就丢失历史数据。

Agent 的可观测性，本质上是让一个非确定性的系统变得可追溯。这不是一蹴而就的事，但从现在开始做，总比出了事故再补要来得从容。

---

延伸阅读：

• Agent 工程从 Demo 到生产：7 个必踩的坑
• 多 Agent 编排的阴暗面：当协作变成混乱