AI 功能计费是一个没人预先规划的工程问题

微软的 Copilot 发布时讲了一个清晰的故事：每用户每月 30 美元，生产力倍增。但实际的账单却丑陋得多。一旦将企业基础许可证成本、每个活跃用户的算力成本以及支持运维开销合并计算，微软每个用户每月亏损超过 20 美元。财务部门没有立即发现这个问题，因为这些成本挂在基础设施预算下，而不是产品损益表里。工程团队知道 Token 账单数额庞大，但没有人把这两条线连接起来。

这正是大多数 AI 团队在构建产品时不知不觉埋下的计费问题。这不是定价策略问题——那是产品决策。这是一个工程问题：你没有任何基础设施来衡量 AI 功能在每个客户、每个功能、每个请求粒度上的实际成本，而任何定价模式的运转都需要这种精度。

传统 SaaS 定价为何在 AI 面前失效

按席位定价假设成本随用户线性增长。AI 立刻打破了这个假设。

对于传统 SaaS 产品，重度用户和轻度用户的服务成本大致相同。存储和算力相对于收入来说很便宜，所以差异并不重要。但对于 AI 功能，一个重度用户触发的智能体工作流所消耗的算力，可能是轻度用户单次查询的 50 倍。而你把他们定价为完全相同。

按查询定价解决了线性问题，但制造了一个采用问题。Salesforce 在 Agentforce 上吃了苦头。以每次对话 2 美元计算，CFO 们很快算出：五名支持智能体处理典型一天的工作量将产生每月 2 万美元的费用。采用率停滞——不是因为产品不好，而是因为不可预测性本身成了障碍。当客户无法预测支出时，他们根本不会消费。Salesforce 在十八个月内迭代了三种定价模式，才找到能够奏效的方案。

更深层的问题在于：智能体是非线性消费者。一个用户请求可以串联规划、工具选择、执行、验证和响应生成——每一步消耗 Token，每一步都是变量。"顺畅路径"可能花费 0.02 美元，而一个触发两次重试循环和三次工具调用的模糊请求可能花费 0.40 美元。你无法提前知道某个请求会走哪条路径。这使得任何静态定价模式都成了对用户实际行为分布的一场赌博。

你实际需要构建的东西

AI 功能的成本归因栈有三个不同的层，而大多数团队至少缺少其中两个。

事件摄取层位于系统中每个 LLM 调用的前面。每个请求——聊天补全、嵌入、智能体步骤、工具调用——都流经一个单一的计量点，记录原始用量：输入 Token、输出 Token、缓存 Token、模型、延迟，以及一组自定义标签（用户 ID、会话 ID、功能名称、团队）。这一层需要能够处理生产系统的吞吐量，并在不显著增加请求路径延迟的情况下写入持久存储。像 LiteLLM 这样的代理可以处理多提供商环境，将 OpenAI、Anthropic 和 Bedrock 的 Token 计数规范化为统一格式。

定价引擎将原始事件转换为成本，使用当前提供商费率。这听起来很简单，直到你需要管理跨多个提供商的多个模型——每个都有不同的输入/输出定价、缓存折扣和不时更改的阶梯结构。引擎需要在提供商成本之上叠加你的利润率，并支持你向客户开放的定价结构——用量阶梯、积分、硬性上限、超额费率。

计费与报告层将成本转化为账单，并让客户了解其消耗情况。这里的工程挑战是构建既足够快以支持实时仪表板、又足够精确以生成账单的系统。这两者有不同的一致性要求。仪表板可以容忍几分钟的延迟；账单不行。

从头构建这个栈通常需要三到六个月的专注工程投入。在遗留平台上尝试构建的公司往往在初始构建完成后，仍需将 25-40% 的持续工程资源用于计费相关工作——数据管道维护、定价配置、对账作业。

工程团队忽视的利润率计算

大多数工程团队不考虑毛利率。那是财务团队的问题。但 AI 改变了技术决策与单位经济学之间的关系，使其成为工程问题——不管你是否愿意。

核心问题在于：传统 SaaS 公司的毛利率在 80-90%，因为服务新增用户几乎没有成本。AI 公司的毛利率在 50-60%，因为每次功能调用都有实际的、不可忽视的成本。这种差距随着功能规模扩大而复利叠加。

以下是一个简化版计算，值得在发布任何 AI 功能之前运行：

取功能的平均每次调用成本（你需要计量层才能知道这个数字）。乘以每用户每月预期调用次数。除以你的定价。如果该数字超过 0.4，那么你的功能在规模化时很可能是利润率为负的。

微软的例子：以每用户每月 30 美元的 Copilot 定价，一个每天运行五次大量编码查询的用户仅算力成本就约为 20-30 美元。该功能定价时假设平均使用量会低得多，但事实并非如此。发现它有价值的客户恰恰是大量使用它的人——而大量使用代价高昂。

这种模式反复出现：构建 AI 功能，观察到活跃用户喜欢它，目睹活跃用户产生活跃成本，发现功能处于亏损状态。财务团队在工程团队本可提前六个月发现的时候才察觉。

防止这种情况的检测手段并不复杂，你需要：

• 从第一天起追踪每次调用的成本，而不是在注意到账单峰值之后
• 按功能和用户群体细分，而不仅仅是聚合数据
• 在发布前而非发布后计算盈亏平衡阈值
• 将每用户成本趋势作为监控指标，与延迟和错误率并列

智能体系统颠覆了简单的成本模型

上面所说的一切都假设是单步 LLM 请求、成本可预测。智能体完全打破了这个假设。

当智能体失败需要重新启动时，它已经执行的每个 LLM 调用都要重新来过。失败的智能体运行成本不是零——而是失败前所有已执行步骤的全部成本。在多智能体系统中，一个用户请求可以触发子智能体生成、并行工具执行和协调轮次。生产中的多智能体部署消耗的 Token 预算，通常是等效单智能体实现的 3-5 倍。

非确定性延伸到了成本本身。同一个用户提示，发送两次，可能经由不同的推理路径执行，成本差异显著。来自测试环境的平均 Token 数是危险的财务模型输入。"不顺畅路径"——模糊输入、重试、推理循环——可能花费顺畅路径的五倍，而不顺畅路径往往集中在你最复杂（通常也是最有价值）的用户身上。

在这种环境中管理成本，需要在执行路径中强制执行，而不仅仅是事后报告。存在于仪表板中的预算对失控的智能体工作流毫无作用。有效的控制需要在多个层面同时运作：

• 成本预算：每个工作流执行的实时货币硬性上限
• Token 预算：防止失控提示的每请求限制
• 步骤预算：强制终止前的最大工具调用或推理迭代次数
• 时间预算：防止卡住的工作流无限期累积成本的挂钟时间限制

执行点与限制本身同样重要。在调用模型之前运行的检查——在生成智能体步骤之前、在触发工具之前——可以防止成本超支。事后运行的检查只能报告超支。

优秀的成本归因是什么样的

一旦你有了计量基础设施，有用的问题就不再是"这个月 AI 花了多少钱？"——而是"哪些功能、哪些客户、以什么利润率，趋势朝哪个方向？"

回答这个问题需要在摄取时给每个事件打上足够的上下文标签，以便之后切片分析数据：功能名称、用户群体、请求类型、会话 ID。这些标签在查询时成本为零，而事后重建却极其昂贵。

可持续运营 AI 功能所需的三份报告：

按功能的利润率趋势：随时间变化的每次调用成本，按功能细分。这可以捕捉到随着使用模式演变或模型价格变化而悄然陷入亏损的功能。发布时盈利的功能，六个月后随着活跃用户使用模式的转变可能变得不再盈利。

每客户成本画像：哪些客户相对于他们的付费金额，让你付出最多的服务成本？在 AI 环境中，重度用户往往是能获得真正价值的客户——他们通常也是成本最高的。理解这种细分既能为定价层设计提供信息，也能指导支持优先级。

重尾成本分析：第 95 百分位的请求成本是多少？对于智能体而言，每次请求的成本分布可能有很重的右尾。少数请求可能消耗中位数的 20 倍。理解尾部能告诉你定价是否能吸收异常值，或者是否需要硬性上限。

基础设施生态系统正在追赶

Stripe 收购 Metronome（为 OpenAI 和 Anthropic 运行基础设施的基于用量的计费平台），标志着市场的走向。专用的 AI 计费基础设施正在成为标准产品类别，而不是每家公司都需要从头构建的东西。Stripe 的 Token 计费产品原生支持 LLM 用量的实时事件摄取、提供商价格同步和账单生成。

开源层也有类似的覆盖：LiteLLM 处理跨提供商的代理级计量；LLM 追踪的 OpenTelemetry 扩展标准化了事件模式。计量的原始基础设施已经存在；大多数团队缺乏的是组织决策——从第一天起就将成本归因视为一等工程关切，而不是在第一次意外账单峰值出现后才开始的追溯性项目。

Token 价格正在下降——过去三年每年约下降 10 倍。这种趋势有助于提升利润率，但并不能消除问题。每 Token 成本降低，但当智能体工作流将每次用户操作的 Token 数量成倍放大时，成本依然会积累。随着模型变得更便宜，市场预期 AI 功能也应该更便宜，将通缩效应传导给客户，而不是作为利润空间留下来。

那些构建持久 AI 业务的团队，是先构建成本可见性，然后才构建定价模式的。不是因为他们有更好的商业直觉——而是因为他们有更好的监控手段，能真正看清正在发生的事情。

在没有成本归因的情况下构建生产 AI 功能，不是一种工程捷径。这是承诺在账单到来之前不去了解功能是否在正常运作。