GitHub Rubicon 新儲存架構：5000 個 AI 代理同時推送，為何只讓分支更新排隊？

一個代理寫程式會推送修改，數千個代理同時工作時，程式碼平台還得承受更多測試、部署與其他代理的讀取。

GitHub Rubicon 儲存架構的細節在 2026 年 11 月 5 日公開，內部測試支援五千個代理同時對同一程式庫工作，每秒送出七千二百次推送。

這個數字描述指定內測，架構仍處於限量私有預覽，廣泛推出預計在明年，並非所有程式庫已經獲得相同速度。

它的主要做法，是把可平行儲存的 Git 物件，與需要確認先後順序的分支更新分開處理。

我認為這對維護大量代理的平台與大型程式庫團隊最值得關注，一般開發者則不需要為它改掉熟悉的 Git 操作。

要看懂為何能拆開，先從一次推送裡有哪些資料必須取得共識說起。

AI 代理為何改變 GitHub 儲存需求？

代理增加的寫入，會帶出更多持續整合、部署與上下文讀取。

傳統開發可能是一個人整理一批修改後再推送，代理則能平行處理多個任務，持續建立分支與送出變更。平台面對的流量形狀，因此可能從短暫尖峰變成長時間高負載。

GitHub 新工程文把需求分成兩個方向。一個是很多使用者在不同程式庫工作，另一個是大量代理同時擠進同一個程式庫。

後者不能只靠把不同客戶分配到更多機器解決。當一個大型專案突然有很多代理同時工作，這一個程式庫本身就要支援更多寫入與讀取。

每次推送還會引出其他工作。持續整合開始測試、部署系統拉取版本，其他代理也會重新取得背景，因此寫入增加時，讀取可能被進一步放大。

官方舉例，一個程式庫從三月至五月的每日請求，平均由約 4400 萬增至約 1.81 億。因為資料只來自單一程式庫，這個約四倍成長便不能當成整個 GitHub 的平均。

當時最繁忙的程式庫，仍多是短時間每秒數十次寫入。但團隊把新架構目標設在高兩個數量級的需求，因為代理可能把目前的尖峰變成日常。

需求不只是一台伺服器更快，因此需要先分開哪些資料可以獨立寫入。

為什麼 Git 物件可以平行存，分支卻要排序？

Git 物件建立後不再改動，但分支名稱指向哪個版本需要一致答案。

Git 物件包括檔案內容、目錄結構與提交資料。它們以內容辨識，建立後不再修改，所以兩個代理寫入不同的新物件時，通常不需要先等彼此同意。

但分支參照需要不同處理。像 main 這個名字目前指向哪一個提交，會影響其他人讀到什麼。若兩個人同時想把它改到不同位置，就需要確認原值與更新順序。

這個差異把一次推送拆成兩種工作。較大的物件資料可以先平行保存，較小的參照更新再取得一致結果，避免讓所有內容都擠在同一條寫入隊伍。

Ref-CAS 名稱中的 CAS 是比較後交換。它先檢查參照是否仍等於寫入者預期的舊值，再決定是否接受更新，因此可以拒絕已經落後的修改。

若兩個代理改的是各自分支，因為參照不同，交易便能平行前進。若兩者競爭同一個參照，系統仍只接受符合條件的一個更新，並沒有取消衝突處理。

因此，這個架構改善的是平台協調大量變更的方式。兩個代理在程式邏輯上互相矛盾，仍需要開發流程處理，儲存服務不會替團隊判斷哪份程式才是正確答案。

這個差異讓持久資料可以分成兩個服務，各自處理不同工作。

Rubicon 如何分開 Blob Storage 與 Ref-CAS？

大型物件先保存到 Blob Storage，再由 Ref-CAS 交易更新分支與物件清單。

Blob Storage 是大型物件儲存服務，適合保存建立後不再變動的資料。Rubicon 把 Git 資料包與讀取加速資料放進這裡，將需要快速共識的少量狀態另交給 Ref-CAS。

寫入時，虛擬副本先處理收到的資料包，確認索引與物件連接關係，再上傳到 Blob Storage。資料已經耐久保存後，才提交參照交易。

這筆交易同時把資料包加入清單並更新分支參照。因為物件已先保存，其他讀者看見新版本時，就能沿清單找到內容，避免分支先變、資料卻還沒到。

Ref-CAS 本身不保存或驗證大型物件，它保存指向物件的資訊。因為只需確認參照更新，所以多數副本記錄的是較小交易，沒有把大型物件也送進相同的共識流程。

交易也只鎖住它會碰到的參照，先檢查預期原值。這讓不同分支不必因為同屬一個程式庫，就在同一把大鎖後面排隊。

官方曾嘗試把所有參照更新集中到一個儲存物件，結果吞吐量卡在每次往返的等待。拆成多個片段能提升寫入，讀取卻又得逐一檢查，容易被最慢片段拖住。

最後採用專用的複製日誌服務，正是為了分開這兩種需求。物件儲存擅長大量保存，參照服務則專心處理較小、需要一致順序的變動，兩者各做適合的工作。

資料放好之後，服務讀寫的運算節點便不必同時承擔永久保存責任。

虛擬副本為何可以壞掉後重建？

虛擬副本的本機磁碟只是快取，正確性依靠可回查的持久狀態。

流量先由 Spokes 路由到分配給程式庫的虛擬副本。這些節點可以提供讀取、寫入或兩者，自己的磁碟只保存可重新建立的快取。

平台會盡量把同一個程式庫的流量導回相同節點，因為已經有快取就比較少下載資料。不過，正確性不依賴某一台特定節點一直存活。

節點失效時，其他副本可以繼續服務，替代節點再依流量從持久儲存補回資料。這讓運算資源較容易增減，不必把每一台機器都當成永久資料保管者。

讀取開始時，副本先和 Ref-CAS 比對版本。版本以日誌序號表示，若本機狀態仍是最新，服務回覆不必附上整套參照資料，只需要確認沒有變動。

如果已經落後，才取得新的參照、版本與資料包指標。副本接著下載需要的內容，再提供讀取，因此平常沒有修改的程式庫可以少做很多重複工作。

這個設計把快取命中與資料正確分開。快取雖能改善速度，但它可能落後最新修改，所以仍需持久狀態與版本檢查，才能知道讀取該用哪份內容。

當某個專案突然增加代理，平台可以加入更多副本承接流量。但新增副本仍要取得所需資料，因此擴張能力不等於完全沒有啟動或資料傳輸成本。

副本能擴張解決前台流量，但每次推送新增的資料包還需要另外整理。

獨立壓縮如何避免新推送拖慢舊資料讀取？

背景節點合併資料包，讓讀寫節點把資源集中在使用者請求。

每次推送都可能新增資料包。因為每個包都可能包含需要的物件，資料包愈多，讀取就愈容易花時間查找。因此只改善寫入吞吐，還不足以維持長期服務速度。

Rubicon 把壓縮整理移到獨立背景節點，直接對持久儲存工作。前台虛擬副本可以集中 CPU 與記憶體處理請求，不必同時反覆執行相同維護。

背景節點先取得某一份區段的租約，避免多台機器同時整理相同範圍。它把新資料包收進區段，達到數量、大小或時間條件後，就封存該區段並開始合併。

合併期間，下一個區段仍可以接收新推送。這讓整理與新資料進入分開進行，不必為了處理一批舊內容，就讓所有代理停下來等待。

發布新資料包前，系統會確認它包含的物件和原本相同。上傳並加入清單後，再用另一筆交易移除舊資料包的清單項目，最後才進行清理。

這裡的合併會保留所有物件。真正移除已經沒有任何參照指向的物件，屬於垃圾回收的工作，因此不能把壓縮理解成隨意刪除舊提交。

多個區段可以由不同節點平行處理，資料包也會逐層合併成較大的包。官方要維持的是推送量增加時，資料包數量仍受控制，讀取不會因碎片愈來愈多而持續變慢。

分開運算之後，內部測試數字才有清楚的機制脈絡與適用範圍。

7200 次推送內測能證明什麼，哪些仍是規畫？

測試說明新架構能承擔高並行工作，並未保證所有程式庫都已完成遷移。

五千個並行代理、每秒七千二百次推送，是團隊在內部測試中展示的結果。它支持新架構能承受高並行工作，並不構成每個客戶當下可取得的容量承諾。

同樣地，低延遲讀取是該測試的觀察，原文沒有給所有公開專案都必須達到的固定毫秒上限。要比較其他系統，還得知道資料量、推送大小與測試負載。

截至這篇公告，架構仍在限量私有預覽，較廣泛推出安排在隔年初。GitHub 在前一週 Universe 已介紹方向，11 月 5 日的新內容是更完整的架構與取捨。

後續計畫包括只讀取需要的物件、依類型整理資料包、部分副本、全球副本與閒置縮到零。這些是官方列出的改進方向，不能當成所有功能已經可以啟用。

針對代理，團隊也規畫免完整複製程式庫的讀取方式、一次提交多檔的原子操作，以及事件串流。它們可能減少下載與往返，但本次文章沒有提供全面可用的日期。

一般開發者仍沿用既有 Git 推送、擷取與分支操作，原本的保護也保留。比較值得準備的是理解代理會產生哪些重複讀取與細碎推送，讓工作流程和平台改進一起減少負擔。

大型團隊若已遇到單一程式庫的代理尖峰，可以持續追蹤預覽資格與推出進度。若目前瓶頸在測試或人員審查，儲存吞吐增加則未必是第一個能改善交付的環節。

維護者可以持續追蹤預覽與推出進度，先從減少代理重複下載與不必要推送改善現有工作。

GitHub Rubicon 常見問題 FAQ

GitHub Rubicon 已全面上線了嗎？

公告描述的是限量私有預覽，較廣泛推出規畫在隔年初。內部測試能力和所有客戶目前可用範圍，要分開理解。

7200 次推送是每個程式庫的保證嗎？

它是指定內部測試的吞吐量。原文沒有把它列成每個公開程式庫的服務保證，也沒有表示所有推送大小與工作負載都能得到同樣結果。

代理之間不需要處理衝突了嗎？

不同物件與分支能減少共用協調，但相同參照更新仍要比較原值。程式邏輯互相矛盾的修改，也仍要靠開發與審查流程解決。

延伸閱讀：GitHub Copilot App 平行 Agent 教學：Worktree 是什麼？怎麼同時跑多個開發任務

延伸閱讀：Anthropic Scion 取代內部 Git：每天三萬次合併，AI 寫程式的瓶頸移到哪裡？

結論

維護大量代理的平台，可以從物件保存、參照一致性與維護工作三種不同負擔理解 Rubicon。一般團隊則先觀察自己的單一程式庫流量與代理行為，等公開供應範圍明確後，再判斷這個架構能改善哪一段等待。

資料來源

• 官方1：github.blog