AI把GitHub撑出了故障，巨头们开始自己修路

11月3日，GitHub官方状态页一天记录了两次服务中断。到了第4天，合并请求继续出现异常或部分失败。

就在用户反复刷新等待的同时，Axios发出一条独家消息：OpenAI拟收购做代码托管工具的Pierre Computer。

一条故障新闻撞上一条收购新闻，时间紧挨着。但这两件事连在一起看，传递的信号比单一事件更值得注意——AI时代最流行的代码托管平台正在承受前所未有的并发压力，而围绕它的控制权争夺已经开始。

AI写的太快，平台跟不上了

GitHub的日常故障并不鲜见，但这次的压力源不同寻常。

问题的根源是AI Agent作为新访客的爆发式增长。过去访问GitHub的主要是人类开发者，他们提交代码、请求审查，节奏相对可控。当Claude Code、Codex这样的AI编程工具进入实际开发流程后，每个自动化任务都在不间断地取用代码、运行测试、合并修改。

Anthropic的工程团队给出了一个具象化的数字：5月份，公司平均每天合并约2500项代码改动。到了9月，这个数字超过3万。也就是说，短短四个月间，每天进入公共代码库的修改量翻了超过12倍。

光是持续集成等自动化任务，每天就要从仓库取用约2500万次代码。高峰期，他们维护着数百个Git镜像分担负载，但主仓库更新得越快，副本就越难跟上。

来自Anthropic工程博客的原话揭示了更深层的问题：“客户端用到哪个文件再去取哪个”成为新思路——因为来取代码的大多始终是始终在线的Agent，而非人类。

这种“机器vs机器”的高频访问模式，让传统git仓库“先拉全量再本地工作”的设计架构开始吃力。

OpenAI的双线出击

OpenAI同样尝过苦头。The Information早在今年3月就报道过，其工程师多次遭遇GitHub服务中断，公司当时已开始开发内部替代工具。

到了11月2日，距离本次收购宣布仅隔两天，OpenAI公开了自研Git后端系统Pando。据工程团队介绍，使用Codex之后，“一个工程师可以同时准备好几份改动”，每次推送触发的自动化任务也成倍增加——写代码的人没有多出好几倍，系统要处理的工作却翻倍了。

换上Pando后，一次推送的中位耗时降了近80％。 该系统从4月起就开始承接真实的开发流量。

而在解决内部问题之外，面向外部开发者，OpenAI选择了资本路径：收购Pierre Computer Company。

这家成立于2023年的初创公司融资约2400万美元，团队不足50人，但其核心产品Code Storage定位为面向AI智能体大规模并行工作负载的Git托管基础设施。Pierre的客户里已经包含了Lovable等AI应用开发平台——该公司在8月披露的数据显示，仅在Lovable平台上，每周新建超过800万个仓库，峰值达到每秒250个。

OpenAI确认会将Pierre的底层代码管理能力整合至自家编程智能体Codex，意图将其从单纯的代码生成插件升级为涵盖存储、版本控制、协同审查的全栈开发平台。交易仍需满足监管批准等交割条件。

与此同时，OpenAI还吸纳了Anthropic Claude Code的产品负责人Cat Wu加入核心团队负责产品管理。这一系列动作的时间巧合并非偶然。

Anthropic的重仓自研

如果说OpenAI走的是“自研＋收购”双线路线，Anthropic的做法则更为决绝。

面对激增的代码变更速度，他们并没有急于寻找外部替代方案，而是决定从头造一套。

7名工程师借助Claude本身的能力，花了5个月做出了内部版本控制系统Scion，以及配套的代码审查工具Antique，最终将整个主代码库迁移了过去。

Scion的架构逻辑与传统Git有明显差异：它采用按需取文件的机制，查历史、建提交、合并改动全部交给服务器端完成。这意味着不再需要为每个Agent预先备一份完整的仓库副本——直接查询服务器算好的结果即可。

不过，这套系统目前主要服务于Anthropic内部庞大的代码库。Claude Code的公开仓库等社区资源仍然保留在GitHub上。换句话说，顶级AI公司在内部基建上已经脱钩，但在开源生态中仍在依赖GitHub。

他们的代码审查流程也展现了AI时代的另一个转变：先让Claude做一轮审查，并在真实环境中跑起来——网页改动就让模型打开浏览器操作功能，工程师接着查看验证证据（操作录像、页面截图、测试结果）。即使如此，Anthropic承认，在每天数万次合并的规模下，并发修改仍可能发生冲突，只是他们称Claude通常能比人类更快发现并完成修复。

Cursor Origin：绕过GitHub的可能性

SpaceX在今年8月完成对Cursor的收购后三天，Cursor推出了自己的代码托管服务Origin。

这个服务的意义在于它提供了一种“绕过选项”：新项目可以直接在Origin建仓库，代码推到Cursor，同事审阅、接收修改意见、合并分支，这些操作完全绕开GitHub。对于已经在GitHub上的老项目，也可以只同步一份到Cursor——你在Cursor里留下的评论，队友回到GitHub也能看到，代码仍以GitHub上的版本为准。

这个策略非常务实：不强迫迁移，而是在关键协作环节提供替代路径。一旦审阅、评论、合并这些高频操作能在Cursor生态内闭环，“专门打开GitHub干什么”就会成为一个越来越多开发者会问的问题。

讽刺的是，Cursor Origin开放早期测试仅仅三天后——8月17日——GitHub发生了一场持续7小时47分钟的严重故障。Cursor员工Matt Palmer当时调侃：“本来想更早发的，可GitHub又挂了。”

时间上的巧合让这场对比显得格外戏剧化。

GitHub也在拼命补窟窿

面对四面八方的挑战，GitHub并非被动接受。

微软旗下GitHub在10月28日披露，今年已新增400万个CPU核心和160PB高速存储，并继续把服务迁往Azure云平台。增加算力之外，GitHub正在改造底层的排队方式——过去即使几个Agent各自在不同分支上提交修改，仍可能在同一个仓库的写入环节相互等待，现在要让这些更新能够并行处理。

同时，GitHub也在把读取和写入所用的资源分开，给取代码的任务单独扩容，减少两边争抢资源的情况。

但这些改造仍在分步推进。一家平台在AI带来的指数级访问增长面前，追赶的速度能否跑赢压力增长的斜率，尚无定论。

接下来看什么

这一轮基础设施争夺的背后，有几个值得持续关注的关键节点：

第一，OpenAI－Pierre收购何时完成交割。 监管审批时间表将决定这场“代码托管主权战”的第一步落地节奏。如果交割顺利，Codex用户在产品中即可无缝使用自有代码存储能力，对GitHub的溢出效应将从此刻算起。

第二，Anthropic Scion系统的开源可能性。 目前Scion仍限于内部使用，但如果未来以开源形式释放，将为更多中型团队提供一套应对高并发Agent代码管理的参考方案，加速行业基础设施的分层重构。

第三，Cursor Origin的留存率和迁移曲线。 绕过GitHub的“旁路策略”是否会被广泛采纳，取决于它在代码审查效率和协作体验上能否稳定超越GitHub。目前的数据缺口很大，但已有早期用户的反馈值得关注。

第四，GitHub Azure迁移的节奏和稳定性。 400万核CPU和160PB存储是一次大规模投入，但AI Agent访问量的增长速度是否会让这次扩容迅速变为新的基线？这决定了微软在代码托管领域的长期成本结构。

第五，开源社区对集中式平台的依赖度变化。 只要像Anthropic这样还在GitHub上保留社区仓库，只要像Pierre这样仍有大量客户在使用Code Storage，集中式代码托管的基础地位就不会立刻动摇。但当头部玩家逐步在内部分离基础设施时，整个生态的结构弹性将面临新一轮考验。