大多数企业 AI 团队是在测试和生产环境之间发现 token（词元）成本问题的：第一张真实账单到账的时候，没人能说清它为什么这么高。查询本身很直接，提示词（prompt）很短，但账单反映的东西要大得多。这是因为 prompt 只占实际计费内容的一小部分。
拿一个直白的问题来看："某地区过去三个月买过这款产品的客户里，哪些最可能复购？"回答它可能需要一次地理空间查询、一次交易记录查询和一次机器学习预测。在数据割裂的企业环境里，智能体必须从多个系统取数，再把结果拼起来。每一次交接都会增加上下文、处理过程和 token 。当数据割裂或结构糟糕时，智能体 会重试、重新组织问题、做校验，而每一次尝试都和其他调用一样计费。
除了这次请求本身，智能体还会发送对话历史、元数据、检索到的上下文、工具输出、校验逻辑和重试指令。这些东西都不出现在输入框里，但全都会被 token 化。缓存能打折一部分，但没有哪部分是免费的。上下文还会累积，每多一份文档或一次先前交互，都会跟着后面每一次调用一起走。在长时运行的工作流里，你真正付费的是累积的上下文，而不是那条 prompt。
如果从一张结构良好的表里直接取数，这个问题就是针对少量上下文的一次模型调用。而作为一个横跨四个系统的智能体，它变成十几次甚至更多次调用，中间包含规划、三次各自携带结构元数据的检索、两次因为连接键不匹配而触发的重试、校验、综合，而且每一次都带着累积的上下文一起走。最终你得到的是同一个答案，但消耗的 token 多了一到两个数量级。这个倍数有多大，取决于工作负载以及智能体需要做多少对账。它的量级是架构本身的属性。
其中一部分增长是真正的回报，也就是那些在过去需要分析师花几个小时、根本不会有人去委托的工作。陷阱在于剩下的那部分，它包含为了得到一个系统本来用十分之一的调用次数就能得到的答案而花掉的 token，或者把同一个答案得出两遍所花掉的 token。这两笔都会出现在同一张账单上。
这个场景很熟悉。它和十年前的云成本问题高度相似。按用量计费让支出难以预测，而成本往往要在采用规模已经铺开之后才变得可见。如今这笔支出已经大到足以迫使董事会层面做决策。Uber 在 4 月就花完了整个2026 年的 AI 预算，主要驱动因素是 Claude Code 的采用，重度个人用户每月花费高达 2000 美元。Amazon关掉了一个追踪员工 token 用量的内部排行榜，并指示员工不要再"为了用 AI 而用AI"。Gartner 预测到 2027 年底，超过 40% 的自主智能体AI 项目会被取消，成本不断攀升是原因之一。
注意这些案例的共同点：没有一个是数据本身的硬问题。编程智能体面对的是一个源码仓库——单一语料、结构一致、集中在一处。如果在这样的条件下成本都能变成预算级问题，那么企业数据分析是更难的场景，因为在那里智能体还必须自己找出数据在哪里、对不一致的结构做协调、在结果校验不通过时重试。
在云成本上管得最好的那些组织，都是早早就在可见性、治理和架构上做了投入。
如何在源头降低 token 成本？
降低 AI 成本最有效的策略，是从一开始就少用 token，而这要从架构开始。有四项值得优先推进的做法：
审计：找出 token 实际花在了哪里，而不只是哪些团队花得最多。有用的拆分维度是按功能来分（规划、检索、校验、重试、综合），因为它能告诉你，你是在为答案付费，还是在为"寻找答案的过程"付费。大多数团队从来没测过这个。
减少数据移动：尽量减少智能体从互不连通的系统里拼接信息的需要。每一次抽取、转换、重新组装，都是 token 消耗增长的机会。
改善数据与上下文质量：扎实的元数据、治理和一致的定义，意味着更少的失败尝试、更少的重试和更低的成本。从价值最高的工作流开始，改善它们所依赖的东西。
优化上下文投递：不是每一条信息都需要送到模型面前。检索过滤、摘要、缓存和上下文压缩，都能削减单次调用中随行传递的内容，而且这些都不需要改动底层系统。
以上这些都不主张为了省 token 去重建数据平台。数据平台整合是一项多年期的工程，有自己的预算，对于一个每月在 AI 上花五位数美元的团队来说，它的花费会超过它省下的 token 成本。这里的关键点是时机：自主智能体工作负载目前还小到可以测量，围绕它们的决策目前改起来还很便宜。这两点都不会持续太久。
在账单到来之前就开始
把数据架构当成一项成本决策，而不是背景条件。现在就审计你的 AI 使用情况，找出成本最高的工作流，然后问一句：你的数据层，是不是让智能体干得更费力。
