Agent 流水线的分布式追踪：为什么你的 APM 工具形同虚设
你的 Datadog 仪表盘一片绿色。Jaeger 链路看起来干净整洁。P99 延迟符合 SLA。而你的 Agent 流水线正在悄无声息地因重试死循环每天烧掉 4000 美元，却没有触发任何一条报错。
传统 APM 工具是为微服务设计的——确定性路径、有界载荷、可预测的扇出。Agent 流水线打破了所有这些假设。执行路径在运行时才能确定。工具调用深度变化剧烈。一次"请求"可能跨数分钟产生数十次 LLM 调用。而当出了问题，失败模式通常不是异常——而是一个悄然膨胀成本和延迟、却返回看似正常输出的静默重试级联。
结果是一代工程师在盲目飞行，信任着那些衡量错误事物的仪表盘。
为什么标准 Trace/Span 模型会失效
经典分布式追踪之所以有效，是因为服务具有稳定的契约。一个 POST /api/orders 请求总是经过相同的三个服务，顺序不变。你预先定义 schema，对偏差设置告警，然后万事大吉。
Agent 流水线不是这样运作的。一次用户查询会触发一个计划-执行-观察循环，其中迭代次数、调用的工具集、分支决策全部由模型在运行时自主决定。你无法对一个静态调用图进行插桩，因为根本不存在静态调用图。
Agent 工作负载的若干特性会击穿 Span 构建时的假设：
非确定性控制流。 相同的输入在不同的运行中会产生不同的执行链路。周二成功的工具调用可能在周三超时，触发三次重试和一条在预生产测试中从未存在过的降级分支。
无界载荷大小。 在多轮工作流中，上下文会不断累积。一个有 10 步、系统提示 4000 个 token、平均工具输出 500 个 token 的 Agent，仅仅因为上下文传递，在最后一次 LLM 调用时就已携带超过 40000 个输入 token——这还不算任何输出生成。传统 Span 假设载荷有界。
无错误传播的嵌套重试。 这是最危险的失败模式。工具返回一个瞬态错误。Agent 以相同方式重试。同样的错误，同样的重试，再来三次。没有任何异常抛给调用方。用户看到的是 45 秒延迟而不是 15 秒，LLM 账单增加了三倍——但你的错误率仪表盘依然是零。
循环检测盲区。 当 Agent 进入循环——反复以相同参数调用同一工具——标准链路只会显示莫名其妙的延迟增长。经典追踪里没有"此 Span 是同一操作第 N 次重试"的内置概念。
专用 Agent 可观测性真正需要什么
缺失的原语分为四类。
Token 预算追踪作为一等指标。 Token 数量对 Agent 的意义，就像内存使用量对传统服务的意义——一种有限资源，其耗尽会导致静默劣化。正确的可观测性栈应实时追踪输入 Token、输出 Token、缓存 Token 和每条链路的成本。更重要的是，它追踪每次成功的成本，而不是每次请求的成本。一个重试三次才成功的流水线，其每次成功成本与一次就能成功的流水线截然不同，即便两者在简陋的仪表盘里都显示为单次"请求"。
工具调用延迟作为有类型的 Span。 每次工具调用都应该被捕获为一个结构化 Span，包含：输入参数、输出数据（或错误）、耗时，以及重试次数。这让你能够区分"LLM 本身慢"和"工具调用的外部 API 慢"——这两种情况在优化时至关重要。它还能让你将工具错误率与下游成本峰值关联起来。
模型版本作为高基数维度。 大多数生产 Agent 流水线同时运行多个模型——一个廉价模型用于路由和分类，一个能力更强的用于推理，可能还有第三个用于综合。每一个延迟指标、错误率和成本计算都需要按模型版本拆分。当一次模型升级发布后 P99 延迟翻倍，你需要立即知道劣化是在路由层还是推理层。
重试次数和循环计数作为显式字段。 这些不应该从重复 Span 中推断，而应作为每条链路的一等数值字段浮出水面，让你可以直接查询："显示所有 retry_count > 2 的链路。"这个查询是排查成本峰值时最有用的单一操作。
三个预判 Agent 劣化的指标
长期运营生产 Agent 的团队最终都会收敛到相同的三个早期预警信号。这三个信号都会在用户察觉之前变得可见。
Token 膨胀率。 追踪每条链路的中位数和 P95 输入 Token 数量随时间的变化。Token 膨胀几乎总是提示词漂移、上下文累积 bug 或意外重试循环的第一个可观测症状。如果你的中位数输入 Token 在没有对应功能变更的情况下周增 20%，那就是出问题了。这在质量劣化触达用户前数天就可以测量到。
工具错误率峰值，而非整体错误率。 Agent 流水线会在内部吸收工具错误——这正是重试逻辑的意义所在。但工具错误率（重试前的错误，而非重试后）是下游 API 不稳定的领先指标。当某个依赖开始抖动，工具错误率会立即飙升。成本和延迟随后跟上。用户可见的失败最后到来。监控重试前的工具错误率，让你有窗口期提前干预。
