提高 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 代理、開啓日誌記錄，讓數據指引優化方向。