可观测性三支柱——日志、指标、追踪——服务了微服务十几年。但智能体一进生产，老三样立刻开始失焦：一次任务跑四十分钟、跨十几次工具调用，失败的原因可能藏在第三步一段被注入的网页文本里，而你手里只有最后一步的报错堆栈。

一、老三样为什么看不见智能体

微服务的调用链是确定性的：A 调 B，B 查 C，接口固定、失败模式可枚举。智能体是决策驱动的动态调用链——模型每次选不同的工具、传不同的参数，甚至自行决定重试。当调用链本身是模型的输出时，你不观测模型，就等于不观测系统的主干。

第二个盲区是维度。传统 APM 关心延迟、错误率、吞吐；智能体多出几样绕不开的账：token 消耗、单次调用成本、提示词版本、工具返回的实际内容。这些要么不在传统指标里，要么沉在日志深处无法聚合。之前聊过 LLM 网关，网关天然是个采集点——但它只能采到模型调用这一层，工具执行和规划过程仍然在视野之外。

第三是复现问题。传统 bug 拿到输入输出基本能复现；智能体的行为取决于当时的上下文、检索结果甚至采样温度，没有完整轨迹快照，事故根本无法复盘。

二、最小可行的遥测面

别急着上平台，先把数据结构定对。一次智能体任务至少要记下四层：

1. 一条完整 trace：以任务为根 span，下挂规划、模型调用、工具执行三类子 span，层级关系就是因果链；
2. 每次模型调用记全：提示词版本号、输入输出 token 数、延迟、模型版本——这是成本归因和回归定位的依据；
3. 每次工具调用记输入输出：成功路径可以采样，失败与重试路径必须全量；
4. 上下文指纹：检索命中了哪些文档、记忆层注入了什么——行为漂移时这是第一线索。

好消息是标准正在收敛：OpenTelemetry 的 genai 语义约定让各家 SDK 的字段名趋于一致，主流智能体框架也内置了 OTel 埋点，接上就有基础数据。多智能体场景里 trace 上下文还要跨进程传递，否则一条任务被拆给几个智能体后，连「哪一环拖垮了全局」都定位不了。

三、落地时的三个坑

1. 脱敏要在采集端做。遥测采的是模型的原始输入输出，里面全是用户数据。先过脱敏层再出内网，否则可观测性本身会变成最大的泄露面。
2. 采样策略要分层。全量采集的成本可能比智能体本身还贵。常见做法是成功轨迹低采样、失败与高成本轨迹全采，再按 trace 标签动态调整比例。
3. 别只当监控用。遥测数据回流评测才是这套投入的复利：线上轨迹抽样进评测集，跑分才不会和真实分布脱节。评测是离线的抽样，遥测是线上的全量，两套数据对得上，智能体的行为才算真正被管住——之前写过智能体评测怎么测才不自欺欺人，那次聊的是离线这一半，这次是它的线上另一半。

小结

智能体可观测性不是运维的收尾工作，而是可靠性工程的主干。看得见，才谈得上管得住；能回放，才谈得上能改进。把智能体放上生产环境之前，先装好黑匣子——等出了事再补，丢掉的是永远找不回来的证据。

说明：本文为公开资料的整理与评述，信息来源包括 OpenTelemetry 语义约定文档、主流智能体框架的可观测性实践与公开工程博客，数据以各官方原文为准。本文由 AI 辅助整理，不构成技术选型或投资建议。