当代码仓库大到一定程度，Git 本身就会成为瓶颈。OpenAI 给出的答案是：不改 Git 协议，改 Git 后端。
发生了什么
据 MarkTechPost 报道，OpenAI 推出了 Pando，一个面向其 monorepo 的 Git 兼容后端。它的核心设计有两点：一是把分支当作彼此独立的对象来处理，二是让存储中的 packfile 能在多次 fetch 之间复用，而不是每次重新打包。效果是推送延迟中位数下降接近 80%，同时该系统目前每天要交付接近 1PB 的 Git 数据。
需要说明的是，Pando 是 OpenAI 内部基础设施，而非面向外部开发者的产品发布。公开信息只给出了延迟改善幅度与数据吞吐量级，没有披露具体架构细节或开源计划。
为什么重要
Git 诞生于 Linux 内核的开发场景，其设计假设是仓库规模可控、分支数量有限。但近十年头部科技公司的 monorepo 早已突破这一假设：单一仓库承载数百万文件、成千上万的日常提交，以及大量并行分支。在这种规模下，传统 Git 的痛点集中爆发——clone 与 fetch 要传输巨量对象，push 时要重新计算和打包，分支越多，重复计算越严重。
业界对此有两条路线。一条是绕开 Git，比如 Google 的 Piper、Meta 的 Sapling，代价是生态割裂、工具链重建。另一条是在 Git 协议之下替换存储与传输层，保持兼容。Pando 显然属于后者：开发者仍用熟悉的 git 命令，但底层换了一套更懂大仓库的实现。这条路线对工程组织更友好，因为它不需要说服整个公司换工具。
影响与看点
对多数团队而言，Pando 不会直接可用，但它指出了一个明确方向：AI 公司正在成为基础设施的深度自研者。训练集群、推理栈之外，代码托管这类“传统”环节同样在被重做，因为大规模并行开发与自动化 agent 提交代码，正在把仓库读写压力推到新量级。
值得关注的三个点：其一，分支独立处理与 packfile 复用是否会被抽象成通用方案，进而影响自建 Git 服务的开源项目；其二，近 1PB 的日交付量意味着这类系统的瓶颈已从计算转向存储与网络，相关优化思路可能外溢到其他超大规模场景；其三，如果未来有 coding agent 大规模自动提交代码，仓库后端的吞吐能力会从“工程体验问题”变成“生产力上限问题”。
一个独立判断：Pando 的真正价值不在那 80% 的数字，而在于它证明了 Git 兼容层仍有巨大的工程空间——不必推翻 Git，也能让它适应下一个十年的规模。
