GitHub大规模宕机7小时！马斯克旗下Cursor趁机“杀入”代码托管发布Origin，内部员工调侃：本想更早发布的

整理 | 屠敏

出品 | CSDN（ID：CSDNnews）

过去几小时里，科技圈都在盛传“Cursor 杀死了代码协作平台 GitHub”。

起因是，Cursor 刚官宣向付费用户推出其最新的代码托管平台 Origin。

极具戏剧性的是，消息传出没多久，全球开发者依赖的代码托管巨头 GitHub 就突然出现大面积服务异常。代码仓库、Pull Request、Actions、API、Webhooks，甚至 GitHub Copilot 都受到影响。

这场突发性的宕机也引来了不少行业大佬的公开调侃。其中，作为使用者的 Vercel CEO Guillermo Rauch 直接在 X 平台打趣：“现在你可以把代码仓库托管在 Cursor Origin 上，并通过 Origin 部署至 Vercel，而 Origin 本身就运行在 Vercel 平台之上。不像 GitHub，它现在还能正常运行 。”

当被网友问及为何调侃此事时，Guillermo Rauch 随即解释：“只是想缓和一下当下的局面，我们自己现在也因为 GitHub 宕机而被卡住了！”

除此之外，Cursor 员工 Matt Palmer 转发自家产品发布推文，写下当天流传甚广的一句调侃：“我们本打算更早发布这个产品，结果 GitHub 宕机了。”

换言之，GitHub 的故障，反倒耽误了这款 GitHub 竞品的上线节奏。

上线与宕机这两个时间点撞在一起，很快让 Origin 被推上了风口，众人猜测：Cursor 这是要直接挑战 GitHub 了？

Cursor 终于开始“自己存代码”了

长期以来，Cursor 都是开发者公认的顶级 AI 原生代码编辑器，核心能力聚焦代码生成、重构、纠错与优化。那么，它推出的 Origin 到底是什么？

简单来说，Origin 是 Cursor 新推出的代码托管和协作平台。以前，开发者使用 Cursor 写代码，代码通常还是托管在 GitHub 上，Cursor 更像是建立在 GitHub 之上的 AI 编程工具。

如今，Cursor 开始自己提供代码仓库，开发者可以直接在 Origin 创建 Repository，并将本地项目推送到 Origin。与此同时，它也提供 Pull Request、代码浏览、Diff、评论、Code Review 和 Merge 等功能，基本覆盖了一套完整的代码协作流程。

也就是说，Cursor 正在从过去单纯的“AI 编程工具”，开始向代码托管平台延伸。

具有 PR、集成等功能

不过，如果 Origin 只是做一个新的 GitHub，显然很难和已经拥有庞大开发者生态的 GitHub 正面竞争。Cursor 真正想做的，是把 AI Agent 直接放进代码托管和协作流程里。

在 Origin 中，代码、Pull Request 和 Cursor 的 Agent 被放到了同一个环境。

Cursor 的官方更新日志写道：“你的代码、拉取请求与 Agent，现在全部集中在一处。” 开发者可以针对屏幕上打开的文件向 AI 提问，也可以让 Agent 修改代码、创建或更新 PR、推送代码。

过去的开发流程往往是开发者自己写代码、提交 Commit、创建 PR，再由其他开发者进行 Review；而在 Cursor 的设想中，这些工作越来越多可以交给 Agent 完成，人类开发者则更多负责提出需求、检查结果和最终决策。

这也是 Origin 与传统代码托管平台最大的区别：它并不是单纯给代码找一个存放位置，而是试图把代码托管本身变成 AI Agent 工作的一部分。

Cursor 代码仓库的应用扩展

与此同时，Cursor 还在继续扩展 Origin 周边的开发流程，例如接入 Vercel、Buildkite、Depot 等服务，让代码从编写、提交、Review，一直到测试和部署，都能够逐渐被纳入同一个工作流。

支持 GitHub 同步

值得关注的是，Origin 此次推出的功能之一是 GitHub 同步，它允许你将 GitHub 存储库实时镜像到 Origin，同时保持 GitHub 作为现有项目的主要数据源。

仅是针对这一点，不少外媒评价称，这是 Origin 最巧妙的设计之一。它并不强制要求用户放弃 GitHub。你只需绑定 GitHub 组织账号，挑选对应仓库，这些仓库就会和 Origin 原生仓库并列展示。

据 Cursor 官方介绍，把 GitHub 连接到 Cursor 后，选择对应的组织，就能看到可以同步的代码仓库。选中需要的仓库，Cursor 就会把它拉取到 Origin 中。哪些内容需要同步可以自行决定，之后也可以随时断开连接。

只要在 GitHub 中拥有已同步仓库的读取或写入权限，就可以在 Cursor 里查看这个仓库。

同步之后，Origin 中的代码会保持实时更新。开发者可以直接在 Origin 里浏览、搜索代码，也可以从 Origin 中的副本拉取代码。不过，代码推送依然会回到 GitHub。

这意味着，只要涉及 GitHub 上的内容，GitHub 仍然是最终的权威来源。另外，每个代码仓库名称旁边都会有对应图标，用来区分哪些仓库由 Cursor 托管，哪些仍然来自 GitHub。

对此，外媒 Venturebeat 评价道：

这是一套经典的楔入式竞争策略，执行得相当巧妙。源代码控制系统的完整迁移，是工程组织风险最高的项目之一。它会牵涉持续集成、合规证据留存、审计记录、分支保护规则、工具链内全部第三方集成，还需要全体工程师改变固有的操作习惯。几乎没有 CTO 愿意为一款尚处于早期 Beta 测试的产品批准如此高风险的迁移项目。

而以只读镜像为主、保留 GitHub 权威地位的模式，企业很容易就可以放行。尝试该功能几乎没有成本，就算后续弃用也不会造成破坏，同时还在悄悄改变开发者日常工作的主要操作入口。倘若 Cursor 的评审体验确实更优秀 ——Cursor 也投入重金来保障这一点 —— 那么事实来源的地位，最终会跟随开发者注意力发生转移。

偏偏这个时候，GitHub 还宕机了

而就在 Origin 上线当天，不少开发者想要体验这两个平台的优劣，可好巧不巧的是 GitHub 便遭遇了一次相当严重的服务故障。

根据 GitHub 官方状态页面，这次事故从 8 月 17 日 13:40 UTC 开始。最初 GitHub 表示部分服务性能受到影响，随后 Pull Requests、Issues、Actions、API Requests、Webhooks、Pages、Git Operations 等服务陆续出现异常，Copilot 也受到影响。

故障最严重时，GitHub 官方表示 Web 端和 API 流量的错误率一度达到约 20%，代码归档下载和原始仓库内容下载的错误率甚至达到约 50%；SAML、OIDC、SCIM 和 Team Sync 等企业功能也受到影响。

直到当天 21:15 UTC，GitHub 才宣布这次事故已经解决，并表示之后会进一步公布详细的根因分析。

从时间线上看，Origin 的上线与 GitHub 的故障确实撞在了一起。

这也就不难理解，为什么社交媒体上很快出现了“Cursor 杀死 GitHub”这样的说法。

但如果把时间线和产品现状放在一起看，这更像是一次极其巧合、却又极具象征意义的撞车。

真正的威胁，不是一次宕机

Origin 的发布，会不会给 GitHub 带来威胁？

答案或许是肯定的，但真正值得关注的，并不是 Origin 能不能在短期内取代 GitHub，而是 Cursor 正在尝试把竞争带到一个 GitHub 过去并不完全属于自己的领域：AI Agent 时代的软件开发基础设施。

在 HN 上，有网友直接追问 Origin：“除了正常运行时间之外，Origin 与 GitHub 最大的区别是什么？我一直听到类似‘面向 Agent 的 GitHub’这样的说法，但如果能听到 Origin 开发团队亲自解释一下，这句话具体意味着哪些实实在在的功能和产品变化，就更好了。”

Origin 的开发者之一、同时也是 Graphite 创始人之一的 Tomas Reimers 随后现身评论区回应。

他坦言：“今天，功能还很少。我们有意将 Origin 作为 GitHub 的替代方案推出，在功能层面先与 GitHub 正面竞争。”

但他也透露，接下来几周，Origin 会重点加强几个方向，包括与 Agent 的集成、理解 Agent 编写的代码——不需要开发者把所有代码都通读一遍——以及自动帮助开发者将 PR 推进到可以合并的状态。

这其实已经透露出了 Origin 所说的“GitHub for Agents”究竟意味着什么。

一次宕机当然不可能让 GitHub 失去竞争力。GitHub 的体量、开发者生态以及企业客户规模，远不是刚刚进入 Beta 阶段的 Origin 能够撼动的。

但 Origin 的出现，确实把一个问题摆到了 GitHub 面前：当 AI Agent 正在改变软件开发方式，代码托管平台是不是也需要跟着改变？

事实上，GitHub 自己也已经在做这件事。

近年来，GitHub 正围绕 AI Agent 不断增加新的开发能力，例如推出 Stacked PRs 等功能，让多个相互依赖的 PR 能够以更适合复杂开发任务的方式进行管理。

所以，这并不是 Cursor 单方面向 GitHub 发起挑战。

真正有意思的是，过去几年 AI 编程工具的竞争，大多集中在“谁能写出更好的代码”上。如今，竞争正在向代码之外延伸：谁负责写代码？谁负责运行 Agent？谁负责审查代码？谁负责托管代码？谁最终掌握整个软件开发流程？

Cursor 已经从编辑器走到了 Agent，如今又进一步走向代码托管。

而一旦代码、Agent、PR、Review、CI/CD 逐渐集中到同一个平台，代码托管就不再只是“存 Git 仓库”这么简单。

它可能会变成 AI 编程时代，整个软件开发流程的基础设施。这或许才是 Origin 对 GitHub 真正值得关注的地方。

参考：

https://cursor.com/cn/changelog/origin-code-hosting

https://venturebeat.com/infrastructure/cursor-launches-origin-code-hosting-platform-as-github-outage-exposes-opening-in-ai-coding-race

https://x.com/cursor_ai/status/2089399059488350447

11.20-21 日，2026 奇点智能大会·北京站。

OpenAI 资深研究科学家 Łukasz Kaiser 确认进行主题分享。

他是 Transformer 八子中唯一还在科研前线的人，GPT-4/5、o1、o3、ChatGPT 的核心开发者。

2021 年，他在这个大会上分享了三个方向：多模态、更大更好的 Transformer、模型即服务。五年后，多模态爆发，ChatGPT 席卷全球，前沿观点全部成了现实。

去年，他讲的是推理模型的进化：从"记忆"到"策略"再到"研究器"——模型开始学会自己思考。

欢迎大家扫码领取 Łukasz Kaiser 历年在奇点智能大会上的分享 PPT 和视频

if like:

click("分享", "点赞", "在看")