OpenAI 披露 Pando：为 Codex 并行开发重建 Git 后端，内部推送延迟降低近八成

Codex 带来的并行工作，先压到了代码仓库

11月2日，OpenAI 的三位工程师公开介绍 Pando，一套已经用于公司单体仓库开发的 Git 后端。工程师和 Agent 仍然使用熟悉的 Git 操作，改变发生在服务端如何接收提交、协调分支与传输历史数据。它不是新的编码模型，也没有要求开发者换一套版本控制语言。

官方将建设原因归于 Codex 放大的并发需求：更多修改会同时进入分支、合并和持续集成流程，多个任务又会反复拉取相同历史。原文称旧系统一度出现慢推送、慢拉取与合并失败。这说明评估 Agent 的实际开发效率时，仓库服务本身也是需要观察的一环。

让不同分支各自推进，保留单个分支的顺序

Pando 把数据包放进不可变的对象存储，并用独立的元数据记录分支指向及依赖。不同分支的更新可以并行处理，不必竞争整个仓库的统一写入顺序。对同一分支的竞争仍需协调，系统也保留读取自身写入结果的能力。

这里的取舍是跨分支的一致性。一次读取涉及多个分支时，不能假设它们来自仓库同一时刻的全局快照。这个边界与提交历史是否完整是两件事：读者仍需要取得目标版本依赖的数据，不能把放宽全局快照解释成允许缺失提交对象。

把反复打包改成复用，把计算压力交给缓存分担

传统 Git 服务会根据客户端已有和需要的对象计算差集，再生成响应数据包。Pando 选择复用推送时收到的数据包，并通过 Git 的 packfile-uri 能力返回额外下载地址。这样，相同历史可以被多个读取者复用，减少每次请求重复计算。

复用也有代价：客户端可能下载部分已经拥有的对象。Pando 在推送协商中限制公布的分支基线，控制数据包依赖，再用后台合并整理小包。可以把它理解成用部分传输冗余，交换服务端更容易缓存、分发和扩容的工作方式，而不是让网络流量凭空消失。

内部性能结果与网页模拟，要分开理解

OpenAI 报告，迁移后内部推送延迟中位数降低近80%，与文章开头所说接近五倍改善相对应。这是该公司自身仓库和基础设施下的生产结果，不是本站实测，也不能直接套用到任意规模的企业代码仓库。

原文还提供了比较不同架构的交互模拟，并明确标注它属于教学模型而非生产基准。模拟帮助解释分支竞争、磁盘压力和读取延迟之间的关系；它不构成对某个现成 Git 托管产品的独立性能排名，更不能替代同一工作负载下的对照测试。

技术已在内部运行，对外分享仍处于探索阶段

工程团队称 Pando 从启动到生产历时十周，核心采用 Rust，并结合兼容性测试、确定性模拟与形式化方法寻找边界错误。上线时先作为原系统的读写代理，再分批迁移流量和依赖接口。这些是团队公布的建设过程，不等于所有工程判断都由模型独立完成。

文章区分了 Pando 服务与公开的 Git 改进。OpenAI 介绍了向上游贡献的数据包下载、校验及追踪相关工作，并提供公开补丁跟踪入口；但对于 Pando 本身，只表示正在探索向用户分享技术的方式。因此当前读者能够研究设计与相关 Git 贡献，不能据此声称已能注册使用一项 Pando 云服务。

继续阅读