这项由英国西英格兰大学布里斯托尔分校数据科学专业独立研究者完成的研究，发表于2026年6月，以预印本形式上传至arXiv，编号为arXiv:2606.04056v1，感兴趣的读者可以通过该编号查阅完整论文。

你有没有想过，当你雇了一个助手帮你办事，却突然收到一张天文数字的账单？这正是越来越多使用AI代理（AI Agent）的开发者和公司面临的真实噩梦。AI代理就像一个被你委托去处理任务的机器人助手，它会自动调用各种服务、反复尝试各种操作。问题在于，每次它调用语言模型服务，都要花钱——而且是真实的美元。当这个助手陷入某种循环或犯了错误，它可能在你没注意到的时候，把成千上万美元花掉，账单直接打到你的信用卡上。

这位研究者做了一件非常扎实的工作：他系统性地整理了现实世界中发生的63个这类事故，像警察建立犯罪档案一样，把每一个案例的来龙去脉、损失金额、技术原因都记录清楚，然后提出了一套从根本上预防这类事故的方案。这套方案的核心思路，有点像给钱包装上一种特殊的生物锁——这把锁不是等钱被花光了才报警，而是从一开始就让钱无法被复制或偷偷挪走。

一、一份令人不安的"事故档案"

要理解为什么这个问题值得认真对待，先看看研究者建立的这份档案揭示了什么。

研究者花费大量时间，从GitHub（程序员公开分享代码和报告问题的地方）上搜寻与AI代理费用超支相关的真实案例。他搜集了来自21个不同框架（可以理解为21个不同的AI代理工具包）中的记录，时间跨越2023年到2026年。最终整理出110条记录，其中63条是经过确认的真实生产事故，另外47条是框架设计上存在明显漏洞的结构性缺陷记录。

为了确保这份档案的可信度，研究者请了一位完全不知道原始分类结果的独立审核人，对所有记录重新打分。两人之间的一致程度，用学术上衡量评分一致性的指标（Cohen's κ）来表示，达到了0.837，这个数字接近"几乎完全一致"的范畴，说明这些分类不是主观臆断，而是有据可查的客观描述。

这63个真实事故分布在18个不同的技术生态系统里，覆盖了包括LangChain、AutoGPT、CrewAI、AutoGen在内的知名AI工具。其中最触目惊心的案例，是一个用户因为AI代理陷入无限循环，在短短几天内花掉了大约2150美元，折合人民币超过一万五千元。还有一个观察型AI助手在一次工具调用密集的任务中，单次调用就消耗了200万个词元（Token，语言模型计费的基本单位）——那相当于把一本厚厚的百科全书塞进了一次对话。

研究者把这些事故按照根本原因归纳为八类机制，就像医生把不同症状归类到不同病因。第一类是重试循环失控，AI代理在遇到错误时反复重试，每次都花钱；第二类是费用缺乏可见性，开发者根本不知道AI代理在花多少钱；第三类是上下文急剧膨胀，随着对话越来越长，每次调用的费用越来越高；第四类是存储放大，系统把大量数据塞进对话里；第五类是完全缺乏预算机制，框架里根本没有设置花费上限的功能；第六类是多个AI代理同时使用同一个预算，导致超支；第七类是配置参数被悄悄忽略；第八类是多媒体内容（比如图片）导致费用急剧上涨——仅仅一张Base64编码的图片，就能让费用飙升31倍。

这份档案还揭示了一个让人啼笑皆非的事实：连AI领域的头部公司自己的工具也没能幸免。Anthropic公司自己开发的Claude Code工具出现了两个已记录案例，而且在其中一个案例的活动日志里，还能找到至少十个与之相同模式的兄弟案例。Pydantic AI和OpenAI Agents SDK同样有类似记录，其中OpenAI的维护人员甚至直接在问题回应里承认"我们目前在这方面没有什么好的解决方案"。换句话说，这不是某个小工具的疏漏，而是整个AI代理生态系统普遍存在的结构性问题。

另一个值得注意的发现是，档案中记录的那些修复方案几乎都是"事后诸葛亮"。开发团队通常在用户报告了问题之后，才快速打补丁修复——最快的修复记录是当天就完成的。工程师们的响应速度其实很快，但问题在于，所有这些修复都发生在用户已经付出真实金钱代价之后。研究者在整份档案里，没有找到任何一个案例是在用户付出代价之前就被预防的。

二、现有解决方案为什么总是慢半拍

面对这个问题，技术界已经出现了一些应对方案，但研究者通过仔细分析发现，这些方案有一个共同的根本缺陷。

现有的解决方案大致可以分为三个层次，就像保护一个贵重物品的三道防线。第一道防线是运行时软件层——比如AgentGuard这样的工具，它像一个财务监控员，在AI代理运行过程中实时追踪费用，一旦超过阈值就踩刹车。第二道防线是网络传输层——比如ATXP这样的支付网关，当AI代理的"钱包"耗尽时，它会在网络层面拦截请求，返回一个"支付失败"的信号。第三道防线（也是现在最缺失的那道）是编译时层，也就是在程序运行之前，在代码写就和编译的阶段就把问题堵死。

运行时监控和网络拦截的共同问题，可以用一个生动的场景来理解。假设你有一个能自动代替你刷卡消费的助手，你告诉他每个月最多花1000元。运行时监控的做法是：助手每次刷完卡，你的手机才收到通知，检查一下是否超支了。如果某次刷卡让累计费用超过了1000元，这笔钱已经花出去了，你顶多拒绝下一笔。网络拦截的做法是：在银行那端设置一个闸门，当余额不够时拒绝交易，但这笔请求已经发出去了，只是银行拒绝了它。

这两种方式都有一个根本问题：它们无法防止"最后一笔超支"的发生。更深层的问题是，在多个AI代理协作的场景下，假设你委托了三个AI助手分别去完成三个子任务，他们共享一个100元的预算。如果这三个助手同时检查"还剩多少钱"，每个人都看到还有100元，然后每个人都去花钱，最终三个人一共花了三倍的预算。这种并发竞争导致超支的情况，在程序员的世界里有个名字，叫"竞态条件"（Race Condition）。研究者的档案里，有11个案例属于这种类型。

这就引出了研究者的核心洞察：现有方案都是在事情发生后才进行控制，而不是从根本上让"超支这件事在程序语言层面上不可能发生"。

三、用编程语言的"所有权法则"来解决问题

研究者提出的方案，借用了编程语言理论里一个叫做"仿射类型"（Affine Type）的古老概念，把它应用到了AI代理的费用控制上。这个概念听起来很学术，但背后的逻辑其实非常直觉化。

先从一个日常比喻说起。在现实生活中，现金和银行账户有一个关键区别：你手上的一张百元钞票，只能在一个地方使用，你把它给了店员，它就不再属于你了。但银行账户余额是一个数字，理论上可以被复制、被多个系统同时读取，这就留下了"双花"（同一笔钱被花两次）的可能性。在现实银行系统里，这个问题通过严密的数据库锁和事务机制来解决，但代价是复杂的工程实现，一旦有疏漏就会出问题。

Rust语言（研究者选用的编程语言）有一个独特的特性，叫做"所有权系统"（Ownership System）。在Rust里，每一个值（你可以把它理解为一件东西）在任何时刻只能有一个主人。当你把这件东西交给别人，你就不再拥有它了，你也无法再使用它。这不是运行时的检查，而是编译器在你的代码被转换成程序之前就会检查的规则——违反了这条规则，程序根本无法编译，更不可能运行。

研究者把这个机制用在了预算控制上。他创建了一个叫做`Budget`（预算）的数据类型，这个类型代表着一笔可花费的钱。这个`Budget`具备三条铁律，由Rust的编译器自动执行：第一，你不能复制一个`Budget`，就像你不能复印现金一样；第二，当你花掉了这笔预算，原来的`Budget`就消失了，你会得到一个代表剩余金额的新`Budget`；第三，当你把`Budget`的一部分委托给一个子任务，原来的`Budget`就不存在了，你无法再用它花钱。

回到刚才三个AI助手共享预算的场景。在这套方案下，那100元预算被表示为一个`Budget`对象。当你需要把它分给三个助手时，你必须调用一个叫做`split`（分割）的操作，把100元分成三份，比如每份33元。分割之后，原来代表100元的`Budget`对象就被"消费"了，从程序中消失了，你无法再从中花一分钱。三个助手各自拿着自己那份33元的`Budget`，各自只能花33元。如果有人试图悄悄保留原来的100元`Budget`，或者试图复制一个`Budget`对象来拥有双份预算，编译器会直接报错，程序根本无法运行。

为了验证这一点，研究者用了一种叫做"编译失败测试"（compile-fail test）的方法。他写了9个小程序，每个程序都故意包含一种违规操作，比如试图克隆`Budget`、试图在分割后再次使用原预算、试图在转让后继续花钱。这9个程序必须全部被编译器拒绝，才能证明保护机制真实有效。最终这9个测试全部通过——意味着所有违规操作都确实无法编译。

这套方案被命名为`token-budgets`，是一个约1180行代码的Rust库，不包含任何不安全代码（Rust中有一个特殊的`unsafe`关键字，允许绕过某些安全检查，这个库完全禁用了它）。

四、费用估算：在花钱之前先预留"押金"

光有类型系统的保护还不够。因为语言模型的服务是按词元计费的，而你在发出请求之前，并不知道这次请求到底会产生多少词元——这就像去餐厅点菜，你不知道厨师最后会给你上多大的份量。

研究者的方案采用了一种"预先保留押金"的做法。在每次向AI服务发出请求之前，系统先根据请求的内容估算一个最坏情况下的费用，从预算中提前扣除这个估算金额作为押金。如果扣除押金后预算不够了，就直接拒绝这次请求，连网络请求都不发出去。等服务返回了实际的费用报告，再把多扣的押金退回来。

估算的准确性至关重要。如果估算得太高，每次都过度保留，就会导致预算明明还够用，却因为押金过高而被误判为不够用，好用的资源被白白浪费。如果估算得太低，押金不够覆盖实际费用，就会超支。研究者为不同的AI服务提供商（OpenAI、Anthropic等）设计了不同的估算策略，并通过实际测试来验证这些估算的可靠性。

默认的估算策略是按照请求文本的字节长度来估算词元数量，再乘以一个2倍的安全系数。这个方法简单粗暴，但过于保守，实测中平均会多保留实际费用的6.2倍，中位数也有2.51倍。这意味着如果一个用户预充了1000元，实际上只有约160元到400元能真正用于付费，其余的都被押金占用了。

为了改善这个问题，研究者还提供了一个更智能的估算器，叫做`AdaptiveEstimator`（自适应估算器）。它通过学习历史记录来不断修正估算值，实测中能把中位数的过度保留从2.51倍降低到2.11倍。还有一种最精确的方式是直接调用服务商提供的词元计数接口，可以把估算误差压缩到接近1倍（几乎精确），但代价是每次花费前需要额外等待约939到1749毫秒——在需要快速响应的应用里，这可能是个不可接受的延迟。研究者把这三种估算方式的选择权交给了用户，并提供了一个清晰的决策框架：如果你使用后付费账户，额外的资金占用成本可以接受，就用默认的简单估算；如果你使用预付费账户，资金被大量占用会造成真实的资金成本，就值得换用更精准的估算方式，或者承受相应的延迟。

五、实验验证：它真的有用吗

有了理论设计，研究者进行了全面的实验来检验这套方案在现实中的效果。

最核心的对比实验是把这套方案与五种主流的现有工具放在同一个场景下进行测试。测试场景基于档案中真实记录的一个LangGraph（LangChain的工具之一）失控循环案例，设置了一个约合0.054美分的费用上限。五种对比工具分别是LangGraph自带的步数限制、LangGraph加上AgentGuard回调、CrewAI的迭代次数限制、AutoGen的轮次限制，以及LiteLLM的代理预算功能。每种工具都运行30次来看结果的稳定性。

结果非常清晰：五种现有工具在全部30次测试中全部超出了预算上限，超出比例从略微超支到高达1395%不等，取决于使用的AI服务商有多"话多"。而这套Rust方案在全部30次测试中零超支。步数限制之所以超支如此严重，是因为它只能限制调用次数，不能限制每次调用的费用——在使用Anthropic服务的情况下，即使只调用了规定次数内，总费用已经超出预算约881%。AgentGuard这类运行时监控工具虽然能追踪费用，但由于它是在每次调用返回后才检查，所以那最后一次超限的调用已经无法阻止了。

进一步的实验在不同温度参数下（温度参数控制AI回答的随机程度，更高的温度意味着更多变化性）进行了160次测试，包含了四个不同的随机程度设置，涵盖两个主流的生产级AI模型。结果依然是零超支、零误拒。

最能体现这套方案独特价值的是那个"粗心操作员"实验。研究者专门设计了五种不同的实现方式，来模拟在多个AI代理并发执行时的预算管理：一种是使用Python语言、没有任何保护的竞态条件版本；一种是Python语言加上正确编写的锁机制；两种是使用Rust的仿射类型分割预算；还有一种是Rust语言加上手动编写的互斥锁保护。结果同样非常明确：没有保护的Python版本在30次测试中30次超支；而其他四种有保护的版本，无论是Python还是Rust，无论是手动锁还是类型系统，都实现了零超支。

这个对比揭示了类型系统保护的真正价值所在：不是说类型系统比手动锁在结果上更好，而是说类型系统使得那种"写错了就会超支"的代码根本无法编译。一个经验丰富、总是写对锁机制的程序员，用手动锁也能达到同样的效果。但现实中的开发者并不总是经验丰富，并发编程的锁机制也确实容易写错。这套方案的价值在于，即使是一个不太了解并发编程的开发者，也无法写出那种"看起来正确、实际上有竞争问题"的预算管理代码。

研究者还把这套方案集成到了一个叫做Rig的真实Rust AI框架上，用仅约40行代码完成了集成。在实测中，设置了0.05美元的费用上限，40个任务中有22个得到了服务，其余18个在预付款检查阶段就被拒绝了，总费用为0.0404美元，低于上限。四个子代理并发运行时，总费用为0.0400美元，同样控制在上限之内。

六、这套方案有什么局限性

研究者对这套方案的局限性非常坦诚，这种诚实反而让整个研究显得更加可信。

首先是"智能推理模型"（如OpenAI的o系列、Anthropic的扩展思考模式）的问题。这些模型会在内部进行大量"思考"，这些思考产生的词元会被计费，但不在返回给用户的内容里，也不受"最大输出词元数"参数的限制。这意味着估算系统无法提前知道这些"隐藏费用"，保护效果会打折扣。对于这类模型，研究者建议把这套方案作为次要防线，主要依赖服务商自带的思考预算控制功能。

其次是"提供商计费数据可信度"问题。这套方案的费用追踪，依赖于服务商在每次调用后返回的实际费用数据。如果服务商返回的数据是错的（比如少报了费用），系统就会以为自己花得比实际少，从而算出错误的剩余预算。研究者用模拟实验测试了这个场景：当服务商少报2倍时，超支率从0%急剧上升到66.6%；当少报10倍时，超支率达到100%。这个风险不是这套方案特有的，所有客户端的费用追踪系统都面临同样问题，但它是一个真实的信任边界。研究者建议定期把记录的费用与服务商账单进行对账，发现偏差及时修正。

第三个局限是"二进制层面的安全性"（Binary-Level Safety）问题。这套方案在源代码层面的安全性由Rust编译器保证，但从源代码到最终运行的程序文件，中间还经历了编译器的优化、机器码生成等步骤。理论上，编译器的某些优化操作可能会（虽然极不可能）影响安全属性。研究者诚实地承认这个问题目前没有完整的形式化证明，把它列为一个公开的猜想，并估计如果要严格证明它大约需要12个人月的专项工作。

第四个局限是这套方案只能在单个程序进程内工作。如果你有多个服务器实例并行运行（这在大规模部署中很常见），每个实例内部的预算控制是有效的，但跨实例的总预算控制还没有实现。研究者提出了一个基于分布式系统设计模式的解决思路，但承认这需要另一个完整的工程项目来实现。

最后，研究者也坦白地说，这套方案目前只在Rust语言环境下有完整的编译时保护。而目前大部分AI代理应用是用Python写的。虽然研究者提供了一个Python版本，但Python没有Rust那样的类型系统，Python版本只能提供运行时保护，和现有工具处于同一水平，无法做到编译时拦截。

七、放在更大图景中：这套方案的位置

研究者对这套方案的定位非常清醒，始终强调它是"众多解决方案之一"，而不是"终极解决方案"。他专门提供了一个决策矩阵，帮助开发者判断在什么情况下应该用哪种方案。

如果你只使用一个AI服务提供商（比如纯OpenAI环境），并且那个提供商自带了服务端的费用控制功能，那么优先使用提供商自带的功能——这些功能是在提供商的服务器上强制执行的，比任何客户端方案都更可靠，完全无法被客户端代码绕过。如果你的应用部署在AWS上并使用Bedrock服务，那么AWS的会话级预算功能就是最佳选择。如果你在用Python框架（LangChain、CrewAI、AutoGen等），那么AgentGuard、LiteLLM之类的运行时工具是更现实的选择。只有当你在用Rust开发新的AI代理应用，并且需要跨多个提供商管理累计费用时，这套方案才是最合适的选择。

研究者特别指出，这套方案与一个叫做"Agent Contracts"的并行研究方向具有互补性。Agent Contracts是剑桥大学研究团队提出的方案，从代理协作合约的角度来约束资源使用。两者解决同一个问题，但角度不同：Agent Contracts在运行时通过合约机制监控，这套方案在编译时通过类型系统预防。实验显示在正常情况下两者的结果没有差异，但面对"粗心程序员"写出的并发错误代码时，类型系统方案能在编译阶段就把问题消灭，而运行时监控需要程序员自己把锁写对才能生效。

说到底，这项研究最值得称道的地方，是它把一个在实践中反复出现、给真实用户造成真实损失的问题，通过严谨的数据收集和务实的技术创新，给出了一个有据可查的解答。它没有声称彻底解决了所有问题，而是清晰地说明了自己能解决什么、不能解决什么。在AI技术快速发展、很多"解决方案"都夸大其词的今天，这种克制的诚实本身就很难得。

对于普通用户来说，这项研究的直接启示是：如果你或者你的公司正在开发或部署AI代理应用，费用超支不是"如果会发生"的问题，而是"什么时候会发生"的问题。做好预算控制，选择合适的工具，不要依赖"AI应该知道什么时候停下来"这种一厢情愿的期待。对于开发者社区来说，这份63个案例的档案本身就是一份宝贵的参考资料——它告诉我们，费用失控问题不是某个框架的特例，而是整个行业都需要认真面对的设计挑战。

归根结底，这位研究者做的事情，是把一个大家都隐约知道的问题，用数据变成了一个所有人都无法忽视的事实，然后用一套有理论依据、有实验支撑的方案，展示了一种可能的出路。具体技术细节感兴趣的读者可以通过arXiv编号2606.04056查阅完整论文，以及作者在GitHub上公开的所有代码和实验数据。

Q&A

Q1：AI代理费用超支是一个普遍问题还是少数情况？

A：这是一个在AI代理领域普遍存在的结构性问题。研究者从21个主流AI框架中收集到了63个确认的真实事故案例，涵盖LangChain、AutoGPT、CrewAI、AutoGen等知名工具，甚至Anthropic和OpenAI自家的框架也未能幸免。这些事故中包括单次事故损失超过2150美元的案例，说明这不是小概率极端情况，而是整个行业都需要面对的真实挑战。

Q2：token-budgets方案在Python项目中能用吗？

A：可以使用，但效果打折。Python版本只能提供运行时保护，和AgentGuard、LiteLLM等现有工具处于同一水平，无法实现Rust版本特有的编译时拦截能力。Rust版本的核心优势——让错误代码根本无法编译——需要Rust语言的类型系统才能实现。如果你的项目是Python框架，选择AgentGuard或LiteLLM等现有运行时工具是更现实的方案。

Q3：提供商自带的费用控制功能和token-budgets有什么区别？

A：提供商自带的控制更强，但更粗粒度。比如OpenAI的max_completion_tokens是在服务商服务器上执行的，无法被客户端代码绕过，但它只能控制单次调用的输出，不能设置跨多个调用的累计预算，也不支持多个AI代理共享一个总预算的场景。token-budgets的优势在于可以精细控制跨多次调用的累计费用，以及在多个子代理之间分配和追踪预算，并且在Rust环境下提供编译时的防误操作保护。