一个月烧掉5亿美元账单之后：Agent到底知不知道自己花了多少?

当大厂们开始为天价 Token 账单算账，一个更根本的问题浮出水面:智能体在执行任务时，自己知道接下来要花多少吗?来自Northwestern、O2 AI Lab 、Stanford 等机构的研究团队提出 BAGEN (Budget-Aware Agents)，把"预算意识"定义为一项独立的智能体能力，并通过一套 rollout-replay 协议在四个环境、五个前沿模型上做了系统评测。结论是：会做任务，不代表知道自己要花多少。

当大厂开始为 Token 账单算账

最近一个月，关于 AI 成本的新闻一条比一条扎心。

据 Axios 报道，一家企业因为开通了企业授权却忘了设用量上限，一个月烧掉了 5 亿美元的 Claude 账单。Uber 的工程师只用 4 个月就烧光了全年的 Claude Code 预算，其 COO 公开表示，Token 消耗和最终交付的有价值产品之间，看不出明显的线性关系。亚马逊取消了内部 AI 使用排行榜，因为员工开始为了冲榜而疯狂刷 Token、执行大量没有实际价值的任务。微软则在收缩内部的 Claude Code 授权。

这些事件放在一起，标志着一个转向:过去一年企业最担心员工不用 AI，而现在，越来越多公司开始担心 AI 是不是用得太多。Token 本身不是价值，完成任务、交付产品才是。企业开始认真计算每一个 Token 背后的 ROI。

但这里有一个被忽略的前提:要想控制成本，不仅只是使用智能体的员工，智能体本身首先得知道自己在花什么、花了多少、还要花多少。如果连这一点都做不到，任何预算管理都无从谈起。

而恰恰是这个前提，几乎没有人系统地验证过。一项新研究正好补上了这一块。一个被忽略的问题:Agent 知道自己要花多少吗?

当下的 AI 智能体正在被部署到越来越长、越来越高风险的任务里。一个编程智能体每一步推理都在消耗 token，一个网页智能体每次检索都在花 API 调用，一个供应链智能体每做一笔采购决策，都在动用真实的资金和仓库容量。

它们花掉的预算分两类。一类是模型自己生成内容所消耗的，主要是 token，称为"内部预算"(internal budget);另一类是智能体在环境中行动所承诺出去的，包括钱、时间、库存，称为"外部预算"(external budget)。随着任务变长，这两类成本都在快速膨胀。

问题在于，现有的评测几乎都只在任务结束后才统计这笔账，很少有人去问一个更根本的问题:智能体在执行过程中，自己知道接下来要花多少吗?

来自 Northwestern University、O2 AI Lab、Stanford、All hands AI、密歇根大学、康奈尔大学等机构的研究团队，把这个能力正式提了出来，命名为"预算意识"(budget awareness)，并构建了一套评测体系BAGEN(Budget-Aware Agent)。一句话概括他们的核心主张:预算不该只是事后记账的指标，而应该是智能体在执行中主动使用的控制信号。

论文标题为《BAGEN: Are LLM Agents Budget-Aware?》，项目主页、代码与数据集均已公开。该团队此前在智能体强化学习方向的工作 RAGEN-2 入选了 ICML 2026 Oral,本研究是其在"智能体自我认知"这一方向上的延续。

有趣的是，研究团队所取的名字藏着一个双关: I used to burn tokens; now I'm BAGEN (begging) the agents to stop (过去我在烧 token，现在我在求着智能体停下来)——在智能体学会自己喊停之前，只能求着它停。

• 论文标题:
• BAGEN: Are LLM Agents Budget-Aware?
• 项目主页:
• https://ragen-ai.github.io/bagen
• 代码:
• https://github.com/mll-lab-nu/BAGEN
• 数据集:
• https://huggingface.co/datasets/MLL-Lab/BAGEN

把"预算意识"形式化：

从单点估计到渐进式区间估计

研究团队首先做了一个看似简单的预备实验:在任务开始时，直接问模型"你大概要花多少 token"，然后跟真实消耗对比。这种"单点估计"恰好是很多现有工作采用的做法。

结果暴露了两个问题。

第一是系统性乐观。五个模型在两个任务上，首轮预测都更倾向于低估真实消耗，而不是高估。更反直觉的是，这种偏差跟的不是任务难度，而是模型的自信程度:在同一个环境里，能力越弱的模型反而越乐观。

第二是首轮估计和后续估计对不上。同一个模型，在任务刚开始时的判断，和它看到部分进展后的判断，经常不一致，而且往哪个方向偏完全取决于具体的模型和任务，没有规律。

这两个问题说明，单点估计根本不够用。一个点估计无法表达模型自己的不确定性，也无法在任务变得不可能完成时发出警报。

于是，团队提出了"渐进式区间估计"(progressive interval estimation)。它的核心是:在执行的每一步，智能体不再给一个数，而是给一个区间(预算的上界和下界)，并且每一步都更新这个区间;一旦判断任务已经不可能在预算内完成，就直接输出 impossible 来预警。

这个设计同时抓住了三个性质：用区间宽度表达不确定性，用逐轮更新表达进展带来的修正，用 impossible 选项表达"任务已经没救了"这个可以直接拿来行动的信号。

评测协议的巧思：

把"估算能力"和"完成能力"分开

这里有一个容易被忽略但很关键的工程问题:如果让智能体在跑任务的同时去估算预算，那估算本身也要消耗 token，会把"完成任务的成本"和"自我评估的成本"混在一起，污染结果。

团队的解法是一套两阶段的 rollout-replay 协议。第一阶段是 rollout 生成:让智能体在没有任何预算上限的情况下把任务跑完，完整记录下整条轨迹、每一轮的成本和最终结果。第二阶段是前缀回放与估计:对每一个非终止的轮次，把之前记录的轨迹前缀重新喂给智能体当作历史，再问它"从下一轮开始，还要花多少"，拿这个预测去对比真实的剩余成本。

这样一来，估算这件事完全发生在任务执行之外，两种能力被干净地解耦开。

在此基础上，团队把预算意识拆成了三个子能力，分别打分:一是可行性预测，判断任务在剩余预算下能不能成功，用 Macro-F1 衡量;二是早期失败检测，对最终失败的任务，看智能体能不能早点拉响警报，用 Fail-F1 衡量;三是区间校准，对最终成功的任务，看预测区间又准又紧的程度，用覆盖率乘以紧致度衡量。

最难的部分:

一个用真实企业数据搭出来的供应链环境

BAGEN 一共覆盖四个环境。其中三个测的是内部 token 预算:Sokoban(8×8 推箱子规划任务，2500 token 上限)、Search-R1(多跳信息检索，3500 token 上限)、SWE-bench(解决真实 GitHub issue，160 轮上限)。

值得一提的是，这项工作中, 由 Northwestern 的 MLL Lab 与 O2 AI Lab 等合作完成，真正体现工程投入的是第四个环境 Warehouse。Warehouse 环境所依托的真实供应链数据与电子制造场景理解，也来自团队在产业一线的积累。它测的是外部预算，也是整套 benchmark 里最不容易构建的一块。这个环境模拟一家电子产品制造/分销公司，智能体要在一个 22 周(11 个决策轮)的周期里做经营决策:生产、补货、向供应商赊账、还债、应收账款保理融资，目标是在不违反任何预算约束的前提下让公司活下去并盈利。

它同时压着三个相互耦合的预算维度:钱(累计成本，美元)、时间(周)、空间(仓库占用，以"件·周"计)。这三者是真正纠缠在一起的：多囤货能提升销售，但会吃掉仓库容量;赊信用额度能改善短期现金流，但带来后续还款压力;推迟生产能省成本，却会拉低最终现金。

构建这个环境时，团队做了几件很费功夫的事，值得展开讲。

数据是真的。需求面板来自一家真实的美国中型消费电子分销商(匿名为 Acme)及其五个下游零售账户，涵盖五个高销量产品线(USB-C 集线器、4K 扩展坞、USB-C/HDMI 线、USB 显示适配器、差旅扩展坞)，共 22 周连续的单品级周度销售数据。批发价、零售商仓储容量、账期(全线 Net-30)、缺货/积压罚金率取自真实的供应商协议，只做了轻度取整。关键是，周与周之间的波动、阶跃式变化、甚至偶尔出现的需求崩塌(比如某个 OfficePlus 单品)，都原样保留在数据里。

论文专门用一节(Appendix C.3)交代了两个被刻意偏离"自然默认值"的关键决策。其一，初始库存设为 0。早期版本给仓库预先备了几周货，结果发现轨迹基本被初始条件主导，大约 11 轮里有 3 轮在"自动驾驶"，策略选择还没开始起作用就过去了;于是改成所有库存从零开始，逼着结果完全由模型决策驱动。其二，国际运输和生产周期被压缩了。真实的深圳到美西门到门海运要 45 到 60 天，直接套进 11 轮、每轮 14 天的设定里，一笔海运订单要到第 11 轮才到货，等于绝大部分时间都在空转;团队把海运压到 32 天、空运压到 6 天、生产周期按单品设为 25 到 45 天，既让智能体能在一个周期内看到决策后果，又保留了时间压力这个核心张力。

奖励设计专门留了"信用分配"的坑。每一步的奖励只计入当期经营利润和缺货/积压罚金，而制造成本、运费、信贷利息、保理费这些都只影响现金、不进入奖励，因为它们是投资和融资成本，回报要到未来几轮的经营利润里才体现。这正是这个环境的核心难点:一个在第 t 轮下的生产决策，要到第 t+4 到 t+6 轮才通过收入回收。如果把这些成本也算进即时奖励，整个环境就会塌缩成一个近视的控制问题，丢掉了团队最想要的长周期协调挑战。

此外，由于 Warehouse 是一个连续优化任务(利润越多越好)，不可直接估计“完成某个任务的budget”，团队又设计了"挑战条件化的可行性探针":每个实例配一组采样出来的目标(目标现金、时间、仓库、成本)，并把可达与不可达的比例严格平衡在 50/50，这样可行性预测和校准指标在正反两侧才都可识别。团队特别说明，这个 50/50 是评测设计的选择，不代表真实供应链里有一半决策会失败。

仅就这一个环境的构建细节而言，就能看出 BAGEN 不是简单地把几个现成 benchmark 拼起来，而是为"外部预算"这个此前几乎没人系统评测过的维度，专门造了一套贴近真实工业场景的测试床。

评测规模与五个模型

评测对象是五个前沿模型:GPT-5.2 Instant、Claude Opus 4.7、Claude Sonnet 4.6、Gemini 3.1 Pro、Qwen3-235B。

规模上，团队在 Sokoban、Search-R1、Warehouse 上每个模型生成 128 条 rollout，在 SWE-bench 上生成 64 条;每一个非终止轮次通过 rollout-replay 协议产出一个估计样本，每个"模型-任务"组合累计 2000 到 3000 个估计样本。其中 SWE-bench 因为编程轨迹特别长，团队还专门设计了分桶采样策略，避免少数超长轨迹主导整个评测集。

四个核心发现

发现一：预算意识和任务能力是两回事。 任务成功率和估计质量只有很弱的相关性(r≈0.35)。最会做任务的模型，往往不是最会估算的那个。比如在 Search-R1 上，Opus 的任务成功率最高(75.8%)，但 Sonnet 的区间估计更好(命中率 36.5% 对 23.1%);在 SWE-bench 上，三项能力的排名干脆裂成三家:Opus 领先任务成功率，Gemini 领先可行性预测，GPT-5.2 领先区间命中率。没有一个模型能在三项子能力上全面领先。团队进一步发现，真正区分"好估计者"的是校准能力，而不是可行性判断。

发现二：乐观偏差是普遍的。 在 20 个"模型-环境"组合里，有 17 个在每一个进度区间上，低估剩余预算的次数都多于高估。而且越弱的模型越乐观，不是越保守。这跟"乐观源于对难任务推理不足"的直觉正好相反，更像是一种"不知道自己不知道"的过度自信。

发现三：失败被发现得太晚，晚到来不及行动。 在最终失败的轨迹上，即便预算已经烧掉了 60%，模型预测"任务可行"的比例还在 70% 以上，要到最后 20% 才骤降。换句话说，模型往往一路自信地跑到接近耗尽，才反应过来任务早就没救了。这种"迟到的认知"白白浪费了大量算力。

发现四：这个信号既能用，也能训，但训练很脆弱。 一个简单的早停策略——只要模型输出 impossible 就终止任务——能在失败轨迹上省下 28% 到 64% 的 token，而总成功率只下降 1.6 到 4.2 个百分点。这说明信号本来就在模型的预测里，策略只是把它用起来而已。训练方面，团队在 Qwen-7B 上发现:二元可行性判断其实是个"校准问题"，光靠 SFT 就能把准确率从 25.5% 提到约 90%，说明能力本就潜藏在模型里，只是缺一个对的输出格式;但区间估计是个"推理问题"，SFT+RL 之后覆盖率也只到 47%，接近一半的区间仍然没能覆盖真实的剩余预算。而且 RL 必须从一个合适的 SFT 起点出发，纯 RL 会直接崩溃——模型要么把所有任务都标成 impossible，要么输出无效格式。

结论：

预算应该是控制信号，而不是事后账单

BAGEN 给出的整体图景是:对今天的前沿智能体来说，预算更像是一个它们目前还缺失的控制信号，而不只是一个用来事后算账的指标。随着智能体承担的任务越来越长、越来越贵、越来越自主，瓶颈正在从"能不能做这个任务"，转向"做任务时能不能管好自己"。

回到开头那些天价账单——5 亿美元的 Claude 账单、烧光全年预算的 Uber、刷榜刷到失控的内部排行榜，它们的共同点是:成本失控往往不是因为单个任务贵，而是因为没人(包括智能体自己)在过程中知道钱正在流向哪里、什么时候该停。BAGEN 想说明的，正是这种"过程中的自我认知"目前还很欠缺。

团队也坦诚指出了仍未解决的核心难题:精确的区间校准依然很难,近一半的区间还会落空,这是他们认为最值得后续攻关的开放问题。

而把视角放长,BudgetBench 衡量的"事前估算"只是第一步。真正的挑战在于,当智能体在执行中发现自己做不完时,它该怎么办？这指向三个尚未被充分研究的方向:

第一，提前求援。智能体应当在预算快要见底、而非已经超支时,主动申请追加资源。这要求它对"还剩多少路要走"有持续的自我判断,而不是埋头干到钱烧光才发现问题。

第二，及时止损。当一个任务的预期回报已经撑不起继续投入时,智能体应当有能力切换到另一个更划算的任务,而不是在沉没成本里越陷越深。这背后是一个动态的任务价值再评估问题。

第三，向上移交。当任务超出自己的能力或预算边界时,智能体应当把它交给更强的智能体,并清楚地说明已经做到哪一步、还差什么。这要求它既能识别自身的边界,也能把中间状态完整地传递出去。

这三个方向的共同点是：它们都不再把预算当成一个事后才结算的数字,而是当成一个贯穿执行全程、需要被持续感知和响应的控制信号。BudgetBench 把"智能体能不能估准预算"立成了一个可衡量的问题,而它真正想推动的,是让智能体学会在预算这件事上管好自己。