我先查这条新闻的原始信源和具体交易细节，确认 OpenAI 收购的是哪一家、A 社（Anthropic）和马斯克各自在做什么。
这里有一处需要核实：中文报道说 “马斯克旗下的 Cursor”“SpaceX 完成对 Cursor 的收购”，这听起来很可疑，我去查一下。
这条新闻我把原始信源都翻了一遍，包括 OpenAI 官方公告、Anthropic 工程博客、Cursor 的 changelog 和 SpaceX 交割公告。中文稿里把几件事的时间压在一起了，其实跨了近三个月。另外 “马斯克旗下的 Cursor” 这个说法，我一开始以为是笔误，核实后发现是真的：Cursor 确实已经被 SpaceX 收购了。
先说结论：这件事是三家在差不多的时间点、从三个不同方向，分别在拆 GitHub 的三块地基，不是 “GitHub 要完了”。11 月 2 日 OpenAI 公开了自研 Git 后端 Pando，11 月 4 日宣布收购做代码存储的 Pierre；10 月 13 日 Anthropic 公布内部版本控制系统 Scion，7 个工程师加 Claude，5 个月把主代码库整个搬离 Git；8 月 17 日，刚被 SpaceX 以 600 亿美元收购、并入 SpaceXAI 的 Cursor，上线了自己的代码托管 Origin。触发点是一样的：AI agent 把 “一个人一天提交几次” 变成 “一个 agent 一分钟提交几十次”，而 Git 从 2005 年就是按 “每个客户端保存一份完整仓库、合并排队串行执行” 设计的。Anthropic 的数字最能说明问题：5 月每天合并 2500 项改动，9 月超过 3 万项，4 个月涨 12 倍；CI 每天要检出代码约 2500 万次，按最朴素的方式取数，一天就是 600PB 流量。GitHub 自己也没闲着，今年加了 400 万个 CPU 核心、160PB 高速存储，把读写资源拆开，写入吞吐提升到最高 35 倍。真正的变化，是代码托管的入口正在从 “平台层” 往 “模型层和 IDE 层” 下移。
Anthropic一、先把三件事的时间和主角对上
中文稿读起来像同一天发生的，其实前后跨了三个月，时间线理清楚才看得懂因果：
| 时间 | 谁 | 做了什么 |
|---|---|---|
| 2026 年 4 月 | OpenAI | Pando 开始承接真实生产流量 |
| 2026 年 8 月 14 日 | SpaceX / Cursor | 600 亿美元全股票收购 Cursor 母公司 Anysphere 交割完成，并入 SpaceXAI |
| 2026 年 8 月 17 日 | Cursor | Origin 代码托管开放早期测试，当天 GitHub 挂了 7 小时 47 分 |
| 2026 年 10 月 13 日 | Anthropic | 工程博客公开 Scion，主库已从 Git 迁完 |
| 2026 年 10 月 28 日 | GitHub | 披露今年的扩容与架构改造进展 |
| 2026 年 11 月 2 日 | OpenAI | 公开自研 Git 后端 Pando |
| 2026 年 11 月 3—4 日 | GitHub | 状态页连记多起故障，其中一起影响 Git 操作，4 日合并请求服务异常 |
| 2026 年 11 月 4 日 | OpenAI | 宣布收购 Pierre Computer，交易待监管批准 |
所以这条新闻的 “撞车感” 是编辑拼出来的：Origin 上线是 8 月的事，Scion 是 10 月的事，Pierre 是 11 月的事。真实节奏是，三家各走各的路，只是都被同一堵墙挡住了。
二、GitHub 到底被压到什么程度
这组数字来自 GitHub 存储团队工程师的公开分享和媒体报道，能看出压力是量级上的：
| 指标 | 数据 |
|---|---|
| 每月 push 次数 | 从 6.9 亿涨到 33.5 亿，同比增长 4.9 倍 |
| 2026 年 9 月提交数 | 73.8 亿次，是去年同期的 5 倍多 |
| Actions 运行次数 | 9 月 32.6 亿次，同比 4 倍 |
| Git 总事件量 | 每月从 2182 亿涨到 4733 亿 |
| 全年提交预测 | COO 预计 2026 年 140 亿次，2025 年约 10 亿次 |
| 今年新增资源 | 400 万个 CPU 核心、160PB 高速存储，继续迁往 Azure |
| 架构改造效果 | 存储与计算解耦后，写入吞吐最高提升 35 倍 |
| 过去一年故障 | 有统计称 257 次中断，这个数字来自第三方汇总，非官方口径 |
它改的三件事，其实和 Anthropic 的思路撞了：
- 不再按整个仓库排队，允许不同分支的引用更新并行处理，减少无谓等待。
- 读写资源拆开，取代码的任务多了，就给读服务单独扩容，别跟写入抢资源。
- 存储与计算解耦，算力节点变成无状态缓存，挂一台只是缓存未命中，不是数据丢失。
一句话：GitHub 在保住兼容性的前提下原地重建，这比 Anthropic 的 “推倒重来” 难得多。
三、OpenAI：先造 Pando，再买 Pierre
这两步是一套组合拳，缺一不可：
- Pando 解决 “写进去”。10 周做完，Codex 参与开发，4 月起接生产流量。官方口径是一次推送的中位耗时降了近 80%，每天承载近 1PB 的 Git 数据；改造前可靠性有时会掉到 90% 以下。
- Pierre 解决 “存下来、看得清”。Pierre 2023 年成立，累计融资约 2400 万美元，主力产品 Code Storage 是面向 agent 负载的 Git 托管基础设施，单仓库可到 32TB、至少 30 路并发写，提供 Python/Go/TypeScript SDK，能对接 GitHub、GitLab、Bitbucket。客户里有 Lovable，8 月披露每周新建超 800 万个仓库，峰值每秒 250 个。
- 它的 Trees 和 Diffs 早就在 Codex 里了。你在 Codex 里浏览文件、看某个改动增删了哪几行，用的就是这两套库。所以这不是 “从零买一块新业务”，是把已经在跑的零件正式装进机器。
官方表述很克制：想在开发者现有的 Git 工作流基础上做适配，没说要直接取代 GitHub，也没公布任何面向公众的托管价格。交易还要过监管，交割前两家仍是独立公司。
四、Anthropic：7 个人、5 个月，把主库搬出 Git
Scion 最值得看的是设计前提变了：它假设 “客户端永远在线”，因为客户端基本都是 agent 和 CI 任务。六个原则，条条都在反着 Git 来：
| 原则 | Git 怎么做 | Scion 怎么做 |
|---|---|---|
| 客户端状态 | 每个克隆是一份完整仓库，可离线 | 客户端只保留有限缓存，用时再取 |
| 职责划分 | 每个客户端都能当服务器 | 历史查询、建提交、合并、变基全在服务端 |
| 查询方式 | 要本地仓库或厂商 API | 所有查询开放成 API，CI 不用落盘 |
| 扩展性 | 靠几百台镜像分摊 | 数据分布式存储，没有完整实体副本，无 packfile |
| 提交成本 | 本地提交再 push，成本随仓库涨 | 服务端提交，成本只随本次改动大小涨 |
| 工作副本 | 默认全量检出 | 稀疏检出 + 虚拟化检出，读多少取多少 |
结果（均为 Anthropic 自述，未独立验证）：资源占用比原来的几百台 Git 镜像小 200 倍，CI 检出从几分钟降到几秒，单 CI 就省出 25% CPU。还有个细节挺有意思：Claude 把人工写的 Git-to-Scion 导入管线重写了一遍，内存少 20 倍、速度快 4 倍，还找出一个人类工程师没注意到的索引没用上。
但 Anthropic 自己划了三条线，别忽略：
- Scion 不是 Git 的通用替代品，只适合 “几万工程师或大量 agent 持续产码” 的超大单体仓库。
- 它依赖超高 token 预算，这个前提大多数公司不具备。
- Claude Code 的公开仓库还留在 GitHub。搬走的是内部主库，不是全部家当。
五、SpaceX 的 Cursor：Origin 是绕开，不是替代
先说清所有权：2026 年 8 月 14 日，SpaceX 以约 600 亿美元全股票完成对 Anysphere 的收购，Cursor 并入 SpaceXAI 部门（xAI 今年 2 月已并入 SpaceX）。所以 “马斯克旗下的 Cursor” 这个说法是成立的，中文稿没写错。
Origin 的定位很取巧：
- 新项目直接在 Origin 建仓库，push 落在 Origin，GitHub 不在链路里。
- 老项目只做镜像同步，GitHub 仍是唯一事实来源，push 还是去 GitHub。
- PR 评论双向同步，在 Cursor 里评论会贴到 GitHub，GitHub 上回复几秒内回到 Cursor。
- CI 和部署用现成的，接 Vercel、Depot、Buildkite，Depot 和 Buildkite 能直接跑你现有的 GitHub Actions 工作流。
三个必须知道的风险，比功能列表重要得多：
- 默认加入，不是默认退出。付费账户自动纳入 Origin，只有企业管理员能关。
- 发布时没有独立的数据条款。留存期限、是否用于训练、子处理方清单、代码导出工具，在 Origin 上线时都没有单独发布；原有的隐私条款写的是 “推理”，不是 “存储”。
- 没有欧盟数据驻留。企业文档口径是仅美国驻留，欧盟只有 “按需申请、仅推理”，Origin 存储的代码同样没得选。
对国内团队来说，第 2、3 条比 “能不能替代 GitHub” 更值得先问清楚。
六、三家打法对比，一句话看清各自补哪块
| 玩家 | 补的是哪一层 | 对 GitHub 的实质威胁 | 明显短板 |
|---|---|---|---|
| OpenAI | 写入吞吐（Pando）+ 存储与审阅（Pierre） | 高，但主要抢 “AI 生成的代码存在哪” 这块增量 | 尚无公开的托管产品与定价，交易待批 |
| Anthropic | 内部超大单体仓库的整体重构 | 低，官方明说不适用于一般场景 | 高度定制，外部几乎无法直接复用 |
| SpaceX/Cursor | IDE 内置托管 + 双向同步 | 中高，切换成本接近零，且自带 36 万付费用户的分发位 | Beta 功能少，数据条款与驻留缺失 |
| GitHub | 原地重建后端，保兼容 | — | 必须背着十五年生态改，最慢也最重 |
一个容易被忽略的变量：8 月 28 日 OpenAI 通知 SpaceX，将停止向 Cursor 供应模型，关停日期定在 11 月 12 日。也就是说，Cursor 在抢 GitHub 的地盘，同时在被 OpenAI 断供。这个行业的敌友关系，基本按月重算。
七、普通团队要不要跟着换
绝大多数团队现在不需要换，但需要做一次十分钟的自测。三个问题，任一答不上来，就是隐患：
- 合并队列能不能承受 100 路以上并发？ 单线程合并队列会最先成瓶颈。有个第三方测算称，Git 基线配置的合并吞吐大约每秒 2 到 3 次，这个数不是官方数据，但方向可以参考。
- 每个写入触发多少次读取？ agent 一 push 就触发 CI，CI 就克隆，读放大会到 1000:1 甚至更高。查一下你们 CI 的 fan-out 比。
- 仓库增长速度在加快吗？ agent 会频繁打检查点，历史膨胀很快。每周记一次仓库体积，斜率变陡就该上浅克隆、稀疏检出或定期收敛历史。
要动手的话，按这个顺序：
- 先把浅克隆、稀疏检出、--filter=blob:none 这类现成手段用起来，八成压力能降下去。
- 把 CI 的 “取全量仓库” 改成 “取需要的目录”，很多流水线根本不需要完整历史。
- 合并队列改成并行 ref 更新或分片队列，别让所有分支排一条队。
- 真到了 100GB 历史、每天上万次合并这个量级，再考虑自建或迁移；到那时你已经是全球少数几家，抄 Anthropic 的思路比抄它的系统更现实。
八、几个容易传错的数字，核对一下
| 说法 | 实际情况 |
|---|---|
| “三家同一天出手” | 跨 8 月到 11 月，Origin 最早，Pierre 最晚 |
| “OpenAI 收购 GitHub 替代品” | 收的是 Pierre 的 Code Storage，是基础设施层，不是成型的托管平台 |
| “Anthropic 抛弃 Git” | 只迁了内部主库，Claude Code 公开仓库仍在 GitHub |
| “Cursor 是马斯克的” | 准确说法是 SpaceX 全资收购、并入 SpaceXAI |
| “Git 每秒只能合并 2—3 次” | 第三方测算，非 GitHub 或 Git 官方数据 |
| Scion 的 200 倍、25% CPU | Anthropic 自述，未经独立验证 |
九、收个尾
这轮变化最值得记住的一点：过去十五年，代码托管拼的是网络效应 —— 代码在哪，协作就在哪，CI 就在哪。现在拼的是另一件事：当代码的主要生产者从人变成 agent，仓库的第一用户就不是人了。人不关心每秒几百次克隆，agent 关心。谁把这一层做顺，谁就拿到下一个入口。GitHub 有 1.5 亿开发者的习惯，这是它最大的资产，也是最重的包袱；OpenAI 和 Cursor 没有包袱，所以敢从增量市场切进去。Git 不会死，但 “把代码往 GitHub 一放就万事大吉” 的时代，确实在松动。
相关 FAQ
问题 1：OpenAI 收购的 “GitHub 替代品” 到底是哪家公司，买了什么？
回答 1： 收购的是 Pierre Computer，2023 年成立于旧金山，累计融资约 2400 万美元，交易金额未披露，仍需监管批准。OpenAI 买的不是一款成品托管平台，而是它的 Code Storage—— 一套面向 AI agent 大规模负载的 Git 存储基础设施，单仓库可到 32TB、至少 30 路并发写，提供 Python、Go、TypeScript SDK，能对接 GitHub、GitLab、Bitbucket。Pierre 的 Trees、Diffs、Highlights 三套开源工具早就在 Codex 里跑着，所以这笔收购更像把已有零件正式装进机器，而不是从零补齐。
问题 2：Anthropic 的 Scion 是要取代 Git 吗，普通公司能抄吗？
回答 2： 不是，也不建议抄。Anthropic 自己在工程博客里写得很清楚：Scion 绝不是 Git 的通用替代品，只适用于 “几万工程师或大量 agent 持续产码” 的超大单体仓库。它依赖三个别人很难具备的前提：接近 100GB 的主分支历史、每天 2500 万次 CI 检出、以及远超常规公司的 token 预算。所以普通团队该抄的是思路 —— 客户端随时在线、服务端承担历史与合并、查询走 API、检出按需取 —— 而不是抄这套系统本身。
问题 3：马斯克的 Cursor 上线 Origin，和 GitHub 是什么关系？
回答 3： 是绕开，不是正面替代。新项目可以直接在 Origin 建仓库，GitHub 不在链路里；老项目只做镜像，GitHub 仍是唯一事实来源，PR 评论双向同步。所以它做的是 “让开发者不用打开 GitHub 也能完成审阅和合并”，切换成本接近零。风险在别处：Origin 对付费账户是默认加入而非默认退出，上线时没有独立的留存、训练、导出条款，也没有欧盟数据驻留选项。代码敏感或涉及数据合规的团队，用之前先把这三条问清楚。
问题 4：GitHub 真的 “不堪重负” 了吗，它自己做了什么？
回答 4： 压力是真的，但它没躺平。数据上，每月 push 从 6.9 亿涨到 33.5 亿，9 月提交 73.8 亿次，Actions 运行 32.6 亿次。应对上，GitHub 今年新增 400 万个 CPU 核心和 160PB 高速存储，继续迁往 Azure，把存储与计算解耦，允许不同分支的引用更新并行处理，还把读写资源拆开单独扩容，写入吞吐最高提升 35 倍。它比 Anthropic 难的地方在于：必须保住 Git 协议和十五年生态的兼容性，只能在飞行中换引擎。
问题 5：普通团队现在要不要跟着换代码托管？
回答 5： 不用换，但要做一次自测。先回答三个问题：合并队列能不能扛 100 路以上并发、每次写入触发多少次读取、仓库体积增长速度是不是在加快。大多数团队的压力其实来自 CI 全量克隆和单线程合并队列，而不是 Git 本身。先把浅克隆、稀疏检出、按需取目录、并行 ref 更新这几件事做掉，八成问题就解决了。真正到了 100GB 历史、每天上万次合并那个量级，再谈自建或迁移 —— 那时候你已经是全球极少数几家，该讨论的是架构而不是工具。
参考资料
[2026-11-08]（GitHub 不堪重负！OpenAI 收购替代品，A 社原地自研，马斯克也要搞）量子位
[2026-11-05]（收购 Pierre、挖角 Anthropic，OpenAI 切入微软编程腹地）第一财经
[2026-11-04]（OpenAI to acquire Pierre Computer Company, Inc.）OpenAI
[2026-11-04]（OpenAI Acquires Pierre Computer to Expand Codex, Challenge GitHub）DevOps.com
[2026-10-15]（Anthropic's Agents Broke Git at 30K Merges a Day）DEV Community
[2026-10-13]（Redesigning source control at Anthropic）Anthropic Engineering
[2026-08-22]（SpaceX Now Owns Cursor — And Origin, Its New Git Host, Has No Published Data Terms）sota.io
[2026-08-17]（Origin Code Hosting）Cursor Changelog
[2026-08-14]（Cursor is now a part of SpaceX）Cursor
免责声明
本文依据 OpenAI 官方公告、Anthropic 工程博客、Cursor 官方 changelog 与交割博客，以及多家媒体和第三方技术博客的公开报道整理。其中 Anthropic 披露的性能数据（资源占用缩小 200 倍、CI 检出提速两个数量级、CI 省出 25% CPU）均为其自述，未经独立第三方验证；Scion 不适用于一般团队的结论也来自 Anthropic 本人表述。GitHub 的流量与扩容数据来自其工程团队公开分享及媒体转述，“过去一年 257 次中断”“Git 基线合并吞吐每秒 2—3 次” 等数字为第三方汇总或测算，非官方口径。OpenAI 收购 Pierre 尚未完成交割，需通过监管审批，最终条款与产品形态可能变化；Origin 的数据条款与驻留情况为 2026 年 8 月发布时的状态，后续可能更新。本文不构成任何工具选型、迁移或采购建议，涉及代码托管与数据合规的决策请以厂商正式条款和自身合规要求为准。