AI Agent执行任务时，你的钱包在悄悄流血

你有没有遇到过这种情况：用同一个AI编程助手，去修复同一个代码库里的同一个bug，今天花了30万token，明天再跑一遍，可能只花了1万token，也可能烧到90万。

这不是段子。论文里给出的实际数据显示，同一任务反复执行，token消耗能相差30倍。这意味着你几乎没法在任务开始前知道这次调用要花多少钱，钱包被谁掏空了，掏空了多少，完全是个黑箱。

这篇论文要解决的就是这个黑箱问题。研究团队来自中山大学、伦斯勒理工学院和东南大学，他们给这个系统起名叫TokenCast，专门用来预测AI Agent在执行任务过程中会消耗多少token。

**为什么token消耗这么难预测**

先说清楚这事儿难在哪。

现在的AI Agent，不管是修代码的、还是做深度研究的，工作方式都差不多：先看任务，然后一步步执行，每一步都可能调用工具、读取反馈、再决定下一步干什么。关键问题出在这个"再决定"上。

Agent

：能够自主执行多步骤任务的AI系统，通过反复调用大语言模型、使用工具、读取反馈来完成复杂任务，比如自动修复代码bug或做深度检索。

每一次工具调用产生的结果，比如读文件的内容、运行测试的日志，都会被塞进接下来的对话上下文里。上下文越滚越大，每次调用大模型时输入的内容也就越来越长。这是个滚雪球的过程：前面产生的每一段文字，后面的每一次调用都要重新读一遍，重新付一遍钱。

打个比方，这就像你在写一篇论文，每写一段就要把前面所有内容重新读一遍才能继续写下一段。前十段的时候还好，读一遍不费什么功夫。可写到第五十段的时候，光是重新读前面的内容就要花掉大半天时间。如果论文写不完全靠运气，你完全没法提前预估自己这周到底要花多少小时。AI Agent面临的就是这个问题，而且这个"论文"到底几段能写完，还取决于模型自己的判断，它可能一次就搞定，也可能反复试错好几十轮。

正因为存在这种不确定性，成本预测就变成了一件必须动态调整的事情，任务执行到一半的时候，预测结果就得跟着更新，而不能只在任务开始前算一次就了事。

**过去的方法为什么不够用**

论文把已有的预测方法归纳成四个场景：单次调用生成前的预测、生成过程中的更新预测、整个任务执行前的预测、任务执行过程中的滚动预测。

之前的研究大多只覆盖了其中一两个场景，而且方法之间互不兼容。

有一类工作专门研究单次模型调用的回复长度，比如输入进去之后模型会吐出多少字。这类方法通常靠隐藏层状态或者熵值统计来判断，但它们的假设是提示词是已知的、完整的，而且往往需要访问模型内部状态。这个假设在Agent场景里根本站不住脚，因为后面的请求压根还没生成，你没法提前知道它长什么样。

另一类工作，比如论文中提到的Self-Prediction方法，是让Agent自己检查一下任务环境，然后估算总共要花多少token。这种方法有个明显的短板：它只在任务开始前算一次，跑到一半发现情况变了，也没法更新。

LightGBM

：一种基于梯度提升决策树的机器学习模型，训练速度快、预测开销低，常用于结构化数据的回归和分类任务。

还有像DSPy、Parrot、SGLang这类多步骤LLM执行框架，它们依赖程序结构或语义依赖关系来调度请求，但这套逻辑要求任务执行路径提前可知。可Agent恰恰是开放式的，它的行为取决于工具反馈和环境状态，压根没有一张提前画好的流程图可以参考。

**TokenCast的核心思路：把执行过程切成一段一段来算账**

TokenCast解决这个问题的办法挺聪明，它不试图一次性算出整个任务要花多少钱，而是把执行过程切成一段一段的片段，每一段单独记账，再想办法把账目拼起来。

具体来说，每一个执行片段用三个数字来表示：这段包含了几次模型调用、这段结束后输入长度净增加了多少、以及这段实际花费和"按起始输入长度乘以调用次数"这个基准值之间的差额。

这第三个数字叫残差，它捕捉的是生成内容和片段内上下文增长带来的额外开销。

残差

：某个片段实际消耗的token数，减去用起始输入长度乘以调用次数得到的基准值，剩下的部分反映了生成过程和内部上下文膨胀带来的额外成本。

这三个数字凑成一个三元组，研究者管它叫segment representation（片段表示）。

关键的地方在于，当两个相邻片段拼接起来的时候，存在一个精确的组合公式：合并后的调用次数就是两段调用次数相加，合并后的输入长度变化也是两段变化相加，但残差不是简单相加,还要多加一项，这一项等于后一段的调用次数乘以前一段带来的输入长度增长。

为什么会多出这一项？因为后一段的残差原本是相对于它自己的起始输入长度计算的,而合并后的残差是相对于前一段的起始输入长度计算的,这两个基准点之间差了前一段带来的那部分增长,而这部分增长会被后一段的每一次调用重复读取，所以要乘以调用次数补回来。

这个设计精妙就精妙在，它把"上下文越滚越大导致后面调用越来越贵"这个核心矛盾，用一个干净的数学关系表达出来了。

如果不这么设计会怎样？论文的消融实验给出了答案：把这个三元组换成简单粗暴的"总token数、输入长度、输出长度"三个数字，任务级和调用级预测的归一化平均误差分别从0.71和0.68恶化到0.88和0.82，误差明显放大。如果保留三元组但去掉组合运算这一步，误差也会从0.69涨到0.78。这说明组合恒等式不是锦上添花的技巧,它直接决定了预测能不能追上上下文膨胀这个核心变量。

**四个预测时间点，覆盖执行全程**

TokenCast并不满足于只在任务开始前算一次账，它设计了四个预测时间点，贯穿整个执行过程。

第一个叫Task Start，也就是任务开始前，预测这次任务总共要花多少token。第二个叫Call Start，是当前这次模型调用的请求已经组装好、但模型还没开始生成回复之前，预测这一次调用会花多少。第三个叫In-call Update，模型已经开始吐字了，根据已经生成的前缀内容，实时更新这次调用的花费预测。第四个叫Task Update，某次调用刚刚结束，根据已经确认的消耗和执行进展，重新预测剩余部分还要花多少。

这四个时间点像是给整个任务安了四道检查关卡，每过一道关卡，预测就刷新一次。

这套机制有点像开车时的导航软件不断重新计算剩余到达时间。你刚上高速的时候，导航根据全程距离给你一个大致预估。开出去半小时后遇到堵车，导航立刻根据实时路况重新算一遍。如果导航只在出发前算一次就再也不更新，那你遇到堵车的时候完全不知道还要多久，这种"一锤子买卖"式的预测对实际决策帮助有限。TokenCast放弃了这种一次性预测的思路，选择让预测跟着执行进度走。

**直接预测和组合预测,两条腿走路**

在任务级预测这块，TokenCast并没有把所有希望都押在组合恒等式上，而是同时维护了两条预测路径。

一条叫direct path（直接路径），把剩余的总花费当作一个单一目标直接预测。另一条叫compositional path（组合路径），把当前或接下来的片段和后续的剩余部分分开预测,再用前面说的组合公式把两部分拼起来。

这两条路径各有各的擅长。任务刚开始的时候，还没有任何片段执行完，组合路径找不到可以依赖的"锚点"，这时候直接路径的表现更好，归一化误差0.82对组合路径的0.87。可一旦有片段执行完了，组合路径就能利用已知的边界信息，误差反而降到0.66，比直接路径的0.72更低。

论文的做法是把两条路径的预测结果都保留下来，再训练一个correction model（校正模型）来综合它们，同时把预测得到的边界变量也一起喂给校正模型。这套组合拳把误差进一步压到0.62，区间覆盖率也从直接路径的88.1%提升到90.6%。

这就好比一个团队里同时配备了一个经验丰富的老会计和一个精算模型，老会计凭经验估个大概,精算模型按照精确公式一步步算,最后由一个更懂两边优劣的主管来拍板综合意见,而不是死板地只信任某一方。

correction model

：一个在直接路径和组合路径预测结果基础上再训练的校正模型，输入包含两条路径的预测值、它们之间的差异以及预测的边界变量,用来进一步压低最终预测误差。

**这些数字是从哪来的：特征工程细节**

TokenCast的预测模型用的是LightGBM，这是一种基于梯度提升决策树的方法，训练快、推理开销低。论文专门做了对比实验，测了六种不同的基础预测器，包括岭回归、KNN、随机森林、XGBoost、CatBoost和MLP，结果LightGBM在归一化平均误差和区间覆盖率上都拿到最高分，误差0.69、覆盖率90.6%，推理只要0.8毫秒。

但模型再好，喂进去的特征也很关键。论文里详细列出了不同预测时间点用到的特征类型，包括任务描述本身的TF-IDF编码、执行历史中的调用次数和token趋势、当前请求的输入长度、生成前缀的哈希编码、以及流式生成的时间戳信息。

TF-IDF

：一种文本特征提取方法，通过统计词语在文档中出现的频率并结合其在整个语料库中的稀有程度，把文字转换成模型能理解的数字向量。

有意思的是，论文还专门分析了不同预测时间点上，哪些特征最重要。在任务刚开始时，初始请求长度的重要性排第一，占0.24。到了调用刚组装完的时候,请求输入token数的重要性冲到0.30，成为最主要的信号。生成过程中，已提交的前缀字节数一家独大，重要性达到0.58。而调用结束之后，最后一次调用的输入token数、剩余待办事项数、无进展调用次数这三个特征并驾齐驱，重要性都在0.23到0.28之间。

这个变化规律说明了一件事：不同阶段最能反映"接下来会花多少钱"的信号是不一样的。任务刚开始时，你只能靠任务本身的描述去猜；调用组装好之后，输入长度直接决定了这次调用至少要花多少；生成过程中，已经写出来的内容长度成了最直接的线索；调用结束后，执行进展和历史趋势才是最有价值的信息。

**训练细节：交叉拟合和加权损失**

组合路径依赖前一段的预测边界来给后一段设定输入基准,这里藏着一个风险：如果直接用同一批数据训练出来的前段模型去预测边界,再拿这个边界去训练后段模型,训练数据和真实推理场景会出现系统性偏差，模型学到的可能是训练集里特有的规律，而不是普遍规律。

为了避免这个问题，论文采用了cross-fitting（交叉拟合）。把任务划分成若干折，每一折的前段预测结果，都由在其余折上训练出来的模型来生成，这样后段模型训练时接触到的边界预测,和它实际推理时会遇到的情况更接近。

cross-fitting

：一种避免模型在自己训练数据上过拟合的技术,通过把数据分成多折,轮流用其中几折训练出的模型去预测另一折的数据,从而让训练阶段接触到的预测误差更接近真实推理场景。

此外，论文还给两类误差设计了加权损失函数，用来惩罚前段预测中context变化量的偏差和后段预测中调用次数的偏差,因为这两类误差会通过组合公式放大，影响最终的成本估计。消融实验显示，同时去掉交叉拟合和这个加权损失，归一化平均误差从0.69一路涨到0.78，区间覆盖率也从90.6%掉到87.4%，两个部分合起来贡献了整套系统里最大的一块提升。

**实验结果：14.5%的平均误差降低**

论文在四个测试集上做了大规模实验：修代码的SWE-bench Verified、检索问答的Search-R1、知识推理的MMLU-Pro、长文本理解的LongBench-v2。搭配六个不同的Agent模型，包括GPT-5.4、Claude Opus 4.6、Gemini 3.1 Pro、DeepSeek-V4-Pro、Qwen3.8-27B和Llama-3.2-3B-Instruct，一共收集了11712条执行轨迹。

对比的基线方法包括三个专门做输出长度预测的方法TRAIL、EGTP、TIE，以及前面提到的Self-Prediction。

结果显示，在96个基准测试与模型的组合里，TokenCast相对于每个组合下表现最好的对手，平均误差降低了14.5%。拆开来看，在任务开始前这个时间点，TokenCast的表现和最强对手差不多，甚至略微落后2.2%；调用开始前也基本持平，只领先1.9%；但一旦进入生成过程中的更新阶段，误差降低幅度飙到30.4%；任务更新阶段也有27.8%的降低。

这个规律其实很好理解。任务刚开始的时候大家都在"猜"，谁都没有执行证据可用，差距自然不大。可一旦有了实际执行的反馈，TokenCast的组合结构就能把这些信息充分利用起来，优势立刻显现。论文里明确写道，TokenCast在24个组合里落后于最强对手，但这24次里没有一次发生在In-call Update或Task Update阶段，全部集中在最初两个还没有执行证据的时间点。

拿SWE-bench Verified配GPT-5.4这组数据具体来说，In-call Update阶段的误差从EGTP的74.6个token降到38.9个，降幅47.9%；Task Update阶段从TRAIL的11.5万个token降到8万个，降幅30.4%。这两个数字放在真实场景里意味着，任务跑到一半的时候，TokenCast给出的花费预测已经相当靠谱了。

**预测区间：不只给一个数,还给一个可信范围**

只给一个点预测其实还不够,用户更关心的往往是"这次任务花费大概率落在哪个范围内"。TokenCast额外训练了分位数模型，输出90%置信区间的上下界，并且用held-out校准任务对这个区间做了进一步的宽度校准。

held-out

：训练过程中专门预留出来、不参与模型训练的一批数据，用来检验模型在没见过的数据上表现如何，或者用来校准预测结果的可信度。

结果显示，TokenCast的区间预测在四个时间点上都比Self-Prediction的原生区间更靠谱。以任务开始前这个时间点为例，TokenCast的区间实际覆盖率达到82.0%，逼近名义上的90%目标；而Self-Prediction的覆盖率只有52.7%，意味着超过四成的真实结果落在了它给出的区间之外。综合考虑区间宽度和覆盖失败的惩罚，TokenCast在四个时间点上平均把这个综合指标降低了32.0%。

**实际应用：预算控制能省多少钱**

光有准确预测还不够，论文进一步做了一个实用场景的测试：预算控制回放实验。

设想你给Agent设了一个token预算上限，执行过程中一旦预测剩余花费加上已经花掉的超过预算，就停下来。论文在288次GPT-5.4执行SWE-bench Verified任务的记录上做了这个回放测试，对比TokenCast和一个固定预算策略。

结果是，在保持任务完成率和固定预算策略完全一致的前提下，TokenCast平均节省了21.3%的token。这个节省不是靠降低任务完成率省出来的，而是靠更精准地判断"这次执行还需要多少钱才能走完"，从而避免了盲目预留过多余量。

这就像你去银行申请贷款,如果银行完全不知道你的还款能力，只能按最保守的方式给你留出最大额度的备用金，这笔钱大概率是浪费的。如果银行能实时监控你的收支情况，动态调整授信额度，既能保证你不会资金断裂，又不会白白占用额度。TokenCast做的正是这种动态调整。

**响应速度：预测本身几乎不占用时间**

有一点容易被忽略：预测这件事本身也要花时间和资源，如果预测过程本身太慢太贵，那这套系统的实用价值就要打折扣。

论文专门测了不同更新频率下的开销。每次调用完成后都刷新一次预测，一次SWE-bench Verified任务平均会触发19.7次预测，累计耗时32.8毫秒。如果改成每三次调用刷新一次，预测次数降到6.9次，耗时11.9毫秒。哪怕是最密集的每调用一刷新频率，相对于一次任务129秒的中位数总执行时间，预测开销占比不到0.03%。

也就是说，这套预测系统几乎是"白嫖"式的，它不会拖慢Agent本身的执行速度，却能实时给出越来越准的花费预测。

**跨场景泛化能力**

一个预测系统如果只能在训练时见过的任务类型和模型上表现好，遇到没见过的场景就抓瞎，那实用价值有限。论文专门测试了TokenCast在陌生任务类型和陌生Agent模型上的表现。

在独立发布的LiveClawBench数据集上，做留一域测试，也就是训练时完全不接触某个任务领域的数据，直接迁移过去预测。零样本情况下，调用开始阶段的误差是Self-Prediction的1.31倍，任务更新阶段是1.47倍，说明完全陌生的场景确实会让预测打折扣。但只要补充20个目标领域的任务样本用于微调，这两个比值就分别降到0.82和0.85，反超了对比基线。

换成陌生Agent模型的场景也类似。完全没见过目标模型的执行轨迹时，调用开始阶段的误差是历史中位数预测的1.02倍，跟瞎猜差不多；补充20个目标模型的任务后降到0.95倍，比历史中位数更准。而且论文发现一个有意思的现象：只用3到10个目标模型样本做迁移微调，效果反而比只用这些样本从零训练还要好，说明从其他模型学到的通用规律确实能迁移过去，不是白学的。

**这篇论文没有回答的问题**

论文最后坦诚地说，他们把TokenCast定位为一个"轻量级预测层"，目前只负责预测，不负责决策。怎么把这些预测结果整合进一个真正主动管理执行过程、在预算约束下做实时决策的运行时框架，是留给未来的方向。

这个留白挺诚实的。预测准了固然重要，但预测之后怎么用,是提前中止执行、动态调整策略、还是给用户发预警，这背后涉及的权衡比单纯的数字预测复杂得多，论文没有假装这个问题已经解决。

写在后面

这篇论文最打动我的地方，不是它把误差降低了多少个百分点，而是它对"上下文重复消耗"这件事给出了一个干净的数学表达。很多工程系统里都存在类似的滚雪球现象，前面产生的负担被后面反复承担，但很少有人把这种关系写成一个可以精确拼接的组合公式。这种把直觉转成精确代数关系的做法，本身就是一种思维训练。

另外一个值得琢磨的细节是，论文里那张特征重要性变化图，展示了不同执行阶段最关键的预测信号完全不同。这提醒我们，预测这件事很难指望一个万能特征打天下,不同阶段掌握的信息不一样,该依赖的证据自然也不一样。这个观察其实超出了token预测这个具体场景，放到任何需要"随着信息增加不断修正判断"的系统里都成立，比如疾病诊断、风险评估，甚至是我们日常做计划时不断根据新情况调整预期的过程。

如果Agent真的越来越多地嵌入我们的工作流程，这种"花多少钱""值不值得继续跑下去"的判断，会不会有一天变成用户界面上一个像油量表一样实时跳动的数字?

Q&A

Q1：TokenCast是用来做什么的？

A：TokenCast是一个专门预测大语言模型Agent执行任务时token消耗量的系统，它能在任务开始前、调用开始前、生成过程中、任务执行中这四个不同阶段实时更新预测，帮助用户提前了解和控制AI使用成本。

Q2：TokenCast相比其他方法效果好多少？

A：在四个基准测试和六个Agent模型的96种组合里，TokenCast相较于每个场景下表现最好的对比方法，平均误差降低了14.5%，在预算控制场景下平均能节省21.3%的token消耗。

Q3：使用TokenCast会拖慢Agent执行速度吗？

A：几乎不会。在SWE-bench Verified测试中，TokenCast每次任务的累计预测耗时平均只有32.8毫秒，相对于一次任务129秒的中位数执行时间，占比不到0.03%，属于可以忽略的开销。