晚上十点，运营发现推荐 Agent 带来的转化掉了一截。监控看板上一切正常，接口成功率满格，平均响应时间稳定。团队从提示词猜到模型，再猜到上游数据源，第二天仍然没有定论。
这类场景在企业里越来越常见。传统看板能看到用户从哪里进来、在哪一步离开，却解释不了 AI Agent 在中间做了什么判断。结果之前的那段过程，长期是空白的。
一、Agent 可观测是什么
Agent 可观测，指的是通过 Agent 运行过程中产生的结构化数据，推断其内部状态与执行路径的能力。数据主要是三类，追踪链路 Trace、聚合指标 Metrics 与运行日志 Logs。目标很具体，把一次任务从识别意图、拆解步骤、调用模型与工具，到交付结果的全过程，变成可以逐条核对的证据。
判断是否做到，可以用一个问题检验。业务结果不对时，团队能不能指出出问题的是哪一步，以及这一步为什么这样走。能指出，才算看清了过程；只能看到结果，就不算可观测。
要区分两个容易混的概念。评测回答结果好不好，可观测回答结果为什么发生。前者的产出是分数，后者的产出是证据链，两者结合才有优化的方向。
和传统应用监控相比，Agent 场景需要多看的几类信息可以对照下表。
| 传统应用监控关注 | Agent 场景还要看清 |
|---|---|
| 接口耗时与响应速度 | 每一步的耗时，以及首个 Token 的返回时间 |
| HTTP 状态码 | 模型的输入输出内容、工具返回的数据 |
| 服务调用拓扑 | 模型、工具、技能之间的真实调用顺序 |
| 请求量与错误率 | Token 消耗、无效重试与任务完成率 |
二、为什么只有日志和监控，看不清 Agent 的执行过程
传统服务的请求路径基本确定，同样的输入走同样的代码。Agent 不一样，同一次提问可能走出完全不同的路径，多一步少一步都不奇怪。链路更长、路径不固定，这就是监控失灵的起点。
具体表现通常有三类。任务变慢，因为模型调用和工具调用都可能卡在等待上。成本变高，因为上下文被反复拼接，无效重试不断累加。最难处理的是第三类，结果错了但系统没有任何报错。模型会返回语法正确、语义错误的内容，HTTP 状态码不会亮红灯，用户投诉却已经出现。
学术研究给这类问题提供了参考。加州大学伯克利分校的研究团队分析了 7 个主流多智能体框架、1600 多条标注轨迹，归纳出 14 种失败模式，并归入三大类，分别是系统设计缺陷、智能体之间的错位，以及任务验证与终止环节的问题。其中一个关键发现是，不少失败并非源于底层模型能力不足，而是来自系统设计。也就是说，只换更强的模型不一定能解决问题，还需要把执行链路看清楚。
看清链路的另一个难点在归因。宾夕法尼亚州立大学、杜克大学与谷歌 DeepMind 等机构的研究者构建了失败日志数据集，覆盖 127 个多智能体系统。他们测试的自动化归因方法中，表现最好的方法识别出责任智能体的准确率是 53.5%，而定位到具体出错步骤的准确率只有 14.2%，即使引入当时领先的推理模型，也还没达到可实际使用的水平。
这个结论对企业实践的意义很直接。在自动化归因成熟之前，把执行过程记录成人能读懂、机器能处理的链路，是定位问题的前提，而不是可选项。
三、一次 Agent 执行过程包含哪些环节
理解可观测，先要理解一次执行长什么样。常见结构可以拆成四层。最外层是一次会话，中间是 Agent 的规划与决策，再往下是它实际发出的动作，包括模型调用、工具调用与技能调用，最后是结果的交付。每一层对应一个可观测单元，上下层之间通过父子关系连成一条链路。
以一个数据查询任务为例。用户问上周新用户的次日留存为什么掉了，Agent 需要先识别意图，再规划步骤，接着读取指标定义、调用查询工具取数、对比历史区间，最后组织结论并回复。任何一步的判断偏差，都会出现在最终答案里。
| 环节 | 这一步在做什么 | 出问题时先看什么 |
|---|---|---|
| 意图识别 | 判断用户真正想问什么 | 原始提问与识别出的任务描述 |
| 规划与拆解 | 决定分几步、调用哪些能力 | 步骤列表与调用顺序 |
| 模型调用 | 推理与内容生成 | 输入上下文、输出内容、Token 用量 |
| 工具与技能调用 | 取数、执行动作 | 调用参数、返回结果、是否重试 |
| 结果交付 | 组织并输出结论 | 最终回答与引用的数据来源 |
图中展示的就是这种嵌套结构，会话包含 Agent 的决策，决策之下再分出模型调用、工具调用与技能调用，右侧的渐变条表示各环节耗时并不均匀。
要让这些环节串得起来，还需要一套统一的标识。会话编号、Agent 名称与版本、模型名称与版本、工具名称，缺一个都会让链路出现断点。这也是 OpenTelemetry 的 GenAI 语义约定要解决的问题，它用 gen_ai 前缀统一属性命名，例如 gen_ai.agent.name 标识 Agent 名称、gen_ai.conversation.id 标识会话、gen_ai.request.model 标识请求的模型。官方文档显示这些属性已经迁移到独立维护的规范仓库，说明这套约定仍在持续演进。
四、采集哪些数据才能看清每一步
三类数据的分工很清楚。追踪链路回答走了哪条路，聚合指标回答哪类问题在变多，运行日志回答这一次具体报了什么错。只上其中一类，都会留下盲区。
字段层面，以下几条是判断问题绕不开的。
- 模型名称与版本，用来判断问题是否与某次模型切换同步出现
- 输入上下文与输出内容，用来核对意图是否被理解正确
- Token 用量，输入与输出分开统计，用来定位成本结构
- 工具名称、调用参数与返回结果，用来判断数据源是否给出了错误输入
- 错误信息与重试次数，用来识别无效循环
- 每一步耗时与首个 Token 的返回时间，用来区分是模型慢还是链路慢
采集方式上有两条路。自研埋点灵活但成本高，换成别的框架往往要重写一遍。更省事的做法是遵循开放标准，OpenTelemetry 的 GenAI 语义约定定义了统一属性，不同框架与模型提供商的数据能落到同一张表里。在围绕这套约定的落地实践中，Agent 相关操作通常被拆成 invoke_agent、chat、execute_tool 这类可组合的 span，层级关系由父子节点表达。标准化的价值不在于字段整齐，而在于换模型、换框架之后，历史数据仍然可以横向对比。
采集范围需要提前划边界。ThinkingAI 在 SDK 设计中的做法可以参考，默认不采集用户的原始对话内容，对敏感字段做脱敏，对过长内容做截断，同时支持用户拒绝采集、私有化部署，以及采集异常时自动降级。可观测的前提是数据进得来，边界清楚的采集方案才走得远。
还有一点容易被忽略。字段不是越多越好，先确定要回答的问题，再决定采什么。不清楚要用这些数据判断什么，采集出来的只是更贵的日志。
五、怎么从异常信号定位到具体步骤
有了数据，下一步是找问题。路径通常是三层下钻。
第一层看聚合信号。任务失败率上升、长耗时集中在某类任务、追踪链路中出现异常结构、Token 消耗突然波动，这些都是入口。它们只告诉你哪里不对劲，不告诉你原因。
第二层下钻到单次追踪。挑一条典型链路，核对模型、工具与技能的实际执行证据，看它是正常返回、超时，还是返回了内容但不符合预期。
第三层落到具体步骤，把范围缩到一个节点上，再判断属于哪一类偏差。
判断顺序可以固定下来，减少来回猜。先看意图是否被理解正确，再看工具是否拿到了正确数据，接着看上下文是否过长导致无效重试，最后把成本与完成率放在一起看。成本上升如果伴随完成率提升，那是投入换效果；成本上升而完成率下降，才是需要治理的问题。
图中的路径就是这三层，从四个聚合信号出发，进入一条完整执行链路，最后聚焦到出错的那一步。
改完之后还有一步常被跳过，用同一套口径复核效果，确认问题真的被解决，而不是换了个样子出现。ThinkingAI 的做法是把用户行为与 Agent 行为放进同一个分析上下文，再借助观测平台的聚合信号下钻到单次 Trace，核对会话、模型、工具与技能的关键证据，由智能诊断给出问题说明、相关证据和改进建议。这样才能回答一个更实际的问题，一次转化下降，是用户需求变了，还是意图理解、工具调用或内容生成出现了偏差。
六、企业落地 Agent 可观测的四个动作
落地不需要一次做完，按下面的顺序推进，每一步都有可验收的信号。
| 动作 | 具体做什么 | 验收信号 |
|---|---|---|
| 定义任务标准 | 明确一次任务的成功与失败如何判断 | 团队对同一结果给出一致判断 |
| 统一标识 | 给会话、Agent、模型、工具建立可关联的编号 | 能从一次结果反查到完整链路 |
| 接入链路追踪 | 先覆盖关键任务，再补聚合指标与告警 | 出现异常时能在链路里找到对应节点 |
| 同口径复核 | 调整后用相同指标复测并纳入迭代 | 改进效果可比较、可复现 |
四个动作之间是递进关系，前一步的产出决定后一步能不能做，右上角的环形表示复核完成后进入下一轮。
有几个做法需要避开。把日志接进来就当完成了可观测，日志能说明报了什么错，但说明不了为什么走到这一步。只看延迟和错误率，会漏掉语义层面的问题。把可观测完全交给运维团队，会失去业务口径，因为判断一次回答是否偏离业务目标，需要业务和产品一起参与。可观测的价值不在数据堆得多，而在能不能回答一个具体的判断问题。
七、关于 Agent 可观测的常见问题
Agent 可观测和传统应用监控有什么区别
传统监控看系统的健康状况，比如响应快不快、报错多不多。Agent 可观测还要看判断过程是否正确，包括意图有没有理解对、工具调用的参数是否合理、上下文是否被无效内容挤占。前者关注服务是否可用，后者关注任务是否被正确完成。
只靠日志能不能做到可观测
可以解决一部分问题，但很难看清完整路径。日志通常按时间顺序记录，缺少层级关系，遇到多轮调用时很难还原哪一步由哪一步触发。要还原执行路径，需要带父子结构的追踪链路。
采集运行数据会涉及用户对话内容吗
这取决于采集方案的设计。以 ThinkingAI 的实践为例，默认不采集用户的原始对话内容，对敏感字段做脱敏、对过长内容做截断，并支持拒绝采集、私有化部署与采集异常自动降级。企业应在接入前明确哪些数据进入系统、保存多久、谁可以查看。
多 Agent 协作场景怎么追踪
核心是把每个 Agent 的执行放在同一条链路上，用统一的会话标识串联，并记录 Agent 之间的消息传递。这样出现问题时，才能分清是某个 Agent 判断失误，还是消息在传递过程中丢失或变形。
现在的工具能自动定位到出错的步骤吗
还不能完全依赖。公开研究显示，即使是较好的自动化归因方法，定位到具体出错步骤的准确率也只有 14.2%。可用的做法是先让人能读懂链路，再用自动化手段缩小范围，把人的判断集中在少数关键节点上。
小团队的最小可用方案是什么
先做两件事，定义任务成功与失败的标准，把会话、模型、工具的基础标识接进追踪链路。指标与告警可以在这之后补充。先有能核对的最小链路，再谈完整平台，比一开始就追求大而全更容易坚持。
参考资料
- Why Do Multi-Agent LLM Systems Fail，arXiv 2503.13657
- Which Agent Causes Task Failures and When，arXiv 2505.00212
- OpenTelemetry GenAI 语义约定属性说明，opentelemetry.io 官方文档
- 深度解析如何为你的 AI Agent 打造完整的可观测体系，腾讯云开发者社区
