Agent 追踪采样：当 “记录所有内容” 耗费 8 万美元却依然漏掉性能退化时

账单在 3 月份寄达。仅追踪（traces）一项就花费了 8.1 万美元，而 11 月时这一数字仅为 1.2 万美元。团队在 10 月份启用了全量 Agent 追踪，理由是可见性越高越好。到了第一季度，可观测性成本的增速已经超过了推理成本——而当生产环境真正出现性能回归（regression）时，包含故障的追踪记录却被淹没在两千万个无人问津的成功 span 中。

错误并不在于决定进行埋点。错误在于将请求追踪（request-tracing）的心智模型引入了一个行为完全不像传统请求的工作负载中。

一个典型的 Web 请求会生成一个包含少量子节点的 span 树：处理器、数据库调用、缓存查找、下游服务。而一个 Agent 请求生成的树包含 5 个 LLM 调用、3 个工具调用、2 个向量查找、中间草稿（scratchpads），以及一个重新审视其中 3 个步骤的规划器。同样适用于 API 网关的采样策略——头部采样（head-sample）1%，保持其余部分的代表性——在 Agent 场景下会产生一个追踪存储库，其中中位数追踪是拥有 200 个 span 的怪物，长尾效应才是唯一关键的部分，而你发现故障的频率与你花钱的频率完全无关。

为什么请求级采样对 Agent 不再奏效

Span 树的大小是首要问题。分布式追踪团队在典型工作负载中测得的追踪量大约是日志量的五倍。Agent 工作负载的情况要严重一个数量级——从业者估计，一个 RAG 管道产生的遥测数据是一个等效无状态 API 调用的 10 到 50 倍，而多步 Agent 会进一步加剧这一情况。在现有追踪设置之上采用 AI 工作负载监控的团队，通常报告其可观测性账单增加了 40–200%。

成本只是问题的一半。更深层次的问题是，基于头部的采样——大多数 APM 工具默认的“在追踪起点做决定”模型——是为这样一个世界设计的：每个成功的追踪看起来都和其他成功的追踪差不多，因此 1% 的成功样本在统计上等同于 100% 的全量样本。Agent 追踪打破了这一假设。一个耗费了 11 次工具调用和 3 次规划器修正的成功 Agent 运行，与一个耗费 2 次工具调用且零修正的成功运行是不可互换的。它们都通过了评估。从聚合数据看，它们都表现良好。但当下周的 prompt 变更意外增加了规划器的循环倾向时，其中一个将成为故障模式。

另一种故障模式更糟糕。包含实际性能回归的追踪——比如工具返回了令人困惑的错误，模型将其解释为用户指令，导致 Agent 进行了未经授权调用的稀有路径——根据定义就是稀有的。如果你以 1% 的比例进行头部采样，你每一百次才会保留一次该追踪。在它发生的其他 99 次里，你只看到指标上升了 0.001 个百分点，却没有任何现场（artifact）可供调查。

尾部采样、成本层级采样与混合默认模式

在 OpenTelemetry 的尾部采样指南中已有详尽记载的成熟模式是：延迟采样决策，直到获得完整的追踪信息，以便策略可以保留“有趣的”追踪并丢弃“常规的”追踪。对于 Agent 而言，“有趣”需要三个视角，而不仅仅是一个。

始终追踪失败路径。 任何工具返回错误、模型产生了不该有的拒绝、安全过滤器触发或策略引擎干预的追踪——全部保留。这些追踪会被用于事故回顾、评估集构建和红队分析。数据量很小，相对于它们的价值，边际存储成本几乎可以忽略不计。Datadog 的默认设置反映了这一点——它们在代表性成功预算之外，保留每秒固定额度的错误追踪（默认为 10 个左右），并允许你将高价值事务标记为 100% 保留。

对成功路径进行头部采样。 常规的成功运行不需要 100% 存储。对枯燥的成功运行进行 1–10% 的头部采样，可以为你提供用于 SLO 计算、仪表板汇总和流量形态分析的总量基准。OpenTelemetry 在这里的建议很直接：在 tracer 的 SDK 端进行头部采样可以在发生任何昂贵开销之前减少传输量，这种损失是统计学上的，而非类别上的。

按成本百分比进行尾部采样。 传统尾部采样捕获的信号——延迟异常值——对于 Agent 是必要但不充分的。成本是一个平行的维度，且通常更有用。耗时 23 秒的追踪很有趣；但因为规划器循环而消耗了 1.40 美元 token 的追踪更有趣，因为 token 成本是捕捉推理循环失效和工具滥用的信号，而仅凭延迟可能会错过这些（快速的循环依然很贵）。配置尾部采样器，使其在保留延迟异常值的同时，保留单次请求 token 支出高于第 95 和第 99 百分位的追踪。这两个分布相关但不相同，而隐藏在其中的间隙——高成本、低延迟——正是 prompt 回归隐藏的地方。

在架构上更有用的框架是，这不再是一个采样决策，而是三个策略的组合。OpenTelemetry collector 的尾部采样处理器原生支持策略组合——string_attribute、latency、numeric_attribute 和 status_code 策略可以在配置中进行“与”（AND）和“或”（OR）操作。大多数团队会采用混合模式：在 SDK 端进行轻量级头部采样（约 50% 或更多）以限制网络出口流量，然后由网关 collector 对剩余部分应用尾部策略。

无人预料到的存储难题

运行这三项策略，存储费用就不再与流量成线性关系。它变成了错误率、成本分布形态以及标记为全量保留的业务关键路径百分比的函数。这是件好事——这意味着成本是随着信息价值而增长，而不是随着原始 QPS（每秒查询率）增长。但这也更难预测，会让财务团队措手不及。

在这里，decision_wait 参数是至关重要的操作控制项。OpenTelemetry 指南建议将其设置为你 p99 追踪延迟的 2–3 倍，因为来自下游慢服务的 span 可能会在采样决策之后才到达，从而导致追踪不完整。Agent 追踪的 p99 延迟可能长达数十秒，因此 30–90 秒的 decision_wait 窗口很正常。这意味着 collector 会进行 30–90 秒的内存中 span 缓冲，这使得 collector 本身成为了关键组件——如果它在窗口期中途崩溃，你会丢失该缓冲区中的所有追踪，包括错误追踪。多位实践者的文章指出，这就是那个令人意外的隐患：尾部采样（tail sampling）将可靠性问题转移到了观测基础设施的上游。

存储分层问题是下一个层面。热存储用于错误和高成本追踪（秒级查询，保留 30–90 天），温存储用于代表性的成功案例（分钟级查询，保留一周），冷存储用于原始遥测数据（已压缩，保留至监管机构或评估团队需要的时长）。供应商的定价模型与这种分层并不完全匹配。Langfuse 按“计费单位”（billable unit）收费——这是追踪、span 和评估分数的总和，其中包含一个自动评估的 10 个 span 的追踪大约消耗 12 个单位。Arize 根据 span 数量和原始 GB 计费。LangSmith 按追踪计费。在中等规模（每月 5000 万个 span）下，根据你的追踪碰巧加载的维度，供应商之间的成本差异可能会在任何方向上产生一个数量级或更多的偏差。

自托管的经济账已经发生了足够大的变化，值得在 2026 年重新计算。在 4 核/16GB 节点上运行的开源追踪栈（Langfuse、Phoenix、OpenObserve）每月只需 50–80 美元的计算成本，就能处理每天 500 万个 span；而带有 NVMe 的 8 核/32GB 节点可以处理 1000 万个以上。对于在 AI 追踪托管观测上月支出已超过 5000 美元的团队来说，自托管的盈亏平衡点比以前更近了，而且运维成本主要由 SRE 团队承担，而不会直接占用 AI 工程师的预算。

成本激增的失败模式

在这种情况发生在你身上之前，有一种尾部采样失败模式值得了解。如果你的采样策略保留了所有超过某个延迟或成本阈值的追踪，而你经历了网络事件或供应商降级，导致大量追踪同时超过该阈值，你的追踪导出器会将它们一次性全部转储到存储后端。账单会激增。实践者报告中描述过，由于上游提供商的延迟翻了三倍，而尾部采样器忠实地保留了每一条当时异常的追踪，导致一个糟糕的下午就产生了数千美元的意外费用。

缓解措施是限制尾部采样器在任何滚动窗口中允许保留的追踪百分比。OpenTelemetry collector 在导出端支持速率限制；通过配置它来限制你的最坏情况账单。合理的默认设置类似于：“保留 100% 的错误、100% 的成本异常，并在任何一小时窗口内最多保留总追踪量的 5%——其余的则丢弃并发出警告。”这样在保留事故调试价值的同时，也为账单设定了上限。

运维纪律

三项纪律区分了那些从 Agent 追踪中获得价值的团队和那些只得到账单的团队。

采样策略是配置，而不是代码。它需要是可评审的、受版本控制的，并且无需部署即可调整。collector contrib 的尾部采样处理器是可通过 YAML 配置的；像对待任何生产配置一样对待该策略——评审差异、对变更发出警报、记录回滚流程。

追踪存储是评估集的来源。保留每个错误追踪的最有力论据是，这些追踪会成为你下一次评估迭代中的负面示例。丢弃了 99% 失败案例的追踪存储，也就丢弃了 99% 的评估素材。当你考虑到在标注流水线中从头重建每条追踪所需的成本时，花钱保留错误追踪的经济账看起来就完全不同了。

“单位正确性的成本”（Cost-per-correctness）是正确的衡量单位。挂钩采样策略最有效的指标不是“每美元产生的 span 数量”，而是“每美元追踪存储解决的事故数量”。建立该仪表板的团队 tend to 发现，他们价值最高的支出是始终开启的错误追踪保留和成本百分位尾部数据；其余的支出则见仁见智。

架构上的认知

Agent 可观测性 e 并不是一个具有更高基数乘数的请求追踪问题。这是一个不同的存储问题，具有不同的信号与容量比例、不同的成本分摊面，以及保留内容与调试能力之间不同的关系。 “日志记录一切”的条件反射是无状态服务直觉告诉你要做的。它产生了一个维护成本高、查询速度慢的追踪存储，并且遗漏了包含实际事故的长尾追踪。

转变是从“采样即成本控制”到“采样即内容精选”（sampling-as-curation）。你保留的追踪应该是未来的你想要的——失败的、成本异常的、在规划器中路径异常的运行——而你保留的常规成功运行的数量只需足够计算聚合健康状况即可。按这种方式配置策略，将 collector 视为生产基础设施，限制最坏情况下的账单，那么那个八万美元的“惊喜”就会变成一个你的事故响应团队真正会使用的价值一万五千美元的工具。