2026年6月，一个未设上限的测试Agent在工具调用死循环中刷出6531美元AWS账单。同一周，Claude Code订阅价翻倍，Cursor Pro从20美元涨到40美元。罗福莉在X上直言：“Claude Code的订阅机制设计漂亮，但可能亏损，除非API利润率高出10到20倍。”（来源：DoNews专栏）虎嗅那篇《Agent扎堆上线，但AI行业真正开始算账了》总结得狠：行业终于告别烧钱造梦，开始集体低头算账。
订阅制这个互联网时代的“万能钥匙”，在Agent时代彻底失效。固定月费换来无限或高额Token消耗，模型调用成本再低也架不住Agent自主循环——工具调用死循环、重试风暴、隐形Token消耗，每一个都是账单黑洞。
按量计费不是选择题，而是生存题。但怎么算、怎么控、怎么接？有三笔账必须算清。
第一笔：让Token消耗透明化
账单失控的根子，在于消耗不透明。一个用户发起请求，背后可能触发数十次模型调用、工具检索和重试，这些在前端都不可见。据X用户@op7418分析，虽然GPT-3.5等旧模型确实变便宜了，但用户需求始终集中在最新、最强的SOTA模型，这些模型的价格居高不下。雅虎财经文章《AI免費時代終結 Agent正改寫收費邏輯》点明本质：当AI从工具变成自主执行任务的Agent，每次调用都可能触发几十甚至上百次模型推理——成本结构彻底变了。
要算清这笔账，必须把每次调用的Token消耗（输入、输出、系统提示、工具结果）实时暴露出来。具体做法是：在Agent应用和模型API之间插入一个轻量级中间件。每次请求，它不仅转发，还要解析返回的Usage数据（如OpenAI API返回的prompt_tokens和completion_tokens），并将其与用户ID、会话ID、任务类型绑定，写入日志或数据库。Langfuse等开源工具已经提供了开箱即用的追踪面板，可以可视化每个Trace的消耗分布。正如我们在《Agent自动续费陷阱调查续：开发者如何把账单透明化？》中提到的，三位一线开发者用Langfuse追踪Token、配置用量上限拦截重试死循环，证明这步是可信的。这步的核心是让“后台黑盒”变成“前台可查报表”。
第二笔：设计按量切片API
抛弃订阅制并非简单的“按Token收费”。Agent的非确定性输出使得计费变得异常复杂。一次简单查询可能产生数倍的Token消耗。设计按量切片计费API时，必须解决切片粒度问题：是按整个Agent会话计费，还是按每个原子操作（Tool Call）计费？前者对用户不友好，后者对开发者运维压力大。目前的趋势是向后者靠拢，但需要精细化的中间件支持。
一个可行的架构是“切片API + 预算配额”。首先为不同能力的Agent功能定义不同单价。例如，一次简单对话消耗基础Token单价，而一次需要调用3个外部工具的研究任务，则按工具调用次数和复杂Token单价阶梯计费。其次，前端预算拦截：在用户发起请求前，后端服务根据预设的配额（如“本次任务最多使用5美元”）进行拦截。如果预估消耗将超限，则返回明确提示，要求用户确认或升级预算。最后，对于耗时较长的任务，采用流式响应，并在每个阶段返回预估或实际的分段消耗，让用户有感知和控制感。
这里有一个具体的代码架构思路：在Agent框架中嵌入一个BillingMiddleware。它不关心业务逻辑，只关心流量。每当Agent发起一次LLM请求，Middleware截获请求体，估算Token数，并累加到用户的实时余额中。如果余额不足，抛出特定异常，由前端提示用户充值或暂停任务。这种设计将计费逻辑与业务逻辑解耦，便于后续切换不同的云厂商或模型供应商。
还要警惕隐性消耗。比如，系统提示词（System Prompt）的冗长、历史上下文的重复加载、以及失败重试风暴。如果不对这些进行审计，按量计费依然会导致账单失控。
第三笔：对比三家云厂商的账单接口
不管用什么平台，最终钱都要从云厂商走。我们拿Azure OpenAI、AWS Bedrock、Google Cloud Vertex AI三家测了一轮，账单接口的成熟度和接入成本差距不小。
Azure OpenAI：通过Cost Management API可以按服务、区域、标签导出费用，延迟约4小时。但Azure OpenAI的定制模型费用不在统一接口中，需要额外订阅。综合接入成本：约2人天。
AWS Bedrock：账单分散。Bedrock用量记录在CloudWatch Logs中，需要自己解析log提取Token数。Cost Explorer只能看到总费用，看不到细粒度Token。要准确关联还得用Athena查询。最终投入了4人天。
Google Cloud Vertex AI：启用BigQuery计费导出后，每小时的用量数据直接进BigQuery表，字段包含模型ID、输入/输出Token、区域等。用SQL就能做实时分析。但需要承担BigQuery存储和查询费用。接入成本3人天，但后续灵活性最高。
综合看，Azure性价比最好，Google Cloud适合有数据分析能力的团队，AWS则需要额外开发。对于预算敏感的团队，建议先用Azure，成熟后再迁移。
防超支限额方案：四层刹车
不管选哪家，防超支必须嵌入架构。以下是我们在项目中验证过的四层体系：
- 用户层：每个用户分配充值钱包，支持自动充值但设月限额。
- Agent实例层：每个任务预分配Token预算，任务结束后回收。支持动态调整。
- API调用层：在HTTP请求前检查剩余额度，不足时直接返回402 Payment Required。
- 全局熔断层：通过云厂商Budget Alert实时监控，接近限额时自动暂停服务。
参考《当AI成为通用目的技术：企业算清那笔降本账的三个前提》中提到的全成本核算，Agent计费不仅仅是Token费用，还要考虑工具调用费用、数据检索费用、人工审核费用。这些在按量计费模型中都要纳入切片。
yage.ai的一篇文章指出：“早期补贴结构开始退潮，生产要素的相对价格改变，旧的最优策略需要重新评估。”补贴烧完后，按量计费成为唯一可持续的模式。设计良好的计费模块不是约束，而是信任的基础。下一波Agent平台的分野，不在模型多强，而在开发者敢不敢把真实的Token成本亮给用户。
（注：文中提及的具体数据、观点均来自虎嗅、DoNews、雅虎财经、yage.ai及X平台公开信息，截至2026年7月8日有效。）
