复合型 AI 系统中的内部结算账本

当 CFO 第一次问“这个助手每月花掉我们多少钱”时，工程团队会给出一个数字。第二次问时，另一个团队会给出不同的数字。第三次问时，财务部门会给出第三个数字，然后有人会打开一个电子表格，尝试从 Span（跨度）中重新推算账单，因为没有人再相信之前的任何答案。就在这一刻，复合 AI 系统（Compound AI System）不再仅仅是一个架构问题，而变成了一个会计问题。

这种故障的形式是结构性的。一个简单的用户请求“总结我上季度的客户反馈”会触发由团队 A 拥有的智能体，它调用由团队 B 维护的检索工具，接着调用由供应商 X 托管的模型，然后通过团队 C 的重排序工具回传结果，而重排序工具又调用了由供应商 Y 提供的另一个模型。一次点击；五个所有者；两张相隔一个月到达的账单。标准的 FinOps 原语——成本中心、分配标签、账号级汇总——是为了切割那些已经拥有稳定所有者的基础设施而设计的。它们无法清晰地组合在一个每次请求都会跨越团队边界的内部调用图中。

《2026 年 FinOps 现状报告》指出，98% 的 FinOps 团队需要对 AI 支出负责，而同一份调查将“对 AI 成本的实时可见性”列为最大的工具缺口。这个缺口并不是“我们看不见账单”，而是“我们无法足够快地看清是账单的哪一部分是由谁产生的，以至于无法在账单寄到之前让任何人改变其行为”。

基于 Span 的归因是唯一能经受审计的账本

依靠 API Key 归因成本的本能是错误的。API Key 映射到的是应用程序，但一个复合 AI 请求并不是一个应用程序——它是一个调用图。如果在 Key 级别进行归因，你只能为每个智能体得到一个“大桶”，而对于该桶内部是哪些工具或子智能体驱动了成本，则完全不可见。

能够生存下来的架构是基于 Span 的归因。每一次 LLM 调用、每一次工具调用、每一次检索步骤都会发出一个 Span，每个 Span 都携带足够的元数据，以便仅凭追踪（Trace）就能重建成本。OpenTelemetry 的 GenAI 语义约定规范了最小值：gen_ai.usage.input_tokens、gen_ai.usage.output_tokens、gen_ai.request.model，再加上一个定价规则在摄取时填充的 gen_ai.usage.cost_usd 指标。成本存在于叶节点 Span 中。父节点不会自动继承任何内容；汇总是一个查询过程。

OTel 规范没有规定的是顶层的归因层。这需要你来设计，并且它必须为每个 Span 回答三个问题：

• 谁发起了此调用？ 主体（Principal）——其意图触发了请求的人类用户或系统角色。
• 谁为此付费？ 成本中心（Cost Center）——通常是拥有智能体的团队，但并不绝对。有时工具团队会承担账单，因为他们拥有与供应商的出口合同。
• 谁授权了导致此结果的链路？ 代调用主体（On-behalf-of Principal）——从父级 Span 传播而来，以便工具团队的成本可以根据是哪个调用智能体触发了他们来进行切分。

这三个标识符是不同的。来自产品 P 的用户可以使用团队 A 的智能体，该智能体调用团队 B 的工具，而该工具向供应商 V 付费。主体是用户，直接成本中心是团队 A 的智能体，代调用链是 A→B，供应商是 V。如果没有这三个标识符，你将无法回答“本月产品 P 在团队 B 的工具上花了多少钱？”——而这正是真正引发预算争夺的问题。

政治博弈面比技术面更尖锐

技术工作是有限的。添加 Header，通过工具调用传播它们，存储带有成本标签的 Span，构建一个可以按任何维度汇总的查询。一个称职的平台团队可以在一个季度内交付这些。

政治博弈面则是内部结算（Chargeback）走向消亡的地方。三种模式会反复出现：

“是你调用的我”辩护。 团队 B 构建了一个搜索工具。团队 A 的智能体每月调用它 200,000 次。团队 B 坚持由团队 A 付费——因为是他们调用的。团队 A 坚持由团队 B 付费——因为他们拥有该工具，选择了供应商，谈判了合同，并且本可以使用更便宜的模型。双方都是正确的。这种未阐明的假设认为成本存在单一的“所有者”，但通常情况并非如此。功能性的解决方案是将变动成本（按次收取的供应商费用）计入调用方，而将固定成本（工具摊销的基础设施和工程负载）计入工具团队。几乎没有人会在第一天就这样做，因为这要求结算账本能够区分每个 Span 的两种成本类型，而大多数账本刚开始时只有一个数字。

“我们从未同意过这个调用量”投诉。 团队 B 根据已知的智能体集合调整了其工具的规模。团队 D 的一个新智能体上线了，流量一夜之间翻倍。团队 B 的供应商账单翻了三倍，因为新智能体每次调用会扇出三次搜索。这是谁的问题？诚实的回答是，内部工具的成本合约是隐性的，而“隐性合约”在 FinOps 领域就是“被推迟的争吵”的代名词。能够生存下来的模式是像对待外部 SaaS 供应商一样对待内部 AI 工具：记录单次调用价格、接入时的预期容量，并在实际值超过预期阈值时发出告警。

“结算币种”不匹配。 团队 A 以带有每月承诺使用折扣的突发计价 API 积分支付给一家供应商。团队 B 按小时计费的预置吞吐量单元（PTU）支付给另一家供应商。团队 C 在内部 GPU 上运行模型，其成本是按某种分配容量单位计算的“摊销基础设施”。向团队 A 结算“Token”是可行的；向团队 B 结算“Token”会掩盖吞吐量承诺；向团队 C 结算“Token”则需要从固定成本池中虚构一个合成的“每 Token 单价”。这没有完美的答案。最不坏的方法是内部统一以单一单位（月底的 USD 等值）进行结算，公布转换规则，让各团队根据其原生供应商的定价进行规划，而账本在月底关闭时进行归一化。

“每 Token 成本”很简单，“每结果成本”才是领导层真正想要的指标。

从业者往往倾向于关注“每 Token 成本”，因为 Token 是可计数的、由供应商标记的，并且能在链路追踪中留存。每 Token 成本是能够呈现在仪表盘上的指标。它也是在第二次董事会会议后，会被高管层面忽略的指标。

原因在于，尽管 Token 成本在下降——模型供应商每年大约会将价格减半——但每个结果消耗的 Token 数量增长得更快，因为复合系统使用了更长的上下文、更多的检索轮次，以及单次解决中更多的工具调用。智能的单位价格正在下降，但一次成功解决的综合成本（all-in cost）却在上升。一个只追踪每 Token 成本的仪表盘会报告“我们正变得更便宜”，而绝对账单却在逐季增长。这就是 Token 成本错觉，财务部门会比工程部门更早察觉到这一点。

真正重要的指标是“每经过验证的业务结果的成本”——即一次“成功”调用的综合成本（包括 Token、工具、基础设施、人工审核），这里的“成功”由你的评估套件（eval suite）所使用的同一套标准定义。构建这一指标需要三个部分：

• 结果归因 (Outcome attribution)。每个用户可见的请求都有一个带有结果标签的顶层 span。标签在请求解决时填充：成功、部分成功、失败、上报至人工。如果没有结果标签，每一次成本汇总都只是“支出的 Token”，而非“花在有效事情上的 Token”。
• 失败成本核算。失败和部分成功的结果仍然需要花钱。真实的“每成功成本”是用总支出（成功 + 失败的 Token）除以成功的次数。这个数字通常是“简单的每 Token 成本乘以每成功 Token 数”计算结果的 2 到 4 倍，它才是决定该功能是否符合单位经济效益的数字。
• 人工参与 (Human-in-the-loop) 成本。当智能体上报并由人工解决时，人工的时间也是结果成本的一部分。大多数账本都会忽略这一点，因为它存在于不同的系统中。这也是随着应用规模扩大而增长、并最能威胁到单位经济效益的成本。

每 Token 成本属于平台团队的仪表盘。每经过验证的结果成本则属于产品团队的仪表盘。这两个仪表盘应该保持一致，但它们回答的是不同的问题，混淆两者会产生最糟糕的内部报告——一种在技术上正确但在运营上毫无用处的报告。

“两个季度的指导性意义”到底意味着什么

最常见的组织演变路径是可预测的。平台团队交付了基于 span 的归因和费用分摊（chargeback）仪表盘。领导层告诉各团队，该仪表盘目前具有“指导性意义”——意味着成本是可见的，但尚未强制执行，没人会因此丢掉预算。团队点头示意，然后无视它，继续发布产品。

两个季度后，一场无关的成本纠纷——通常是某个团队耗尽了云预算——导致 AI 支出仪表盘被纳入财务审查。突然间，“指导性”变成了“追溯性地从你第三季度的预算中扣除”，之前被推迟的政治压力会瞬间爆发。那些在六个月内对仪表盘保持观望的团队现在发现，他们的智能体成本比那些进行了优化的团队高出 3 倍，而他们第四季度的预算已经耗尽。

避免这种情况的模式并不浪漫：首先发布带有“费用展示 (showback)”功能的归因系统（只有可见性，不影响预算）；公布一个至少提前一个季度预警的“向内部结算 (chargeback) 转型”的目标日期；运行一个并行的月份，在此期间将仪表盘的数字与实际的供应商发票进行核对（在上线前将“未标记”的缺口缩小至 20% 以上）；并让团队在费用分摊正式生效前根据费用展示进行优化。费用展示阶段并非一种客气——它是账本的集成测试。在仪表盘上看起来正常的数字，往往在月底供应商发票到达时崩溃，因为发票中包含了仪表盘从未建模的分配类别。

从第一天起就将复合 AI 视为会计系统的团队并没有避免预算争斗。他们只是在数据支持下进行预算争斗，在一个数据值得信任的场合进行，而且他们比那些推迟工作的团队早六个月面对这些问题。

给开发者的启示

如果你的复合 AI 系统在调用图中包含超过两个内部团队的工具，那么账本就不是未来的问题，而是当下的问题，推迟处理就是一种失败模式。最小可行费用分摊架构是包含三个标识符（主体 principal、成本中心 cost center、代表对象 on-behalf-of）的每 span 成本归因、顶层 span 的结果标签，以及用于跨供应商标准化的文档化结算约定。最大可行的架构则在此基础上增加了每个工具的可变成本与固定成本分解、人工参与成本集成，以及公布的费用展示到费用分摊的转换日期。

早在行业在供应商层面解决复合 AI 的单位经济效益之前，公司内部就会在团队层面解决这一问题。谁先建立账本，谁就制定了其他人都要遵循的谈判规则。