AI 摘要
- OpenAI 公開自建的 Git 後端 Pando，用來承接 Codex 帶動的大量並行開發。
- 切換到 Pando 後，程式碼推送延遲中位數降低近 80%。
- 原有系統曾出現推送緩慢與合併失敗，促使 OpenAI 重建後端。
OpenAI 公開其自建的 Git 後端「Pando」，用它承接 Codex 帶動的大量並行開發工作。這套系統保留 Git 協定與既有操作方式，改變分支更新的協調邏輯，並重複使用推送時收到的封裝檔（packfile）加快資料傳輸。OpenAI 表示，切換到 Pando 之後，程式碼推送延遲的中位數降低近 80%，系統每天傳送的 Git 資料量接近 1 PB。
背景：單一儲存庫承受並行開發壓力
隨著 OpenAI 自家工程師利用 Codex 同時執行多項開發工作，該公司的單一程式碼儲存庫出現更多分支、推送與合併作業，持續整合（CI）系統也必須更頻繁地擷取程式碼。OpenAI 指出，原有系統自 2025 年底開始出現推送與讀取緩慢、合併失敗等問題，可靠性有時低於 90%，這是促使該公司重建 Git 後端的原因。
核心改動：分支更新改採因果一致性
Pando 最主要的變化在於分支更新的協調方式。部分分散式 Git 架構需要依序處理整個儲存庫的參照（ref）更新，即使推送的是彼此無關的分支，也可能互相等待。
Pando 改採因果一致性（causal consistency）的更新邏輯，讓不同分支可以並行更新，同時維持各分支內部的更新順序。
隨之而來的權衡
代價是當用戶端讀取多個分支時，系統不保證能取得整個儲存庫在同一個時間點的狀態。換句話說，Pando 是以跨分支的一致性，換取分支層級的並行度。
傳輸層：重用封裝檔與 packfile-uri
傳統 Git 伺服器通常會依照用戶端已持有的資料，另行產生傳輸用的封裝檔。Pando 的做法是保存推送時收到的封裝檔及其相依關係，讓不同用戶端重複使用，再透過區域快取傳送；系統也會在背景合併封裝檔，減少擷取大量更新時必須處理的檔案數量。
此外，Pando 使用 Git 既有的 packfile-uri 機制，讓用戶端從各地的快取服務下載封裝檔，降低伺服器重新產生傳輸資料的負擔。
OpenAI 提供的數據顯示，Pando 曾在一小時內傳送超過 57 TB 的 Git 資料，其中超過 99% 來自本機磁碟快取。
上線時程與遷移方式
Pando 自今年 4 月起開始處理正式環境流量。OpenAI 先把它當作既有系統的讀寫代理（proxy），再逐步遷移開發工具與服務。遷移過程中，工程師原有的 Git 操作方式不需改變。
其他業界的類似調整
Cursor 與 Anthropic 先前也調整了原始碼管理架構，但各自切入點不同。
| 項目 | Pando（OpenAI） | Continuity（Cursor） | Scion（Anthropic） |
|---|---|---|---|
| 定位 | 自建 Git 後端 | 調整原始碼管理架構 | 取代內部單一程式碼儲存庫原有的 Git 系統 |
| 關鍵作法 | 分支更新採因果一致性、重用封裝檔、使用 packfile-uri | 以 S3 預寫日誌保存 Git 資料 | 以 Scion 取代原有 Git 系統 |
| Git 相容性 | 保留 Git 協定與既有操作方式 | 維持 Git 相容性 | 來源未說明 |
| 是否對外提供 | 尚未宣布 | 來源未說明 | 來源未說明 |
目前範圍與尚未公開的部分
與 Cursor 的 Continuity 一樣，Pando 維持 Git 相容性。目前 Pando 已支援 OpenAI 單一程式碼儲存庫的開發工作，部分 Git 用戶端的改善也已回饋給開源社群；不過 Pando 本身尚未宣布對外提供，OpenAI 也未公布更廣泛的部署計畫。
Reference Link : ithome.com.tw
