補貼結束：使用工具的代理實際成本

6月1日，GitHub Copilot對所有計劃啟用了基於使用量的計費，這一變化迅速引發了開發者的強烈反應。雖然專業版計劃仍保持10美元月費，但增加了每月AI信用額度池。每個信用額度售價1美分，根據使用的模型和處理的令牌（包括輸入、輸出和快取令牌）消耗。對於執行前沿模型的密集代理會話，這種計費方式與固定的訂閱模式截然不同。

但這一新聞的核心並非計費本身。代理工作流的底層成本在6月1日並沒有實際變化——令牌一直在消耗，迴圈一直在執行，工具呼叫一直在擴充套件上下文。真正變化的是，計量表變得可見了。在固定費率下被默默補貼的工作負載，現在顯示為逐項賬單。

令牌去向

要理解為何賬單如此沉重，可以比較兩種看似相似但計費方式截然不同的場景。聊天補全接近單次交易：你傳送提示，模型回覆答案，大致為輸入和輸出各付費一次。但使用工具的代理截然不同。代理並非回答問題，而是透過迴圈逐步逼近目標：它推理任務、呼叫工具、讀取結果、再次推理、呼叫另一個工具，直到認為任務完成。

每次迴圈迭代都包含容易忽略的成本。在許多代理框架中，每次輪次都會攜帶大量累積的上下文：先前的訊息、工具描述、檢索的檔案和工具結果。即使部分上下文被快取、總結或剪枝，系統仍需執行計量工作來保留足夠狀態供下一步決策。你最終想要的答案只是所支付費用的一小部分。迴圈本身就是賬單。

這就是代理成本不能優雅擴充套件的原因。它隨著輪次數擴充套件，而輪次數又隨代理需要多少發現而擴充套件，這進一步取決於請求的模糊性和攜帶的不相關上下文的量。一個清晰、範圍明確的任務可能在三個輪次內完成，而同一個任務以開放式問題提出可能會漫遊15個輪次，每個輪次都攜帶之前所有成本。在固定費率下，這種差異不可見；在基於使用量的計費下，這決定了是一次小互動還是一次昂貴互動。

工具設計成為成本模型的一部分

我最近寫過關於模型上下文協議伺服器的隱性稅收：臃腫的工具目錄如何悄悄降低模型路由到正確工具的能力。冗長的描述、重疊的職責和模糊的引數使模型工作更困難、選擇更差。那個論點關乎準確性。計費變化為此類臃腫增加了第二張賬單，這次以美元計。

工具目錄通常部分內容會透過代理迴圈攜帶。一個用三句緊湊句子描述的工具和一個用三段冗長段落描述的工具可能都能工作，但後者每次載入代理時都要在上下文中支付租金。乘以40個工具的目錄和執行十二輪次的工作流，冗長工具設計的成本就不再是舍入誤差。工具設計已經是一門正確性學科，現在也成了成本紀律。同樣的審計在提高路由準確性的同時，也收緊了賬單。

提示紀律的侷限

有個層面是個人使用者可以控制的，因為節省效果真實且立竿見影。兩種模式最為重要，我已將它們傳授給一個大型醫療組織試點專案中的工程師。它們不是魔法，而是讓代理避免不必要發現迴圈的方法。

第一種模式關於輸入。將提示代理的方式從寬泛問題改為簡短需求。例如，“檢視就診資料並告訴我發現了什麼”迫使代理進入發現模式，消耗輪次弄清楚你的意圖，而每個輪次都攜帶全部上下文。相比之下，一個提前明確指定專案、表名、過濾日期欄位、所需輸出形狀和排除項的提示能大大壓縮迴圈。例如：“使用精選臨床專案和銀區就診表，顯示2025年每個月的就診總數，使用admission_date_time進行包含，按月返回一行，按時間排序。”第二個提示簡化了迴圈，代理在第一個輪次就獲得所需資訊，直接工作而非反覆詢問。

實踐中，這種差異不僅是潤色。模糊版本迫使代理發現資料模型、推斷日期語義、選擇聚合方式和決定顯示格式。具體版本將任務轉化為有邊界的查詢。這種差異體現在準確性、延遲和成本上。

第二種模式關於輸出，這是大多數人忽略的槓桿。在中間步驟請求純文本或Markdown，只在最終確認的可交付成果時使用富HTML格式。格式化輸出生成成本高，且需求會變化。如果一開始就要求一份精美的HTML報告，然後改變篩選條件，你將為重新生成所有佈局支付完整輸出令牌費用，通常不止一次。更經濟的做法是先用文本驗證資料，只在最後格式化。

這些模式有效，但也有上限。它們將成本控制的所有負擔放在使用者身上，且只在每個使用者每次提示都保持紀律時才有效。一旦有人回到“告訴我發現了什麼”，節省就蒸發，團隊和意外賬單之間只隔著一個預算上限，而它只會在超額髮生後報告。

成本是治理問題，而非預算問題

這種脆弱性是真正的教訓。預算上限是事後限制而非控制。它可以阻止失控，但只告訴你超支了多少而非原因，也無法讓下一次執行更便宜。將成本視為預算問題讓你永遠對計量表做出反應，而將其視為架構問題則能一次性構建節省，無需依賴每個人的良好行為。

這意味著重要的控制屬於平臺，而非單個提示。這裡的平臺並非代理本身（開發人員日常使用的編碼助手或聊天客戶端），也非模型或其下的路由器。而是位於代理之上的控制平面，組織在此強制執行策略、訪問、可觀測性以及現在的成本控制，覆蓋所有代理和模型。一個讓IT能看到誰在做什麼以及能安裝哪些功能的管理控制台是其早期窄例項。一個將規劃傳送給廉價模型的路由器是其中的一個功能。平臺是規則存放處，代理消費規則而非設定規則。平臺應根據任務路由模型，用廉價模型進行規劃，保留前沿模型用於值得其價格的工作。它應限制迴圈，要求代理在固定迭代次數後檢查。它應限制工具結果負載，防止粗心查詢將一百萬行轉儲到上下文視窗。它應預設中間工作使用純文本，使廉價路徑成為阻力最小的路徑，而非使用者必須記住的事情。

這些控制中的每一個使用者都可以手動近似，而平臺可以簡單保證。這正是我在資料訪問背景下反覆強調的原則：安全行為不能依賴鍵盤前的人記住規則。提示指導行為，而護欄讓更便宜、更安全的行為成為預設。成本治理就是作為控制平面的護欄，帶有美元符號，在你已經執行誰可以看哪些行的同一層強制執行。

模式，而非供應商

將本文僅視為GitHub的故事將是錯誤的。GitHub是當前示例，因為其變化可見且近期，但基於使用量的代理工作計費是許多AI工具的發展方向。底層的經濟邏輯類似：代理工作負載將單次答案轉化為模型呼叫、工具呼叫和上下文管理的迴圈。一旦工作負載從自動補全轉向自主，固定費率補貼遲早會面臨壓力。

將6月1日視為定價事件的組織會最佳化幾個提示、抱怨並繼續前進，直到下一個供應商改變計量。而將其視為架構訊號的組織會將成本控制下沉到平臺中，無論哪個供應商在計數哪類令牌，這些控制都有效。這是更持久的立場。這個月的賬單沒有變大，它變得誠實了，而誠實的賬單正是你可以設計應對的。