提高 GitHub 代理工作流中的令牌效率

GitHub 的代理工作流（Agentic Workflows）就像一組街道清潔工，負責清理倉庫中的小雜亂。這些工作流顯著改善了倉庫的衛生和質量，但與其他代理工作一樣，成本已成為開發者日益關注的問題。由於 CI 作業會自動排程和觸發，成本可能會在無形中累積。

幸運的是，使自動化更高效比最佳化互動式桌面會話更容易。開發者會話期間的工作難以預測，但代理工作流的工作完全在 YAML 中指定，並且每次執行都會重複。

GitHub 在自己的倉庫中維護並使用 Agentic Workflows，因此與使用者一樣關心令牌效率。在 2026 年 4 月，他們開始系統性地最佳化許多日常依賴的工作流的令牌使用。

首先，他們需要記錄令牌使用情況。每個代理框架（Claude CLI、Copilot CLI、Codex CLI）以不同格式輸出日誌，歷史執行資料可能不完整。但代理工作流的安全架構使用 API 代理來防止代理直接訪問身份驗證憑據。這個代理使得能夠以單一的標準化格式捕獲所有執行的令牌使用。現在，每個工作流都會輸出一個 token-usage.jsonl 工件，包含每條 API 呼叫的輸入令牌、輸出令牌、快取讀取令牌、快取寫入令牌、模型、提供者和時間戳。

有了令牌資料後，他們構建了兩個每日最佳化工作流：每日令牌使用審計員和每日令牌最佳化器。審計員讀取近期工作流執行的令牌使用工件，按工作流聚合消耗，並標記異常。最佳化器則檢視被標記工作流的原始碼和日誌，建立 Issue 描述低效問題並提出最佳化建議。

根據初步結果，最常見的低效問題是未使用的 MCP 工具註冊。由於 LLM API 是無狀態的，代理執行時通常會在每個請求中包含 MCP 工具函式名稱和 JSON 模式。對於包含 40 個工具的 GitHub MCP 伺服器，每次互動可能增加 10–15 KB 的模式。如果代理只使用兩個工具，其餘 38 個就是純粹的額外開銷。在煙霧測試工作流中，移除未使用的工具將每呼叫上下文大小減少了 8–12 KB，每次執行節省了數千個令牌。

一個更大的結構性機會是將資料獲取操作（如檢索拉取請求差異、檔案內容和審查評論）從 GitHub MCP 呼叫替換為 GitHub CLI 呼叫。MCP 工具呼叫除了資料檢索外，還是一個推理步驟，消耗額外的令牌。而呼叫 'gh pr diff' 則是一個確定性的 HTTP 請求，無需 LLM 參與。他們採用了兩種遷移策略：代理前資料下載和代理內 CLI 代理替換。這些技術將大多數 GitHub 資料獲取移出了 LLM 推理迴圈。

衡量效率提升並不容易，存在三個混雜因素：並非所有令牌都同等重要（不同模型成本不同），工作量變化（倉庫是即時的），以及輸出質量是否改變。為了標準化模型差異，他們使用了有效令牌（ET）指標：ET = m × (1.0 × I + 0.1 × C + 4.0 × O)，其中 m 是模型成本乘數，I 是輸入令牌，C 是快取讀取令牌，O 是輸出令牌。輸出令牌權重為 4 倍，快取讀取令牌權重為 0.1 倍。該公式將不同模型層的消耗標準化。

初步結果顯示了顯著的成本節約。在 gh-aw 和 gh-aw-firewall 倉庫中的十二個生產工作流中部署後，Auto-Triage Issues 工作流在 109 次修復後執行中顯示出 62% 的減少，Daily Compiler Quality 改善 19%，Daily Community Attribution 改善 37%。在 gh-aw-firewall 倉庫中，Security Guard 和 Smoke Claude 分別改善了 43% 和 59%。執行頻率同樣重要，Auto-Triage Issues 平均每天執行 6.8 次，其最佳化累計節省了約 7.8 M ET。

基於這些結果，他們強調了三個模式：許多代理輪次是確定性的資料收集；未使用的工具成本高昂；單個錯誤配置的規則可能導致迴圈失控。例如，Daily Syntax Error Quality 工作流因一行配置錯誤導致代理陷入 64 輪的回退迴圈。

下一步計劃包括將單體代理重構為子代理團隊、從工作流級最佳化轉向系統級最佳化，以及分析工作流組合中的重疊。他們強調，第一步是新增 API 代理、開啟日誌記錄，讓資料指引最佳化方向。