神级反转，GitHub 昨夜大规模宕机7小时，Cursor 火速上线Agent版代码托管平台

8月17日，对 GitHub 来说，无疑是噩梦般的存在。

美东时间上午 9 点 40 分左右（北京时间晚上 9 点 40 分），GitHub 开始出现大面积故障。API Requests 最先报警，随后不到 20 分钟，Actions、Webhooks、Issues、Pull Requests 接连出现异常，Copilot、Pages 等服务也被陆续拖下水。

开发者很快发现，代码拉不下来、PR 打不开、CI/CD 跑不动，部分页面甚至直接显示“No servers available”。

14:04（北京时间 22:04）开始，GitHub 官方披露，Web 和 API 请求错误率一度达到约 20%，archive 和 raw repository content 下载错误率更升至约 50%。这已经不是普通意义上的网页“抽风”，而是覆盖代码浏览、协作到自动化流水线，多条开发链路的大规模严重故障。

直到大概 7 个半小时后，GitHub 才宣布事故解决。官方目前只表示已经定位到一个“problematic component”（问题组件），故障后半段还持续出现零星身份认证失败，并对 authentication token retries （身份认证令牌重试机制）进行了调整，完整的 Root Cause Analysis （根因分析）尚未公布。

好巧不巧，就在 GitHub 忙着救火的同时，Cursor 官网火速上线 AI Coding 版代码托管平台 Origin，并茶里茶气地表示：“Cursor can now host your code.”

Cursor 表示，即日起正式开始向所有付费用户逐步开放代码托管平台 Origin 的早期测试。它已经可以自己建 Repo、处理 Pull Request、浏览代码，同时支持和 GitHub 同步。

换句话说，那个过去主要负责帮你“写代码”的 Cursor，现在连你的代码放在哪里，也准备一起管了。

这个时间点巧得几乎像免费送了 Cursor 一次全球神级营销，并且还是“友商”拱手相送。三天前，SpaceX 刚完成对 Cursor 母公司 Anysphere 的 600 亿美元收购交割，Cursor 正式成为 SpaceX 的全资子公司。

同一个交易日里，GitHub 母公司微软股价也下跌超 3%，收于 480.35 美元附近，对应市值单日蒸发超过千亿美元。

Cursor 版 GitHub

从这次开放的 Early Beta 来看，Origin 并非只是在云端存了个代码副本，而是构建了一个完整且深度内嵌于 Cursor 体系的 Git Forge。

结合官方更新日志，可以把 Origin 的核心功能拆解为四大板块：

无缝上车

全功能 Git 工作流：开发者可以直接在 Cursor 内创建 Repo，通过标准的 Git 命令完成 clone、push、pull 等常规操作。

原生 PR 与代码审查：支持完整的 Pull Request 流程，包括查看 commits、检查状态（checks）、代码比对（diff），以及进行 Review、评论和 Merge。

网页端代码探索：支持在浏览器端直接浏览和全文搜索代码库。

GitHub 双向实时同步

GitHub 双向实时同步：官方明确表示，初期绝不逼迫开发者“搬家”。现有 GitHub Repo 可以直接同步到 Origin。导入后，GitHub 依然是权威数据源（Source of Truth），代码 push 依然发往 GitHub。

评论毫秒级打通：在 Cursor 里留下的 Review 会实时推送到 GitHub；GitHub 网页端的新回复，也会立刻在 Cursor 中更新。

一键“反客为主”：这才是 Origin 最聪明的后手。当团队习惯了在 Origin 里工作后，只需点击仓库设置里的「Detach from GitHub」，即可解除绑定。Origin 瞬间从一个“镜像客户端”，转变为团队真正的独立主代码仓库。

每个代码仓库都有智能体（差异化）

GitHub 现有的工作流是为人设计的，而 Origin 则是为了接住未来庞大的 AI 算力。

堆叠式 PR（Stacked PRs）：Agent 习惯一次性进行横跨几十个文件的大规模重构。Origin 允许将庞大的变更拆解为有依赖关系的多个小 PR，通过可视化图谱呈现，极大降低了人类 Reviewer 的认知负担。

智能合并队列（Merge Queue）：当几十个 Agent 同时提交 PR 时，Origin 能自动排序并在后台隔离预先处理冲突，确保主干 CI 永远“常绿”。

AI 自动解决冲突：面对跨文件的复杂代码冲突，Origin 在底层直接内置了 AI 引擎，能自动理解业务逻辑并裁决冲突，连人工介入都省了。

机器可读的审查状态：放弃了仅供人类阅读的绿勾和文字评论，Origin 将审查状态做成了结构化的 API，让 Agent 直接读懂“哪里需要修改”并自动执行闭环。

打通开发与部署的周边生态（首批 Apps 接入）

部署与 CI/CD 接入：首批打通了 Vercel、Depot 和 Buildkite。Vercel 负责为每个 PR 自动生成预览部署（Preview Deployment）；Depot 和 Buildkite 负责跑 CI，并且完美兼容开发者现有的 GitHub Actions 工作流。

极致的并发性能：底层具备每小时 29.6 万次 clone、每秒 22.6 次 commit 的高吞吐架构，全球同步延迟低于 400 毫秒，专为承载大规模并发操作而建。

现阶段，显然还谈不上“取代 GitHub”。Cursor 的策略极其务实：能兼容的先兼容，能搬进来的先无痛搬进来，绝不让迁移成本把用户挡在门外。

但问题也随之而来：一家做代码编辑器的公司，为什么开始拿“每秒能扛多少次 commit”、“机器可读审查状态”来当卖点？

当一个程序员背后站着 10 个 Agent

答案就藏在 Cursor 自身的定位转变里。

今年以来，Cursor 已经越来越少把自己描述为一个“带 AI 的编辑器”，而是越来越多地谈论 Agent 如何自主完成软件工程任务。当开发者开始同时调度 5 个、10 个甚至更多 Agent 并行工作时，软件生产的一个基础假设被彻底打破：一个账号背后不再是一个人，而是一支机器大军。

人的开发节奏有天限，Agent 却没有，并且 Agent 的到来瞬间击穿了人类程序员的开发节奏。它们能不知疲倦地读取仓库、创建分支、修改代码、提交 PR，将单个用户产生的 Git 操作量瞬间放大几十倍。

这直接暴露了传统托管平台的短板：几十个 Agent 同时并发修改同一个仓库，谁来处理冲突？谁先合并？CI 如何重算？GitHub 近期匆忙将 Stacked Pull Requests 推入公众视野，正是为了应对 AI 带来的更大的 PR 和 Review 瓶颈。

AI Coding 的战火，正从“谁写代码”烧向“谁管代码”。

过去两年，Cursor 抢占 IDE，模型厂商比拼生成能力，争夺的都是代码生产的“最上游”。但随着 Agent 真正规模化进入生产，战火必然烧向下游：代码最终放在哪里？谁来调度 CI？谁处理 Merge Conflict？

这些过去属于 GitHub、GitLab 的“后院”问题，正在变成 AI Coding 公司可以重塑甚至抢占的新大陆。

参考链接：

https://cursor.com/cn/changelog/origin-code-hosting?utm\_source=chatgpt.com

本文来自微信公众号“AI前线”（ID：ai-front），作者：四月，36氪经授权发布。