GitHub 於香港時間十月七日凌晨在官方工程網誌發文，宣布正在「不停機」重建整個 Git 基礎設施，以應付由 AI 編碼代理帶動的「代理規模」開發。官方披露，今年九月單月平台錄得七十三億八千萬次提交，按年多於五倍；推送次數由每月六億九千萬增至三十三億五千萬，增幅四點九倍。
新架構的核心是把「耐久儲存」與「服務請求的運算」分拆：權威版本庫數據改存於 Azure Blob Storage，讀取由可隨流量增減的輕量快取工作節點承擔，壓縮及垃圾回收等維護工作亦移離即時服務路徑。GitHub 稱內部基準測試的寫入吞吐量最高提升三十五倍，分支保護、必要審查及審計日誌等現有管控維持不變。本文內容已逐項核對 GitHub 官方工程網誌原文，來源真實性已驗證。
GitHub 重建 Git 底層迎「代理規模」：九月提交七十三億次、按年逾五倍，儲存與運算分拆後寫入吞吐最高三十五倍
當一個版本庫內同時有數以千計的 AI 代理各自開分支、每做一步就提交一次，Git 托管平台的瓶頸便不再是「讀」，而是「寫」。GitHub 首席軟件工程師 Brian Celenza 於美國時間十月六日（香港時間十月七日凌晨約四時五十八分）發表〈Building Git infrastructure for agent-scale development〉，首次公開說明 GitHub 為何要重寫支撐十億個版本庫的儲存層，以及新架構的設計原則。本文先整理官方披露的數據與現有架構限制，再拆解新設計的技術原理，最後談對香港開發團隊、金融及受規管企業的實際影響。
一、核心事件：代理把 Git 流量推到新量級
官方披露的關鍵數字
GitHub 在文中列出多項按年比較，反映代理式開發（agentic software development）對平台造成的壓力：
- 整體 Git 活動：由二零二五年九月至二零二六年八月，每月 Git 事件由二千一百八十二億宗增至四千七百三十三億宗，即多於兩倍。
- 提交：二零二六年九月，開發者與代理在 GitHub 上共作出七十三億八千萬次提交，是一年前的五倍以上。
- 推送：按年增長四點九倍，由每月六億九千萬次增至三十三億五千萬次。
- 拉取請求合併：數量接近一年前的四倍。
- GitHub Actions：九月執行三十二億六千萬次，按年多於四倍。
- 最繁忙版本庫：單一版本庫在八月錄得約十億次請求。
官方指出，最活躍的一群版本庫正展示代理式開發的「前沿形態」：大型工程團隊一邊跑繁忙的持續整合（CI）管線，一邊有越來越多代理在同一代碼庫內工作。
五個架構難題
文章歸納了這類工作負載帶來的挑戰：
- 提交往返時間成為單一代理的瓶頸：代理在緊密循環中幾乎每個動作都提交或建立檢查點，速度受單次推送完成時間所限，人類察覺不到的延遲對代理而言就是上限。
- 寫入吞吐需求以數量級增長：數以千計代理各自在分支上工作，持續寫入最終匯聚到架構中的同一點。
- 合併爭奪同一個參照：主幹開發、發佈列車與合併佇列，都把工作匯入一個必須吸收所有合併的分支參照（ref）。
- 每次推送放大成數千次讀取：CI 與代碼掃描會在每分鐘內對同一分支頂端複製或抓取數千次。
- 版本庫操作必須保持快速：平台需持續壓縮數據、清理無用物件，每次新寫入都增加這部分工作，成本隨流量累積。
GitHub 的結論是：「快速複製」只解決一半問題。讀取可以靠快取和副本橫向擴展，但每次推送都必須先耐久儲存、並以一致狀態公開，下一個代理或 CI 工作才能在其上繼續，寫入因此難得多。
二、技術原理深度解析
現行架構 Spokes：耐久與擴展綁在一起
GitHub 現時以名為 Spokes 的系統儲存每個版本庫：在多台檔案伺服器的本地磁碟上各存一份完整副本，預設為五份。本地高速磁碟令 Git 操作可低延遲讀取原生數據，多份副本則提供冗餘並分散讀取。當推送更新參照時，系統以「三階段提交」協議配合多數決（quorum），確保 CI、網頁介面及 API 用戶端看到一致的版本庫狀態。官方指這套組合目前服務十億個版本庫。
問題在於，用來保證耐久性的機制，同時也是用來擴展的機制。磁碟上的副本就是「唯一真相來源」，要加讀取容量就得多加一份耐久副本；而每份副本都參與每次寫入，推送速度取決於副本組中最慢的一台。結果是：為吸收讀取量而增加副本，反而拖慢寫入；失去一份副本會減少讀取容量；失去多數決則寫入完全停止。對大多數版本庫這個取捨可以接受，但在最高活躍度下便成為天花板。
新架構的設計原則
GitHub 表示，新設計保留 Git 語義真正需要的協調，其餘部分盡量獨立進行：
- 只協調必須取得共識的部分：一次推送真正需要共識的只是「參照更新」本身；儲存底層物件、驗證物件連通性、秘密掃描（secret scanning）等工作量大得多，但大部分可與其他寫入並行。推送的關鍵路徑因此縮到需要協調的那一小步，其餘工作不再拖慢確認回應。
- 把維護移離服務路徑：壓縮與垃圾回收是版本庫最重的工作之一，現時與回應即時 Git 請求的主機共用；新架構由獨立工作節點直接對耐久儲存執行維護，繁忙版本庫可在背景持續優化，不影響推送與抓取。
- 擴展讀取而不增加耐久副本：讀取容量改由輕量工作節點提供，它們快取數據以回應請求；權威副本存放在底層耐久儲存層，平台因此可吸收 CI 扇出、代理群及大型複製造成的讀取高峰，而不會為每次推送增加工作。
- 每層只做一件事：權威版本庫數據存於 Azure Blob Storage，由其提供耐久性與複製；運算層專注於以最低延遲提供吞吐。
- 更快從故障恢復：儲存與運算耦合時，失去一台主機同時減少容量與耐久性，恢復要重建整份版本庫副本；分拆後，失去一個運算節點更接近一次「快取未命中」，替補節點可立即接手，並在流量到來時從耐久儲存補回快取。
- 容量按需求配置：運算節點可隨流量增減，毋須預先按峰值配置。版本庫遇上發佈或新一批代理上線等突發活動，可臨時獲得額外容量，高峰過後再收回。
官方稱，在內部基準測試中，新架構的寫入吞吐量最高達現行的三十五倍，讀取容量則可獨立擴展以應付需求。GitHub 強調重建在平台持續運作下進行，不設「全球代碼停止流動」的維護窗口，也不要求用戶改變開發方式；下一篇系列文章將進一步介紹未來架構細節。
管控維持不變
文章特別列出新架構必須保留的管控：維護者需要分支保護與必要審查，確保未經審查的變更不會進入預設分支；安全團隊需要審計日誌與版本庫可見度去調查可疑存取；值班工程師需要可靠的自動化與足夠的可觀測性，找出部署失敗原因。GitHub 的三項指導原則為：建基於開發者已信任的工作流程（分支、審查、合併、歷史）、可靠性優先，以及讓人始終掌控自己的代碼。
三、日常應用場景
1. 開發者與技術團隊
對日常用戶而言，這次重建不需要改任何操作，但有幾點值得提早準備：
- 代理提交策略：若團隊讓編碼代理頻繁建立檢查點，可評估在本地累積多個小步驟後再推送，或把探索性工作放在短命分支，減少對主幹參照的爭奪。
- CI 扇出成本：GitHub 點名 CI 與代碼掃描每分鐘對同一分支頂端抓取數千次。團隊可檢視管線是否重複完整複製，善用淺層複製、部分複製及快取，既省時間也減輕平台壓力。
- 合併佇列設計：主幹開發配合合併佇列是代理時代的主流做法，但所有工作都匯入同一參照；新架構縮短參照更新的關鍵路徑，對高頻合併團隊尤其有利。
延伸閱讀：Cloudflare 早前亦推出面向代理協作的 Git 平台 Artifacts 公開測試（https://ysk.hk/r/1288），GitHub 本週則開源 AI 程式碼審查基準 ReviewBench（https://ysk.hk/r/1344），可見「代理寫代碼」已逼使整條工具鏈重新設計。
2. 企業與受規管行業
GitHub 明言設計目標包括「在嚴格監管要求下交付的企業」。對銀行、保險及上市公司而言，最關心的是審計日誌、分支保護與必要審查會否在遷移中受影響；官方承諾這些管控維持不變，但具體遷移時間表與數據落地安排尚未公布，有數據駐留或外判監管要求的機構，宜留意 GitHub 下一篇架構文章及其企業版公告，再評估是否需要更新供應商風險評估文件。
3. 一般用戶與開源維護者
GitHub 指「為最繁忙工作負載而設計，會提升所有人的底線」：跨時區審閱志願者貢獻的維護者、開出第一個拉取請求的學生，都會用上同一個更快、更具韌性的基礎。故障恢復由「重建整份副本」變成接近「快取未命中」，理論上亦可縮短單點故障造成的服務中斷。
4. 香港與亞洲市場視角
對已採用 GitHub、Copilot 及 Actions，並開始試用編碼代理的香港金融科技公司、銀行科技團隊及外判開發商而言，這份數據值得細讀。GitHub 公布的增長數字說明，代理帶來的不只是「寫得更快」，還有 CI 分鐘、代碼掃描與合併頻率的倍增。本地團隊在規劃 AI 編碼代理落地時，應同步預算 CI 資源、審查人手與合規紀錄，而非只看授權費。亞洲時區團隊亦常在美國夜間進行大型合併與發佈，平台寫入吞吐的提升對跨時區協作有直接意義。
四、專業評價與潛在考量
優勢
- 對症下藥：把耐久性與擴展分拆，是分散式系統的成熟做法；GitHub 把它應用於 Git 托管，直接回應「加副本反而拖慢寫入」的結構性矛盾。
- 數據透明：官方罕有地公開提交、推送、合併及 Actions 的按年倍數，讓企業可量化代理式開發對工具鏈的實際壓力。
- 管控先行：明確承諾保留分支保護、審查與審計日誌，對受規管企業是必要前提。
- 彈性容量：運算節點按需增減，有助應付發佈日或代理群上線等突發流量。
需要留意的地方
- 只有內部基準：「最高三十五倍寫入吞吐」來自內部測試，未有公開基準方法或時間表，實際效益要待正式上線後觀察。
- 遷移風險：在不停機情況下更換十億個版本庫的儲存層，本身就是高風險工程；過渡期的穩定性值得關注。
- 雲端依賴加深：權威數據集中於 Azure Blob Storage，令 GitHub 與微軟雲的綁定更深；企業在供應商集中度評估中應把這點納入考慮。
- 細節未公開：數據所在地區、企業版與 GitHub Enterprise Server 是否同步受惠等問題，官方尚未交代。
結語
GitHub 這篇工程文章的訊息很清楚：代理已不是實驗性質的輔助工具，而是正在把全球最大代碼托管平台的寫入量推到原有架構的極限。九月七十三億八千萬次提交、推送年增四點九倍，迫使 GitHub 把沿用多年的 Spokes 拆成「耐久儲存＋彈性運算」兩層。下一步要看系列下一篇的架構細節，以及 GitHub Universe（十月二十八至二十九日）會否公布更具體的時間表。
如果你的團隊正準備引入 AI 編碼代理，卻缺乏人手處理 CI 管線、代碼審查與日常開發，可參考 YSK Limited 的開發者外判月費計劃，HK$2,000／月起、一年約、全遠端並含一部美國 VPS（https://ysk.hk/services/outsourcing）；如需同步規劃雲端遷移與零信任存取管控，亦可了解雲端遷移與網絡安全服務（官網刊 99.99% SLA，https://ysk.hk/services/cloud-security）。
參考來源
- GitHub 官方工程網誌：Building Git infrastructure for agent-scale development（Brian Celenza，2026-10-06 美國時間）https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/
- GitHub Blog RSS（發現來源）https://github.blog/feed/
- YSK Limited 新聞：Cloudflare Artifacts 公開測試與「下一代 Git 平台」競賽 https://ysk.hk/r/1288
- YSK Limited 新聞：GitHub 開源 AI 程式碼審查基準 ReviewBench https://ysk.hk/r/1344