OpenAI 於 2026 年 11 月 2 日公開 Pando 原始碼管理後端的架構與部署成果。隨 Codex 增加並行分支、推送、合併及 CI 抓取需求，原有 monorepo 服務曾出現推送與抓取緩慢、合併失敗，可靠度一度低於 90%。Pando 保留標準 Git 用戶端與協定，改造伺服器端的物件儲存、版本協調及傳輸。
傳統 Git 必須同步不可變的 blob、tree、commit、tag 物件與可變的 refs。OpenAI 評估多副本三階段提交（3PC）及共用 write-ahead log（WAL），認為前者需多輪協調與磁碟同步，後者的共用 manifest 更新則會成為競爭點。Pando 改採因果一致性，允許不同分支獨立更新；單一 ref 更新仍保持序列化，但同時讀取多個分支不保證取得同一時刻的全域快照。
推送時，Pando 將 Git packfile 以不可變 blob 儲存，並記錄 ref 版本、依賴與新指標。官方稱同步中繼資料操作維持 O(1)，抓取時依據客戶端已有與需要的提交規劃封包，版本距離 Δ 的中繼資料查詢約 O(log Δ)。為提高封包重用率，伺服器在 push 協商時僅宣告選定基礎分支；其 monorepo 封包中位數低於 20 KiB、第 99 百分位低於 3 MiB，但代價是部分物件重複上傳。
讀取端使用 Git packfile-uri 功能從區域快取服務 Express 下載封包。官方報告快取命中率超過 99%，標準雲端虛擬機可使 fetch 與 clone 飽和 10 Gbps 連線。背景 compaction 以類似 LSM-tree 的方式將 L0 小封包逐層整理成 covers，現已使用至 L4，減少長時間未同步的用戶端需要下載的封包數量。
OpenAI 表示 Pando 以 Rust 開發，在約 10 週內由工程師與 AI 代理協作完成，2026 年 4 月起承接正式流量；遷移時先以讀寫代理同步舊系統，逐步轉換數百項整合。正式環境推送延遲中位數降低近 80%，每日服務接近 1 PB Git 資料，曾於單小時傳送逾 57 TB 封包，其中超過 99% 位元組由本機磁碟快取提供。
OpenAI 也向上游 Git 貢獻 packfile-uri 下載、續傳、驗證及追蹤改進。文章附帶的 3PC、WAL、Pando 比較模擬屬合成教學模型，不是外部服務實測排名；實際效能來自 OpenAI 自身負載，未公布 Pando 對外產品化或獨立部署時程。
發生了什麼事
OpenAI 已將 Git 相容後端 Pando 用於 monorepo，透過分支獨立更新、因果一致性、快取與背景壓縮支援大量 AI 代理。
為什麼重要
AI 寫碼代理使分支、推送與抓取暴增，原始碼管理後端的吞吐量與一致性取捨成為平台工程問題。
影響哪些人
大型 Git 服務維運人員、DevOps、CI 平台工程師及使用 AI 寫碼代理的開發團隊。
已確認與未確認
已確認官方的近 80% 延遲改善、10 Gbps、快取及每日傳輸數字；跨組織效能、對外供應與成本尚未證實。
