AI 科技新聞

OpenAI Pando 重建 Git 後端：AI 同時寫程式，版本系統為何也得升級？

OpenAI Pando 是為大量並行開發打造的 Git 後端，已用於內部程式碼庫。解析它如何處理分支與下載，以及官方效能數字的適用範圍。

OpenAI 官方 Scaling Git 工程文章封面。圖片來源：官方原文。

OpenAI Pando 的出現，反映了 AI 寫程式之後的一個新負擔：程式寫得更快，儲存與交換修改的系統也得跟得上。

工程團隊常用 Git 記錄檔案版本、保留修改歷史。OpenAI 又把大量專案放在同一個程式碼庫中管理，稱為 monorepo。當工程師與 Codex 同時工作，把修改推送到伺服器的操作，也就是 push，就會大量增加。

OpenAI 在 2026 年 11 月 2 日公開 Pando 的設計。這是一套新的 Git 後端，已支援內部集中程式碼庫，重點是讓大量工作能同時寫入與下載。

它對開發團隊的啟示很具體：使用 AI 增加產出時，也要檢查等待、測試與版本管理是否變成新的瓶頸。

OpenAI Pando 解決什麼問題？

Pando 要處理的是多人與多個 AI 同時工作的規模。當修改分成許多分支，各自準備測試時，後端必須持續接受新版本，也要讓其他工作取得相同的程式碼。

分支可以理解成從共同版本另開一條修改路線。它讓不同任務先各自進行，確認完成後，再考慮是否合併。

但如果不相關的分支也得排隊更新，AI 多開工作只會把排隊人數增加。官方因此將目標放在並行寫入與高流量下載，同時保留熟悉的 Git 協定與操作方式。來源：OpenAI 工程文章。

這套後端讓不相關的分支可以各自更新，減少所有修改都擠在同一個協調點的情況。但這項選擇也有取捨：讀取多個分支時，看到的狀態可能來自不同時間點。

下載端則採取重用資料的方式。為了減少傳輸量，Git 會把許多版本資料壓成一包，稱為 packfile。因為重複打包會消耗資源，與其每位下載者都重新算一份，系統盡量讓多個用戶取得可重用的資料包，再透過快取分送。

快取就是把常用資料放在較接近使用者、能快速讀取的位置。因此，同一份歷史被大量測試工作下載時，後端不必反覆做相同計算。

這種設計說明，AI 開發的瓶頸有時出在共同基礎設施。模型能更快完成修改，仍需要周邊系統接住那些修改。

OpenAI 表示，在自己的正式環境中，Pando 讓推送的中位延遲降低近 80%，並能每天傳送接近 1 PB 的 Git 資料。1 PB 約等於一百萬 GB，這個量級凸顯了內部讀取需求。

但這是 OpenAI 特定工作量下的結果，不代表每個團隊安裝同一項技術，就能讓所有開發步驟加速五倍。推送、下載、測試與人工審查，本來就是不同階段。

對一般團隊來說，更實際的起點是量測等待發生在哪裡。如果工作時間主要花在測試或審稿，先改善那個階段，通常比追逐新的版本後端更直接。

它建立在 Git 的協定與客戶端之上。官方強調的是改造服務後端，讓原本的工作方式能承受更大規模。

截至 2026 年 11 月 3 日，這篇公告介紹的是內部系統與設計，沒有提供公開服務的申請方案。

有。官方列出對 Git 的修改與公開追蹤入口，但公開 Git 改進，與整套 Pando 已開放使用，仍是不同的事。OpenAI 的 Git 專案可用來追蹤相關進展。

這個案例值得開發團隊關注，因為它把 AI 產出增加後的基礎設施問題具體呈現出來。小團隊可以先記錄每個任務卡在推送、下載、測試或審查多久，再決定要改哪一段流程。

想持續追蹤 AI 開發工具與工程案例，歡迎免費訂閱 AI 郵報，並從官方工程文章查看完整架構。