bingdadaOpenAI 自研了 Git 新后端 Pando，在保持 Git 协议兼容的前提下实现多分支并行写入与读取复用，生产环境推送延迟中位数降低近 5 倍，日均交付近 1 PB 数据。
过去一年，OpenAI 内部单体仓库（monorepo）的体量与访问压力同步飙升。Codex 这类编程智能体的普及，让工程师可以同时推进多条工作流，分支数量、推送频率、合并操作以及来自开发环境、研究任务和持续集成（CI）的拉取与克隆请求都在成倍增长。这种需求会叠加：一位工程师可能同时有多个变更等待 CI，而每次推送又会触发多个作业去拉取同一个提交。
从去年年底开始，支撑该仓库的系统开始吃力，拉取和推送变慢、合并失败频发，可靠性一度跌破 90%。问题究竟出在 Git 本身，还是出在服务单体仓库的方式上？Git 诞生于内核社区通过邮件交换补丁的年代，二十多年来开发者一直在围绕它调整工具链。OpenAI 希望保留这套熟悉的工作流，同时重建后端，使其能够并行处理不同分支的推送，并同时向大量读者提供同一份历史。
于是有了 Pando——一个面向 Git 仓库的新后端。它在不中断任何工程工作、不改变团队使用 Git 方式的前提下上线，如今支撑着 OpenAI 单体仓库的全部开发活动。其设计目标有两个：一是写入的水平扩展，针对大量分支的并发推送做优化；二是最大化读取吞吐，让客户端能跑满可用网络带宽。在生产环境中，Pando 将推送延迟中位数降低了近 5 倍，每天交付近 1 PB 的 Git 数据。
扩展源码控制系统本质上要解决两个维度的问题：大量写者向不同分支推送，以及大量读者拉取同一份历史。Pando 对两者都做了优化。
第一，Pando 独立协调每个分支的更新。无关分支的更新可以并行推进，读者拉取某个分支时只拿到该修订所需的历史。代价是，当读者同时查看多个分支时，可能看到它们处于不同的时间点。
第二，Pando 在多次拉取之间复用打包文件（packfile，Git 用于压缩多个对象的格式），而不是为每个客户端单独生成。客户端可能下载到一些已经拥有的对象，但服务器能以极小的计算量把同样的字节发给许多客户端。
这些取舍让写入可以跨分支扩展，读取则可以从缓存中服务。要理解它们如何配合，需要先回到 Git 的对象存储与传输机制。
Git 仓库需要让对象（objects）与引用（references）两部分保持同步。仓库把文件快照以及连接它们的历史记录为一张对象图。对象可以是 blob、tree、commit 或 tag：blob 保存单个文件的内容；tree 把名称与 blob 或其他 tree 关联起来，形成目录结构；commit 指向一棵根 tree 以及零个或多个父提交，从而构成仓库历史。
对象由其类型和内容的哈希值标识，且不可变：记录一个改动文件会创建新的 blob，而未变的文件和目录可以复用已有对象。分支和标签是引用（ref），指向提交；在分支上提交会创建新提交并更新该分支的 ref。
Git 的对象以“松散”或“打包”状态存储。松散对象存放在以对象 ID 命名的独立文件中；打包对象则集中存放在 packfile 里，使相似对象可以互为增量（delta）存储。在一次拉取中，客户端告诉服务器它想要哪些提交、已经拥有哪些提交；服务器找出从目标提交可达的对象，排除客户端已知的部分，把剩余内容以与磁盘上相同格式的 packfile 发送出去。
围绕 Git 的扩展，业界常见做法包括限制仓库规模、拆分仓库、或在协议层做代理缓存。Pando 的独特之处在于同时兼顾写并行与读复用，并保持与 Git 协议和客户端的兼容——工程师和智能体都能无缝接入既有工作流。这一点对 OpenAI 尤为重要：基于 Git 构建意味着客户端侧的改进可以回馈上游，惠及更广泛的社区。
在国内，大型科技公司与开源社区同样面临单体仓库与智能体并发带来的源码管理压力。部分企业采用自研分布式存储层或基于对象存储的缓存网关来缓解克隆与拉取瓶颈，也有团队在 Git 协议之上做多副本与增量传输优化。与 OpenAI 明确选择“保留 Git 兼容、重建后端”的路线相比，国内更多实践倾向于在现有 Git 服务（如 GitLab、Gitea 等）外围叠加缓存与调度层，以较低改造成本应对峰值。随着 DeepSeek、通义千问等模型驱动的编程助手普及，如何让源码基础设施承载智能体级别的高并发，正在成为国内工程团队共同面对的新课题。
OpenAI 表示将继续向上游 Git 贡献改进，以支撑智能体规模的工作负载。对开发者而言，这一案例的启示在于：当 AI 智能体成为代码生产的主力，源码控制系统的瓶颈往往不在协议本身，而在服务端的并发模型与缓存策略。关于 Git 的内部结构，可参考 Git 官方文档 与 Pro Git 书籍；关于 OpenAI 的工程实践，可查阅其 官方博客。
Pando 是 OpenAI 为 Git 仓库自研的新后端，在保持 Git 协议与客户端兼容的前提下，实现写入的水平扩展和读取吞吐的最大化，目前支撑其单体仓库的全部开发活动。
在生产环境中，Pando 将推送延迟中位数降低近 5 倍，每天交付近 1 PB 的 Git 数据，同时可靠性从一度低于 90% 的低谷中恢复。
常见方案多通过拆分仓库、限制规模或协议代理缓存来缓解压力；Pando 则同时优化多分支并行写入与多读者共享历史的读取复用，并保持对 Git 生态的兼容。
Git 是开发者熟悉的工作流基础，保留兼容意味着客户端改进可以回馈上游社区，也能让工程师和智能体无需改变习惯即可迁移。
Bingdada 是一个专注 SEO、GEO（生成式引擎优化）与 AEO（答案引擎优化）的内容平台，由资深内容编辑、SEO 技术工程师与 AI 研究专家组成的团队持续运营。我们追踪搜索引擎与生成式 AI 的最新动态，为读者提供准确、实用、可落地的方法论与行业洞察。
编辑团队：内容策划 · 技术编辑 · AI 研究组
网站：bingdada.com
© 2026 Bingdada. 保留所有权利。
SEO & GEO 技术探索者，专注于搜索引擎优化和生成式引擎优化。
从《纽约时报》诉OpenAI案切入，剖析AI训练合理使用的法律逻辑、跨领域支持者的核心论点，以及这场版权之争对全球AI创新生态与国内大模型合规路径的深远影响。
OpenAI发布社区安全报告计划并收紧青少年保护政策，涵盖执法转介、跨对话预警识别与武器信息限制，本文解析其治理逻辑及国内平台对照。
OpenAI 宣布支持 robots.txt 中的跨提供商 AI 训练偏好信号，网站只需声明一次即可向多家 AI 公司传达内容使用意愿。本文解析该机制的运作逻辑、对内容行业的影响，以及国内厂商的同类探索。
获取最新的 SEO 与 GEO 技术资讯。
我们尊重您的隐私，随时可以取消订阅。
