美东时间 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，编辑 | 秦聪慧 ）
