觀點 · 資訊分享

AI 寫程式快到 Git 撐不住：OpenAI 用 Codex 10 週打造 Pando，推送延遲少近 8 成

Codex 讓 OpenAI 內部的分支與推送暴增，原本的版本控制系統可靠度一度低於 90%。OpenAI 自建 Git 後端 Pando，工程師照用原本的 git 指令，中位推送延遲減少近 8 成。

發布: 2026-11-02
篇幅: 約 3 分鐘 · 1,527 字
結構: 7 節 + 3 題常見問題
標籤: #OpenAI#Codex#Git#AI 代理#版本控制

AI 寫程式快到 Git 撐不住：OpenAI 用 Codex 10 週打造 Pando，推送延遲少近 8 成

一句話看懂：Codex 讓 OpenAI 工程師同時開出大量分支，原本的 Git 伺服器撐不住，於是 OpenAI 用 AI 在 10 週內蓋出新的 Git 後端 Pando，推送延遲少了近 8 成。

OpenAI 自建 Git 後端 Pando資訊圖卡：AI 代理讓推送量暴增，OpenAI 重寫 Git 伺服器端，工程師不用改習慣

先用白話講：Git 後端是什麼？

Git 是工程師存放程式碼、記錄每次修改的工具。你可以把它想成一間共用的圖書館：每個人借書（fetch、clone）、還書並登記修改（push）。

以前這間圖書館的人潮有限。現在每位工程師身邊都跟著好幾個 AI 助手，同時改好幾份稿、同時還書，櫃台開始大排長龍。Git 後端就是圖書館的櫃台和倉庫，OpenAI 這次等於把整個櫃台系統重蓋，但讀者借還書的方式完全不變。

發生什麼事

OpenAI 在 11 月 2 日的工程部落格公開 Pando：

起因：Codex 讓分支、推送、合併，以及 CI 與研究工作的下載量一起暴增。從去年底開始，舊系統變得很慢、合併失敗，可靠度一度低於 90%
現況：Pando 已承載 OpenAI monorepo（把所有專案放在同一個儲存庫）的全部開發
成效：中位推送延遲減少近 80%（官方另一處寫「近 5 倍」）；一天可送出近 1 PB 的 Git 資料，曾在一小時內送出超過 57 TB，其中超過 99% 來自本機磁碟快取
開發方式：核心由一位工程師設計、交給多組 AI 代理實作，從開工到上線只花 10 週，今年 4 月開始承接正式流量

它怎麼做到的？

做法	一般 Git 伺服器	Pando
推送到不同分支	常常要排同一條隊	各分支獨立，互不等待
回應下載	每個人都現場打包一份	重複使用之前收到的 packfile
一致性	所有分支同一時間點一致	只保證單一分支的先後順序

給開發者的技術細節

因果一致性：每次推送的 packfile 存成不可變的檔案，另外記錄「這個版本依賴哪些前一版」。代價是同時讀多個分支時，看到的可能不是同一刻
只公告主幹：分支有幾百萬個時，光是列出所有分支就可能超過 100 MiB。Pando 預設只告訴用戶端主幹（trunk），讓推送出來的 packfile 能被別人直接重用；中位 packfile 小於 20 KiB
packfile-uri：利用 Git 協定裡少見的功能，回傳下載連結，讓用戶端去區域快取抓檔，官方實測能跑滿 10 Gbps
背景合併：小 packfile 依層級逐步合併（目前到 L4），讓落後很多的用戶端也能快速算出要下載哪些檔
驗證：用 Rust 從零開發、寫 Git 相容性測試給代理用，並用 GPT‑6 Astra 寫 Lean 與 TLA+ 形式化規格來找 bug

我的看法

這篇最有意思的不是 Pando 本身，而是起因：AI 寫程式的速度，開始把周邊基礎設施壓垮。我們這種小團隊不會有幾百萬個分支，但同樣的事會以小規模出現：讓 AI 代理同時開好幾條分支、每次推送都觸發 CI，GitHub Actions 的分鐘數、NAS 上自架 Gitea 的效能，都可能先撐不住。

比較實際的做法是先盤點：哪些 CI 其實不必每次推送都跑、代理開的分支有沒有定期清。另外，「一位工程師設計、代理實作、形式化驗證找 bug」這個分工，比單純叫 AI 寫程式更值得學。