1. 从五个提问场景看企业客户到底在焦虑什么过去大半年我在不同场合被企业客户问到关于 AI 可观测性的问题频率高到有点出乎意料。有意思的是虽然每次问法都不一样但聊到深处会发现他们真正担心的其实是同一件事。我先把这五种典型问法摆出来你可以对照看看自己或团队是不是也问过类似的话。第一种问法最直接“你们这套 Agent 跑起来之后我怎么知道它有没有在正常工作”这通常来自运维或者平台团队他们习惯了传统服务的监控面板突然面对一个会自己调工具、自己规划步骤的 AI Agent第一反应就是“我看不见它”。第二种问法偏业务“用户投诉说 AI 回答得不对我怎么复现当时到底发生了什么”这是客服或业务负责人问的他们要的不是技术指标而是能还原一次具体会话的完整链路。第三种问法来自成本侧“这个月 AI 调用费用涨了三倍到底是哪个环节在烧钱”财务或者技术负责人会这么问他们需要把成本拆解到具体的模型调用、工具调用和重试次数上。第四种问法偏安全合规“AI 有没有调用过不该调用的工具或者把敏感数据传出去”这是安全团队的口吻他们关心的是行为边界和审计留痕。第五种问法最抽象往往来自高层“我怎么判断这个 AI 系统是可靠的而不是碰巧跑通了几个 demo”这其实是在问可观测性能不能支撑起对系统的整体信心。你看这五种问法表面上分属运维、业务、成本、安全、管理五个视角但底层诉求高度一致他们需要一套能穿透 AI 黑盒的观测能力把 Agent 的每一步决策、每一次调用、每一分花费都变成可查询、可回溯、可告警的数据。这就是 AI 可观测性要解决的核心问题。传统微服务的可观测性有三大支柱——日志、指标、链路追踪这套方法论已经非常成熟。但 AI Agent 不一样它的“执行路径”不是代码里写死的而是模型在运行时动态生成的。同一个输入两次运行可能走完全不同的工具调用链。这就导致传统监控手段直接失效你没法给一个不确定的流程预先埋点。所以我在跟客户聊的时候通常会先纠正一个认知AI 可观测性不是“给 AI 加个日志”那么简单它是一套专门针对非确定性执行路径设计的观测体系。接下来我会把这套体系拆开讲清楚包括它和传统可观测性的本质差异、OpenTelemetry 在其中的角色、MCP 协议带来的新观测点以及实际落地时最容易踩的坑。2. AI Agent 的可观测性为什么不能照搬微服务那一套2.1 非确定性执行路径让传统埋点彻底失灵微服务的调用链路是确定的。A 服务调 B 服务B 服务查数据库这条路径在代码里写死了你只要在关键节点埋点就能画出完整的调用拓扑。但 AI Agent 的执行路径是模型在运行时决定的。举个例子用户问“帮我查一下上个月的销售数据并生成报告”Agent 可能先调用数据库查询工具再调用图表生成工具最后调用文档导出工具但也可能先调用一个搜索工具确认“上个月”具体指哪个月再走后面的流程。更麻烦的是同一个问题问两次模型可能选择不同的工具组合。这意味着你没法像传统埋点那样“预先知道要在哪里打点”。你必须把观测能力做成通用的、与具体工具解耦的机制让每一次模型决策、每一次工具调用都自动产生可观测数据。这就是为什么 OpenTelemetry 这类标准化协议在 AI 可观测性领域变得特别重要——它提供了一套与具体实现无关的数据采集规范。2.2 Agent 的“思考过程”才是观测的核心对象传统监控关注的是“请求进来了没有”“响应时间多少”“错误率多高”。但 AI Agent 的观测重点完全不同你需要看到的是模型为什么选择了这个工具而不是那个它在哪一步产生了犹豫它的推理链里有没有出现幻觉我见过不少团队一开始只监控 API 调用成功率结果发现成功率 99% 但用户满意度很低。原因很简单API 都调通了但模型选错了工具或者推理链中间某一步跑偏了。所以 Agent 可观测性的核心对象不是“接口”而是“决策过程”。你需要把模型的推理步骤、工具选择理由、中间结果都记录下来才能定位问题。2.3 成本维度在传统监控里根本不存在微服务监控很少关心“这次调用花了多少钱”因为计算资源是固定的。但 AI Agent 每一次模型调用都是按 token 计费的而且不同模型、不同上下文长度、不同重试次数成本差异巨大。一个设计不好的 Agent 可能因为反复重试同一个工具调用把成本放大十倍。所以 AI 可观测性必须把成本作为一个一等公民指标。你需要能回答这次会话总共花了多少 token哪个工具调用最贵重试浪费了多少成本这些数据在传统 APM 工具里是完全没有的。3. OpenTelemetry 在 AI 可观测性里的真实定位3.1 为什么是 OpenTelemetry 而不是自研埋点很多团队第一反应是自研一套埋点系统毕竟“不就是记录日志吗”。但实际做下来会发现几个问题第一你需要定义一套数据模型来描述 Agent 的决策链路这个模型要足够通用才能适配不同框架第二你需要处理跨进程、跨服务的上下文传递比如 Agent 调用了一个远程工具怎么把 trace 上下文带过去第三你需要一套标准化的导出协议才能对接各种后端分析平台。OpenTelemetry 恰好解决了这三个问题。它有一套成熟的 Trace 数据模型支持跨进程上下文传播而且有大量现成的 exporter 可以对接主流后端。更重要的是它的语义约定正在逐步覆盖 AI 场景比如 gen_ai 相关的属性定义。你不需要从零设计数据格式直接用社区标准就行。3.2 Span 粒度怎么切才是合理的用 OpenTelemetry 做 AI 可观测性最关键的设计决策是 Span 怎么切。切得太粗你只能看到“一次会话”的整体耗时定位不到具体问题切得太细Span 数量爆炸存储和分析成本都受不了。我的经验是分三层第一层是会话级 Span代表一次完整的用户交互第二层是步骤级 Span代表 Agent 的一次决策循环包括模型推理和工具选择第三层是调用级 Span代表一次具体的模型 API 调用或工具执行。这样切的好处是你既能从会话级别看整体表现也能下钻到具体哪一步出了问题。3.3 属性设计决定了你后面能查什么Span 的 attributes 设计直接决定了你后面能做哪些分析。我见过很多团队只记录了基本的耗时和状态结果后面想查“哪个工具调用最频繁”都查不了。以下是我建议至少记录的属性属性类别具体字段用途模型相关model_name, token_count, finish_reason成本分析和模型对比工具相关tool_name, tool_input_size, tool_status工具调用分析和错误定位决策相关step_index, decision_type, retry_count推理链路还原会话相关session_id, user_id, turn_index会话级聚合分析这些属性看起来多但都是实际排查问题时真正会用到的。比如 retry_count 这个字段我一开始觉得没必要后来发现它是定位“成本异常”最快的线索——重试次数一高成本必然飙升。4. MCP 协议给可观测性带来的新变量4.1 MCP 让工具调用从“内部函数”变成“外部服务”MCP 协议的核心价值是让 Agent 能以标准化方式调用外部工具。但这也意味着工具调用从“进程内函数调用”变成了“跨服务网络调用”。这个变化对可观测性的影响很大你不再能通过简单的函数埋点来记录工具调用必须像监控微服务一样监控 MCP 调用。具体来说你需要记录 MCP 请求的完整生命周期请求发出时间、服务端处理时间、响应返回时间、传输数据大小、错误码等。这些数据对于定位“为什么这个工具调用这么慢”至关重要。4.2 MCP 的流式输出让链路追踪变复杂很多 MCP 工具支持流式输出比如一个搜索工具可能边搜边返回结果。这给链路追踪带来了新挑战一个 Span 可能持续很长时间而且中间会不断产生新数据。如果你等 Span 结束才上报实时性就很差如果边流边上报又要处理数据乱序和部分失败的问题。我目前的实践是为流式调用创建一个长 Span但在流式过程中定期上报“进度事件”作为 Span Event。这样既能保证实时性又不会把 Span 切得太碎。4.3 工具描述本身也需要被观测MCP 工具有一个容易被忽略的观测点工具的描述文本。模型是根据工具描述来决定是否调用某个工具的。如果描述写得不好模型可能该调的时候不调或者不该调的时候乱调。所以我会把工具描述也纳入观测范围记录模型在选择工具时“看到”的描述内容这样当出现工具选择错误时可以快速判断是不是描述本身有问题。5. 落地时最容易踩的五个坑5.1 只记录成功路径忽略失败和重试很多团队一开始只记录成功的调用觉得失败的不重要。但实际排查问题时失败和重试往往才是关键线索。一个工具调用失败后Agent 可能会换一个工具重试这个决策过程如果不记录你就完全看不懂为什么最终结果和预期不一样。我的建议是失败路径的记录要比成功路径更详细。至少记录失败原因、失败时的上下文、Agent 的后续决策。5.2 把可观测性做成事后补丁而不是架构一部分我见过太多团队在 Agent 上线后才想起来加可观测性结果发现很多关键决策点根本没有埋点位置。可观测性必须在 Agent 架构设计阶段就考虑进去比如在决策循环里预留 hook 点在工具调用层统一封装观测逻辑。5.3 忽略上下文传播导致链路断裂当 Agent 调用一个远程 MCP 工具时如果 trace 上下文没有正确传播你看到的链路就是断的Agent 这边显示“调用了工具”工具那边显示“被调用了”但两边对不上。这个问题在跨团队协作时特别常见因为不同团队可能用不同的 trace 系统。解决方案是统一使用 OpenTelemetry 的上下文传播规范在 MCP 请求的 metadata 里带上 traceparent 头。这样无论工具是谁开发的只要遵循同一套规范链路就能自动串起来。5.4 数据量爆炸导致存储成本失控Agent 的观测数据量比传统微服务大得多因为每一步决策都要记录而且流式输出会产生大量事件。如果不做采样和聚合存储成本会很快失控。我的做法是分层采样会话级 Span 全量保留步骤级 Span 按比例采样调用级 Span 只保留异常和慢调用。这样既能保证关键数据不丢又能控制成本。5.5 只看技术指标不看业务指标最后一个坑是最隐蔽的很多团队把可观测性做成了纯技术监控只看延迟、错误率、token 数但忽略了业务层面的指标比如“用户满意度”“任务完成率”“回答准确率”。结果技术指标都正常但业务方还是不满意。我的建议是在可观测性体系里预留业务指标的上报接口让业务团队能把自己的评价数据关联到具体的会话和步骤上。这样才能真正回答“AI 到底有没有在正常工作”这个问题。6. 一套可落地的最小可观测性方案6.1 从三个核心指标开始如果你刚开始做 AI 可观测性不要一上来就追求大而全。我建议先从三个核心指标开始任务完成率、平均决策步数、单次会话成本。这三个指标分别对应业务效果、执行效率和成本控制能覆盖大部分企业客户的核心关切。任务完成率怎么定义可以是用户没有重新提问的比例也可以是 Agent 明确输出“任务完成”的比例。平均决策步数反映 Agent 的效率步数突然变多往往意味着模型在某个环节卡住了。单次会话成本则直接关联到商业可行性。6.2 用 OpenTelemetry Collector 做统一采集采集层建议用 OpenTelemetry Collector它能在数据进入存储之前做过滤、采样、脱敏和格式转换。这样你的 Agent 代码只需要按标准格式产生数据后面的处理逻辑都在 Collector 里配置不用改代码。一个典型的 Collector 配置包括接收 OTLP 数据、按属性过滤敏感字段、按比例采样、导出到后端存储。这套配置可以复用到不同的 Agent 项目上。6.3 告警规则要围绕“决策异常”而不是“系统异常”传统告警关注 CPU、内存、错误率但 AI Agent 的告警应该关注决策异常。比如单次会话决策步数超过阈值、某个工具调用失败率突然升高、单次会话成本超过预算、模型输出被安全策略拦截等。这些告警能帮你更早发现 Agent 的行为异常而不是等到用户投诉才知道出了问题。6.4 把可观测性数据反哺到 Agent 优化可观测性数据的价值不只是排查问题还能用来优化 Agent。比如你可以分析哪些工具调用最常失败然后优化工具描述分析哪些决策步骤最耗时然后调整模型参数分析哪些会话成本最高然后优化提示词减少不必要的调用。我在实际项目里发现持续用可观测性数据做优化的团队Agent 的任务完成率能在两个月内提升 20% 以上。这个收益远比单纯“能看日志”大得多。7. 我在实际项目里的一些体会做了这么多 AI 可观测性相关的项目我最大的体会是这件事的技术难度其实不高难的是认知转变。很多团队习惯了传统监控的思维模式总觉得“加个日志就行了”结果做出来的东西根本回答不了业务方的问题。另一个体会是可观测性必须从第一天就做不能等上线后再补。因为 Agent 的行为太复杂了你事后根本没法还原当时发生了什么。我见过一个团队上线三个月后才想起来加观测结果发现历史数据全丢了只能从头开始积累。还有一点可观测性不是某一个团队的事。它需要 Agent 开发团队、平台团队、业务团队一起参与开发团队负责埋点平台团队负责采集和存储业务团队负责定义什么算“正常”。只有三方对齐了可观测性才能真正发挥作用。最后分享一个小技巧在 Agent 的提示词里显式要求模型输出“决策理由”然后把这个理由记录到 Span 属性里。这样当你排查问题时不仅能看到模型选了什么工具还能看到它为什么这么选。这个信息在定位“模型为什么跑偏”时特别有用比单纯看调用链高效得多。