企业 AI Agent 事故中，模型问题只占 35%——剩下 65%，是工程层面的可观测性缺失。
这是 Gartner 2025 年调研里最让工程师沉默的数据。团队花三个月调优 Prompt，把准确率从 82% 提升到 91%，然后上线，然后——没有人知道 Agent 在生产环境里什么时候会”卡住”，为什么会”想错”，以及哪一步调用了错误的工具。
AI Agent 可观测性不是”加几个监控仪表盘”那么简单。它是一套完整的工程体系，涵盖 Tracing 链路追踪、Metrics 指标采集、Logs 日志记录三大支柱，是 DevOps 工程师和 AI 平台团队在 2026 年必须掌握的核心能力。
为什么传统 APM 不够用
传统 APM（应用性能监控）的核心假设是：系统行为是确定性的——给定相同输入，相同代码路径，总是返回相同输出。
AI Agent 打破了这个假设。同一个 Prompt，同一个模型，每一次 LLM 推理都是一次随机采样。输入不变，Agent 的工具调用序列可能不同，推理路径可能不同，最终输出可能不同。传统 APM 的”请求→处理→响应”线性模型，无法描述 Agent 的多分支推理行为。
可观测性（Observability）的概念因此被引入 AI 领域：在不依赖预先已知故障模式的前提下，通过系统外部输出推断其内部状态的能力。 对于 AI Agent，这意味着你能通过 trace 和 metrics 反推 Agent”在想什么”——即使它从未按你预期的方式运行。
AI Agent 可观测性三大支柱
Tracing：追踪 Agent 的推理链路
Tracing 是 AI Agent 可观测性的核心。它记录 Agent 一次完整任务执行中的所有关键事件：用户输入 → LLM 推理调用 → Prompt 片段 → 工具选择 → 工具执行结果 → 下一轮推理。
一个典型的 Agent trace 包含以下 span：
User Input: "查询本月销售额超过 100 万的客户列表"
├── llm.reasoning (span: "reasoning-step-1")
│ └── content: "用户需要销售数据，需调用 CRM API..."
├── tool.call (span: "crm_api.query")
│ └── args: {filter: "sales > 1000000"}
│ └── result: [客户A, 客户B, 客户C]
├── llm.reasoning (span: "reasoning-step-2")
│ └── content: "已获取结果，需格式化输出..."
└── final_response: [格式化后的客户列表]这条 trace 的价值不只是”看到结果”，而是能回答任何事后问题：如果第三步推理失败了，是 LLM 幻觉了工具名，还是工具本身返回了错误数据？
OpenTelemetry（OTel） 是当前 AI Agent tracing 的标准方案。CNCF 2026 年报告显示，采用 OTel 标准的 AI 监控栈企业占比已达 41%。LangChain、AutoGen、LlamaIndex 等主流框架均已提供 OTel exporter 支持。
Metrics：设定 Agent 的 SLO
Metrics 是量化 Agent 行为的指标集合。与 tracing 不同，metrics 回答的是”Agent 系统整体表现如何”，而非”某一次执行发生了什么”。
AI Agent 关键 Metrics：
| 指标 | 定义 | 典型 SLO 目标 |
|---|---|---|
| 请求成功率 | Agent 成功完成任务的比例 | ≥ 95% |
| LLM 推理延迟 | Prompt → First Token 的 P99 | ≤ 3s |
| 工具调用成功率 | 工具 API 返回 2xx 的比例 | ≥ 98% |
| Token 消耗速率 | 每小时消耗的平均 token 数 | 监控告警阈值 |
| 循环调用率 | 单任务内工具循环调用占比 | < 5% |
告警设计：建议使用多级告警——WARNING（超过 SLO 的 80%）→ CRITICAL（超过 SLO 的 95%）→ INCIDENT（低于 SLO）。避免告警疲劳，聚焦真正影响用户体验的指标。
Logs：审计与合规的最后一道防线
Logs 是最细粒度的可观测性数据，也是满足中国监管合规要求的关键。
《深度合成管理规定》和等保 2.0 要求 AI 系统具备完整的操作审计能力。对于 AI Agent，Logs 需要覆盖：
- 每次 LLM 推理的完整 Prompt（敏感数据需脱敏处理）
- 工具调用的输入输出
- Agent 最终决策及其依据
- 异常场景的完整上下文
日志留存规范：等保三级要求日志留存至少 6 个月，建议生产环境 Agent 日志保留 1 年以上。存储成本需纳入运维预算——单个生产级 Agent 每日产生 2–8 GB trace 数据。
OpenTelemetry 在主流框架中的实战配置
以 LangChain 为例，植入 OTel tracing 的最小化配置：
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
# 初始化 OTel Provider
provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-collector:4317"))
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)
# LangChain Agent 自动使用全局 tracer
from langchain.agents import initialize_agent
agent = initialize_agent(
tools, llm,
agent="zero-shot-react-description",
tracer=trace.get_tracer(__name__)
)配置完成后，所有 Agent 执行链路自动导出到你的 OTLP 兼容后端（Grafana Tempo、Jaeger、阿里云 ARMS 等）。
国内工具链方案对比
| 方案 | 优势 | 劣势 | 适合场景 |
|---|---|---|---|
| 阿里云 ARMS + OTel | 全托管，与阿里云生态深度集成，SLA 保障 | 成本较高，数据出境合规需单独评估 | 已在阿里云部署，预算充足 |
| Grafana + Prometheus + Tempo（私有部署） | 开源可控，数据不出境，灵活扩展 | 运维成本高，需专人维护 | 数据敏感度高，自建能力强的团队 |
| 商业 SaaS（Helios、Syncsort） | 开箱即用，支持主流 LLM 平台 | 数据出境，合规风险 | 海外业务为主，暂不考虑国内合规 |
| 自研 + OTel | 完全可控，定制化能力强 | 开发周期长，重复造轮子 | 大厂有专属 AI 平台团队 |
国内企业 78% 倾向使用阿里云 ARMS 或 OpenTelemetry + 私有部署组合（艾瑞 2025 企业调研）。对于数据敏感行业（金融、医疗、政务），私有部署几乎是必选项。
等保合规审计的日志设计
等保三级测评对 AI Agent 日志系统有明确要求：
日志记录完整性：需记录所有 AI 生成内容的完整上下文，含用户输入、Agent 推理过程、最终输出。任何日志字段不可事后修改。
日志访问控制：日志记录权限与日志查阅权限必须分离。普通运维人员可查阅监控仪表盘，但无法接触原始 Prompt/Response 内容——等保三级要求原始日志只能由安全管理员调取。
脱敏要求：涉及个人信息的用户输入需在日志阶段完成脱敏处理。建议在 OTel Exporter 层统一处理，而非在业务代码中分散处理。
等保测评对接建议：
- 选用通过等保三级认证的日志存储产品（如阿里云日志服务企业版）
- 在 Agent 框架层统一接入，不要让每个业务线各自记录日志
- 至少提前 3 个月启动等保测评流程，Agent 合规整改周期比传统系统更长
从告警到修复的闭环
再好的监控体系，如果告警没人响应，就只是成本。
建立 AI Agent 故障复盘机制：
P0 故障（Agent 完全不可用）：立即通知，15 分钟内响应，当日出具故障报告。
P1 故障（SLO 降级超过 20%）：工作日 2 小时内响应，形成事件记录（Incident Record），分析根因并提交修复方案。
P2 故障（偶发异常）：纳入周度运维 review，持续出现三次则升级为 P1。
故障报告模板需包含：故障时间线、触发条件、root cause 分析、短期缓解措施、长期修复方案、下次预防计划。
Action Checklist
立即执行（1 周内）
- [ ] 在现有 LangChain/AutoGen Agent 框架中接入 OpenTelemetry exporter，验证 trace 数据可导出
- [ ] 识别当前 Agent 系统最关键的 3 个 Metrics（建议优先：请求成功率、LLM 推理延迟、工具调用错误率），配置多级告警
- [ ] 评估现有日志系统是否满足等保三级对原始 Prompt 的留存要求
中期规划（1–3 个月）
- [ ] 搭建统一的 Agent 可观测仪表盘（建议使用 Grafana + Tempo），覆盖所有生产环境 Agent
- [ ] 制定 AI Agent SLO 体系，明确各业务线的可用性目标
- [ ] 对接等保三级测评机构，提交 Agent 日志系统合规评估报告
- [ ] 建立 Agent 故障复盘机制，纳入运维 SOP
结论
三条落到行动清单的结论：
- 模型问题只占 35%，但最容易背锅：在没有 trace 的情况下，LLM 的每一次”奇怪行为”都会被归咎于模型——但很可能是工具 API 超时或 Prompt 解析错误。Trace 让责任归因准确。
- 国内合规要求让日志设计变成必答题：等保三级不只是”通过测评”，而是”日志设计不合格 = Agent 系统不合格”。从第一天就把合规纳入架构设计，而非事后补救。
- 2026 年 AI Agent 可观测性工程师缺口 1:8：这是国内目前供需比最失衡的 AI 工程岗位之一。团队提前建立可观测性能力，既是工程竞争力的体现，也是吸引人才的加分项。
想系统了解 AI Agent 从 POC 到生产环境的完整工程路径，可以参考我们的 2026 年 AI Agent 落地实战：从概念到规模化的转折之年。
你的团队是否已建立 AI Agent 可观测性体系？ 联系 Spotech 团队，获取专属的 Agent 监控架构评估与 OTel 接入方案。