Token 感知型日志：当你的追踪成本超过其观测的推理成本时

我在上个季度交流过的一个团队花了六周时间追踪其智能体（agent）平台上的内存压力报警。这些智能体的运行成本很低——每次运行只需几美分。但追踪（trace）却不是。他们的遥测流水线消耗的预算是其所监测的 LLM 调用预算的三倍，而且大部分支出都花在了几个月没人看过的字段上：每个 span 上存储的完整 prompt 正文、在父级和子级追踪中重复出现的工具输出，以及一个在每次捕获的追踪上重新支付推理费用的 LLM-judge 评估器。

这是 AI 可观测性成本危机的缩影。一份 2026 年的行业报告模拟了一个拥有 10,000 个对话且每个对话有五轮互动的客户服务机器人——这相当于每天 200,000 次 LLM 调用、4 亿个 token，以及大约 100 万个追踪 span。Datadog 用户广泛报告，在处理其 REST API 的相同后端上监测 AI 工作负载后，可观测性账单飙升了 40-200%。流水线在为同样的 token 支付两次费用：一次是为了生成它们，一次是为了记住它们。

解决方法不是“减少日志”。解决方法是将 AI 系统的可观测性视为一种具有自身单位经济效益的工作负载，与传统服务发出的请求-响应遥测分开处理。传统日志是你可以压缩并遗忘的结构化字段；AI 日志则是无限制的文本正文，每当有人读取它们时，就会重新计入推理预算。这种区别就是“Token 感知日志”的含义。

为什么 AI 遥测具有不同的成本曲线

传统的 API 调用会发出几百字节的结构化日志——请求方法、路径、延迟、状态和少量属性。而单次智能体轮次会发出 1KB 的结构化字段和 10 到 50KB 的文本正文：组装好的 prompt、检索到的文档、工具参数、工具结果、模型的推理追踪（reasoning trace）、助手的回答，而且通常在父级 span 上还会再次出现相同的内容，因为编排层和底层的调用都独立捕获了它。

这种量级的倍增效应已有详尽记录。RAG 流水线和智能体工作流产生的遥测数据是同类 REST 端点的 10 到 50 倍，追踪存储的规模通常比传统的请求-响应流程高出 4 到 8 倍，因为每个用户轮次都会扇出到意图分类、检索、排序、生成和验证——其中每一个都是带有自己输入副本的独立 span。

有两种模式让情况变得比原本更糟。第一种是双重捕获。大多数智能体框架既监测高级别的“用户轮次”追踪，也监测低级别的提供商客户端，导致相同的 prompt 出现在两个 span 上。第二种是重新评估。团队使用 LLM-as-judge 评估器来扫描生产追踪以获取质量评分，而该评估器对它接触的每一个追踪都运行自己的推理。一位 AI 负责人报告称，他们的评估成本是智能体工作负载的十倍。公认的最佳实践比例接近 1:1，但大多数团队并没有衡量这一点，因为评估器运行在与智能体不同的成本中心。

实际后果是，你不能像思考 Datadog 摄取项那样思考 AI 可观测性成本。你必须将其视为第二次模型部署，恰好消耗了你第一次模型的输出作为输入。

追踪即堆：到底什么在花钱

将追踪想象成一个堆分配器（heap allocator）。你附加到 span 的每个字段都是一个长期存在的分配。结构化字段——持续时间、模型名称、prompt token 数、输出 token 数、错误代码、重试次数、延迟百分位——成本微乎其微，索引效率高，且在聚合分析中非常有用。文本正文——完整的 prompt、原始工具输出、检索结果、推理追踪——每个都有几 KB，几乎从未被人类查询过，也是导致你存储层支出翻倍的核心原因。

Token 感知的思维模型将每个字段分为三类。结构化元数据便宜且可查询；在每个追踪上都捕获它。文本正文昂贵且原始形式很少有用；要刻意捕获。可重新推导的信号——情感得分、评委评分、语义相似度——甚至比文本更贵，因为它们需要消耗 token 才能产生，因此它们应该被采样，而不是穷举。

团队犯的错误是将这三类字段同等对待。一个典型的监测库会捕获完整 prompt，因为它“总是在那里”，而团队发布的尾延迟 P99 报警只需要持续时间字段。报警触发是基于持续时间；存储账单却来自 prompt。一旦你查看每个字段的可归因成本，优化方案就变得显而易见：保留结构化字段，正文变为选择性开启（opt-in），而重新推导的信号则基于采样运行。

这也是为什么主要可观测性平台中的 span 大小限制（通常每个字段 256KB）不仅仅是一个性能护栏。它们在暗示该平台并不是为了全保真存储推理输入而设计的。当你的 span 被截断时，那是平台在告诉你，你正在将其作为冷存储用于一种本应具有不同保留层级的工作负载。

用 Prompt 指纹替代完整 Prompt

在冗长的 AI 遥测流水线中，最具杠杆效应的举措就是用 Prompt 指纹（Prompt Fingerprinting）替代完整 Prompt 采集。你不再为每一次追踪都存储组装好的 6,000 个 token 的 prompt，而是存储该 prompt 的哈希值，外加插入其中的变量，以及指向 prompt 模板版本的指针。一个生命周期较短的完整 prompt 样本会被发送到另一个更便宜的存储桶中——比如按百分之一的每日配额采样——以备你确实需要查看发送内容的情况。

成本差异是巨大的。一个 SHA-256 哈希加上几个插值通常不到 1 KB。而对应的 prompt 主体通常要大上 20 到 100 倍。对于上述规模的客户支持机器人工作负载，这种转换能让 prompt 相关的摄取成本从主要的支出项目降至可以忽略不计的零头。

指纹识别之所以可行，是因为 prompt 主体很少是真正的调试信号。当一个智能体（agent）失败时，你几乎总是需要三样东西：哪个模板版本是活跃的、填充了哪些变量，以及模型返回了什么。模板版本来自你的 prompt 注册表；变量是简短且结构化的；模型输出通常是唯一需要完整保留的部分。如果真的需要，你可以通过前两项重新构建 prompt，而在重构不足以解决问题的情况下，你可以调用那些稀有的高保真完整样本。

指纹识别还实现了原始文本无法做到的去重。如果你 30% 的流量都命中了带有相同变量的相同 prompt 模板——这在重度使用工具、频繁使用相似查询重新调用检索的智能体中很常见——你的指纹计数会将这些条目合并为一个带有计数器的条目。这能为你提供有用的信息（该模板处理了三分之一的负载），而无需在追踪存储中存下那 30% 的流量。

关注结果的采样

头部采样（Head sampling）——即保留固定比例的传入追踪——是 AI 工作负载的错误默认选择。它对成功和失败一视同仁，结果导致你拥有数千条无聊的追踪，而真正需要调试的失败案例样本却寥寥无几。正确的默认选择是基于结果的尾采样（Outcome-aware tail sampling）：采集 100% 的错误追踪、100% 的低质量输出追踪以及 100% 的成本异常追踪，然后对成功的追踪进行低频采样。

具体来说，一个关注结果的策略如下所示：

• 始终保留智能体抛出异常、触发工具错误或触发安全过滤器的追踪。
• 始终保留其 token 成本超过工作负载中位数两个标准差以上的追踪。
• 始终保留带有低分评价（由 judge 评估或用户反馈产生）的追踪。
• 对其余部分进行 5-10% 的采样。

这个决策必须在追踪导出时而非摄取时做出，这就是为什么它被称为尾采样（Tail Sampling）——你等到追踪完成并已知结果后，再决定是否保留它。OpenTelemetry 尾采样器支持这种模式，大多数付费平台现在也提供了类似功能。节省的费用会体现在存储账单而非摄取账单上，但对于 AI 工作负载来说，存储通常占据主导地位。

同样的原则也适用于 LLM-judge 评估。对每一条采集到的追踪都运行 judge 评估，会导致某团队报告的那种 10 倍成本比的病态现象。对 1-5% 的分层样本（按用户群组、查询类别和 judge 置信度分层）运行 judge 评估，可以在不为每次交互支付双倍推理成本的情况下，为你提供真正想要的趋势信号。那些能将评估与工作负载成本比维持在 1:1 左右的团队，是将 judge 评估视为采样问题，而非穷举扫描。

留存分层与 COGS 心态

即使经过采样和指纹识别，你仍会有大量的追踪数据，而且其中大部分数据的价值会在几天内迅速衰减。符合这一现实的留存模型是最后一个大杠杆。

行之有效的模式是两层留存。热层（Hot tier）以高保真度保留过去 7 到 30 天的数据——包括结构化字段、采样的主体、judge 评分——用于活跃的调试和告警。冷层（Cold tier）则保留聚合后的结构化字段和 prompt 指纹计数，期限为 90 天或更久，用于成本分析、漂移监控和容量规划。主体数据不会移至冷层；它们在离开热层时即过期。如果调试过程需要旧的 prompt 主体，你只需支付少量的显式重放或重新运行成本，而不是为了永久保留每个主体而支付高昂的常驻成本。

这是需要组织架构转变的部分。传统的观测性通常通过留存时长来衡量——“我们保留 90 天的日志”——因为单条记录的成本很小，而历史访问的价值很高。AI 的观测性必须通过每个活跃用户或每次智能体运行对 COGS（销售成本）的贡献来衡量，因为单条记录的成本大到足以反映在损益表（P&L）上。如果一个团队将他们的遥测流水线视为固定成本的公用设施，他们将不断被账单惊吓；如果一个团队将其赋予单位经济效益指标，他们就能在第一个月发现回归问题。

将 AI 观测性纳入 COGS 的实际效果是，有人需要对成本负责。如果没有这种所有权，默认的结果就是平台团队为了调试某个事故而增加了埋点，账单随之增长，但没人注意到，因为它被打包进了平台费用中，三个季度后财务才会问为什么观测支出翻了一番。有了明确的归因——按智能体功能、按工作负载、按租户划分的遥测成本——发布智能体的团队就拥有了追踪账单的所有权，这是唯一能持续产生合理采样默认设置的结构。

当 Trace 本身就是产品时

这一切都有一个重要的反模式。有些产品本身就是它们的 Trace —— 比如客户通过 Trace UI 进行交互的 Agent 平台，显示逐步推理过程的 AI 编程工具，以及 Trace 本身就是分析对象的评估平台。在这些产品中，Trace 不能被激进地采样，因为 Trace 是交付物，而不是元数据。

对于这类工作负载，答案不是“少打日志”，而是要认识到 Trace 存储已经成为了主数据存储，而不是一个遥测边车，并据此进行构建：为驱动产品的查询建立适当的索引，根据产品需要的持久性进行副本备份，并像对待任何主数据存储一样将其计入产品成本。那些提供固定费率“摄取所有数据”定价模型的工具在这种规模下会让你感到非常痛苦，这就是为什么更成熟的 Agent 平台公司正在构建自己的 Trace 存储，而不是运行在 Datadog 的通用摄取系统上。

如果你处于这种境地，这种转变与十年前日志管理领域发生的转变如出一辙：当你的“日志”变成你的“数据”那一刻，将它们运行在通用的可观测性后端就不再合理了。

下一步该构建什么

如果你的 AI 遥测流水线是随着 Agent 产品自然增长的，那么以下三个具体举措通常在第一个月就能回本：将 Prompt 正文捕获替换为 Prompt 指纹识别加采样的全精度捕获；将头部采样转换为结果感知型尾部采样，让判定模型运行在分层抽样上，而不是全量数据流上；为每个 Agent 运行的遥测成本添加一个单位经济效益条目，并由负责该 Agent 的团队承担。

更大的转变是思维模型。AI 系统的可观测性是它自己的销货成本 (COGS) 条目。Trace 不是免费的，你捕获的正文不是免费的，而在每个 Trace 上运行的 LLM 判定模型相当于支付了两倍的推理账单。一旦团队内化了这一点，优化就会变得显而易见，问题也将不再是“我们如何负担得起这么多日志”，而是“我们到底需要看到什么”。