全球程序员依赖的“水电煤”，在一天之内断了一次电，又被另一个人重新接上了。
美东时间8月17日上午9点40分，GitHub官方确认正在调查“影响部分服务的性能问题”。故障迅速扩散，API请求、Actions、Webhooks、Issues、Pull Requests接连报错，负责登录的SAML、OIDC、SCIM身份认证和Team Sync也受到波及，Copilot同样未能幸免。
据GitHub状态页披露，当天Web与API流量的错误率一度接近20%，归档和原始仓库下载的错误率逼近50%。整个故障持续约七小时，其中核心服务中断约三小时，全球开发者无法拉取代码、运行CI流水线，AI补全功能也无法使用。
几乎同一时间，Cursor正式宣布代码托管平台Origin向所有付费用户开放测试版。
这个被Cursor定位为“为Agent时代设计”的代码托管平台，支持创建仓库、执行标准git操作、发起PR、合并代码、管理权限，还支持将GitHub仓库整体镜像过来。其中最受关注的是一个“Detach from GitHub”按钮，点击后即可将Origin设为权威数据源，完成主客易位。
当天股价收跌3.04%，市值蒸发约1120亿美元。不过，此次下跌发生在美股科技板块整体回调的背景下，Meta同期跌幅也超过3%，微软的下跌并非单一事件驱动。
GitHub出了故障，Origin恰好同一天开放测试。据多家媒体报道，Origin的发布属于既定计划，与GitHub故障在时间上的重合更可能是巧合。
各自的细节
GitHub这次故障的严重性，在于它近乎“全链路”失守。开发者最常用的几条路径（拉取代码、运行流水线、提交Issue、发起PR）全部中断，连登录都受到影响。一家掌握“全球绝大多数团队权威代码源”十余年的平台，暴露出代码世界中枢纽带存在单点风险。
Origin方面，Cursor的定位显示，这是一套“专为Agent时代设计”的git托管平台，不是编辑器套了层云壳。它把GitHub的核心操作重新实现了一遍，涵盖建仓库、clone、push、pull、浏览代码、开PR、review、合并、管理权限，一整套都在。
它和GitHub之间的关系设计更值得注意，同一份代码可以存在多个位置，但总得有一份具有权威性，出现分歧时以谁为准、CI从哪里拉取、上线部署认哪一份。过去十几年，这份“权威源”的资格都在GitHub手中，如今Origin提供了一个按钮，可以一键切换。
两件事放在一起，GitHub的瘫痪只是一个导火索，Cursor真正要争夺的是“权威数据源”这个位置。这个位置之所以现在能被挑战，是因为底座的使用者群体正在发生变化。
理解Origin，得先放下“这是Cursor版GitHub”这个印象。它的意图藏在几个面向Agent的设计中，虽然目前测试版只放出了第一批基础功能。
堆叠式PR。Agent倾向于大批量修改代码，一次动数十个文件并不罕见，全部塞进一个PR，人工reviewer难以处理。Origin允许将一个大变更拆分为多个小PR，按依赖关系堆叠，用可视化依赖图展示，从结构上缓解“人工审查负担过重”的问题。
合并队列。一个仓库中十个Agent各自修改一批代码、各自提交PR，CI全部通过。先合并哪个？合并一个之后，其余九个的测试结果是否仍然有效？传统GitHub处理这种场景相当吃力，合并冲突、CI重跑、反复rebase。Origin的合并队列支持自动排序和冲突检测，保证主干CI始终为绿，并在合并层内置AI引擎自动解决冲突，减少人工介入。
机器可读的审查状态。GitHub的审查状态本质上面向人类，表现为一个绿色勾选和一段评论文本。Agent要判断一个PR是否可以合并，需要解析评论内容，存在不确定性。Origin将审查状态设计为结构化API，Agent可以直接读写，无需推断。
还有原生MCP支持，Agent可以像调用API一样驱动整个平台，不局限于IDE内部。这几项核心特性目前仍属于官方路线图中的“即将上线”功能，当天开放的测试版主要提供仓库、PR、代码浏览和GitHub双向同步等基础能力，Agent原生特性将稍后推出。Origin的方向很清楚，把代码、PR和Agent放在同一个平台中，让机器不再迁就人类的工作节奏。
GitHub追不上Agent的速度
Cursor做Origin的根本理由，一句话概括，GitHub已经跟不上Agent的速度。今年3月，Cursor联合创始人Michael Truell公开了一组数据，Cursor内部合并的PR中，35%由运行在云端虚拟机上的自主Agent完成。Agent自己开分支、自己提交、自己发起PR。
GitHub这套工作流设计于2008年，核心面向“人”。一个人写完代码，找一两个人审查，排队等待合并，节奏以小时和天计算。Agent不遵循这个节奏，十几个Agent同时涌入一个仓库，时间尺度是秒。Origin在发布会上公布的性能数据指向的就是这个场景，每小时29.6万次clone、8.1万次push，单个仓库每秒22.6次commit，全球同步延迟低于400毫秒，自动故障转移10毫秒。每秒22次commit听起来偏高，但对成规模的Agent集群而言，这恰好是其工作模式所需要的吞吐能力。
GitHub的瓶颈从来不是容量不够，问题出在并发使用者从几十个人变成成百上千个随时开分支、随时合并的Agent时，原有架构难以承载。在为人类设计的系统中，合并冲突是偶发事件；Agent主导的场景下，合并冲突变成高频操作。Origin就是针对这个现实构建的。
如果只是Cursor一家做代码托管，市场只会把它当作又一个GitLab或Bitbucket。但2026年的Cursor已经不再是那个“AI版VS Code”，它手里握着几样其他竞争者难以复制的资源。
资金和算力。6月16日，SpaceX在纳斯达克IPO后行使收购选择权，以600亿美元全股票交易收购Cursor母公司Anysphere，这是风投支持的创业公司有史以来最大规模的收购案。交易于8月14日正式完成，Cursor成为SpaceX全资子公司，并入SpaceXAI部门，与Grok团队同属一个体系。与收购同期推进的，还有一款1.5万亿参数的自研模型，该模型在Colossus超算上使用超过十万张GPU从零训练，此前已在Cursor Compile大会上发布。同时拥有模型、算力和资本，才有条件重新构建代码基础设施。
垂直整合。Cursor起步于编辑器，成长为一个独立的AI IDE，现在进一步向下延伸，自建代码托管和协作层。“编辑器—模型—托管—Agent”全线贯通的路径，与GitHub Copilot横向接入的模式截然不同。横向整合求广度，垂直整合求控制和优化深度，Origin可以为Agent吞吐量把每一层都做针对性优化。
团队。2025年12月，Cursor收购了代码审查初创公司Graphite，Origin正是由Graphite团队主导开发。堆叠式PR、合并队列这些概念，Graphite已经实践了数年，在“下一代代码协作”领域有深厚积累。如今他们依托SpaceXAI的资金和算力，将此前的理念重新实现。
护城河真的那么深吗
GitHub最大的护城河，说到底是沉淀了十几年的生态，几乎每一个开源项目、每一套CI配置、每一个开发者的使用习惯，都扎根在GitHub上。托管功能本身反倒在其次。短期内，没有哪个团队会将核心项目从GitHub整体迁移。Origin自身也清楚这一点，因此设计了“镜像+双向同步+一键Detach”的方案，将迁移成本降至极低，让用户先试用、后迁移。
Origin的进攻策略可以概括为“寄生”，先以GitHub为权威源镜像仓库，让用户在Cursor中自然使用起来，等用户习惯了、Agent也开始在上面运行之后，再提供“Detach from GitHub”的选项，完成权威源的切换。渐进式策略比正面硬刚要有效得多。
但Origin远非无懈可击。目前开放的仍是测试版，堆叠式PR、合并队列等核心差异化功能尚未正式上线。生态方面，Vercel、Depot、Buildkite只是第一批接入方，与GitHub庞大的Actions市场相比差距明显。微软也不是旁观者，它手里有Azure、有Copilot、有全球最大的开发者关系网络，一旦感受到实质性威胁，反应速度和资源体量都不容低估。
底座之争，才刚刚开始。
代码世界的“权威数据源”，第一次有了一个具备实质竞争力的挑战者。GitHub的瘫痪暴露了它的单点脆弱性，Origin的开放证明这个位置可以被重新争夺。过去十几年，开发者默认代码存放在GitHub，这件事不需要思考。现在，它开始需要思考了。
对开发者来说，眼下合理的做法是去试用Origin，尤其是已经在使用Cursor云端Agent运行后台任务的团队。迁移成本几乎为零，试一下“为Agent设计的底座”和“为人类设计的底座”之间到底差在哪，没有什么风险。
对微软和GitHub来说，真正的警报在于竞争对手开始从编辑器层向下渗透，直接触及GitHub赖以存在的地基。对手同时握着模型、算力、资本和顶尖的代码协作团队。护城河再深，也架不住持续抽水。
下一次GitHub再出故障，开发者可能已经不需要等它恢复了。（本文首发钛媒体APP，作者 | AGI-Signal，编辑 |秦聪慧 ）
和兴网提示：文章来自网络，不代表本站观点。
