4 篇博文 含有标签「cost-attribution」

一个 Agent 运行了。计划步骤（plan-step）崩溃了。工具调用（tool-call）步骤在经历了两次 500 错误重试后，在第四次尝试时成功了。用户得到了他们的答案。

那算是多少个事件？问产品，这是一个事件 —— 用户得到了有效结果，因此转化漏斗统计了一次转化。问 SRE，那是三个失败加上一个成功，底层步骤的错误率是 75%。问财务，那是四次计费推理，两次重试的工具调用，以及大约四倍于产品部门预测的单位成本。每个团队的仪表盘都是正确的。但它们也是不可调和的，一旦有人试图调和它们 —— 通常是在事故回顾期间 —— 他们会发现团队已经基于三个相互矛盾的可信度图景运行了数月之久。

FinOps 团队在一年前推出了 AI 内部计费（Chargeback）。仪表盘非常华丽。每个功能团队都能精确到分地看到上个月的推理账单，平台 PM 的幻灯片展示了 SKU 级别的业务线归因。相比一年前，组织拥有了更多的 AI 功能，但 AI 的质量却变差了。目前还没有人将这两个事实联系起来，但它们其实是同一件事。

用一句话概括这种失败模式：内部计费为推理 Token 定价，却悄无声息地忽略了评估 Token 的定价。因此，组织架构中的每一位 PM 都面临着一个奖励模型升级、惩罚评估规范的激励结构。12 个月后，评估覆盖率在萎缩，而账单却在增长——这与 FinOps 项目最初设想的激励效果完全背道而驰。这并不是仪表盘的漏洞，而是内部计费模型在严格执行其设计逻辑，只是在 AI 领域，源自云成本 FinOps 的设计假设已不再适用。

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

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

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

你的财务团队可以准确告诉你，上个月你在 Anthropic 和 OpenAI 上花了多少钱。你的产品团队可以告诉你，哪些功能的用户点击量最高。但公司里没人能告诉你 Draft-Email 是否盈利，Summarize-Thread 是否应该保留在免费层级，或者新的 Rewrite-Tone 功能是否在单用户成本上蚕食了 Draft-Email 的利润。你拥有两个声称追踪同一笔支出的仪表盘，但它们都无法回答那个真正驱动产品决策的问题。

这就是分配缺口。你按端点（endpoint）测量 Token 支出，因为这是供应商 API 提供的数据。但 /chat 端点服务于 12 个刚好共享同一个提示词模板的功能，“按端点”统计将这 12 个功能全部合并到了同一个细目中。在有人完成将 Token 成本导回至产生成本的功能这一底层工作之前，定价层级、功能权限管理、弃用决策以及“我们要不要发布这个功能？”的讨论，全都只能靠直觉。

这项底层工作并不光鲜。它是请求级标记（request-level tagging）、追踪与遥测数据的关联（trace-to-telemetry joins），以及一种坚决的态度：如果不带成本标签，就不发布任何 AI 功能。将此视为基础设施投资的团队，最终会获得按用户群细分的单功能利润报告。而将其推迟到下季度的团队，最终在 18 个月里只能凭感觉做定价决策，并在事后发现，某个单一客户群在负利润的情况下消耗了一半的推理账单。