GitHub 宕机 7 小时同日，Cursor 上线 Agent 版代码托管平台 Origin

8 月 17 日，GitHub 遭遇了一场持续约 7 个半小时的大规模故障；几乎同一时段，AI 编程工具 Cursor 正式上线了自家代码托管平台 Origin 的早期测试版。两大事件叠加，让「代码基础设施是否会被 AI Coding 玩家重塑」再次成为业界讨论焦点。

GitHub 大规模宕机 7 小时

美东时间 8 月 17 日上午 9 点 40 分左右，GitHub API Requests 率先报警；不到 20 分钟内，Actions、Webhooks、Issues、Pull Requests 接连出现异常，Copilot、Pages 等服务也陆续受影响。开发者反馈代码无法拉取、PR 无法打开、CI/CD 流水线停滞，部分页面直接显示「No servers available」。

下午 14:04，GitHub 官方披露 Web 与 API 请求错误率一度达到约 20%，archive 与 raw repository content 下载错误率更升至约 50%。故障后半段还持续出现零星身份认证失败，官方随后对身份认证令牌重试机制进行了调整。截至目前，GitHub 仅定位到一个「problematic component」，完整根因分析尚未发布。

Cursor 推出代码托管平台 Origin

就在 GitHub 忙于救火的同一时间，Cursor 在官网更新日志中上线了 Origin 的早期测试版，面向付费用户逐步开放。Origin 并非简单的云端代码备份，而是一套深度嵌入 Cursor 体系的代码托管平台，其核心设计围绕 AI Agent 工作流展开。

Origin 的基础能力包括：

完整 Git 工作流：开发者可直接在 Cursor 内创建仓库，通过 clone、push、pull 等标准命令管理代码。
原生 PR 与代码审查：支持完整 Pull Request 流程，包括 commits 查看、状态检查、diff 比对、Review、评论与 Merge。
网页端代码浏览：可在浏览器内直接浏览和全文搜索代码库。
与 GitHub 双向同步：现有 GitHub 仓库可同步至 Origin，GitHub 仍是权威数据源；在 Cursor 内留下的 Review 评论会毫秒级同步到 GitHub，反之亦然。

面向 Agent 的差异化设计

与传统托管平台不同，Origin 明确将 Agent 视为一等公民。其差异化功能集中在四个方向：

堆叠式 PR（Stacked PRs）：支持将大型重构拆分为多个有依赖关系的小 PR，并通过可视化图谱呈现，降低人类 Reviewer 认知负担。
智能合并队列（Merge Queue）：当多个 Agent 同时提交 PR 时，系统自动排序并在后台隔离预处理冲突，确保主干 CI 持续可用。
AI 自动解决冲突：跨文件复杂冲突由内置 AI 引擎自动理解业务逻辑并裁决。
机器可读的审查状态：将审查状态结构化为 API，便于 Agent 直接读取并自动执行闭环修改。

首批接入的周边生态包括 Vercel（预览部署）、Depot 与 Buildkite（CI/CD），并兼容现有 GitHub Actions 工作流。官方披露的性能指标为：每小时 29.6 万次 clone、每秒 22.6 次 commit、全球同步延迟低于 400 毫秒。

行业背景：从「谁写代码」到「谁管代码」

Origin 上线前不久，SpaceX 完成了对 Cursor 母公司 Anysphere 600 亿美元的收购交割，Cursor 成为 SpaceX 全资子公司。同一天，GitHub 母公司微软股价下跌超 3%，市值单日蒸发超过千亿美元。

Cursor 在今年以来持续弱化「带 AI 的编辑器」定位，转而强调 Agent 如何自主完成软件工程任务。当单个用户开始同时调度 5 个、10 个甚至更多 Agent 并行工作时，传统代码托管平台在并发 PR、合并冲突处理、CI 重算等方面的短板被显著放大。GitHub 近期将 Stacked Pull Requests 推向公众视野，也被业内视为对 AI 时代 PR 与 Review 瓶颈的回应。

Origin 当前仍处于 Early Beta 阶段，Cursor 的策略是优先兼容而非强迫迁移。开发者可随时通过仓库设置中的「Detach from GitHub」解除绑定，让 Origin 成为独立的主代码仓库。但从功能设计可以看出，AI Coding 的竞争正在从「谁写代码」向「谁管代码」延伸，代码托管这一传统上属于 GitHub、GitLab 的领域，正在迎来新的玩家。