AI 智能体撑破了开发者基础设施：OpenAI 自建 Pando，并收购 Pierre

11 月 3 日和 4 日，GitHub 接连宕机，整个平台上的 Git 操作、拉取请求、议题、Actions 和 Webhooks 都受到影响——这是过去十二个月里 201 起事故中的最新两起。时间点颇为微妙。第一次宕机的两天前，OpenAI 刚刚披露了 Pando：一个从零重建的内部 Git 后端，原因是它自己的编程智能体让普通的推送操作变得不再可靠。第一次宕机的两天后，OpenAI 宣布将收购 Pierre Computer Company，而这家公司的基础设施早已在 Codex 内部运行。把这几步棋放在一起看，开发者工具正迎来一个结构性的拐点：二十年来托管人类所写代码的基础设施，正在为一个由 AI 智能体编写大部分代码的世界而被彻底重新设计。

11 月的这些公告，是自 10 月以来逐渐成形的一个更大趋势的一部分。10 月 13 日，Anthropic 公布了 Scion 的细节——这是一个在其单体仓库中完全取代 Git 的自研版本控制系统。8 月 17 日，Cursor 推出了 Origin，一个内嵌在其 AI 编辑器中的代码托管平台——就在同一天，GitHub 宕机了 7 小时 35 分钟。每家公司都从各自的工程实践出发，得出了结构上相似的结论：Git 不是为智能体编程所带来的规模和并发而设计的。

Codex 的提交增长速度超过了 Git 的承受能力

催生 Pando 的直接原因，不是 GitHub 的可靠性，而是 OpenAI 自己的编程智能体。当开发者开始并行运行多个 Codex 会话时，推送模式变了：不再是一次顺序提交，而是一位工程师可能同时有好几个后台智能体在推送改动，每一次都会触发自动化的审查和测试流水线。OpenAI 在其11 月 2 日的工程博文中报告称，在这种情况下，推送延迟恶化，合并时不时失败，整体系统可靠性跌到了可接受的水平以下。

Pando 的应对是架构层面的，而不是简单地扩容。核心创新在于按分支并行更新：每个分支独立更新，因此推送到互不相关分支的操作可以并发进行，而不必去争夺 Git 的引用更新模型所要求的那把全仓库写锁。传入的 packfile 直接写入 blob 存储，而分支版本及其依赖关系则记录在一个团队称为 Turtle 的独立元数据服务中。一个名为Express的分发服务最大限度地在不同客户端之间复用 pack，缓存命中率超过 99%。

根据OpenAI 报告的数据，性能提升相当可观，不过这些是公司自测的结果，尚无独立复现：推送延迟中位数下降了近 80%，系统每天处理将近 1 PB 的 Git 数据，单小时最高送出过超过 57 TB 的压缩 Git pack。由于缓存命中率很高，如此大的吞吐量只需要少量 CPU 核心就能撑起。

Pando 本身就是用 Codex 建出来的。一位工程师设计了核心架构；一组组智能体负责实现；一小群工程师负责部署。从启动到投入生产大约用了十周，自 2026 年 4 月起承载线上流量。它用 Rust 编写，没有任何历史遗留依赖，并使用形式化验证工具——Lean用于证明检查，TLA+ 用于描述并发系统的行为——来验证正确性。另外还有智能体持续运行，探测 Pando 的安全状况。OpenAI 已经向上游 Git 项目回馈了修复，并表示正在探索让 Pando 更广泛可用的方式，但系统本身目前仍是内部使用。

有一个值得注意的刻意取舍：Pando 无法提供整个仓库在某一时间点上的统一视图。每个分支在内部是一致的，但同时跨多个分支读取的客户端，看到的可能是不同时间的快照——这对人工审查流程来说可以应付，但对于同时从多个分支拉取的智能体流水线，就需要特别考虑。

收购 Pierre，补上了 Codex 缺失的托管层

11 月 4 日，也就是 Pando 博文发出两天后，OpenAI 宣布有意收购 Pierre Computer Company, Inc.交易的财务条款未披露；这笔交易仍需获得监管批准。Pierre 的开源项目——Diffs、Trees 和 DiffsHub——在收购完成后将继续保持开源。

这笔交易并非试水。Pierre 的 Trees 库让用户浏览仓库里的文件；它的 Diffs 库负责渲染并排的代码对比。这两样都已经内嵌在 Codex 应用里。任何在 Codex 里浏览过文件或审查过改动的开发者，其实早就在用 Pierre 的代码了。这次收购真正带来的是 Code Storage：一种可编程、托管式的 Git 基础设施，按照 AI 智能体产生的吞吐量和并行度来校准，而不是按照人类开发团队的节奏。

Code Storage 的客户名单最清楚地展示了 Pierre 所要解决的规模问题。AI 驱动的开发平台 Lovable 每周新建超过 800 万个仓库，峰值时每秒新建 250 个。Pierre 的规格正是围绕这样的环境打造的：单个仓库最大 32 TB，每个仓库每秒超过 500 次 Git 请求，整个平台每秒超过 1.5 万次 API 请求，以及 99.99% 的可用性承诺。背后的团队来自 Cloudflare、Coinbase、Discord、GitHub、Meta、Reddit、Stripe 和 Twitter。

这笔收购符合一种可以辨认的平台整合模式。率先报道此事的 Axios 将其定性为 OpenAI 瞄准了微软旗下的 GitHub。这个定性方向是对的，只是为时尚早：Pando 解决的是后端传输层；Code Storage 解决的是托管层；Codex 则是上面的智能体层。五天之内的这几步——披露 Pando、GitHub 宕机、收购 Pierre、扩大 Codex 配额——看起来更像是一盘协同的平台棋局，而非巧合。OpenAI 目前公开层面仍然缺少的是代码审查与协作层；这个空缺依然存在。

这对微软的竞争意义异常直接：微软拥有 GitHub，同时又在 OpenAI 持有可观的投资股份，这让它对同一家机构而言，既是支持者，又是竞争目标。

Anthropic 走得更远：七名工程师彻底取代了 Git

OpenAI 是在保持协议兼容的前提下升级了自己的 Git 基础设施，而 Anthropic 则干脆抛弃了 Git。10 月 13 日，公司发表了一篇工程博文，介绍了 Scion——它的单体仓库如今运行在这个自研版本控制系统之上。一支七人工程团队用五个月完成了从 Git 的全面迁移，而在此期间，合并量先翻了一倍多，然后又翻了一倍。

让 Git 不堪重负的规模数字很具体。2026 年 5 月，Anthropic 的单体仓库每天大约处理 2500 次代码合并。到了 9 月，这个数字超过了 3 万——四个月里增长了 12 倍。持续集成每天要拉取仓库大约 2500 万次。在基于 Git 的系统达到峰值时，公司维护着数百个镜像来分担这些读负载，每次检出都要耗费好几分钟的 CI 时间。主分支的历史已经增长到将近 100 GB。如果这些 CI 拉取在 Git 下以朴素方式访问仓库，每天的总数据传输量将超过 600 PB。

Scion 的设计在架构层面回应了这些限制。Git 的分布式模型假设客户端可能需要离线工作，因此给每个客户端一份完整的仓库副本——这是 Git 在 2005 年诞生时的一个刻意设计。Scion 则把客户端视为永久在线，并把所有计算都推到服务器端：提交、合并、变基、历史查询，以及逐行的改动归属，全部在服务端运行。客户端按需惰性拉取，只取回某个任务所需的具体文件或变更集，而不维护完整的本地副本。历史的基本单位是变更集：它是一份预写日志中的一条记录，只记录相对其父节点被修改的文件，并用内容寻址的指针指向对象存储中的压缩文件内容。

Anthropic 报告的运维改进虽然是公司自测的，但考虑到数百个 Git 镜像被取消，这些数字是可信的：Scion 的基础设施在 CPU 和内存上比之前的镜像系统小 200 倍，检出速度快了大约 100 倍。这七名工程师还构建了配套工具：Antique，即代码审查界面；一套代码搜索系统；以及一层用于访问控制的 IAM。Anthropic 拿来类比的是谷歌的 Piper——这个集中式单体仓库系统支撑着谷歌内部的开发，同样把仓库视为服务端资源，而不是分布式副本。

Claude 贯穿了 Scion 的构建和日常运行。当 Claude Mythos Preview 在内部可用时，Anthropic 让这个模型重写了从 Git 到 Scion 的导入流水线。结果内存占用减少到原来的二十分之一，运行速度快了四倍。Claude 还通过 Anthropic 所称的对抗式审查，持续参与代码审查过程本身：Claude 扮演提议改动的挑剔批评者，运行基于浏览器的测试，产出截图和操作录像作为可核验的证据，然后才由人类工程师评估结果。实际效果是，每一项进入 Anthropic 代码库的改动，在人看到之前都要先经过 Claude 的评估。

Scion 不会成为通用产品。Anthropic 明确将其描述为「绝不是 git 在通用场景下的合适替代品」，因为对于任何尚未达到 Anthropic 这种特定规模的组织来说，它的集中式架构都需要大量的迁移工作。公司倒是做出了一个预测：随着智能体提交量不断叠加，大多数正在积极推进 AI 编程的工程组织，都会在六到十二个月内遇到类似的 Git 瓶颈。

Origin、GitHub，以及规模化重建的竞赛

Cursor 从产品角度切入了这个领域。SpaceX 通过 Cursor 的母公司 Anysphere，以 600 亿美元全股票交易收购了 Cursor，交易于 8 月 14 日完成。三天后，Cursor 推出了 Origin，一个直接内嵌在编辑器里的代码托管平台——就在同一天，GitHub 一场长达 7 小时 35 分钟的宕机，让 Git 操作、Actions、拉取请求、议题和 Webhooks 全部瘫痪。公司称它「为智能体规模而设计」。

Origin 基于 Git，仓库地址形如cursor.com/codebase/name，并可选择与 GitHub 同步，方便希望分阶段迁移的团队。Cursor 在 2025 年 12 月收购了拉取请求工作流初创公司 Graphite，让 Origin 在上线前就有了代码审查的基础。到 10 月，其应用市场已扩展到20 多项集成，包括 Vercel、Depot、Buildkite、Cloudflare、Linear、Sentry 和 CodeRabbit。

GitHub 的应对则是另一个量级。在10 月 28 日的 GitHub Universe 大会上，公司披露仅 2026 年一年就新增了 400 万个 CPU 核心、160 PB 的存储和每秒 50 Tb 的网络容量。每月提交量从 2024 年的 6500 万次，增长到 2026 年 9 月的 74 亿次——不到两年增长了约 100 倍，主要由 AI 编程工具推动。仅 9 月一个月，GitHub Actions 就处理了 32.6 亿个作业。

GitHub 也在推进架构改造，而不只是扩容。它的内部基准显示，采用计算与存储分离的新架构后，写入吞吐量最高可提升 35 倍。并行分支更新——与 Pando 核心相同的设计原则——也在落地，以防止往不同分支提交的智能体在共享写入层上互相阻塞。向 Azure 的多区域迁移预计将在 2027 年初完成。11 月 3 日和 4 日的宕机表明，这一转型仍未完成。

三种思路，同一个问题，尚无公开可用的解决方案

这四家的模式在结构上如出一辙：AI 编程智能体改变了开发者与存储其工作成果的系统之间的关系，而现有基础设施并不是为应对这种变化而设计的。人类工程师在一个工作日里按线性顺序推送代码，中间自然有停顿。智能体则持续不断、并行地、同时跨多个分支推送代码，没有停顿。Git 的核心设计——按仓库的写锁、完整克隆的客户端架构、按人类节奏运转的合并队列——是为前一种模式构建的，在后一种模式下扩展性很差。

如今已投入生产的三种架构应对，体现了三种不同的思路。Anthropic 选择全面集中：Scion 把所有计算都放在服务器上，把对客户端的要求降到几乎为零。OpenAI 在保持 Git 兼容的前提下，在分支层面实现并行：Pando 去掉了共享写锁，又没有破坏现有的工具生态。Cursor 则把托管内嵌进开发环境：Origin 消除了代码编写之处与存储之处之间的界线。

这些答案目前都还没有向更广泛的软件行业公开提供。Scion 是内部系统，没有发布计划。Pando 也是内部系统，没有宣布开放时间。Code Storage 是唯一一个正通过 Pierre 收购走向普遍部署的组件，但它解决的是托管层，而非底层协议的限制。GitHub 的隐含判断——靠投入容量和演进架构，无需取代 Git 就能解决智能体规模的问题——将在未来一年里面临真正的考验。Anthropic 的预测说得很明白：六到十二个月后，大多数认真推进 AI 编程的组织都会撞上同一堵墙。正是这个倒计时，而不是任何产品发布，让开发者基础设施这个问题在此刻变得紧迫。