什么是 agent 可观测性，它为什么重要？2026 年 4 月 20 日

什么是 agent 可观测性，它为什么重要？

AI agent 打破了传统可观测性赖以建立的假设。本文讲清楚有哪些变化、你需要捕获什么，以及为什么它是评估、可靠性和成本控制这一切之下的基础。

“可观测性”不是新词。后端工程师手里有 trace、指标和日志已经十来年了。所以当团队开始交付 AI agent 时，一个很自然的第一反应是：我们已经有了 Datadog / OpenTelemetry / Prometheus，为什么还需要别的东西？

简短的回答是：agent 工作负载打破了传统可观测性所默认的那些假设。你确实可以把一个常规的 APM 挂到 agent 上拿到 一些 东西 —— 延迟、错误率、几行日志 —— 但你会错过那些真正决定”agent 能不能持续工作”的东西。这篇文章会讲清楚那些东西是什么、为什么它们不一样，以及为什么 agent 可观测性最后会成为评估、可靠性和成本控制都依赖的基础。

传统可观测性的预设

经典的应用可观测性建立在一组在过去算是合理的假设之上：

  • 程序是 确定的：相同输入产生相同输出。
  • 执行路径是 狭窄的：一次请求每次大致命中相同的服务序列。
  • 失败是 响亮的：异常、非 200 的状态码、堆栈跟踪。
  • 调试的基本单位是 日志行：grep 一下日志、找到错误、修掉它。
  • 每次请求的成本是 可预测的：可以基于历史流量做容量规划。

agent 把这些每一条都打破了。

跑 agent 时哪些假设崩了

非确定性。 同一个用户输入不会产生同一条执行路径。两次对同一 prompt 的运行可能调用不同的工具、检索不同的文档、得出不同的答案。延迟直方图能告诉你系统慢，但告诉不了你 这一次具体的运行 为什么跑偏。

分支式、自决式的控制流。 agent 在运行时决定要做多少次 LLM 调用、要伸手去拿哪个工具、要不要反思和重试。“这次请求花了多久？“是传统 trace 能轻松回答的问题。“agent 在放弃前做了多少步推理，哪一步产生了幻觉？“则不是。

静默的失败。 agent 通常不会崩溃。它产出一份看上去没问题但其实是错的输出。一条幻觉出来的引用、一段被记错的用户偏好、一次参数看似合理实则编造的工具调用 —— 这些都没有堆栈跟踪。可观测性系统必须把它们浮出来，因为没有别的东西会做这件事。

不透明的状态。 一个不平凡的 agent 会跨轮携带状态：对话历史、scratchpad 记忆、向量库的检索结果、被反馈回来的工具输出。最终的输出是所有这些的函数，没有看到这些状态，重现一个 bug 基本是不可能的。

不可预测的成本。 每次 LLM 调用都有可变的 token 成本。每次工具调用都可能命中付费 API。agent 决定再循环一次是一个单请求的成本决策，不是一个容量规划的决策。如果你不能在 trace 级别归因成本，你就控制不了它。

agent 可观测性实际捕获什么

从传统可观测性到 agent 可观测性的迁移，本质是一次 原语 的迁移。你不再用 span + 日志去思考，而是开始用一次运行内部的结构化、有语义类型的步骤去思考。

Litefuse 数据模型 把它组织成三层：

  • Observation 是一次运行内部的单个步骤 —— 一次 LLM generation、一次工具调用、一次检索、一次 agent 到 agent 的交接。它们是有类型的：一个 generation 不是一个 toolcall，因为你关心的字段是不一样的。完整词汇见 observation 类型。
  • Trace 把 observation 组织成一次逻辑请求。一个 trace 就是”用户让 agent 规划一次旅行”—— agent 为回答这个问题所做的一切都活在一个地方。
  • Session 把 trace 组织成一次多轮对话或工作流，这样你能看到跨轮的漂移，而不仅仅是单轮内部的样子。

在此之上，一个 agent 可观测性系统还会捕获一些通用型 APM 原生看不懂的东西：

  • Agent graph —— 一次运行在子 agent、工具和决策节点之间到底是怎么分支的可视化呈现。你不再读瀑布图，而是开始读推理的形状。
  • Token 与成本跟踪 精确到每个 observation，这样你能看到是哪个 agent 的哪一步在烧预算。
  • Session 用于多轮上下文，因为大多数真实 agent 是对话式的。
  • MCP tracing —— 对你 agent 与之通信的 Model Context Protocol 服务的可见性，它正在迅速成为标准 agent 表面的一部分。
  • 采样、脱敏、环境 —— 在不泄漏 PII、不被数据量淹没的前提下，把这套东西在生产规模上真正跑起来所需要的运维原语。

而且因为这一切都建立在 OpenTelemetry 之上，你不会被锁死 —— 同一份 trace 可以同时发到 Litefuse 做 agent 级分析，也发到你现有的 APM 做基础设施关联。

它为什么重要

agent 可观测性不是产品跑通之后才加的”锦上添花”。它是另外三件事赖以构建的衬底。

1. 它是调试非确定系统的唯一方式

当一个 agent 给出糟糕的答案，问题不是”日志里有没有异常”。没有。问题是：是什么样的决策序列产生了这个输出？ 那个序列只有在你把每个决策都捕获为结构化 observation 时才看得见。没有 trace，调试就只能退化为盯着一个输入和一个输出去猜中间发生了什么 —— 而这正是无法扩展到一两个工程师以上的工作方式。

2. 它是评估的反馈闭环

评估驱动开发（在 配套文章 里有更详细的讨论）依赖一股稳定流回数据集的真实生产 trace。离线实验的好坏取决于它跑的数据集，而数据集的好坏取决于它是从哪些生产 trace 构建出来的。可观测性正是让这条流水线变得可能的东西 —— 每一条 trace 都是候选的测试用例，每一条糟糕的 trace 都是候选的回归测试。把可观测性这一层切掉，整个评估闭环都会饿死。

3. 它是大规模下控制成本与可靠性的方式

agent 一旦进入生产，两个数字就开始变得非常重要：每次用户交互的成本，以及静默出错的速率。两者都是 agent 级的问题，不是基础设施级的问题。每个 observation 的成本跟踪让你看清是哪个子 agent 或哪个工具在流血。trace 级别的打分 —— 通过 在线评估 —— 让你能在质量回归刚刚出现在流量里时就抓住它，而不是等客户来抱怨。两件事都不是单靠经典指标就能拿到的。

结论

传统可观测性回答的是：系统在不在线，跑得多快？ 这些问题对 agent 依然有效 —— 但它们是最小、最不有趣的那一类。一个 agent 团队每天真正需要回答的问题是：

  • 为什么 这一次具体的运行 产生了 这一份具体的输出？
  • 哪些步骤正在生产里静默地失败？
  • 哪些 prompt、模型或工具在随时间变差？
  • 每一次用户交互在花我们多少钱，钱花到哪儿去了？

agent 可观测性就是为回答这些问题而构建的工具品类。对认真对待可靠性的团队来说，它不是可选项 —— 它是其它一切之下的那一层。

如果你想看得更深，可观测性文档 会带你过一遍完整的数据模型以及构建于其上的各项特性。

这个页面对你有帮助吗？
支持