SpaceX 60亿美元收购 Anysphere：Origin git平台才是真正的标的

2026年8月14日，SpaceX 向美国证券交易委员会提交了 8-K 表格，确认已完成对 Anysphere 的全股票收购。Anysphere 是 Cursor 代码编辑器的母公司，此次收购估值 600 亿美元。Anysphere 股东获得了约 3.89 亿股 SpaceX A 类股票。这是有史以来 AI 编程公司最大规模的收购，达成时间大约在交易首次宣布后的两个月。

自今年六月以来，大多数报道都聚焦在这个数字上。十九个月前估值 25 亿美元的公司如今价值 600 亿美元，这个轨迹确实疯狂，很容易让人只盯着这条曲线讲故事。但这次收购并不是真正的产品新闻。真正的产品新闻发生在宣布交易的同一天——2026年6月16日，Cursor 首届开发者大会 Compile 上——Anysphere 同时发布了三款产品：一款名为 Cursor Mobile 的公开 iOS 测试版、一款基于 SpaceX Colossus 超算训练的 1.5 万亿参数前沿模型，以及一个名为 Origin 的 git 托管平台，Anysphere 将其定位为 GitHub 的直接挑战者。

Origin 才是真正值得仔细审视的产品，因为它的架构赌注将超越 SpaceX 交易对 Anysphere 股权结构表产生的任何影响。Origin 目前还没有正式发布的产品——它采用候补名单模式，承诺 2026 年秋季全面开放。因此这必然是对一款已宣布产品的评测，而非经过实战检验的评测。但在候补名单开放、营销噪音变大之前，现在就值得理解这个赌注本身，以及现在为其提供资金支持的公司。

Origin 实际上是什么

Anysphere 将 Origin 描述为一个"为 AI 智能体时代构建"的 Git 兼容代码托管和协作平台——这意味着它假设推动提交、处理 Pull Request 和解决冲突的主要角色是 AI 智能体，而不是坐在键盘前的人类。这是一个真正的区别，而不仅仅是定位文案。GitHub、GitLab 和 Bitbucket 都是围绕人类工作流设计的：人类以burst形式写代码，每天提交几次，在功能完成时打开一个 PR。Origin 则围绕一种工作流构建：在这种工作流中，十几个 AI 智能体可能每分钟跨十几个分支推送数十个小提交，所有操作都针对同一个代码库，而且大多数冲突解决都不需要人类参与其中。

该产品建立在 Graphite 技术栈之上，Anysphere 于 2025 年 12 月收购了 Graphite。Graphite 是一款备受好评的独立风投支持的代码审查工具，基于堆叠式 Pull Request 构建——这种工作流将一个大改动分解为一个依赖链中的多个小 PR，按顺序审查和合并，而不是作为一个巨大的 diff 一次性处理。Graphite 多年来一直在构建专门处理大量并发、互相依赖分支的基础设施，事实证明，当你需要多个 AI 智能体并行修改代码库的重叠部分时，这恰恰是所需要的原语。Anysphere 并非从头开始构建 Origin 的核心 diff 和合并引擎，而是收购了一支已经为人类解决了这个问题某个版本的团队，并将其重新指向 AI 智能体。

根据 eesel AI 和 BigGo Finance 的报道，Origin 的后端是 Graphite 技术栈的深度重构版本，针对 AI 智能体而非人类产生的操作频率和模式进行了重新优化：clone、push 和 commit 调用的频率更高，diff 更小更频繁，重叠编辑需要自动对账的预期比例也更高。存储层被描述为 NVMe 和 S3 的混合——快速本地存储用于活跃 AI 智能体会话的热路径，S3 作为后盾用于持久化，并值得注意的是，用于支持"无限代码库副本"这一声明。在此基础上，Origin 将 Graphite 的堆叠式 PR 模型作为一等公民的原语保留，添加了 AI 驱动的自动合并冲突解决作为内置功能而非插件，并通过传统 API 和模型上下文协议（Model Context Protocol，MCP）对外暴露整个系统——这样 AI 智能体（而不仅仅是使用 CLI 或 Web UI 的人类）就可以编程方式驱动代码库操作。

Git 兼容性声明比初看起来更重要。这意味着 Origin 被定位为可无缝切换的主机，而非 Git 对象模型本身的替代品。现有工具、CI 运行器、本地 git 客户端——原则上都不需要改变。这与至少另一家竞品正在采取的策略有显著不同，我会在下文详述。

对于没有使用过堆叠式 diff 工作流的读者：它不是在一个单一的长期分支上构建一个大功能，然后在最后打开一个大 Pull Request，而是将功能分解为一系列小的、互相依赖的分支——每个都建立在前一个之上，每个都有自己的小 PR，每个都可以在就绪时独立审查和合并。链会随着栈中更早的 PR 落地而自动更新，所以你不需要手动 rebase 一个巨大的分支。Graphite 整个产品都是围绕让这条链对人类工程师可控而构建的——他们发现 rebase 互相依赖的分支非常痛苦，以至于大多数团队在没有工具辅助的情况下永远不会采用这种工作流。Origin 的赌注是，相同的底层原语——大量小的、互相依赖的、可独立合并的改动——几乎完美地描述了一群编程 AI 智能体自然产生工作的方式，无论是否有人故意这样设计。Graphite 需要说服人类以这种形式写代码，而 Origin 只需要接受 AI 智能体已经倾向于这样做这一事实。

公告的背景

值得精确描述 2026 年 6 月 16 日发生的事，因为 Compile 上的三个公告并非偶然在同一天发布的独立新闻——它们被呈现为一个连贯的方案。Anysphere 利用其首届开发者大会发布了 Origin、一款名为 Cursor Mobile 的公开 iOS 测试版（用于从手机监控和操控 AI 智能体），以及一款基于 SpaceX Colossus 超算集群从头训练的 1.5 万亿参数专有模型——这是 SpaceX 和 xAI 用于大规模训练运行的相同基础设施。SpaceX 收购在同一天得到确认。MLQ News 的报道将这三者描述为同一战略举措的组成部分：Anysphere 利用新母公司提供的计算和资本获取，在同一天下午资助了一个垂直整合的技术栈——自己的模型、自己的编辑器、以及现在的自己的托管层——而不是将它们作为独立里程碑在不同的季度发布。两个月后，8 月 14 日的 8-K 文件使所有权那半的方案正式生效。

这一切背后的估值轨迹值得单独思考。Anysphere 在 2025 年 1 月估值 25 亿美元，到当年 5 月达到 90 亿美元，2025 年 11 月在 Accel 和 Coatue 领投的 23 亿美元 D 轮融资后达到 293 亿美元，据报道在 2026 年 4 月之前还在讨论 500 亿美元的投前估值——然后被 SpaceX 600 亿美元的全股票报价取代。这在十九个月内增长了约 24 倍，而据其他报道，该公司年度经常性收入已接近 10 亿美元。无论你对 Origin 作为工程项目有何看法，开发它的团队获得的资本、算力，以及现在这个国防和航空航天规模的资产负债表，变化速度之快超过了几乎任何开发者工具公司。这样的速度是 Origin 能够可信地为一款还没有付费客户的产品承诺 NVMe 级性能和"无限"副本的部分原因——也是为什么值得对其治理和定价提出比对待一个自力更生的竞品更尖锐的问题。

为什么现在是这个时机：GitHub 确实在不堪重负

对"我们重建 X 因为现在是 AI 智能体时代"这类宣传持怀疑态度是一种健康的本能——2026 年有大量的 SaaS 营销在不需要它的功能上强行加上"AI 智能体"这个词。但在这种情况下，有独立报道支持这个前提。《The New Stack》报道称，Cursor、GitLab 和 Zed 在 2026 年中期独立得出了相同的诊断：最流行的 git 托管服务正在因与人类开发者增长无关的负载而崩溃。不是更多的工程师在 clone 和分支——而是数十或数百个 AI 智能体同时访问同一个代码库，每个智能体想要 clone、分支、push 和查询的频率都远高于人类，而且经常想要查询代码库的完整历史和结构，却不需要完整的本地 checkout 来做到这一点。

三种不同的赌注：GitHub 之后的方案

这是一个真实的、承重的架构问题，而且有实际用处的是：三个独立的、资金充足的团队独立地得出了"当前 git 托管模式在智能体规模的流量下无法支撑"的相同结论。更值得关注的是，他们并没有得出相同的修复方案。

三种押注 GitHub 后继者的不同方案

Cursor 的 Origin 保留了 Git 对象模型和 pull request 的心智模型，但在底层重建了托管层，以适应智能体频率的操作，并将堆叠式 diff 和自动冲突解决作为原生功能而非后期附加。

据报道，GitLab 的"Project Switch"正处于"下一代源代码管理"（Next Generation Source Code Management）的私人测试阶段，采取了更保守的方案：它保持 Git 协议本身完整，但重构了架构，使智能体可以查询和审视仓库内容，而无需先拉取完整的本地副本。据同一篇 New Stack 报道，GitLab 公开宣称这能将每个智能体任务的执行速度提升 50 倍。

Zed 的 DeltaDB 是激进方案。它彻底抛弃了 commit 作为历史原子单位的地位，用连续的细粒度 delta 流取代，每个 delta 都直接链接到产生它的智能体对话。这是对源代码控制四十年来表示变更方式的真正突破，意味着任何采用它的人都要付出真实的迁移成本。

将三者并排比较，这是一场正在公开上演的正当架构辩论，而非营销层面的交锋。Origin 是中间路线：比 GitLab 的方案对底层存储和合并模型的颠覆性更大，但比 Zed 的方案对你的现有心智模型和工具链的颠覆性小得多。这一中间立场可能是 Origin 最强的单一卖点——你可以在不需要你的 CI 流水线、你的 git blame 习惯、或你的现有 GitHub Actions 工作流去理解一个全新历史单元的情况下，获得智能体级的性能。

开发者为什么应该真正关注

成本。 Anysphere 尚未公布 Origin 的定价，鉴于该公司今年在定价沟通方面的过往记录——下文会详细说明——这种缺失值得指出而非一笔带过。目前公开的所有内容都是架构和定位，而非价格表。

延迟和规模声明。 NVMe 加 S3 混合存储以及"无限副本"的表述是针对一个特定瓶颈的真实工程选择：智能体工作负载产生的读/写操作数量，比传统开发每单位人工编写的代码要多得多。如果你今天在大型 monorepo 上只运行几个编码智能体，你可能已经感受到 GitHub 或 GitLab 在自动化活动爆发期间限制你的速率或变慢。Origin 明确地设计成不会那样做。GitLab 公布 Project Switch 的 50 倍数据，即便你将其作为供应商基准数据打折，也告诉你整个行业现在认为这是一个解决得很糟糕的、值得用大数字来标榜的问题。

开发者体验。 原生堆叠式 diff 加上自动冲突解决，对于智能体编程最常产生的失败模式是一对真正有用的组合：五个智能体各自触及相邻文件，产生一堆小的、重叠的、单独看来都合理的 diff，然后由人工来理清。Graphite 团队专门花了数年构建"许多小的依赖变更"的工具，而将自动解决集成到其中而非留给人工审核，是一个合理的使用场景。

锁定效应。 这是公告一笔带过、你最应该重视的部分。如果你采用 Origin，你就将你的源代码、AI 编码模型、编辑器，以及越来越多的计算资源都放在了同一屋檐下——而这屋檐，在 2026 年 8 月 14 日，属于 SpaceX。Git 兼容性意味着理论上你可以迁移仓库历史到其他地方而无需重写，这是一个真实的缓解措施。但是，堆叠式 diff 工作流、你的智能体所接入的 MCP 集成，以及你针对 Origin API 构建的任何 CI，并非以同样的方式可移植。你采用 Cursor 技术栈的部分越多——编辑器、模型、现在是托管服务——离开其中任何一部分的代价就越高。

安全性和可维护性。 现在一家供应商同时控制着编写代码的编辑器、建议代码的模型，以及（很快）存储代码的托管服务。这在操作上很方便，同时也是真正的风险集中故事：一次宕机、一次策略变更，或一次与收购相关的重组，会同时影响你的整个工具链，而非其中某一个环节。同样值得深思的是，这家供应商现在是一家主营业务为航空航天和国防相关基础设施的公司的子公司——这与微软旗下的 GitHub 或独立的 GitLab 有着截然不同的监管和声誉形象。涉及的所有各方尚未就所有权结构对美国以外的团队、或对源代码存放资产负债表有任何敏感性要求的公司意味着什么发表任何公开言论。这不是说存在问题——而是说这个问题还没有得到解答，在你将生产仓库加入等待名单之前提出这个问题是合理的。

Origin 的宣传对于已经在并行运行多个编码智能体处理同一代码库的团队来说是最有说服力的——AI 原生初创公司、进行大量 Cursor 开发的代理服务商，或者已经因自动化活动达到 GitHub 速率限制的任何团队。在实践中这会呈现为以下几种具体形态：

多智能体功能小队。 一个团队同时针对同一仓库运行多个智能体——一个重构模块，一个为其编写测试，一个更新文档——需要 resulting diffs 能够作为一个可审查的、按依赖排序的堆栈落地，而非三个针对同一文件的碰撞 PR。

夜间批量智能体运行。 将数十个独立的智能体任务（依赖更新、lint 修复、迁移脚手架）排入队列过夜执行的团队，需要一个能吸收数百次小推送而不产生速率限制或将其排在人工流量之后的托管服务。

智能体驱动的 CI 反馈循环。 在智能体需要读取 CI 结果、修补失败的测试、并重新推送的高频循环中——每个任务数十次——API/MCP 表面比 Web UI 更重要。这是一个为人与托管服务对话而优化的的工作流，而非为人点击操作而优化的。

如果你的当前工作流是一两个开发者偶尔使用 GitHub Copilot 或 Cursor 的自动补全，Origin 的架构没有在解决你面临的问题。该产品明确瞄准的是"我们有十几个智能体整天提交，而我们的 git 托管服务跟不上"的细分市场，这在 2026 年中期是一个真实且不断增长的细分市场，但仍然是一个特定的细分市场——大多数个人开发者和小型团队远未达到 Origin 所构建的流量模式。

营销中遗漏的内容

有几件事值得直接点名：

尚未发布。 以上所有内容都是 Anysphere自己对架构的描述，加上对该描述的报道。没有在真实智能体负载下对 Origin 的独立基准测试，没有 GA 定价，只有等待名单而非产品。秋季 2026 是公布的目标，而截至本文撰写时，还有几周时间——但"几周时间"在这个行业里以前也拖延过。

堆叠式 diff 有真实的采用成本。 Graphite 多年来作为独立产品，试图让团队采用堆叠式 PR，而这是一种对习惯于单一统一 pull request 的工程师来说有真实学习曲线的工作流。将其作为 Origin 的默认原语并不会消除那个学习曲线——它只是意味着你从注册的那一刻起就继承了它，无论你的团队之前是否使用过 Graphite。

Anysphere 的定价沟通记录并不好看。与 Origin 无关的是，Cursor 在 2025 年和 2026 年的大部分时间里都在处理用户对其混乱的、基于积分的定价变更的强烈不满——包括 Anysphere 自己在 Reddit 上发布的一篇帖子，承认"我们对个人计划定价的近期变更沟通不够清晰"，此前用户反映账单不可预期地暴涨。Anysphere 早在 2026 年 6 月就再次调整了 Teams 定价结构，将使用量拆分为独立的第一方和第三方模型池，并新增每月 120 美元的 Premium 档位，明确就是为了解决可预测性的投诉。这些问题单独看都不构成否决理由，但它们是相关背景信息，影响你对该产品"定价稍后公布"的承诺应给予多少信任——毕竟这个产品将要托管你的源代码。

纵向整合叙事与"开放、git 兼容"的表述形成了矛盾。Anysphere 一方面对开发者说"你的代码保持可移植，因为我们保留了 Git 兼容性"，另一方面却在打造一个编辑器、一个拥有 1.5 万亿参数的专有模型，以及现在一个主机——这三者在一起工作时效果最佳，且都为同一公司所有。这两种说法并不完全矛盾，但它们之间存在张力。值得关注的是，随着 Origin 真正推出定价和默认设置，哪一种说法最终会胜出。

与 GitHub 相比，Origin 的优势在于对 GitHub 并非为这种工作负载设计的架构聚焦，以及背后有一支备受好评的被收购团队。GitHub 的优势则是 Origin 尚未拥有的一切：一款成熟的产品、成熟的安全与合规追踪记录，以及历经 18 年建立的网络效应——这些都是候补名单产品在第一天无法企及的。

与 GitLab 的 Project Switch 相比，Origin 正在为更大的声称收益进行更大的架构变更（新的存储和合并模型），而 GitLab 正在进行更小的、保留协议的变更，现有 GitLab 客户更容易逐步采用。GitLab 的方案对不想重新学习 git 托管方式的团队来说是更安全的赌注；Origin 的方案对已在 Cursor 生态系统中游刃有余的团队来说是天花板更高的赌注。

与 Zed 的 DeltaDB 相比，Origin 显得保守。DeltaDB 是这三者中唯一真正提议用新东西取代 commit 作为历史单元的——这要么是正确的长期答案，要么是一个要求比大多数团队所能承受的更大的迁移痛苦的赌注。Origin 的 Git 兼容性是对这种风险的对冲，而 DeltaDB 明确拒绝采用这种策略。

抛开 SpaceX 的标题新闻，Origin 是对一个真实基础设施问题的合理、资源充足的答案：git 托管确实不是为智能体规模流量而构建的，收购 Graphite 团队来解决这个问题是一个合理的技术策略。但不那么合理的是将其简单地视为"面向智能体的 GitHub"。它是正在组装中的纵向整合栈的第三条腿——编辑器、模型、主机——由一家在不到二十个月内将估值从 25 亿美元提升到 600 亿美元全股票收购的公司打造，而同一时期它还花了大量时间因定价沟通不清晰向用户道歉。技术是可信的。但将它作为你整个源代码控制层受托人、在没有公开价格和没有人完全理解的股权结构的情况下交给它的信任，是另一个独立的问题，而公告没有回答这个问题。

谁应该尝试、等待或忽略

如果你已深度融入 Cursor 生态系统、在共享仓库上运行多个智能体、且已经感受到 GitHub 或 GitLab 在自动化负载下出现卡顿——那就尝试候补名单。你获益最多，额外需要消化的锁定也最少，因为你已经 commitment 在 Cursor 的模型和编辑器上了。

如果你是一个小团队或独立开发者，你的 git 使用仍然是人类节奏的——等待。Origin 的架构并不能解决你当前面临的问题，等待不会让你损失任何东西，同时定价、GA 稳定性和 SpaceX 所有权问题会由候补名单上走在前面的人来回答。

如果代码托管、数据主权或供应商集中度是你所在组织必须面对的问题——受监管行业、政府相关工作，或任何已有全工具链单供应商锁定策略的团队——请忽略。Git 兼容性给了你一个技术层面的出口匝道；但它没有给你一个答案来回答在此期间持有你密钥的公司究竟属于谁。

如果你想关注这个领域而不做任何承诺，Origin、GitLab 的 Project Switch 和 Zed 的 DeltaDB 之间的三方架构之争值得关注——这是多年来"git 主机实际上应该如何工作"第一次成为一个真正开放的、 активно 争议的问题，而不是每个人仅为 GitHub 使用的已解决答案。

讨论：如果你今天在共享仓库上运行多个编程智能体，首先真正出问题的是什么——git 主机速率限制、合并冲突量、CI 队列时间，还是完全不同的其他东西？像 Origin 这样兼容 Git 的重建能解决这个问题吗，还是解决方案必须更像 Zed 的与 commit 的干净决裂？