你的 Agent 在沉默地犯错——Agent 可观测性 2026 实战指南

你的 Agent 可能在生产环境中已经跑偏了很久，而你浑然不知——因为它的每个 API 都返回了 200。2026 年，Agent 可观测性已经从「可选」变成了「强制」。这篇文章梳理了为什么传统监控对 Agent 无效、OpenTelemetry GenAI 语义约定如何成为行业标准、以及落地时该从哪里下手。

上周我在做一个多 Agent 协同任务。主 Agent 调了子 Agent，子 Agent 查了知识库，返回了一个看起来完全合理的结果。我检查了日志：所有 API 调用都返回 200，所有工具调用都成功了，没有异常，没有超时。

但结果是错的。

不是那种明显的错——不是 JSON 解析失败，不是参数类型错误。而是语义上的错：Agent 理解对了问题，找对了文档，但在整合信息时做了一个错误的推断，然后信心满满地把结果交给了下游。下游的 Agent 信任它，继续往后传。等我发现问题的时候，错误已经被传递了三层。

事后复盘时我发现：我根本没有办法追踪这个错误是怎么发生的。日志告诉我「谁调了谁」和「最终返回了什么」，但中间那个 Agent 的推理步骤、为什么做出那个推断、看到了哪些上下文——全是黑箱。

这就是 2026 年生产环境里 Agent 系统面对的核心问题：你的 Agent 可能在沉默地犯错，而它每次犯错都看起来像是成功。

Agent 的失败模式，传统监控完全看不到

传统的可观测性三板斧——指标、日志、链路追踪——是为确定性系统设计的。一个 HTTP 服务要么返回 200，要么抛 500。你盯着错误率和响应时间，基本能判断出系统是否健康。

Agent 把这个模型打破了。

同一个输入，因为温度设置、检索结果排序、工具可用性这些因素的微小变化，Agent 两次执行可能走完全不同的路径。第一次它调了 3 个工具，5 步完成。第二次同一任务它调了 8 个工具，15 步，多花了 4 倍 token。但两次都返回了 200。

更致命的是第二个问题：Agent 的「失败」几乎不以错误的形式出现。

Agent 会返回结果，格式正确、结构完整，看起来合理。但内容错了——它误解了用户的意图，从检索到的文档中做了一个错误的归纳，或者调了一个不合适的工具完成了任务。传统监控对此完全失明。没有错误码，没有栈回溯，没有任何红色告警。

Gartner 2026 年初的数据说，只有大约 15% 的 GenAI 部署真正做了可观测性。换句话说，85% 的团队在生产中对自己的 Agent 到底在干什么，基本是猜的。

OpenTelemetry GenAI 约定：让 Agent 的行为「可说清楚」

2026 年 Agent 可观测性领域最重要的事件不是某个产品发布，而是一个规范的成熟：OpenTelemetry GenAI 语义约定。

这个规范定义了一套标准的 span 属性和指标命名，让 Agent 的每一步执行（模型调用、工具执行、子 Agent 交互）都能以统一的结构化数据被记录下来。重要性在于：你按这个规范打点，就可以在任意兼容的后端之间切换，不需要重新埋点。

规范定义了 6 种核心 span 类型：

• create_agent: Agent 创建时触发，携带名称、模型、配置信息
• invoke_agent: 执行 Agent，分 CLIENT（远程执行）和 INTERNAL（本地进程内）两种
• invoke_workflow: 多 Agent 编排，是父 span，包住多个 invoke_agent 子 span
• execute_tool: 单次工具调用，记录名称、参数、返回值
• chat/inference: 底层模型调用本身，记录模型名和 token 用量
• retrieve: 检索调用，记录检索内容和相关性评分

有了这套结构，一个多 Agent 任务从发出请求到最终返回结果，中间的所有跳转、推理、工具调用，都能被组织成一棵可回放的调用树。

还有一个被很多人忽略的设计细节：内容捕获默认关闭。

请求和响应的消息体默认不记录，这是出于隐私考虑。你可以选择三种模式：不记录、存储在 span 属性中、存储在外部的独立存储中只保留引用。对于生产环境中处理用户数据的系统，外部存储加引用的模式是推荐方案——你不会把敏感内容写入遥测管道。

实际上要追踪什么

做了那么多铺垫，落地时到底需要追踪哪些东西？

从最基础的开始，这五个维度是底线：

1. LLM 调用。 每次模型交互都要记录完整上下文：传入的系统提示、用户消息、模型返回、token 用量、响应时间。没有这个，你根本没法排查 Agent 为什么给出了某个回答。很多时候问题根本不在 Agent 逻辑，而在于上下文里塞进了一段不该有的内容。

2. 工具调用。 Agent 调了什么工具、传了什么参数、花了多久、返回了什么。这是最常见的性能瓶颈来源。很多 Agent "觉得慢"不是因为模型推理慢，而是因为调了一个不需要的工具，或者同一个工具被重复调用了三次。

3. RAG 检索。 Agent 做错事，经常不是因为推理能力差，而是因为拿到了坏的上下文。追踪检索调用能让你看到：实际召回了哪些文档、哪些被排在了前面、哪些被模型忽略了。

4. 应用元数据。 用户 ID、会话 ID、领域标识符。当用户报告问题时，能直接拉到那个会话的完整追踪，排查时间从小时级缩短到分钟级。

5. 关键决策点。 这个最容易被忽略。Agent 在执行过程中会有一些关键分支：比如根据某种条件决定调用工具 A 还是工具 B，或者根据检索结果决定是否继续追问。这些决策的输入和输出如果没被记录，出了问题你只能猜。

2026 年的新变量：MCP 追踪

MCP（Model Context Protocol）作为 Agent 与工具之间的通信标准，在 2026 年越来越普及。随之而来的问题是：通过 MCP 调用的工具，在追踪里曾经是个黑箱。

2026 年 OTel v1.39 版本中新增的 MCP 语义约定解决了这个问题。它定义了 mcp.method.name、mcp.session.id、mcp.protocol.version 等属性。而且设计得很聪明：当 MCP 的埋点检测到外层已经有 GenAI 的 execute_tool span 时，它不会创建一个重复的 span，而是直接在外层 span 上追加 MCP 特有的属性。你拿到的是同一棵调用树，但每一层都更厚了。

这意味着如果一个 Agent 调用了 10 个不同的 MCP Server，你可以在一个 trace 里完整看到：从 Agent 的推理到具体调用了哪个 MCP Server 的哪个工具、花了多久、返回了什么——没有黑箱。

怎么选平台：先定部署模型，再看功能

2026 年的可观测性平台市场正在快速整合。Langfuse 被 ClickHouse 收购、Braintrust 完成了 8000 万美金的 B 轮。但选平台时，功能列表是第二位的，第一个决策点是：你的数据能出去吗？

目前有三种主流部署模式：

自托管（Self-hosted）。 Langfuse 和 Arize Phoenix 都支持 Docker Compose 或 Kubernetes 部署。如果你的数据不能出内网——比如金融机构、医疗领域——这是唯一选项。代价是运维成本。

托管 SDK。 LangSmith、Braintrust。加几行代码就能拿到步级追踪和内置评估工具，最快的上手路径。数据留在第三方平台上，按 trace 量或 span 量付费。

代理网关（Proxy Gateway）。 Helicone。零代码变更，通过改 base URL 就能捕获所有模型调用。但架构风险：网关是整个链路的单点故障，一旦挂了，所有 Agent 都连不上模型。

最简洁的起步建议

如果你现在还没做任何可观测性，从最小闭环开始：

1. 在你的 Agent 框架里启用 OpenTelemetry auto-instrumentation —— 大多数主流框架（LangChain、CrewAI、ADK、Mastra）都支持一行代码开启
2. 确保你至少打了 gen_ai.client.operation.duration 和 gen_ai.client.token.usage 这两个直方图指标——没有它们你无法在任何维度上分析成本和速度
3. 选一个后端存 trace，本地开发阶段用 ConsoleExporter 就够了，上线前换成自托管或托管方案
4. 设置 fallback rate 和 tool call retry rate 告警——这是最容易提前发现问题的信号

做完这四步，你就已经跑赢了市面上 85% 的 Agent 系统。

代理行为与普通软件的本质区别在于：它的失败不表现为错误，而表现为看起来正确的错误行为。 如果你没有一个能回放的步级追踪链路，你根本无法区分"做得对"和"做得像对了"。这不再是运维质量的问题，而是 Agent 系统"可信任"的基本前提。