為 Agent 規模開發建構 Git 基礎設施

應對 Agent 開發挑戰，GitHub 開始重構 Git 基礎設施

GitHub 官方宣布，為了應付「Agentic software development」（代理式軟體開發）帶來的架構挑戰，公司正在重建 Git 基礎設施。GitHub 正依據新的設計原則重構底層，以支援大規模的併發讀寫。

數據顯示的規模與成長趨勢

根據 GitHub 提供的數據，目前負載最高的工作量，反映出這個平台要面對的規模。2026 年 8 月的資料顯示，GitHub 上最繁忙的儲存庫每月約有十億次請求。整體 Git 活動也在快速成長：從 2025 年 9 月到 2026 年 8 月，GitHub 每月的 Git 事件數量從 2182 億次增加到 4733 億次，成長超過兩倍。

在代理式開發走得最前面的大型工程團隊，除了跑繁忙的 CI 管線，還部署了越來越多的 Agent 群組。光是 9 月，開發者與 Agent 在 GitHub 上就進行了 73.8 億次提交，是一年前的五倍以上。GitHub Actions 當月執行了 32.6 億次，同樣是去年同期的四倍以上。這些數據顯示，要支援這些團隊，就必須建構能處理持續、高併發讀寫的 Git 基礎設施。

現行架構面臨的五大技術瓶頸

針對上述規模，GitHub 指出現行架構有幾個關鍵問題。

首先，Agent 的提交週轉時間成為瓶頸。Agent 在緊密迴圈中，幾乎每個動作後都會提交或建立檢查點，速度受限於單一推送完成的速度，人類開發者不會察覺的延遲，反而成了限制因素。

其次，寫入吞吐量需求呈數量級成長。每月推送次數從 6.9 億次增至 33.5 億次，年增率達 4.9 倍。數千個 Agent 在單一儲存庫的不同分支上工作，產生持續的寫入，而這些寫入集中在架構的單一節點。

第三，合併操作會在單一參考點上形成競爭。基於主幹的開發、發布列車和合併隊列，把所有工作都匯聚到單一參考點。GitHub 上的拉取請求合併量，已經成長到一年前的近四倍。

第四，每次推送會衍生出數千次讀取。CI 和程式碼掃描每分鐘可能對同一分支尖端克隆或獲取數千次。GitHub Actions 的執行次數在 9 月達到 32.6 億次，比一年前成長超過四倍。

最後，儲存庫操作必須維持快速。為了維持速度，系統得持續壓縮儲存庫資料，並清理不再需要的物件。每次新寫入都會加重這項工作，而且隨著容量上升，成本會以複利方式增加。

舊架構的限制與新設計原則

目前的架構依賴 Spokes 系統，把儲存庫的完整副本存放在數個檔案伺服器的本機磁碟上，預設為五個副本。這套機制透過三階段提交協議確保一致性，但把耐用性與擴展性綁在一起。要增加讀取容量，就得增加耐用副本，而每個副本都要參與每一次寫入，所以寫入速度受限於最慢的副本。在活動量最高的情況下，這成了效能天花板。

為了解決這個問題，GitHub 提出新的設計原則。

首先是最小化協調。系統將重新設計，只在真正需要共識的參考點更新時才進行協調，物件儲存、驗證和機密掃描等工作則可並行處理，縮短推送的關鍵路徑。壓縮和垃圾回收等維護工作，會移到獨立的工作節點，避免影響即時請求。

其次是解耦儲存與運算。新架構會把權威儲存庫資料放在 Azure Blob Storage，由它提供耐用性和複製能力。運算層則由輕量級工作節點組成，負責快取資料來服務請求。這樣的分離讓讀取容量可以獨立擴展，不必增加耐用副本，就能吸收 CI 扇出和 Agent 群組帶來的讀取尖峰。

可靠性與控制權的平衡

GitHub 強調，建構新架構的過程不會中斷服務，也不會要求用戶改變軟體開發方式。新系統要支援最嚴苛的工作負載，包括受嚴格監管要求的企業、建置作業系統的團隊，以及運行數千個 Agent 的組織。這些工程挑戰的成果，將讓所有用戶受益，從審閱各時區志願者貢獻的維護者到初次提交拉取請求的學生都包括在內。

新架構必須保留團隊現有的控制機制，包括分支保護、必要審查、稽核日誌和儲存庫可見性。GitHub 的指導原則包括：建立在開發者已經信任的工作流程上、把可靠性放在第一位，以及讓人們繼續掌控自己的程式碼。

未來展望

在內部基準測試中，新架構的寫入吞吐量最高提升了 35 倍，讀取容量也能獨立擴展以滿足需求。GitHub 表示，隨著自動化開發提高軟體變更的頻率和併發性，平台會持續調整其基礎設施，同時不犧牲團隊所依賴的治理和控制。後續文章將深入探討未來架構及相關發展歷程。