大规模 AI 的隐藏成本

在 2026年6月1日，GitHub 永久停用了 Copilot 的固定费率”premium requests”，并改为基于使用量的 AI 额度。当新模型下的首批发票一个月后到达时，一些具备代理功能的用户看到了一些他们没有准备好的账单：一位开发者报告称，在最繁重的代理工作流中，月费用从 $29 跳升至 $750。

这是 2026 年期间 AI 工具市场更广泛转变的一个明显例子——也可能出现在仍然采用固定费率的组织中。

组织会统计它们节省的工时。许多组织并未计算固定费率下隐藏的成本：上下文消耗以及失败后的重试。还有一些费用根本不会出现在供应商发票上，包括审查输出和维护提示所花费的时间。一旦计费转向实际消耗，缺乏成本约束的组织就会面临一张让人惊讶的账单，方式与 Copilot 新模型让部分用户感到意外相似。

无人计价的上下文

AI 显然需要上下文，这一点毫无争议。问题在于所发送的上下文是否相关，还是仅仅因为方便而被使用。发送整篇文档是向模型提供信息的最快方式，但这并不一定是最便宜或最好的方法。

2026 年 5 月，斯坦福大学数字经济实验室发布了一项针对八种前沿模型的代理编码任务分析，发现这些任务 消耗的代币量是普通代码聊天的千倍以上，其主要驱动因素并非模型输出，而是一次又一次重新发送的输入上下文。代理在每一步都会重新读取其完整历史。相同任务多次运行时，代币消耗的差异最高可达三十倍。

准确性也并非随上下文量线性提升：它往往在适度的量级达到峰值，随后只会增加成本而不提升价值。

因此，代币盲目并非因为 AI 不需要上下文，而是因为缺乏度量，没人去质疑所有这些上下文是否真的必要。在固定费率下，这个问题很容易被忽视。而在基于消耗计费时，它就成为成本的一部分。

当你为失败付出双倍代价时

代理工作流还带来另一种几乎从未出现在 ROI 计算中的成本。设想一个简化的十步链，每一步单独运行的成功率为 95%。听起来足够可靠，但串联起来后，该链整体完整运行且不出现任何错误的概率仅约为 60%。

在每次调用时都重新发送累计上下文的工作流中，每一次失败以及随后的重试不仅会让你为重复的步骤付费，还会再次为之前发送的所有内容付费。

在构建首个代理流水线时，几乎所有人都会经历这种常见的痛点。我本人也经历过。起初，只有少数几个代理时，这并不重要。但随着流水线的扩展，每一次失败的运行成本都在上升，这促使我开始思考每个代理需要哪些上下文以及如何缓存，而不仅仅是关注运行是否成功。

同一分析计算出，十步代理每步 95% 的可靠性下，其在重试时消耗的代币约比完美可靠系统多出 40%。这笔费用会出现在发票上，但可能不会出现在任何 ROI 电子表格中。

监督不是错误，而应计入预算

这一点必须精准阐述，因为容易被误解。审查 AI 输出并非系统故障；它是使用 AI 时的合法且预期的环节，就像代码审查是与开发者协作时的合法环节一样。问题不在于输出被审查，而在于这项工作几乎从未计入 AI 实际节省的计算中。

Glean 的 Work AI Institute 对 6,000 名员工进行调查，发现自动化每周为他们节省约 11 小时，但 其中近 6.5 小时用于维护任务：为 AI 系统提供上下文、检查其工作并清理错误。于是净节省约为 4.5 小时——不到标题数字的一半。AI 仍然节省时间，只是没有最初数字显示的那么多。

提示需要维护，而不仅仅是作者

如今，提示更像是生产代码：模型更新、上下文变化或看似微小的编辑都可能影响其表现。如果没有版本管理和测试，这些变化可能悄然引入问题。针对代码的回归测试在验证提示时仍常被忽视。看似对单句的微小修改可能进入生产环境，导致准确率下降，却在问题累积成可见影响之前无人察觉。

构建完善的评估框架——包括测试集以及对每次更改进行自动化回归测试——是一项额外工作，几乎从未出现在“AI 节省时间”的计算中。

更便宜的代币，更高的账单

GitHub Copilot 并非例外。CFO Dive 引用的一项调查发现，近七成美国公司报告至少出现部分 AI 预算超支在过去一年中，主要发生在全面转向基于消费计费之前，而不是之后。

贝恩公司在其六月的代币经济学分析中，补充了一个最能概括整体情况的悖论：代币单价在一年内下降了一半，而同一时期的消费增长了 4.5 倍。

模型变得更便宜，但账单仍顽固地居高不下。公司转向更新的模型，让代理承担更复杂的任务，并为其发现了更多工作流。代币更便宜并不意味着支出降低；而是意味着有更多理由去消耗它们。

账单到来前的准备方法

以下框架并非关于减少 AI 使用，而是关于在决定进一步扩展之前了解 AI 成本。

1. 首先获取可视性

在你将消费按团队、工作流细分之前，应用和已完成任务划分之前，每一次扩展都是盲目的赌注。那种可视性也不是免费的：尤其是对于代理工作流，追踪每一步、记录发生了什么以及原因，并监控失控的循环，都需要额外的工程时间和工具。应将其计入 AI 运行成本，而不是事后额外的考虑。

2. 重新以净值计算 ROI

从报告的节省工时中扣除用于审查、修复和提示维护的时间。如果时间节省是用例的目的且净结果为负或无法验证，则该用例尚未准备好扩展。如果预期收益是质量、产能、风险降低或收入，则直接衡量该结果。

3. 实施成本纪律，但不要一刀切

在失败成本低的场景下，硬性支出上限是有意义的：内部工具、实验性代理、开发环境。对于关键的面向客户的功能——例如客户服务助理——硬性上限不可行，因为它会带来停机风险。在这种情况下，需要分层回退到更便宜的模型并设置预警，而不是直接切断到零。

4. 将提示和评估视为工程资产

对它们进行版本管理、测试并在部署前审查更改，就像管理生产代码一样。

凭借自有数据走进续约谈判

没有自己的使用数据，供应商定价难以评估。在续约或模型更改之前，计算在拟议条款下您现有工作流的成本。目标不仅是谈判更低的价格，而是了解该价格在您实际消费水平下的表现，而不是从发票中才得知。

本周可以做的三件事：检查是否能按团队和工作流细分 AI 消费；选择一个用例，将审查所花时间与报告的节省工时并列；并找出硬性支出上限可能导致停机而非控制成本的场景。

AI 成本是可以管理的，只是不能在第一次从账单上才发现它们时才去管理。