Gartner 报告显示，2026 年 80% 的企业应用嵌入了 AI Agent，但其中不到 10% 已规模化进入生产环境。核心瓶颈是什么？不是模型能力，不是基础设施——而是可观测性。当 Agent 开始在复杂的工作流中做出自主决策时，企业发现他们无法回答一个最基本的问题："Agent 刚才做了什么，为什么？"
McKinsey 的 2026 年 State of AI 调查进一步佐证了这一判断：57% 的企业将 Agent 的可观测性列为规模化部署的首要技术障碍。传统 APM 工具只能告诉你"服务是否在线"——当 Agent 在 100% 在线的情况下输出错误决策时，APM 完全沉默。整个行业正在重新定义"监控"在这个新时代的含义。
本文基于 Expanso、Azure、Confident AI 等机构的研究，以及 OpenTelemetry GenAI 社区的最新规范，提供企业部署 AI Agent 可观测性的六项最佳实践。
什么是 AI Agent 可观测性？
AI Agent 可观测性是指在生产环境中追踪、监控和评估 AI Agent 行为的实践体系。它回答的是这样一个问题：当 Agent 从一个输入走到一个输出时，中间经历了哪些推理步骤、调用了哪些工具、访问了哪些数据、模型输出了什么中间结果？
这不同于传统 APM（应用性能监控）。APM 监控延迟、错误率和吞吐量——它假设应用是一个确定性的请求-响应系统。但 AI Agent 本质上是非确定性的：同一个输入可能产生完全不同的执行路径。传统 APM 无法捕获这种复杂性。
它也不同于简单的 LLM 监控。LLM 监控关注的是单个提示的输入和输出。但 Agent 是多步决策系统：Agent 可能调用 3 个工具、执行 5 次模型推理、经历 2 轮思考循环。可观测性必须追踪每一步的因果关系。
Digital Applied 的 2026 年企业调查显示，68% 的企业在 Agent 生产事故后需要超过 24 小时才能定位根因——因为它们的可观测性工具无法跨越工具调用和模型推理之间的鸿沟。这就是可观测性成为瓶颈的直接体现。
最佳实践一：追踪每一步，而非只看最终答案
这是 Agent 可观测性的第一原则。当用户投诉时，只看最终答案无法知道错误发生在哪个环节——工具调用失败、检索返回无关内容、还是模型推理本身出错。
Expanso 的研究表明，超过 70% 的 Agent 生产事故发生在中间步骤。这些事故包括：工具调用参数格式错误、API 返回了意料之外的数据结构、检索系统返回了低相关性文档、Agent 陷入了无限循环。
具体做法：
- 每次模型调用作为一个独立 span，包含输入 prompt、输出 completion、Token 用量
- 每次工具调用作为一个独立 span，包含工具名称、输入参数、返回结果、执行时长
- 每次检索（RAG）作为一个独立 span，包含查询向量、检索到的文档片段和相关性分数
- Agent 的多轮推理步骤链接为 trace——每一轮的思考和行动都记录在案
Azure 的 Agent Factory 团队建议将 Agent 追踪视为"分布式追踪"的一个特例——只不过这里的"服务"不是微服务，而是推理步骤。每个推理步骤都是一个可观测的单元。
最佳实践二：标准化 OpenTelemetry GenAI 约定
如果每个 Agent 框架使用自己的可观测性格式，企业将被锁定在单一供应商上。OpenTelemetry GenAI 语义约定（Semantic Conventions）正是为了解决这个问题。
这些约定定义了以 gen_ai.* 为前缀的标准化 span 属性，包括：
gen_ai.request.model：请求的模型名称（如 gpt-4o、claude-sonnet-4）gen_ai.response.token_count：响应的 Token 总数gen_ai.usage.prompt_tokens：提示部分的 Token 数gen_ai.usage.completion_tokens：补全部分的 Token 数gen_ai.system：AI 系统标识（如 openai、anthropic、bedrock）
通过采用这些约定，企业可以在不同可观测性后端之间自由切换——从 Datadog 到 Grafana，从 LangSmith 到 Weights & Biases——而不会丢失语义信息。Confident AI 的 2026 年工具对比报告将 OpenTelemetry GenAI 兼容性列为选择可观测性平台的首要筛选条件。
最佳实践三：观察全链路，而非单次提示
在复杂的 Agent 场景中，一个任务可能触发多个 Agent 之间的协作。A2A（Agent-to-Agent）协议的兴起意味着单个"任务"可能跨越多个 Agent、多个模型、多个工具集。可观测性必须跨越这些边界。
Azure 推荐使用"分布式追踪 + 关联 ID"的模式：每个顶层任务分配一个唯一的 trace ID，所有子任务、子 Agent 的 span 都继承这个 trace ID。无论 Agent 链有多深，运维团队都能通过 trace ID 重建完整的执行路径。
多 Agent 系统的追踪关键点：
- 父 Agent 调用子 Agent 的请求和响应必须记录为父子 span 关系
- Agent 间的数据传递必须被追踪——谁传递了什么数据给谁
- 当 Agent 链出现错误时，可观测性必须能定位到链中的第一个故障点
- 多 Agent 场景下的超时和重试逻辑也应在 span 中标注
最佳实践四：评估质量，而非仅看可用性
传统 SRE 指标在 Agent 场景下严重不足。Agent 服务可能 100% 可用——但没有一个回答是准确的。McKinsey 的研究表明，超过 40% 的企业在生产中遇到 Agent 输出"看似合理但完全错误"的情况，而传统监控完全无法捕获。
可观测性管道必须集成质量评估层。推荐做法是在追踪 span 上附加质量分数——评估每个 Agent 响应的准确性、完整性、对齐性和工具调用正确性。
质量评估的具体维度：
- 准确性：模型输出是否与事实一致（可通过自动的基于事实的一致性检查或人工抽查）
- 完整性：Agent 是否覆盖了用户问题的所有方面
- 对齐性：Agent 的决策是否符合预设的行为边界和安全策略
- 工具调用正确性：Agent 是否调用了正确的工具，参数是否正确
- 检索相关性：RAG 检索到的文档是否与问题相关
Confident AI 的 2026 年平台评估指出，领先的可观测性工具已支持"评估即 span 标注"——质量评估结果作为元数据直接附加到追踪 span 上，而非作为独立的后处理流程。这使得运维团队可以在 dashboards 上同时看到性能指标和质量指标。
最佳实践五：衡量每次运行的成本与 Token
AI Agent 的经济学不同于传统软件：每次执行都有直接的 Token 成本。Agent 的一次"失控运行"可能消耗数万 Token，产生可观的费用。
可观测性必须提供每次 Agent 运行的成本核算：
- 每次模型调用的 Token 消耗（prompt + completion）
- 每次工具调用的 API 费用（如数据库查询、第三方 API 调用）
- 每次检索的嵌入成本
- 每个用户的累计使用量
- 异常高耗运行的告警机制——当单次运行 Token 消耗超过预设阈值时触发告警
Azure 建议在 Agent 设计阶段就设置"成本护栏"：如果 Agent 在一次任务中 Token 消耗超过 X，自动中断并返回错误。可观测性系统必须实时追踪这个阈值。Expanso 的研究显示，实施 Token 预算管理的企业将 Agent 运行成本降低了 30-50%。
最佳实践六：治理追踪内容
Agent 可观测性会产生大量数据——但并非所有数据都应该被保存。Agent 的输入可能包含 PII（个人身份信息）、商业机密或敏感的内部数据。可观测性管道的设计必须从一开始就考虑数据治理。
推荐做法：
- 在追踪数据离开应用之前进行 PII 脱敏——使用属性处理器（attribute processors）自动识别和掩码敏感字段
- 设置数据保留策略——生产追踪数据保留 30 天，审计相关数据保留 90 天
- 对包含敏感信息的 span 设置访问控制——只有授权人员可以查看原始输入输出
- 在跨 Agent 调用中传递脱敏后的数据，而非原始数据
数据治理不仅是合规要求——它也是成本控制的一部分。Azure 的实践指南指出，来源端（source-side）处理可以减少 50-70% 的遥测数据量。通过裁剪冗余属性、采样低频路径、聚合重复调用，企业可以在保留可观测性价值的同时大幅降低存储成本。
从追踪开始，以账单结束
AI Agent 可观测性不是锦上添花——它是规模化部署 Agent 的前提条件。没有可观测性，企业就无法回答最基本的运营问题：Agent 在做什么、做得好不好、花了多少钱。
Gartner 预测，到 2027 年，没有生产级可观测性的 AI Agent 项目将有 60% 的概率在投产 6 个月内被回滚。这不是因为 Agent 本身有问题——而是因为团队无法诊断和修复问题。
企业应从今天开始建立 Agent 可观测性的基础：从 OpenTelemetry GenAI 标准格式开始，追踪每一步而非只看最终答案，嵌入质量评估而非仅监控可用性，治理数据而非全量保存，衡量成本而非无限消耗。从追踪开始，以账单结束——这才是生产级 Agent 可观测性的完整闭环。