智能体可观测性，指的是仅凭遥测数据就能解释一个智能体在生产环境里为什么这样行动：它做了哪些决策、调用了哪些工具、时间和钱花在了哪里。没有这层能力，智能体运维就只能靠猜，因为压根没有可供诊断的东西。

打开网易新闻 查看精彩图片

多数团队是在上线之后才发现这一点的。原型在演示里跑得好好的，仪表盘上各项服务指标一片健康，用户却开始抱怨。下面这条诊断路径，从整体运行到单个步骤再到背后的依赖，用来拆解五种在生产环境中反复出现的失败模式。

先看运行，再看步骤，最后看依赖

智能体行为异常时，先看整次运行是否反常：是不是太长、太慢、太贵，或者给出的答案和它掌握的证据对不上。然后定位到出问题的那一步。最后再看这一步背后的依赖，比如数据库、接口或推理服务。下面五种模式，基本都能在这三个层面之一被识别出来。

模式一：听起来对，其实不对

设想一个智能体去查账户，因为权限错误拿到空结果，随后却像这个账户没有任何活动一样回答用户。所有请求级指标都是绿的。

这类问题要在步骤层面诊断。要记录每次工具调用是否真正成功，而不是只看调用有没有送达。然后找出那些在失败或空步骤之后仍然给出最终答案的运行。这种组合应当按质量事故处理，而不是当成传输错误。

模式二：永远结束不了的运行

工具反复返回一条没用的消息，智能体就换着措辞一遍遍再问。每次调用都很快、都合法，加在一起却很贵。

这在运行层面会显现出来：运行时长异常、参数相近的重复调用、单次运行成本持续走高。给步骤设预算、对运行时长离群值告警，能把一个看不见的循环变成值班工程师可以处理的事件。

模式三：慢，但谁都没错

智能体响应要十二秒。模型调用占了几秒，检索又占了几秒，下游服务补上了剩下的部分。没有任何一个环节突破自己的阈值。

办法是把每次运行拆成模型时间、工具时间和依赖时间，找出关键路径上的那一环。这也是智能体遥测必须和基础设施遥测打通的地方：拖慢速度的依赖往往是一个常规服务，只有两种视图共享同一条链路，才能把它点出来。

模式四：账单涨得比流量快

上下文在步骤之间不断累积，工具结果被完整回传，同样的查询反复执行。用量看着没变，花费却在上升。

要按智能体、工具和调用方分组，查看每一步的输入规模和工具结果的大小。体积最大的那些工具输出，往往是最容易削减的部分。

模式五：没人能复现的故障

用户报告了一次失败。工程师用同样的输入重放，却得到了正确答案。模型输出会变，工具数据会变，而且没人记录当时用的是哪个模型、哪版提示词、哪版工具。

解决办法是每一步都记录足够的信息，以便重建决策路径，并给每次运行附上版本信息。敏感的提示词和结果，在存储之前应按策略做脱敏处理。

把诊断变成日常运维

发现一次模式是有用的。规模化运营意味着让响应可重复：对模式告警而不是对原始计数器告警，把每起事故路由给负责出错环节的团队，并把智能体行为与底层服务关联起来。

智能体本身也开始参与进来。协助诊断的运维智能体，应当被要求达到它所检查的系统同样的标准：用遥测数据作为证据，自身动作可观测、可审批。使用 Bonree ONE 这类平台的团队，可以在一个地方把智能体运行与应用、基础设施监控放在一起查看，其 Sage AI（一个 AI 运维智能体工作台）则提供了用自然语言在这些数据之上运行运维问答、分析和诊断的入口。

上线前的检查清单

  • 每次运行一条链路，每次模型调用和工具调用各有一个跨度
  • 工具结果与送达状态分开记录
  • 按运行跟踪步骤数、令牌用量和延迟
  • 每次运行附带模型、提示词和工具版本
  • 遥测数据入库前完成脱敏

快速问答

生产环境里的智能体，最先该监控什么？从每一步的工具结果、运行时长、分阶段延迟和单次运行成本入手，这四项能揭示上面大部分模式。

智能体运维和 AIOps 是一回事吗？两者有重叠。智能体运维强调在生产环境中安全地运行智能体，并用智能体协助运维工作，以遥测数据作为证据。