AI智能体的成本爆炸问题
那个Pull Request只有三行代码。 团队中的一个开发者更新了一个依赖。包装库将其默认模型从gpt-4o-mini改为了gpt-4-turbo。代码编译通过。每个测试通过。CI流水线全部绿色。PR在周五下午被合并。
周一早上，有人打开了API仪表盘。
每日消耗率跳涨了10倍。
不是10%。是十倍。这个变更已经上线72小时了。没有人注意到，因为没有任何东西损坏。系统运行良好，甚至更快，因为新模型响应更自信。日志显示零错误。延迟指标正常。从他们拥有的每一个运营信号来看，系统都是健康的。
账单讲述的却是另一个故事。
今年我已经从不同的团队、不同的模型、不同的规模听到了无数次这个故事的变体。我想直接说一件事：这不是一个关于粗心大意的故事。合并那个PR的开发者是胜任且谨慎的。团队在监控。他们有测试。他们有代码审查流程。
他们没有的是将成本作为一等工程关注点。而在2026年，这个差距正在成为团队可能犯的最昂贵的错误之一。
1、没有人警告过你的悖论
让这件事真正令人困惑的是这个。AI推理的成本正在急剧下降。
- Epoch AI的分析显示，等效性能里程碑的每token推理价格每年下降9倍到900倍。
- GPT-4发布时每百万输入token为30美元。GPT-4.1今天以2美元提供可比的推理能力。
- Claude Opus 4发布时每百万token为15美元。Opus 4.6便宜67%且能力显著更强。这个趋势是持续且真实的。
然而企业AI推理账单却在爆炸。
AI推理成本现在占企业AI预算的85%，三年前还只是其中一小部分。企业AI平均预算已从2024年的每年120万美元增长到2026年的700万美元。
一些财富500强公司报告每月AI推理账单达数千万美元。
如果我们用一句话总结这个悖论：智能的成本在下降。部署智能的成本在飙升。
理解为什么是解决这个问题的前提。
2、摧毁你预算的五种机制
我看到的每一个AI账单冲击都可以追溯到以下五种机制中的一种或多种。它们相互叠加。它们在测试期间全部不可见。它们恰好在产品增长时——你最不希望它们出现的时候——发难。
机制一：免费层幻觉
你的试点运行在供应商补贴的信用额度上。你的团队可能没有追踪哪些成本是信用额度、哪些是以完整生产费率计费的——这意味着你用来预测生产成本的基线在结构上被低估了，有时低估5到10倍。
当你转入生产计费时，第一张账单不是一个峰值。它才是现实。峰值是你拿来对比的那个人为偏低的试点数字。
修复方案：在任何生产部署之前，以完整生产费率重新定价试点中的每个API调用。基于这个数字而非信用补贴的数字建立你的财务模型。
机制二：智能体乘数
这是造成最大损害的机制，也是获得最少关注的机制。
一个简单的聊天机器人每条用户消息进行一次LLM调用。智能体不是。一个单一的用户意图——"研究这个主题并写一份摘要"——可以触发规划、工具选择、多次工具执行、验证、错误处理和响应生成。这一个用户行为消耗的token是直接聊天完成等效结果的20到30倍。
一个修复单个bug的编码智能体可能在规划、文件读取、代码编辑、测试和验证过程中消耗50,000到200,000个token。DataRobot将一个复杂的智能体决策周期基准测试为每次0.10到1.00美元。在大规模下，算术很快成为一个严重问题。
一家咨询公司在两个类似的客户简报上运行了同一个研究智能体。一个花费了0.40英镑。另一个花费了14.80英镑。同一个智能体，同一类型的任务。37倍的成本差异。直到月度账单到达时才有人注意到。
这不是一个bug。这是非确定性执行的本质。做得更好的智能体花费更多。输出越好，账单越高。当演示令人印象深刻时没有人告诉你这一点。
机制三：重试螺旋
生产代码有重试逻辑。当API调用失败时——在生产规模下，有相当比例的调用会失败——系统会重试。一旦错误处理完全运行，一个面向用户的操作可以触发3到5次实际的API调用。token消耗增长但没有对应的用户价值增长。
这个机制在现有成本指南中获得最少的关注，但它正在迅速成为最重要的一个。乘数范围从管理有序的有意推出中的10倍，到具有激进重试逻辑和发布后添加的智能体组件的多功能部署中的717倍。
七百一十七倍。这是一个有文档记录的真实数字，不是理论上的最坏情况。
机制四：多智能体系统中的上下文重复
从单智能体系统迁移到多智能体系统的成本通常高出5到10倍，而不是2倍。在多智能体工作流中，每个智能体都重新读取上一步的完整上下文。三个智能体链式运行意味着三次完整的上下文读取。同样的信息被处理和计费三次。
如果你正在构建协调者-实现者-验证者模式——你的系统可能需要的那种多智能体架构——你正在为每个任务多次处理相同的上下文付费。没有人在设计时对此建模。每个人都在计费时才发现。
机制五：模型轮换作为治理问题
Datadog的2026年AI工程状态报告，基于来自1,000多个组织的生产遥测数据，安静地揭示了最重要的发现："在实践中，模型轮换已经成为一个治理问题。" 70%的生产组织现在同时运行三个或更多模型。每次模型切换也是一次行为变更。
同一个提示词在不同模型上不会产生相同的输出。相同的成本配置在不同模型版本上也不会成立。当你的依赖默默地从廉价模型升级到昂贵模型——就像本文开头的故事那样——没有任何东西会损坏。一切只是贵了10倍。
企业LLM支出到2025年中达到84亿美元，六个月内翻了一番多，即使每token成本大幅下降。一家从中等规模起步、每月60,000美元、使用量以5%月环比增长的中型SaaS公司，年推理账单接近100万美元。支出在增长因为使用量在增长——而且因为模型升级在广告每token成本下降的同时默默地增加了每任务成本。
3、没有人谈论的输出Token问题
有第六种机制值得单独用一段来讨论，因为它几乎让每个工程师第一次看到时都感到惊讶。
大多数成本计算器显示的是输入定价。输出token是一个单独的计费项目而且很贵。主要提供商的输出与输入成本中位比约为4:1，高级推理模型达到8:1。一个较长的智能体响应可能比整个输入上下文更贵。
OpenAI的o3和o3 Pro生成你被计费但在最终响应中永远看不到的推理token。真实成本通常是可见输出的2到3倍。对于推理密集型任务，你为思考付费，不仅仅是为答案付费。
然后还有上下文窗口大小。在某些提供商上，处理100,000以上token的上下文每个token的成本比短对话更高。使用Gemini Pro模型，一旦你跨过200K输入token，你需要支付2倍的价格。发送一个百万token上下文窗口而50,000个token就够用时，不仅仅浪费token——它让你进入了更高的定价层级。
4、那些正在解决这个问题的工程师到底在做什么？
好消息是：这是一个可解决的工程问题。那些账单随着使用量增长保持平稳或线性增长而非指数增长的工程师——在做四件特定的事情。
4.1 模型路由：为正确的任务选择正确的模型
一个团队的AI账单从每天32英镑降到了8英镑——相同的智能体、相同的任务、相同质量的输出，纯粹来自更聪明的模型选择。75%的成本降低，系统功能没有任何变化。
原则：能可靠地解决给定任务类别的最便宜模型就是该任务的正确模型。不是最强大的模型。是你能为该特定任务的需求辩护的最强大模型。
在实践中，这意味着一个三层路由策略。简单的分类、提取和格式化任务使用最便宜的适当模型。复杂的推理、多步规划和任何涉及生产关键决策的任务使用前沿模型。其他一切使用中层模型。路由决策在调用级别运行，而不是系统级别。
关键约束：你不能简单地将推理模型替换为非推理模型并期望相同的结果。模型层级的存在是有原因的。每个提示词优化——将简单请求路由到更便宜的模型同时将复杂推理保留在前沿模型上——捕获大约60%的可用节省。手动模型切换只捕获25%。这两个数字之间的差距就是钱所在的地方。
4.2 经济熔断器
你给了AI智能体访问权限。有人给它预算了吗？没有定义的预算边界，智能体可以在没有人工监督的情况下触发成千上万次昂贵的调用。
修复方案：将每个智能体视为一个损益中心。在它上线之前定义"花费过多"意味着什么——重试上限、支出速度限制、当成本加速超出预期时触发的硬停止。一旦触及边界，熔断器启动，任务停止。
这并不复杂。它是一个在每个工具调用之前检查累计支出与预算的守卫。如果预算被超出，智能体升级而非继续。构建这个守卫的成本以小时计。没有它的成本可以用本文开头的故事来衡量。
具体来说：在三个级别设置硬上限——每个任务、每个用户会话和每天。每任务上限捕获失控的单次执行。每会话上限捕获连续触发十个昂贵任务的用户。每日上限捕获凌晨3点无限循环的基础设施故障。
4.3 CI/CD中的FinOps门控
CI/CD流水线是成本冲击在到达生产之前被阻止的地方。流水线中的FinOps门控分析配置变更并标记将实质性地改变成本配置的PR。
这个例子是精确的：一个开发者更新了一个库，默认模型改变了，门控捕获了它并发出警告"预计成本增加：+900%。需要工程负责人审批。"灾难在它到达生产之前就被捕获了。
本文开头造成10倍账单飙升的三行PR会被这个门控捕获。修复不是更好的代码审查。它是一个自动化的检查，以与linter标记代码质量问题相同的方式标记成本影响。
4.4 归因优先于优化
每个智能体动作都需要携带上下文——哪个租户触发了它，哪个功能或工作流拥有它。许多智能体在共享API密钥上运行，没有链接到特定团队或工作流。财务可以看到总账单但无法指向一个负责人。如果没有在调用级别附加该元数据，你无法强制执行任何东西，因为你无法识别你在看什么。
这是使一切成为可能的基础步骤。没有归因你无法智能路由。没有归因你无法设置每个功能的预算。没有归因你无法诊断账单飙升。为每个LLM调用标记触发它的功能、工作流和用户上下文。每个调用站点只需四行代码。这是你在AI成本治理中可以做出的杠杆率最高的投资。
5、已经在发生的治理转变
98%的组织现在管理AI支出，高于2025年的63%和2024年的31%。这个学科现在有了一个名字——AI FinOps——它正在遵循十年前云FinOps同样的轨迹。在2016年，大多数公司在云账单问题已经增长到很大之后才发现它。
在2026年，大多数公司在AI账单问题已经增长到很大之后才发现它。
区别在于AI账单问题在结构上比云账单问题更难。云成本是确定性的，你为你配置的资源付费。AI成本是非确定性的，你为智能体决定使用推理路径每次都在变化的工作付费。同一个任务可能花费0.40英镑或14.80英镑，取决于模型选择如何处理它。
AI FinOps不再是一个财务报告功能。 它是一个根植于架构、工程和平台决策的技术能力。成本和策略需要在设计时和部署时出现，而不是在发票到达后作为事后回顾。获胜的方法是开发者原生的：适合团队已经交付软件方式的仪器化，以及在热路径中运行的护栏。
这不是一个新部门。它是为已经在构建系统的同一批工程师准备的新学科。
6、这对你如何构建意味着什么？
我想以一些实用的东西而不是警告来结束。
我认识的那些在运行生产AI系统而没有账单冲击的工程师共享一个习惯：他们在设计时考虑成本，而不是在部署时。在任何智能体投入生产之前，他们必须回答三个问题。
一个典型任务执行的预期成本范围是什么？不是一个精确的数字，一个范围。如果你在部署前无法回答这个问题，你就无法在实际成本超出范围时捕获它。
这个智能体被允许使用什么模型，更改它的审批流程是什么？对特定模型版本的硬依赖，配有文档化的变更流程，不是过度工程。它是防止三行PR故事发生在你团队身上的守卫。
什么会触发成本警报，谁会收到它？每日消耗图是一个滞后指标。当任何单次执行超过基线三个标准差时触发的每任务成本阈值是一个领先指标。你想在异常任务成为模式之前就知道它。
防止生产智能体上下文漂移的同一套纪律——规范先行、始终验证、持续观察——恰好也是防止账单灾难的同一套纪律。两者都要求你在看到异常之前定义正常是什么样的。
在发布之前定义正常。 从上线那一刻起监控偏差。在你需要之前构建熔断器。
账单冲击不是不可避免的。这是将成本视为生产后关注点的结果。而在2026年，随着智能体运行着比其聊天机器人前辈多20到30倍的LLM调用，正是工程纪律将可持续扩展的团队与构建了令人印象深刻的东西然后不得不与CFO进行一次非常不舒服的对话的团队区分开来。
原文链接：AI Agent Cost Explosion: The 10x Production Problem
汇智网翻译整理，转载请标明出处