企业官网建设流程全解析

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 设计直接决定了你后面能做哪些分析。我见过很多团队只记录了基本的耗时和状态，结果后面想查“哪个工具调用最频繁”都查不了。以下是我建议至少记录的属性：

这些属性看起来多，但都是实际排查问题时真正会用到的。比如 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 属性里。这样当你排查问题时，不仅能看到模型选了什么工具，还能看到它为什么这么选。这个信息在定位“模型为什么跑偏”时特别有用，比单纯看调用链高效得多。