OpenAI公开了内部Git后端Pando的架构与迁移经验，展示如何通过按引用（分支）独立更新和复用packfile来应对智能体驱动的并行读写洪峰。Pando在保留现有Git工作流的同时显著降低推送延迟并提高读取带宽利用，但牺牲了全库统一快照语义，迁移与集成仍有成本。
OpenAI在2026年11月2日公开了一套名为Pando的Git仓库后端，解释公司如何在保留现有Git工作流的同时，应对Codex带来的大量并行开发任务。公司称，迁移后内部代码推送的中位延迟降低近80%，系统曾在一小时内传输超过57 TB的Git数据包，其中超过99%的字节来自本地磁盘缓存。
这不是一次当天才上线的产品发布。按照OpenAI的工程文章，Pando自2026年4月开始承载生产流量，目前已支撑公司单体代码仓库的全部开发。此次披露的重点，是这套内部基础设施的架构、迁移过程和运行结果，而非对外开放的新服务。
它提出的问题也不只是“Git能否更快”：当一个工程师同时安排多个智能体修改不同分支，每次推送又触发多个持续集成任务下载同一份代码，版本控制系统需要处理的并发量，会随着开发方式变化而成倍叠加。
瓶颈不只在仓库有多大，更在同时有多少读写
OpenAI称，从2025年末前后开始，原有单体仓库服务出现拉取和推送缓慢、合并失败等问题，可靠性有时降至90%以下。文章没有为这一可靠性指标给出完整统计口径，因此不能直接将它等同于整个开发平台的可用率。
团队没有放弃Git，而是把改造重点放在服务端。Pando的两个目标分别是：让不同分支的写入能够横向扩展，以及让大量客户端同时读取代码时，尽可能用满各自可用的网络带宽。
理解这一点，需要区分Git仓库里的两类数据。对象保存文件内容、目录结构和提交历史，内容改变会产生新对象；引用则像指针，记录分支或标签指向哪个提交。推送不仅要上传对象，还要更新引用；读取一个新提交时，服务端必须能提供它所依赖的对象。
在OpenAI分析的传统方案中，如果整个仓库的引用更新都要经过同一个协调点，即使两个客户端修改的是互不相关的分支，也可能相互等待。增加存储容量，并不必然消除这种协调瓶颈。
用分支独立更新，换取更大的并行空间
Pando把协调范围收缩到单个引用。收到推送后，它将数据包作为不可变对象存入对象存储，再在元数据存储中记录新的引用版本，包括分支的新位置、对应数据包及其依赖关系。不同分支可以独立推进，只有同时争用同一引用的更新才会发生冲突。
这一设计保留了单个引用更新的可串行化保证，也提供“读取自身写入”的一致性：成功推送后，客户端能够读取刚更新的提交。
但它没有提供整个仓库所有分支在同一时点的统一快照。例如，在两个分支都发生更新时，一次克隆可能读到分支甲的较早版本和分支乙的较新版本，另一个客户端则可能看到相反组合。OpenAI将其描述为因果一致性，并认为内部工程师和智能体主要依赖单个分支的更新顺序，而非所有分支之间的全局顺序。
这是一项明确的工程取舍，而不是一致性问题被彻底消除。需要跨分支统一快照的系统，不能直接假定Pando提供这种语义。
不再为每个读取者重新打包
读取端的改造围绕Git的packfile展开。这是一种把多个对象压缩在一起的数据包格式。Git官方协议文档说明，客户端与服务端会交换已有和需要的提交信息，协商应传输的数据。常规服务端可以据此生成适合特定客户端的数据包，尽量避免重复发送对象。
Pando则优先复用已经存在的数据包，而不是每次都为客户端重新计算和压缩。这意味着客户端有时会收到自己已经拥有的对象，但服务端可以把同一份字节反复交给大量读取者，减少CPU计算与磁盘读写。
为了使上传的数据包更容易复用，Pando默认在客户端推送新功能分支时，只将指定主干分支作为协商基准，而不是公布所有分支。代价是反复推送同一个功能分支，或者把功能分支叠加在另一个功能分支上时，客户端可能重复上传主干之外的内容。
OpenAI称，在其单体仓库中，按这种方式产生的数据包中位大小低于20 KiB，第99百分位低于3 MiB。公司认为，这一带宽代价可以接受，因为已有相应主干历史的读取者，可以用同一个数据包获取该分支。这些分布反映的是OpenAI自身工作负载，不能据此推断其他仓库也会得到相同结果。
读取时，Pando通过Git的packfile-uri机制返回数据包下载地址，由名为Express的服务利用区域缓存提供文件。服务端负责协商和选择数据包，数据传输则可以独立扩容。后台还会合并小包，避免落后较多提交的客户端必须逐一下载成千上万个文件。
性能数字说明了什么，又没有说明什么
OpenAI披露，切换到Pando后，推送中位延迟降低近80%，合并可靠性得到改善；在标准云虚拟机上，克隆和拉取操作可以用满10 Gbps网络链路。公司还报告，系统曾在单小时内提供超过57 TB的数据包，超过99%的传输字节来自本地磁盘缓存。
这些指标指向不同层面：推送中位延迟衡量一次写入的典型等待时间，链路利用率反映特定客户端与网络条件下的数据传输能力，单小时传输量则体现系统面向多个请求的数据分发规模。缓存提供的重复读取字节，也不等于同等规模的新增代码。
上述结果均来自OpenAI自身的生产运行或测试披露，并非独立第三方复测，也不能合并解释为软件开发效率提高了80%。代码审查、测试执行和最终合并仍属于完整开发链路中的其他环节。
由智能体参与建设，但仍需要迁移与验证
OpenAI称，Pando从项目启动到投入生产用了10周，核心设计由一名工程师完成，智能体团队参与实现，少量工程师负责部署。系统采用Rust编写，并通过Git行为一致性测试和确定性模拟测试检查协商、数据包规划及并发边界。
迁移也不是一次性替换。Pando最初作为原有源码管理系统的读写穿透代理运行，让两套系统保持同步，再逐步承接流量。团队还迁移了依赖旧API、Webhook和仓库下载接口的数百项集成。这说明，保留Git命令并不意味着更换后端没有集成成本。
对外开放的边界同样需要分清。OpenAI已经公开其Git客户端代码仓库，公司称，部分下载、索引、追踪和数据包复用相关改进已进入上游Git，另一些仍在公开仓库中。但客户端改进公开，不等于Pando后端已经开源，也不意味着外部团队可以直接使用同样的托管服务。
文章表示，OpenAI仍在探索向用户分享相关技术的方式。就目前披露而言，Pando更重要的意义，是展示了一条面向并行智能体的基础设施改造路径：不必先改变开发者熟悉的版本控制工具，而是重新安排一致性、计算和带宽之间的成本。能否把这条路径推广到其他团队，仍取决于各自的分支模式、数据包大小、网络条件，以及对跨分支一致性的要求。