AI 编程工具 Cursor 发布了自家的代码托管服务 Origin。从仓库存放到拉取请求的评审、合并，再到 CI（持续集成）的对接，全部在编辑器内部完成，目前以早期测试版向付费方案用户逐步开放。发布当天恰逢 GitHub 出现大规模故障，也因此格外受关注。
仓库和拉取请求都搬进编辑器
Origin 通过 Cursor 桌面端新增的标签页打开。官方还准备了专用的命令行工具，新建仓库、复制仓库等操作也可以在终端里完成。
其底层是 Linux 之父 Linus Torvalds 开发的版本控制系统 Git。开发者各自持有仓库副本、分头修改后再合并的分支机制，正是 Git 被广泛采用的原因之一。由于 GitHub 同样建立在这套基础之上，现有的工作流可以直接沿用。
放在 Origin 上的仓库支持完整的拉取请求流程，包括查看差异、留言讨论和合并。代码、评审和 AI 智能体处在同一个界面里，开发者可以针对正在浏览的仓库直接提问，随后让 Cursor 修改代码，或者新建分支并推送，整个过程不会被打断。读代码的地方、写代码的地方和提问的地方不再分开，这是它与现有托管服务最直观的区别。
从 GitHub 迁入只需几次点击，同步是双向的
对于已经在 GitHub 上运行的项目，官方提供了专门的集成功能。几次点击即可复制到 Origin，原有 GitHub 仓库更新后也会同步到 Origin。反方向的同步同样有效，因此团队可以在完全迁移之前先并行使用一段时间。
在 CI 方面，发布时就提供了对接 Vercel、Depot 和 Buildkite 的连接器。搭配 Vercel 可以快速搭建测试环境，用来确认应用更新后的运行情况。用 GitHub Actions 编写的既有工作流也能继续运行，因此为迁移而重写构建配置的工作量被压到最低。
目标是承载智能体的数量，而非人数
Cursor 反复强调的说法是，这是面向智能体规模打造的代码托管。也就是说，它并非再造一个 GitHub，而是按照大量 AI 智能体同时运行的前提来设计的。
Cursor 的智能体分为两类：一类运行在用户本机，另一类运行在云端沙箱（隔离的执行环境）中。差别在长时间任务上体现得最明显，云端智能体在工作站关机之后仍能继续处理。考虑到智能体每次运行都要拉取仓库，把代码的存放位置掌握在自己手里，意义并不小。
该公司表示今后会继续增加集成对象，并推出以智能体为前提的新功能。具体内容尚未公开，目前能确定的只有方向。
发布当天 GitHub 出现大规模故障
Origin 亮相的 8 月 17 日，正好是 GitHub 发生大规模故障的日子，拉取请求、Issues、Webhooks 和 Actions 均受到影响。归档和原始文件下载的错误率一度达到 50%，据报道受影响用户达到数百万人规模。
替代服务恰好在这一天出现，网上不少人调侃时机太巧。不过这类产品发布通常要提前数周准备，从博客素材到分阶段的测试版投放都需要时间，因此很难认为是看到故障之后临时行动。与其说是刻意挑选时机，不如说是巧合叠加。
背后是 SpaceX 的收购
Origin 是 Cursor 运营方 Anysphere 并入 SpaceX 之后的首个重要产品更新。这笔收购于 2026 年 6 月 16 日宣布，为全股票交易，总额 600 亿美元（约 9.5 万亿日元），并于 8 月 14 日完成。Anysphere 被编入新设立的 SpaceXAI 部门。
据称 Cursor 在不到 4 年的时间里实现了年化 40 亿美元（约 6,400 亿日元）规模的营收，其中约 26 亿美元（约 4,100 亿日元）来自企业客户。把代码存放也纳入自家体系，可以看作是将开发流程从入口到出口都收进一家公司这一趋势的延续。
※1 美元 = 159 日元换算（截至 2026 年 8 月 18 日）
总结
Cursor 发布的 Origin，是把仓库存放、拉取请求和 CI 对接整合进编辑器内部的代码托管服务。它提供与 GitHub 的双向同步以及 Vercel 等集成，并从付费方案用户开始以早期测试版开放。与 GitHub 大规模故障同日登场提升了关注度，但其本质在于按照 AI 智能体大规模运行的前提，重新构建开发基础设施。
