GitHub測試5000個AI代理人同時作業，每秒處理7200次推送

GitHub在單一儲存庫中測試5000個AI代理人同時作業，並以每秒7200次推送的速度處理程式碼變更；GitHub表示，測試期間讀取請求也維持低延遲。推送是將修改後的程式碼傳送至遠端儲存庫。

GitHub於5日在官方技術部落格公布，新版Git儲存架構名為「Rubicon」。這項架構設計在2026年5月首次遷移至Azure後展開。

GitHub舉例指出，單一儲存庫的日均請求量從2026年3月的4400萬次，增至同年5月的1億8100萬次，約增加4倍。

GitHub表示，目前最繁忙的儲存庫在短時間內每秒會收到數十次寫入請求。GitHub在5日的技術說明中預期，若AI代理人未來能持續並行作業，這類短暫的請求集中可能在一年內轉變為持續的寫入需求。

推送增加時，讀取請求也會跟著增加。自動測試與部署系統會取得新程式碼，其他AI代理人也會讀取最新版本，以掌握工作脈絡。

GitHub先前已推出Copilot Projects公開測試版，用來協調多個儲存庫中的代理人工作。此次技術說明則聚焦於支援代理人作業的儲存庫讀寫架構。

Git不會用新內容覆寫既有紀錄，而是將程式碼存為新的物件。推送時還必須更新各分支所指向的最新版本。

Rubicon將程式碼資料與分支資訊分開管理。程式碼資料包存放在Azure Blob Storage，分支資訊及已儲存資料包的清單則由獨立服務Ref-CAS管理。

Ref-CAS只檢查每項作業要修改的分支，再更新該分支。不同分支的變更可以同時處理；若兩項作業同時修改同一分支，系統就必須協調衝突。

推送程式碼時，虛擬副本會先處理新的資料包並上傳至Blob Storage，接著在Ref-CAS記錄一筆交易，同步更新資料包清單與分支資訊。

收到讀取請求後，虛擬副本會向Ref-CAS確認分支資訊的版本，再載入所需資料包。如果版本沒有變動，就能透過一次比對處理請求，無須重新取得整份分支清單。

負責讀寫的虛擬副本會使用可重建的快取。GitHub也將架構設計為能在儲存庫請求量增加時擴充虛擬副本。

新推送累積出大量資料包時，獨立節點會在背景合併資料包。GitHub將這項整理工作與虛擬副本的處理資源分開，讓後者能專注於讀寫請求；清除未被引用物件的垃圾回收工作也交由專用程序處理。

GitHub最初測試將所有分支變更寫入同一筆紀錄，但每秒寫入量僅數百次。改為將紀錄拆成多個部分後，寫入量雖然增加，讀取卻變慢，因為確認儲存庫是否變更時必須逐一查詢各個部分。

GitHub表示，若只計算參照狀態更新，新架構每秒可處理數萬次作業。Rubicon目前仍處於範圍有限的非公開測試階段，GitHub計畫在2027年初擴大適用範圍。