Agent 成本归因与计费工程 2026

一、问题的提出：Agent 时代的成本失控与归属黑洞

2026 年中，主流生产级 Agent 系统已经稳定在每个会话 30-200 次 LLM 调用、平均上下文 30k-200k token 的规模，工具调用链路上外接 SaaS API、向量检索、代码执行沙箱并存。一个中型 B2B SaaS 平台在 Agent 能力全量上线后第 60 天的成本账单上，70% 的 LLM 推理费用来自不到 8% 的会话，但平台无法回答"这 8% 是哪些租户、哪些工作流、哪一轮工具调用造成的"。更糟的是，计费报表只能给出"本月总账单 + 租户维度估算"，无法定位到单次工具调用、单次重试、单条上下文片段的真实边际成本。这种"成本失控 + 归属黑洞"问题，与早期云原生时代 Snowflake / Datadog 在 metering 之前的盲区是同构的。

本文从工程实战角度切入，给出一套 Agent 系统的成本归因与计费工程方案：从 Token 级精确计量、工具调用副作用计费、多租户成本护栏，到与 OpenTelemetry semantic conventions 对齐的可观测性图，再到与 Snowflake/Stripe metering 桥接的产品化闭环。我们不讨论 token 单价的浮动策略，也不展开多模态模型的视觉/语音 token 折算细节（这些是商务问题），本文聚焦如何在生产系统里把"哪一次 LLM 调用、为哪个租户的哪个工作流、产生了多少可计费成本"这件事精确、稳定、可审计地落地。

二、形式化：成本归因的四元组

我们将 Agent 系统的成本归因抽象为一个四元组 $(S, T, A, D)$，其中：

• $S$ 是主体（Subject），即执行 LLM 调用的具体身份：可以是用户、租户、子工作流、子智能体。一次 Agent 运行往往嵌套多个 Subject。
• $T$ 是租户（Tenant），计费的最终付费方。生产中 $T$ 通常通过 API key 维度或 session metadata 注入。
• $A$ 是动作（Action），可计费的最小单元：一次 LLM chat completion、一次 tool call、一次向量检索、一次代码沙箱执行、一次外部 API 调用。
• $D$ 是成本维度（Dimension），包括 token_count（输入/输出）、token_type（text/image/audio/cache_hit/cache_miss）、tool_cost（外部 API 实际收费）、latency_penalty（违反 SLO 时的隐性损耗）、retry_count（重试带来的边际成本）。

成本归因的核心是建立从 $S \times T \times A$ 到 $D$ 的精确映射：每一个可计费的 $A$ 都必须带 $S$ 和 $T$ 标签，任何 $A$ 的 cost dimension 都可按 $S$、$T$ 任意切片聚合。形式化上，对任意时间段 $[t_1, t_2]$，租户 $T_i$ 的账单为：

$\mathrm{Bill}(T_i, t_1, t_2) = \sum_{a \in A, \mathrm{tenant}(a)=T_i} \sum_{d \in D} w_d \cdot \mathrm{cost}_d(a)$

其中 $w_d$ 是维度权重（token 单价、tool 实际收费、SLA 违约罚分等）。生产中的真实挑战不是定义这个公式，而是保证所有 $a$ 在被采集时都携带 $(S, T)$ 标签，且 $\mathrm{cost}_d(a)$ 的计算不被中间件、改写、重试、缓存所扭曲。

更进一步，成本归因的精度是有梯度的：粗粒度归因（"这个租户本月 1000 美元"）仅需在网关层做 token 聚合；中等粒度（"这次会话的哪个 tool call 占了大头"）需要工具层 wrapper 配合；细粒度（"这条 context 里的 RAG chunk 贡献了多少"）需要 RAG pipeline 全程打 tag；极细粒度（"这个 token 位置上的归因"）需要模型的 attention 归因或 surrogate attribution——后者在 2026 年仍属研究前沿，不在本文讨论范围。我们讨论的是生产可落地的"粗 + 中等 + 细"三档归因，对应 99% 的计费争议场景。

三、Token 级成本计量：从 prompt/completion/token-type 三轴精确归因

Token 级成本是 LLM 计费的主战场，但生产中的 LLM 网关（LiteLLM、Portkey、OpenRouter 自建、Cloudflare AI Gateway）普遍只暴露"input tokens + output tokens"两个聚合数字，这种粗粒度无法回答**"这条上下文里是 system prompt 占大头还是 RAG 检索结果占大头"**这类问题。

实战中的最小可行拆解是 三轴拆分：

轴一：prompt vs completion 拆分。这是最基础的，但要确保 completion token 中不包含 reasoning 模型（o1/o3/DeepSeek-R1）的内部 thinking tokens——它们是 cost 但用户感知不到，必须显式标注为 reasoning_tokens 并独立计费，否则账单会和用户预期严重错位。

轴二：context segment 拆分。一段 prompt 通常由 system + few_shot + memory + rag + tools + user_query 拼成，每段对最终回答的边际贡献不同。生产做法是网关层在拼接 prompt 之前给每段打 span tag，例如：

span.input.system_prompt_tokens = 850
span.input.few_shot_tokens = 1200
span.input.rag_chunks_tokens = 3400
span.input.user_query_tokens = 180
span.output.completion_tokens = 240
span.output.reasoning_tokens = 850

轴三：cache 命中拆分。Anthropic prompt cache、OpenAI prompt cache、DeepSeek implicit cache 在 2026 年已经普遍支持，三者的 cache hit token 单价通常比 cache miss 低 60-90%。账单必须显式拆分 cached_tokens 和 uncached_tokens，否则租户无法看到"我用了多少 cache"——而这正是推理降本的关键观察点。

三轴拆分的工程实现核心是 OTel GenAI semantic conventions（详见 pitfall 提到的 OTel 演进）。具体来说，genai.usage.input_tokens、genai.usage.output_tokens、genai.usage.cached_tokens、genai.usage.reasoning_tokens 已经是 v1.30+ 的标准 attribute；context segment 拆分通过 genai.input.messages[N].role + genai.input.messages[N].content 数组形式自然落入。下游计费引擎只需消费 OTel span attribute 即可聚合，不需要在 LLM SDK 里手工打 tag——这是 2026 年 OTel 全面铺开后最重要的红利之一。

另一个工程细节是 reasoning tokens 的"价值折扣"。Reasoning 模型（o1/o3/DeepSeek-R1）的 thinking tokens 单价通常是普通 output tokens 的 3-5 倍，但它们对用户的边际价值未必高 3-5 倍——很多场景中用户根本看不到 thinking 内容，只关心最终答案。生产做法是给 reasoning tokens 打 reasoning.visible_to_user 属性（true/false），计费引擎按"对用户可见度"做价值折扣：不可见的 reasoning tokens 按基础单价的 40% 计入账单。这条机制在 Anthropic 和 OpenAI 的内部架构中都有公开讨论，是平衡"模型能力"和"用户感知成本"的关键工程实践。

四、工具调用计费：副作用成本、外部 API 成本与缓存命中的折扣账本

Agent 的非 LLM 成本往往被严重低估，但实战中能占到总账单的 30-50%。三类典型工具调用需要独立计费：

第一类是副作用工具（写数据库、发邮件、调支付接口）。这类工具的真实成本不仅是 API 调用费，还包括幂等性失败的重试成本、回滚成本、业务侧的失败损失。生产做法是引入"动作成本账本"：每次副作用工具执行前，计费系统预占一笔 escrow（按预计成本 + 30% buffer），执行完成后按实际成本多退少补，失败/超时按 100% 实际成本计费。这个机制最早来自 Stripe 的 payment intent 设计，在 Agent 时代被工程化复用。

第二类是外部 SaaS API（搜索、向量库、CRM、代码沙箱）。这类工具通常按"调用次数 + 数据量"双向计费，工程上需要在工具 wrapper 层记录调用前后的数据量（query bytes、result bytes、embeddings count），并在 cost dimension $D$ 中加入 tool_io_bytes 一项。注意：向量检索要按 query_embedding_count × result_count 双维度计费，不能只算一次 API 调用——这是早期生产中最常见的漏账。

第三类是缓存命中。RAG 的语义缓存、工具结果缓存、prompt 缓存的命中都会带来"折扣"，但工程上必须显式记录折扣金额而非简单记录"未发生调用"。原因很简单：和真实计费系统（Snowflake、Stripe metering）的桥接要求每条记录都是正金额 + 负金额的清晰账目，不能让"什么都没发生"代表"省了多少钱"。生产做法是给每次缓存命中生成一条 cache_hit_credit 记录，金额为该动作如果未命中时的估算成本。Snowflake 的 metering_event 规范允许负值（credit），Stripe 的 Usage Records API 同样支持负值用于退款——这是和商务系统对接时的硬性约束。

另一个常被忽视的细节是缓存未命中的"踩空成本"。一次缓存 lookup 本身也消耗资源（向量检索调用、相似度计算、对象存储读），虽然比 cache miss 后真正执行工具调用便宜一个数量级，但仍是非零成本。生产中的做法是把 cache lookup 也作为一条独立的 metering event 记录，与 cache hit / miss 分三档计费：lookup 成本（最小）、hit 折扣（负值）、miss 后真实成本（正值）。Cloudflare AI Gateway 在 2026 年的公开 case study 中展示了这种三档账本如何让租户看清"我的 cache 配置到底省了多少钱"——他们发现许多租户高估了命中率，实际命中率不到 30%，节省的金额远低于心理预期。账目透明倒逼租户重新审视 cache 策略，这是计费工程给产品带来的二次价值。

五、多租户成本护栏：配额、熔断、突发识别与公平性

多租户 Agent 平台的成本护栏和传统云原生 metering 不同：LLM 调用的边际成本非线性（小模型可能比大模型单次便宜 100 倍，但单次成功率低 30%），且单次用户行为可能引发级联工具调用（一次对话触发 50 次 LLM 调用 + 30 次外部 API 调用是常态）。生产中的护栏必须分四层：

第一层是租户配额。每日 / 每月 / 每分钟的 token 预算和调用次数预算，按租户 SLA 等级（金/银/免费试用）分层。配额检查必须在 LLM 网关入口完成，不能等 Span 落库后异步阻断——否则用户已经在 GPU 上烧钱了。

第二层是熔断。当租户的实时成本超过去年同期 300% 阈值时，自动降级到低成本模型（GPT-4o-mini → Claude Haiku → DeepSeek-V3）。熔断需要滑动窗口聚合（5 分钟粒度），不是简单的累计。注意熔断不能简单按"调用次数"判定，必须按"成本金额"判定——一次 Claude Opus 调用可能顶 100 次 Haiku 调用。

第三层是突发识别。常规护栏容易把正常业务高峰（如月初的报表生成）和真实失控（如 prompt 注入触发的递归调用）混为一谈。生产中要在网关层跑一个轻量级异常检测（基于历史 28 天同租户同时段基线的 z-score），当 z > 4 时触发人工 review。OpenAI 在 2026 年初披露的 abuse detection 内部做法是这条路径的一个公开实例。

第四层是公平性。当平台总配额触顶（如 GPU 集群跑满）时，如何在多租户间公平降级？不能让付费最高的租户独享 GPU（这违反长期公平性），也不能用先到先得（这被早期云厂商诟病过）。生产中的做法是 weighted fair queueing（WFQ）按租户 SLA 等级 + 历史使用率综合打分，详见 id=435 "LLM 推理调度的延迟公平性工程"。成本护栏和公平性调度在工程上是同一个回路：配额决定了"能跑多少"，WFQ 决定了"这么多怎么分"。

还有一个工程细节是配额与成本的"非对称"：配额是硬约束（过了就阻断），成本是软信号（超了不阻断但告警）。生产中很容易把两者混为一谈，结果要么是告警变成阻断（用户体验差），要么是阻断变成告警（成本失控）。正确的做法是把两者解耦——配额在网关入口的硬阻断逻辑里跑，成本在 worker 后台异步聚合，告警通路与阻断通路必须独立部署、互不依赖，否则一处故障会同时影响两条业务路径。Anthropic 在 2025 年公开的 Claude.ai 后端架构中明确提到过这个解耦原则，是 Agent 平台计费工程的常见最佳实践。

六、统一视角：成本归因的可观测性图

成本归因如果脱离可观测性栈，本质是黑箱。我们在前五节零散提到的 OTel span attribute，在工程上需要落成一个 billable observability graph：

[LLM 网关] --emit--> [OTel Collector] --route--> [Metering Sink]
                                                          |
                                                          v
                                              [Cost Aggregation Worker]
                                                          |
                                                          v
                                                [Tenant Bill + Quota Check]

关键设计原则：

1. Span 必须 billable 标记。在 OTel SDK 层给每个 LLM call span 打 billing.relevant = true attribute，下游 collector 据此分流到 metering 通道；非计费 span（日志、调试）不进入 metering。
2. Context propagation 跨进程传递租户。当 Agent 主进程调用子 Agent、调用工具执行器、调用外部 API 时，租户 ID 必须通过 W3C Trace Context 的 baggage 字段透传，不能依赖业务层的 metadata 传递（容易丢）。
3. 重试与回滚的可计费性。一次 LLM 调用重试 3 次，计费应该是 3 次而非 1 次；但最终完成只算 1 次业务结果。这种"尝试成本 vs 实际成本"的拆分在 OTel 里通过 retry.count attribute 表达，下游计费引擎按"尝试成本"计费，按"实际结果"算 SLA。
4. 可观测性图可被产品查询。这是 2026 年与早期 Snowflake metering 的最大区别：产品经理、CS、财务要能直接 trace 到成本根因。生产做法是把 OTel collector 的输出同时路由到 Grafana Tempo（trace）、ClickHouse（聚合）、Stripe Metering（账目），三者用统一的 tenant_id + trace_id 关联。

可观测性图的最大价值是回答"为什么这个租户这个月账单涨了 40%"——能从 trace 链路定位到是 RAG 检索次数增加（context 涨）还是 reasoning tokens 激增（reasoning model 占比涨），而不是一句"LLM 涨价了"敷衍。在 Datadog 的 2025 公开案例中，他们把这条链路做到了生产环境的"7 分钟根因定位"——以前 LLM 账单争议平均需要财务 + 工程 + CS 三方 4 天协作才能定位到租户工作流，OTel 统一可观测性图落地后缩短到 7 分钟，且 80% 的争议可由租户自助在账单页面点击 trace 链接自查解决。这条经验值得所有 Agent 平台借鉴：账单透明度本身就是产品竞争力。

七、工程实践：从计费数据到产品决策的闭环

计费数据的最终消费者是产品决策。我们把闭环拆成六个动作：

1. 账单按租户 SLA 分层展示。金级租户看日粒度账单（含每条 trace 的链接），免费租户看月粒度汇总。粒度差异本身就是产品差异化。
2. 预算告警前置。租户预算到 70% / 90% 时分别触发软告警和硬告警，硬告警可选择自动降级（切到低成本模型）。告警在 agent 每轮结束时检查，不阻塞推理主路径。
3. 成本预测。基于过去 28 天数据用 Prophet / 时间序列模型预测本月剩余成本，预测值超预算 110% 时自动给 CS 推邮件。这个机制在 Stripe、Datadog、AWS 都有公开案例。
4. 成本-价值关联。不是所有 token 都等价——一段对话是用户主动发起的（高价值）还是 agent 主动重试的（低价值）。生产做法是给每条成本记录打 value_signal 属性（用户停留时长 / 任务完成度 / 反馈得分），财务结算时按 value 折扣。
5. 成本 A/B 实验。当平台升级 prompt 模板、切换模型、调整 RAG 检索策略时，要能比较新旧两组的单位任务成本。这要求 agent 框架支持 experiment_id 透传到所有 cost span。
6. 回溯审计。所有 cost span 保留 13 个月（与 Snowflake 默认一致），任何历史账单争议都能从原始 trace 重建。这要求 OTel collector 配置远端存储（S3 + Parquet），不要只走本地的 Tempo。

需要补充说明的是，回溯审计的合规边界因行业差异巨大：金融行业通常要求 7 年留存，医疗行业受 HIPAA 约束需要在审计后删除 PHI（个人健康信息），SaaS 平台则普遍遵循 GDPR 的"被遗忘权"——即租户有权要求删除其历史 metering 数据。生产中的工程折中是双轨存储：完整 trace 数据（含 PHI）保留在受合规管制的对象存储，租户请求删除时物理清除；而脱敏后的聚合数据（仅 token count + 成本金额，无 prompt 原文）保留 13 个月供账目查询。这种双轨设计在 AWS HealthLake 和 Datadog HIPAA 模式中都有公开实例。

这六个动作的工程实现可以放在同一个后台 worker 里（成本聚合 worker），也可以拆成多个微服务。关键是不让成本数据变成"只有财务能看的死表"——它必须回到产品决策循环里。

八、讨论：与现有计费系统的桥接与博弈

最后讨论几个工程上的开放问题：

第一，自建 vs 用 SaaS。Snowflake、Stripe、Metronome、Amberflo 等 SaaS metering 已经成熟，但 Agent 场景的 sub-second 频次（一次会话 50-200 条 metering event）和非结构化维度（context segment、reasoning_tokens）让 SaaS 的 schema 设计面临适配成本。生产中常见的折中是：核心聚合自建（ClickHouse + 自研 worker），最终账单推给 SaaS——既能享受自建的灵活性，又不丢失 SaaS 的发票/对账能力。

第二，LLM 推理成本的不透明性。模型厂商的 input/output token 单价经常调整，且 prompt cache、batch、reserved capacity 有不同的折扣结构。计费系统必须能"模型侧成本对账"——定期（每日）拉取模型厂商的用量明细，与自家 metering 聚合结果比对，差异 > 0.5% 触发对账调查。

第三，隐私与计费的张力。当租户要求"我的 prompt 不能被计费系统看到原文"时，计费系统只能用 token count + 哈希指纹做归因，无法做 context segment 拆分。这是一个产品-工程-法务三方博弈，目前行业共识是默认做 segment 拆分，但租户可付费关闭（接受更粗粒度账单换取隐私）。

第四，成本归因的伦理边界。当发现某租户的某工作流成本失控，是否应该主动告知"你的 prompt 设计有问题"？这种"被告知"是服务还是冒犯？行业目前倾向于只告警不诊断，让租户自己查询——但这条边界会随监管变化。

九、给 SRE / 产品 / 平台工程师的可落地清单

我们把全文要点浓缩为一张可落地的清单：

• SRE 必做：① 把 LLM 网关的 span attribute 与 OTel GenAI semantic conventions 对齐；② 在网关层做租户配额硬阻断；③ 成本异常 z-score > 4 触发人工 review；④ 计费数据 13 个月冷存储。
• 产品必做：① 按 SLA 等级分层账单粒度；② 预算 70%/90% 双告警；③ 月度成本预测超预算 110% 自动推 CS；④ 把"价值信号"接入成本记录。
• 平台工程师必做：① OTLP 跨进程透传 tenant_id baggage；② cache hit 必须产生 credit 记录而非"零成本"；③ retry 计费按"尝试成本"而非"实际结果"；④ 实验 ID 透传到所有 cost span 支持 A/B。
• 架构师必做：① 自建核心聚合 + SaaS 最终账单 的双层架构；② 每日模型侧用量对账（差异 > 0.5% 触发调查）；③ context segment 拆分为默认、隐私敏感租户可关闭；④ 成本异常只告警不自动诊断。

成本归因与计费工程不是"月底财务算账"的边角问题，而是 Agent 平台能不能从"烧钱 demo"走到"自我造血的商业产品"的关键分水岭。它既是工程问题，也是产品问题，更是伦理问题——三者必须在同一个数据基础上协同演化。

一句话摘要：把 Agent 的每一条 LLM 调用、工具调用、缓存命中、副作用执行都纳入带租户标签的可计费可观测性图，是 Agent 平台从 demo 走向商业产品的成本工程分水岭。

参考文献

1. OpenTelemetry. Semantic Conventions for Generative AI. v1.30+, 2026.
2. Stripe Engineering. Metering Usage Records API and Billing Telemetry Architecture. 2025.
3. Snowflake. Metering Events Schema and Aggregation Patterns. 2025.
4. Anthropic. Prompt Caching: Cost Models and Discount Structures. 2026.
5. OpenAI. Batch API and Cached Token Billing Semantics. 2026.
6. LiteLLM. Production Telemetry and Per-Tenant Cost Attribution. 2025.
7. Datadog. LLM Observability and Cost Tracing at Scale. 2025.
8. AWS. Bedrock Token Usage Attribution and Reserved Capacity Reconciliation. 2026.
9. Google Cloud. Vertex AI Cost Management and Quota Enforcement. 2025.
10. Microsoft Azure. AI Content Safety Cost Attribution in Multi-Tenant Workloads. 2026.
11. Cloudflare. AI Gateway Token Accounting and Cache Hit Discount Ledger. 2026.
12. Metronome. Real-Time Metering for Sub-Second Agent Workloads. 2025.