美东时间8月17日上午9点40分，GitHub官方确认正在调查“影响部分服务的性能问题”。故障迅速扩散至API请求、Actions、Webhooks、Issues、Pull Requests等核心功能，身份认证系统和Copilot同样受到影响。据GitHub状态页披露，当天Web与API流量的错误率一度接近20％，归档和原始仓库下载的错误率逼近50％。整个故障持续约七小时，其中核心服务中断约三小时，全球开发者无法拉取代码、运行CI流水线，AI补全功能也无法使用。
几乎同一时间，Cursor正式宣布代码托管平台Origin向所有付费用户开放测试版。该平台支持创建仓库、执行标准git操作、发起PR、合并代码、管理权限，并支持将GitHub仓库整体镜像过来。其中最受关注的是一个“Detach from GitHub”按钮，点击后即可将Origin设为权威数据源。据多家媒体报道，Origin的发布属于既定计划，与GitHub故障在时间上的重合更可能是巧合。
GitHub此次故障的严重性在于其近乎“全链路”失守。开发者最常用的拉取代码、运行流水线、提交Issue、发起PR等路径全部中断，连登录都受到影响。一家掌握全球绝大多数团队权威代码源十余年的平台，暴露出代码世界中枢纽带存在单点风险。Cursor的定位显示，这是一套“专为Agent时代设计”的git托管平台，将GitHub的核心操作重新实现了一遍，涵盖建仓库、clone、push、pull、浏览代码、开PR、review、合并、管理权限等完整流程。
Origin与GitHub之间的关系设计更值得注意。同一份代码可以存在多个位置，但总得有一份具有权威性，出现分歧时以谁为准、CI从哪里拉取、上线部署认哪一份。过去十几年，这份“权威源”的资格都在GitHub手中，如今Origin提供了一个按钮，可以一键切换。两件事放在一起，GitHub的瘫痪只是一个导火索，Cursor真正要争夺的是“权威数据源”这个位置。
Origin的意图藏在几个面向Agent的设计中。堆叠式PR允许将一个大变更拆分为多个小PR，按依赖关系堆叠，用可视化依赖图展示，从结构上缓解人工审查负担过重的问题。合并队列支持自动排序和冲突检测，保证主干CI始终为绿，并在合并层内置AI引擎自动解决冲突。审查状态被设计为结构化API，Agent可以直接读写，无需解析人类评论文本。还有原生MCP支持，Agent可以像调用API一样驱动整个平台。这几项核心特性目前仍属于官方路线图中的“即将上线”功能，当天开放的测试版主要提供仓库、PR、代码浏览和GitHub双向同步等基础能力。
Cursor做Origin的根本理由在于GitHub已经跟不上Agent的速度。今年3月，Cursor联合创始人Michael Truell公开了一组数据，Cursor内部合并的PR中，35％由运行在云端虚拟机上的自主Agent完成。GitHub这套工作流设计于2008年，核心面向“人”，节奏以小时和天计算。Agent不遵循这个节奏，十几个Agent同时涌入一个仓库，时间尺度是秒。Origin在发布会上公布的性能数据显示，每小时29.6万次clone、8.1万次push，单个仓库每秒22.6次commit，全球同步延迟低于400毫秒，自动故障转移10毫秒。
Cursor已经不再是那个“AI版VS Code”。6月16日，SpaceX在纳斯达克IPO后行使收购选择权，以600亿美元全股票交易收购Cursor母公司Anysphere，交易于8月14日正式完成。与收购同期推进的还有一款1.5万亿参数的自研模型，该模型在Colossus超算上使用超过十万张GPU从零训练。同时拥有模型、算力和资本，才有条件重新构建代码基础设施。Cursor起步于编辑器，现在进一步向下延伸，自建代码托管和协作层，“编辑器—模型—托管—Agent”全线贯通的路径，与GitHub Copilot横向接入的模式截然不同。
Origin的方向很明确，把代码、PR和Agent放在同一个平台中，让机器不再迁就人类的工作节奏。GitHub的瓶颈从来不是容量不够，问题出在并发使用者从几十个人变成成百上千个随时开分支、随时合并的Agent时，原有架构难以承载。在为人类设计的系统中，合并冲突是偶发事件；Agent主导的场景下，合并冲突变成高频操作。代码托管市场的竞争格局，正因Agent的规模化应用而开始重塑。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
