作者 | Mark Silvester

譯者 | 馬可薇

這項工作對于所有在持續集成（CI）環境中運行大語言模型（LLM）Agent 的團隊都具有參考價值，因為定時執行的自動化任務往往會在不易察覺的情況下持續累積成本。GitHub 會將所有 Agent 調用統一通過一個 API 代理轉發，并為每次運行生成一個token-usage.jsonl文件，以統一格式記錄輸入 Token、輸出 Token 和緩存 Token 的使用情況，適用于 Claude CLI、Copilot CLI 和 Codex CLI。

為了能夠跨不同模型進行成本比較，團隊設計了一項名為“等效 Token（ET）”的指標。該指標將輸出 Token 按 4 倍權重計算，將緩存讀取 Token 按 0.1 倍權重計算，然后再根據模型類型應用不同的系數：Haiku 為 0.25 倍，Sonnet 為 1.0 倍，Opus 為 5.0 倍。按照這種計算方式，無論使用哪種模型，ET 下降 10% 都對應著約 10% 的成本下降。

整個優化閉環由兩個 Agent 工作流驅動。“每日 Token 使用審計器”負責按工作流匯總資源消耗、標記異常運行情況，并找出成本最高的任務。當審計器發現某個工作流值得關注時，“每日 Token 優化器”會讀取相關源碼和近期日志，自動創建 GitHub Issue，并提出具體的優化建議。這兩個 Agent 本身的消耗情況也會被納入同一份日報統計。

優化器發現的最常見低效來源是未被使用的 MCP 工具。由于 LLM API 本質上是無狀態的，每次請求都需要攜帶工具 Schema，因此一個包含 40 個工具的 GitHub MCP Server，每輪交互可能會額外增加 10 KB 至 15 KB 的 Schema 內容。在 GitHub 的冒煙測試工作流中，僅僅刪除未使用的工具定義，就能讓每次調用的上下文減少約 8 KB 至 12 KB。

團隊還將獲取 Pull Request Diff 和文件內容等操作，從 MCP 調用改為直接使用ghCLI 命令。這些數據要么在 Agent 啟動前預先下載到工作目錄中，要么通過透明 HTTP 代理在運行時獲取，從而避免將認證 Token 暴露給 Agent。

在十多個生產環境工作流中，優化效果十分明顯。Auto-Triage Issues 在修復后的 109 次運行中持續實現了 62% 的 ET 降幅，Security Guard 降低了 43%，Smoke Claude 降低了 59%，而“每日社區歸因”也實現了 37% 的改善。唯一出現反向變化的是 Contribution Check，其 ET 增加了 5%。GitHub 認為，這并非優化失效，而是因為工作負載發生變化，處理的大型 Pull Request 數量有所增加。

不過，團隊也指出了 MCP 精簡策略的局限性。以“每日社區歸因”為例，該工作流包含 8 個未使用的 GitHub MCP 工具，并且整個運行過程中從未調用過這些工具，但即便將其移除，ET 指標也沒有下降。GitHub 對此解釋道：“在這個工作流中，工具清單只占整體上下文中很小的一部分。”

目前，Anthropic 和 OpenAI 都提供 Prompt 緩存功能，而 LangChain 也支持基于 Callback 的 Agent Token 追蹤機制。GitHub 的創新點則在于構建了一套“審計——優化”閉環，將代理層的可觀測性與能夠自動創建 Issue 的優化 Agent 結合起來。目前，Auditor 和 Optimiser 已經作為gh-awCLI 的組成部分提供給用戶使用。GitHub 在文章中寫道：“最便宜的一次 LLM 調用，就是根本不發生的那一次調用。”

GitHub 表示，下一階段的重點將轉向工作流組合層面的分析，尋找代碼倉庫內多個工作流之間重復讀取的數據和可共享的中間產物，從而進一步降低整體 Agent 工作流的運行成本。

GitHub Slashes Agent Workflow Token Spend up to 62% with Daily Audits and MCP Pruning - InfoQ(https://www.infoq.com/news/2026/05/github-agentic-token-savings/)

會議推薦

企業級 Agent 落地，繞不開 4 個真實的工程問題！如何在 Agent 安全性和可用性之間找到平衡點？Agent 需要什么樣的記憶系統才能真正理解上下文？如何通過算法壓榨實現智力增量與成本控制的極致平衡？多 Agent 協作，如何做到可觀測、可治理、可控制？6.26-27 AICon 上海站，國內頭部公司的 Agent 實踐，一次說透。

今日薦文

你也「在看」嗎？