這項由英國西英格蘭大學布里斯托爾分校數據科學專業獨立研究者完成的研究，發表於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環境下提供編譯時的防誤操作保護。
