AI 寫的程式愈來愈多，Git 為什麼反而需要重新設計？

2026 年 9 月，GitHub 平台記錄到 73.8 億次 commit，超過一年前的五倍。這是 GitHub 10 月發布的工程資料，不代表 73.8 億次提交都出自 AI，也不是程式碼品質提高五倍的證明。但它說明一件對軟體基礎設施非常具體的事：在 Agent 加入之後，原本替人類開發節奏設計的部分系統開始被推向新的負載邊界。[1]

11 月 2 日，OpenAI 也發表名為 Pando 的 Git 後端架構。官方說明，Pando 已支援其內部主要程式庫，目標是在維持 Git 協定與既有工作方式的條件下，處理大量分支的平行寫入及高速讀取。[2] 兩份文章來自不同公司，卻都指向同一個問題：當軟體變更從一天數十次，變成由大量 Agent 高頻率、平行地提交，傳統的集中協調可能比生成程式碼更快碰到極限。

先拆開一個誤會：Git 沒有突然變成不能用

Git 是版本控制系統。它記住一個專案在不同時間點有哪些檔案及內容，讓人可以建立分支、比較差異、合併修改，也能追查某次變更的來源。GitHub、GitLab 和企業自建服務都可以在 Git 上提供儲存庫託管、權限、Code Review、工作項目和自動化管線。討論 Git 需要「重新設計」，很多時候真正討論的是這些系統背後如何處理資料、平行更新與可用性。

最容易理解的差別是，Git 本身能讓兩個人在不同分支工作，並不意味著伺服器可以在極短時間內接受數千個不同 Agent 的更新，還要同步供應大量 CI 工作下載、保留一致的版本指標。版本控制的語意可以繼續相同，但負責接收與傳送 Git 物件的後端架構可能需要更有效率。

這也解釋為什麼 OpenAI 特別強調 Pando 保持 Git 協定相容，GitHub 也表示在新架構導入時不要求所有客戶重寫工作方式。[1][2] 技術改造發生在使用者原本不必看見的基礎設施，目的恰恰是保留大家熟悉的 Git 使用習慣。

一個核心技術概念：Git 物件幾乎不變，分支指標卻一直變

理解大規模 Git 架構，最簡潔的入口是分清楚「物件」與「指標」。Git 的 commit、tree、blob 具有內容定址的特性，物件 ID 反映內容；已建立的物件通常可以被視為不可變的資料。新版本不需要把舊版本整份改寫，而是建立新的物件並更新某個分支所指向的 commit。這種設計讓多份歷史可以共存，也便於驗證內容是否一致。

但分支指標是另一回事。假設 Agent A 和 Agent B 同時讀到 main 指向版本 X，兩個 Agent 都想把 main 更新到自己的新版本。如果系統不管先後就接受任意寫入，後面的更新可能覆蓋前者，使某次工作從最新分支消失。因此，更新同一個 ref 需要一致性條件，通常還需要檢查基底版本是否仍符合預期。

這就產生一個重要區分：大量不可變物件可以分散保存與重用，但少量會變動的 ref 需要精確協調。若系統為了保護少量 ref，把整座儲存庫都鎖住，連互不相關的分支更新也必須等待，吞吐量就會受限。GitHub 和 OpenAI 的新架構，正是希望把保護正確性必須付出的協調成本，限制在更適當的粒度。[2][3]

對只使用 Git 指令的工程師來說，這種區分看似距離很遠，其實它決定了為什麼新增快取或更強的主機有時無法改善 push。如果真正阻塞的是一致性鎖和跨區副本等待，增加更多讀取節點不一定有幫助，甚至可能使每次寫入要等更多回應。

人類開發與 Agent 開發，對儲存庫造成的壓力不同

一位人類工程師通常會閱讀需求、思考方案、修改一段程式、運行測試，再把工作推送到遠端。這個過程可能需要數十分鐘到數小時。Agent 的速度未必在每個任務都比較快，但它可以自動化反覆修改、提交、檢查與再修正；當系統允許許多 Agent 並行時，儲存庫可能同時接到大量短間隔的小更新。

GitHub 的文章指出，高頻率 Agent 會讓 push 完成時間成為循環速度的限制。人類不一定察覺的一點延遲，若乘上每個 Agent 的反覆操作與成百上千個任務，就可能造成顯著排隊。GitHub 公開比較的數據顯示，月推送量從約 6.9 億次增至 33.5 億次，約 4.9 倍；Pull Request 合併量也接近一年以前的四倍。[1]

另有一個常被忽視的放大效果：一個 commit 送進伺服器後，後面的 CI、程式碼掃描、建置與其他 Agent 可能立即抓取同一個版本。寫入只有一次，讀取卻會擴散。GitHub 表示，2026 年 9 月 GitHub Actions 的執行量達 32.6 億次，超過一年前的四倍。這些數據描述的是 GitHub 整體活動，不能假設所有增長都因 Agent 而起。[1]

第一個瓶頸：不同分支，為何還要排同一條隊？

要理解寫入問題，可以想像一間辦公室只有一個受理窗口。A 團隊在分支 alpha 上改動前端，B 團隊在分支 beta 上修正測試。兩份工作互不相干，卻因為窗口每次只能處理一件事而排隊。當同時到來的工作不多，成本不明顯；當送件數量激增，等待時間就會成為整體進度的限制。

Git 的分支實際上包含一種叫 reference，簡稱 ref 的指標，它指向目前最新的 commit。更新同一個 ref 必須維持順序及一致性，否則可能發生覆寫。但更新彼此獨立的 ref，理論上不需要每次都鎖住整個儲存庫。這就是大規模 Git 服務重新思考「鎖定與協調範圍」的原因。

GitHub 10 月 21 日的文章寫得很清楚：其既有架構中的某些寫入流程由整個儲存庫層級控制。跨資料中心的副本回應會增加延遲，讓繁忙儲存庫的寫入吞吐受限。GitHub 正把協調範圍改為個別 reference，讓不同分支的寫入可同時推進。官方稱在內部測試、使用接近實際流量的情境時，獨立 reference 的寫入吞吐提高約三至四倍；這是特定測試條件下的結果，不是每個客戶的速度保證。[3]

OpenAI Pando 使用類似問題意識：只讓真正更新同一 reference 的請求競爭，由資料庫的原子比較與交換類機制保護 ref 指標，其他分支各自前進。[2] 兩家產品實作不同，但核心是同一項工程原理：必須一致的地方維持一致，不需要彼此等待的地方就讓工作平行。

第二個瓶頸：每次抓取程式碼，都要重新計算一次嗎？

Git 使用 commit、tree 和 blob 等物件表示版本與內容。當工程師或 Agent 從遠端取得更新，伺服器通常需要根據對方已有的歷史，以及希望取得的新版本，算出應該傳送哪些物件，再把資料壓縮成 packfile。這樣做能節省流量，但反覆計算本身也要消耗 CPU、記憶體及 I/O。

當一個專案只需每天讓幾位工程師同步，成本可接受。若上千個 Agent、測試環境與建置程序都在頻繁抓取同一份或相近的程式碼歷史，一直重新計算相同的內容可能就不划算。GitHub 的技術路線是把讀取用的運算資源和具有持久保存責任的儲存分開；OpenAI 則強調重用客戶端已送入的 packfile，盡可能讓後續 fetch 直接使用它們。[1][2]

Pando 的文章說明，系統在 push 時將所接收的 packfile 與 ref 版本關聯，後續讀取可依客戶端已擁有和希望取得的 commit，選出適合的 pack。它也利用 Git 的 packfile-uri 功能，把可另行下載的 packfile 位置交給客戶端。這樣可以利用快取讓許多使用者共用資料，降低重複打包成本。官方報告在其環境中，快取命中率超過 99％，也觀察到利用標準雲端虛擬機飽和 10 Gbps 網路連結的讀取情境。[2]

這些技術細節對一般開發者不必逐項操作，但會改變操作體驗。當 Agent 需要反覆建立工作環境、複製專案、讀取相依分支，初始化時間及同步延遲都會影響完成一項任務的總時間。

第三個瓶頸：提交容易，合併卻只有一條主線

平行開發可以讓很多 Agent 同時進行，但並行不代表變更沒有衝突。假設十個 Agent 在十個分支各自修正，最後都要合併到 main，主分支仍然只有一個。每次合併都可能改變下一個工作所依賴的版本，因此需要排序、重新測試以及處理衝突。

GitHub 提到，主分支、發布列車和 merge queue 會把大量工作集中在同一個 ref。[1] 這不是單靠增加讀取伺服器就能解決的事。當兩個變更都修改同一支 API，甚至分別做出與對方不相容的調整，系統必須能辨別先後版本，且在合併之後重新驗證相依性。

這也指出企業常見的錯誤投資順序：先增加 Agent 數量，卻沒有重新安排任務範圍。若每個 Agent 都改同一個大型檔案、同一批共用規則，分支數增加不一定提高交付速度。軟體架構中模組邊界、API 契約與測試分工，反而決定平行工作究竟能不能成立。

三個容易被「架構升級」掩蓋的例外

第一個例外是主分支上的連續寫入。即使系統把不同 feature branch 的更新拆開，所有人最終仍可能把修改合併回同一個 main。只要每次合併都必須以最新版本為基礎，整合階段就無法像獨立分支一樣無限制平行。實務解法可能包括更好的測試隔離、合併佇列、依相依性排序與減少大規模衝突，而不是單純追求更多同時執行的 Agent。

第二個例外是外部依賴。某個 PR 裡的程式碼即使完全正確，也可能因第三方 API 限流、測試資料不足、部署環境缺少設定而無法交付。Git 後端的讀寫效率只能處理其中一段。衡量軟體交付速度時，應把從需求到部署的整段時間都列入，而不能把 push 的效能數據轉換成整體生產力改善幅度。

第三個例外是舊系統與歷史資料。公司可能有大量大檔案、過時分支、長年累積的 CI 腳本和特殊權限。新的儲存架構能否順利承接，取決於相容性、遷移策略及回退能力。OpenAI 在 Pando 的技術文章提到，初期採用與既有系統同步的代理方式逐步搬移流量，以降低切換風險；這種過程控制通常比一次性全面換平台更值得企業借鏡。[2]

第四個瓶頸：自動生成更多變更，也生成更多審查

Git 基礎設施的容量，還不是全部問題。人類審查者需要知道一次變更是否符合需求；安全工具需要檢查依賴與權限；QA 必須確認沒有破壞既有功能。原本一天出現五份 PR 的團隊，如果突然每天出現五十份，可能讓程式碼審查成為新的待辦積壓。

因此，應該把「Agent 生產率」和「軟體交付率」分開測量。前者可用任務生成速度、候選修正次數或可執行測試來觀察；後者至少還要考慮從 PR 提交到審核完成的等待、部署成功比例、上線後缺陷與修復時間。程式生成更快但返工增加，未必是效率改善。

OpenAI 在 11 月 4 日宣布擬收購 Pierre，公告中特別強調檔案瀏覽、差異比較、即時語法顯示及 Code Storage。這使兩天前的 Pando 公告有了更完整的產品脈絡：底層提升 Git 平行工作承載能力，上層改善人和 Agent 如何理解、審核及保存大量變更。不過，收購仍待交割，實際整合功能與時程尚未確定。[4]

別忘了錯誤率會隨工作量一起放大

每次 Agent 產生程式碼，都有可能遺漏需求或修改到不應修改的地方。這不代表 AI 不值得使用，而是企業不能假設高產出量與高通過率會自動同時成立。假如任務數量快速增加，但每件合格任務仍需要人工抽查，審查規則和測試證據就必須跟著擴充。

可採用風險分級。純文字文件與低風險畫面改版，經固定檢查後可使用較輕量的審核；涉及權限、個資、收費與正式系統變更，則要求更嚴格的測試和核准。這不是宣稱低風險任務完全不需要審查，而是讓有限的工程時間用在最可能造成損失的地方。

從這個角度看，Git 的「版本歷史」並不只是工程師便利功能，而是企業識別變更責任的核心紀錄之一。當更多人與 Agent 可以高速修改系統，越需要保留可重現的工作版本、已確認的測試以及核准紀錄。升級儲存層能承接工作量，升級工作規範才能承接責任。

基礎設施的速度，不等於企業系統可以放棄安全性

GitHub 的新架構討論了讀寫分離與權威儲存層，OpenAI 則描述不同 ref 可以獨立寫入。這些技術不是為了省略一致性規則，而是避免在不必要的地方重複協調。對需要高可用與稽核的企業而言，這個差別至關重要。

假設某個 Agent 下載到不完整的資料包，或在分支更新尚未持久寫入前就得到成功回覆，後續測試可能建立在錯誤版本之上。因此，新架構仍需要完整性檢查、提交可見性的規則，以及發生節點故障時的恢復策略。GitHub 特別把穩定性與原有管控作為架構目標；OpenAI 公布的設計也說明哪些資料必須同步記錄，哪些壓縮整理可以在背景完成。[1][2]

這裡有一個對企業 IT 主管很有用的觀念：增加吞吐量不應以降低可恢復性來交換。真正可以改善的，是把計算、快取和必要的一致性邊界拆開；該保留的版本歷史、權限驗證、備援與審計，仍然要存在。對金融業、醫療、製造等有嚴格變更責任的組織尤其如此。

「重新設計 Git」不等於每家公司都應該重建 Git

Pando 與 GitHub 的工程文章談的是極大規模工作量。如果一家公司的開發團隊只有十位工程師、每天總共幾十筆 commit，沒有證據顯示它現在需要自建分散式 Git 服務。這時更重要的通常是分支權限、合併規則、CI 品質、資安檢查以及需求如何拆分成可獨立完成的任務。

可用一個簡單的「瓶頸定位」方法來看。從任務被接受的時間開始，標記第一次寫入 commit、第一次 push、首次測試完成、審查通過與部署完成。這些時間點彼此相減，就能看出延遲發生在哪一段。若大部分時間都耗在需求來回，升級 Git 儲存層不會有顯著效果；若每個 Agent 的 checkout 都很慢，才需要研究讀取、快取或工作環境重用；若大量 PR 堵在審查，就應先改善檔案可讀性、測試證據與審核政策。

另一個決策是建立基準值。試點之前先量測目前每週可交付的合格工作、修正次數及嚴重缺陷，再讓 Agent 在相同安全邊界下承接可比較的任務。若沒有基準，就容易因為「現在可以同時開很多視窗和分支」誤以為效率顯著成長。

「Agent 數量增加」有時會讓團隊更慢

平行工作不是越多越好。假設系統有一條主要測試環境，每次只能部署並跑一組完整的端到端測試。現在有二十個 Agent 同時提交修改，但測試環境一次只能處理一份。新增 Agent 可能先讓待測試佇列增加，後續的版本更新還會使尚未測試的變更過時。這時候限制同時進入整合階段的工作數量，可能比繼續加 Agent 更有效。

實務上可以設置在製品限制（Work in Progress Limit），也就是限制某個階段同時進行中的任務數。例如允許多個 Agent 在獨立環境撰寫與自測，卻限制進入主分支待合併的 PR 數量，讓 reviewer 與 CI 能維持穩定處理。這是借用生產管理的概念，目的不是壓低產出，而是降低大量半成品造成的等待與返工。

另一種改善方式，是把頻繁互相影響的任務合併或排序。假如三個 Agent 需要反覆修改同一個共用資料模型，最好先由負責資料契約的人確定欄位與版本，再讓其他 Agent 依契約動工。與其讓每個 Agent 獨立猜測，最終在整合時碰撞，不如先降低相依性。

一個銀行資訊系統的假設案例

以下是教學用假設情境，不是任何真實銀行的部署報告。某個案件管理系統要新增「優先級」欄位，團隊讓四個 Agent 分別處理資料庫 schema、API、前端篩選及測試。若在開工前就寫清楚 API 契約、欄位預設值、排序邏輯及權限，四個 Agent 才有可能在不同工作分支同時產出可合併的變更。

反過來說，若沒有契約，資料庫 Agent 把欄位命名為 priority_level，API Agent 用 urgency，前端 Agent 認為資料是文字而不是有限的代碼，最後就算每個人都提交了一份完整 PR，系統仍難以通過端到端驗收。這是治理與協作問題，不是 Git 儲存效能問題。

同一個案例也能示範正確的驗收順序：先讓各分支對照固定契約測試，再將經過批准的變更按相依順序合併；每次合併後重跑整合測試，並保留 PR、測試和審批紀錄。若正式部署後發現排序錯誤，才有能力追查問題源自需求、資料轉換或哪次合併。

如何評估一份技術效能數據是否能用在自家公司？

GitHub 公布的寫入吞吐倍數、OpenAI 公布的 Pando push 延遲改善，都來自其特定環境。評估這些結果，需要知道工作量的規模、資料大小、讀寫比例、網路拓撲與測試方式。讀取密集與寫入密集的環境，通常面對不同瓶頸。以單一巨大儲存庫為中心的團隊，與分散在數十個小儲存庫的團隊，也不見得需要相同架構。

一個合理的評估表應該同時收集四組資料：平常與高峰的 push 頻率；clone 或 fetch 的延遲分布；CI 從提交到結果回報的等待時間；以及合併衝突、失敗重試與恢復紀錄。最好再按工作類型切開：人類手動提交、Agent 自動提交、整合測試下載與部署管線讀取。若所有操作混在平均數裡，容易忽略真正最慢的一小部分任務。

舉例來說，某些團隊的 clone 很慢，是因為專案包含不必要的大型資產、建置產物或缺乏合理快取，而非 Git 服務本身無法承受 Agent。這時清理儲存庫、調整工作目錄與測試環境，可能比更換整個程式碼平台更省錢。問題定位正確之後，才能把供應商提供的效能數據放進適當的比較位置。

團隊可以自己做的技術實驗

即使沒有千萬次的 Git 操作，也能設計一項小型實驗，找出自家的瓶頸。先選一個可重現的測試專案，固定基底版本，建立多個互不相依的工作分支。測量只有一位開發者、五個 Agent 和十個 Agent 同時執行時，從建立分支到 push 完成的時間；同時記錄 CI 工作等待、測試失敗、審核完成及合併衝突數量。

接著更改一個條件：讓部分任務故意修改相同的 API 契約或共用檔案，觀察佇列、衝突與返工如何改變。這個實驗能讓團隊發現，效能問題有時來自儲存服務，有時來自任務切割。只有在不改動測試標準的情況下比較，才能判斷加速到底是改善了工具，還是降低了品質要求。

如果公司已經有 CI 系統的記錄，可以建立每週監控：平均與高分位 push 時間、首次測試等待、PR 首次審核等待、修正回合數，以及每週真正部署的合格變更。只報告 commit 數，很容易鼓勵大量拆碎或無意義的提交；只報告部署數，又可能忽略一次部署包含不同規模的變更。因此，指標應搭配任務難度與實際品質判斷。

從 Git 日常規範開始，降低不必要的 Agent 負載

即使不更換平台，團隊也能改善一些容易被低估的問題。首先應控制倉庫中不必要的大型二進位檔案與產物，避免每個 Agent 建立工作環境時下載無關內容。其次要明確設定哪些分支屬於正式發布、哪些只是可清理的短期試驗。大量無人管理的暫存分支，可能讓介面搜尋、權限管理與日後追查變得困難。

另外，應限制 Agent 在每一次小修改後都觸發完整且昂貴的測試；可以在不犧牲最終品質的前提下，先執行快速的靜態檢查與單元測試，進入整合階段再跑完整測試。這不是跳過品質關卡，而是按照變更範圍安排適當的驗證成本。若流程中需要多次自動測試，也要設定佇列與並行上限，避免測試資源被大量低價值工作排滿。

最後，把每個 Agent 的工具權限與任務範圍寫清楚。它可以讀哪些路徑、修改哪些檔案、建立哪類分支，是否能對外推送與觸發部署，都應由系統權限而非口頭提示控制。這些治理措施與 Git 儲存後端是否採用新架構無關，卻直接影響大量代理工作能否安全展開。

為什麼這不是「去中心化比較好」的問題？

Git 的使用方式本來就支援分散式歷史，但企業仍然需要一個能確認正式版本的協作機制。新一代後端所追求的，是讓不需要同步的工作少等待，讓必須一致的版本指標準確運作。它不等於所有工作都不需要中心，不等於每位 Agent 都可以自決正式版本，也不表示審核可以被取消。

真正值得關注的是邊界能否被清楚設計。哪些資料應被視為不可變並廣泛快取？哪些更新需要原子驗證？哪些任務要在主線整合時重新測試？哪些高風險改動應由人批准？當團隊能逐項回答，才能合理決定要投資 Git 平台效能、Agent 執行環境，還是工作流程治理。

GitHub 與 OpenAI 共同指向的下一個課題

GitHub 的公開數據已經說明規模壓力，OpenAI 的 Pando 則展示一種維持協定相容的技術選擇。它們不能證明所有軟體開發都需要重寫基礎設施，卻足以支持一個較務實的判斷：在 AI Agent 增加工作並行度之後，版本控制平台必須重新檢視哪些操作真的需要協調、哪些資料可以快取，以及哪些變更仍應由人來驗收。

企業下一步應追蹤的，不只是各家宣稱的最高吞吐量。更應觀察實際產品是否支援 Agent 分支隔離、可讀的差異審查、可執行測試、受保護合併與部署回溯。Git 沒有因 AI 失去價值，它仍是團隊信任與追溯的基礎。恰恰相反，當自動化讓修改變便宜，可靠的版本歷史和合併規則會變得更加重要。

延伸閱讀與來源

[1] GitHub Engineering，〈Building Git infrastructure for agent-scale development〉，2026 年 10 月 6 日，10 月 26 日更新：https://github.blog/engineering/building-git-infrastructure-for-agent-scale-development/

[2] OpenAI Engineering，〈Scaling Git at OpenAI〉，2026 年 11 月 2 日：https://openai.com/index/scaling-git-at-openai/

[3] GitHub Engineering，〈The bridge to agent-scale Git infrastructure〉，2026 年 10 月 21 日：https://github.blog/engineering/architecture-optimization/the-bridge-to-agent-scale-git-infrastructure/

[4] OpenAI，〈OpenAI to acquire Pierre Computer Company, Inc.〉，2026 年 11 月 4 日：https://openai.com/index/openai-to-acquire-pierre/

圖片資訊

封面圖片為原創 AI 概念插畫，以分散式分支與多重儲存節點表現大量平行寫入，並非實際 Git 伺服器架構圖。