在開發 AI Agent（AI 代理）的自動化工作流時，許多工程師最頭痛的不是 AI 能不能完成任務，而是 Token 消耗導致的成本失控。特別是當 Agent 被整合進 CI（持續整合）流程中，大量定時執行的任務會悄悄累積高昂費用。GitHub 最近分享了他們如何將 Agent 工作流的 Token 支出降低高達 62% 的實務經驗，這對於任何在生產環境運行 LLM Agent 的團隊都有極高的參考價值。
成本監控的基礎：統一度量衡
要優化成本，首先必須能精準地量化它。GitHub 建立了一套 API Proxy（API 代理伺服器），讓所有 Agent 的呼叫都經過這個通道，並將輸入、輸出與快取 Token 統一記錄在 token-usage.jsonl 檔案中。
由於不同等級的模型（如 Claude 的 Haiku, Sonnet, Opus）價格差異巨大，GitHub 引入了 Effective Tokens（有效 Token，簡稱 ET）這個指標。他們將輸出 Token 的權重設為 4 倍，快取讀取設為 0.1 倍，再乘以模型本身的價格倍率。這樣做的好處是，無論使用哪種模型，只要 ET 下降 10%，就代表實際成本降低了 10%，讓團隊能用統一的標準來衡量優化成效。
解決 Token 浪費的關鍵：MCP 剪枝與工具替換
在 Agent 的運作機制中，有一個常見的成本陷阱：工具定義（Tool Schemas）。GitHub 使用了 MCP（Model Context Protocol，模型上下文協定），這是一種讓 AI 能與外部工具溝通的標準。但因為 LLM API 是無狀態的（Stateless），每次對話都必須把所有可用工具的定義重新傳給 AI。
如果一個 MCP 伺服器提供了 40 個工具，即便 AI 這次對話只用到其中一個，其餘 39 個工具的定義依然會佔用 10 到 15 KB 的上下文空間。GitHub 發現許多工具在特定工作流中根本沒被用到，因此採取了 MCP Pruning（MCP 剪枝），將不必要的工具定義移除。在某些煙測試（Smoke-test）工作流中，單次呼叫就能省下 8 到 12 KB 的上下文。
除了剪枝，GitHub 還將部分 MCP 呼叫替換為 gh CLI（GitHub 命令行工具）。例如獲取 Pull Request 的差異（Diff）或檔案內容時，直接透過 CLI 預先下載到工作區，或透過透明 HTTP 代理處理，避免 AI 在對話過程中反覆透過昂貴的 API 呼叫來獲取基礎資訊。
建立自動化優化閉環
GitHub 最核心的創新在於將優化過程本身也交給 AI Agent 來處理，形成一個閉環：
首先是 Daily Token Usage Auditor（每日 Token 使用審計員）。它負責分析所有工作流的消耗量，找出異常飆高的執行紀錄，並標記出最昂貴的任務。
接著是 Daily Token Optimiser（每日 Token 優化員）。當審計員發現問題後，優化員會讀取該工作流的原始碼與最近的日誌，分析浪費原因，直接開啟一個 GitHub Issue 並提出具體的修復建議。
這種以 Agent 優化 Agent 的模式，讓成本管理從手動分析變成了自動化的維運流程。
實務限制與啟發
值得注意的是，並非所有優化手段都有效。GitHub 發現，在某些工作流中，即使移除了完全沒用到的工具，ET 也沒有下降。這是因為該工作流的整體上下文非常大，工具定義所佔的比例微乎其微，因此剪枝的效果被稀釋了。
這給我們的啟發是：優化必須建立在數據分析之上。先透過監控找出真正的瓶頸（是工具定義太冗長？還是對話輪數太多？或是輸入資料過大？），再採取對應的手段。
總結來說，GitHub 的經驗告訴我們，最便宜的 LLM 呼叫就是那些不需要發出的呼叫。透過統一的度量指標、精簡上下文內容以及自動化的審計機制，開發者可以在維持 Agent 能力的前提下，大幅壓低營運成本。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。