8 月 18 日上午，Cursor 编辑器里冒出一个新标签页——Codebase。原本安静了几周的产品节奏，被一次「趁虚而入」式的发布彻底改写：Cursor 开始向付费用户滚动推送自家代码托管平台 Origin；约三个半小时后，GitHub 状态页亮起持续 6 小时 42 分钟的全球性故障。网页与 API 错误率接近 20%，归档与原始文件下载的错误率一路冲到 50%。一场精心策划的平台发布与一场失控的巨头故障撞在了同一个工作日。
Origin 不是又一个 GitHub。它要做的是把代码、PR 与 AI Agent 塞进同一个窗口：开发者可以为代码库命名并形成独立 URL，通过命令行完成推送；内置完整的代码托管能力——存储、权限、检查与合并，全程无需打开浏览器。Agent 直接作用于屏幕上的文件、就地修改 PR、分支推送，所有动作都在编写代码的编辑器里完成。首发当天 Origin 已接入三家合作伙伴：Vercel 为每个 PR 生成预览部署并在合并后发布生产环境；Depot 与 Buildkite 提供持续集成，且两者都能原样执行现有的 GitHub Actions 工作流。
但最聪明的一刀，是 Origin 选择让 GitHub 继续当「数据源」。连接 GitHub 组织后，原有仓库会与 Origin 原生仓库并列展示，推送仍会同步至 GitHub；访问权限沿用 GitHub 现有的读写设置，PR 的对话双向同步——一边的评论数秒内即可出现在另一边。这种「只读镜像」的切入方式规避了源代码托管迁移的高风险：迁移涉及持续集成、合规证据、审计记录、分支保护规则与全体工程师的操作习惯，几乎没有团队会为一个早期测试版产品批准全面迁移。但如果 Origin 的审阅体验足够出色，开发者实际工作重心会逐渐转移，数据源最终会跟随注意力迁移。
发布时点撞上 GitHub 大规模宕机，被外界视为「趁虚而入」，但更准确地说是「Agent 时代的高频 commit/clone 把传统 Git 基础设施打穿」——Origin 给出的 Agent 级性能数据是每小时 29.6 万次 clone、每仓库每秒 22 次 commit。当一个并行 Agent 工作流能在几小时内产生成百上千次提交与拉取时，传统 Git 平台的吞吐与冲突解决就成了瓶颈，而 Origin 把并行 PR 管理、自动合并冲突解决、400ms 全球延迟直接做成原生能力。
Origin 的核心卖点是把 Agent 放进了代码与 PR 所在的同一界面
Cursor 没有重新发明版本控制，它重新发明的是 Agent 与版本控制之间的衔接面。开发者可以询问屏幕上文件的问题，把审阅意见交给 Agent 就地修改 PR，或直接让它推送分支——所有动作都在编辑器内完成。这意味着原本要在 GitHub 网页、CI 日志、Code Review 评论、IDE 之间来回切换的工作流，现在被压进一个工作流。
「只读镜像」是这场迁移战的胜负手
迁移的真正成本不在工具，而在「合规证据 + 审计记录 + 分支保护规则 + 全体工程师的操作习惯」。Origin 选择同步至 GitHub、沿用 GitHub 权限与 PR 双向同步，本质是把迁移成本外包给了注意力迁移：等开发者习惯了在 Origin 里看 diff、留评论、合 PR，注意力重心转移之后，数据源自然跟上。这与当年 GitHub 用「social coding」把 SourceForge 边缘化的路径如出一辙，只是这次社交面换成了 Agent。
Agent 时代 Git 基础设施的瓶颈被钉在了台面上
GitHub 6h42min 的全球故障不是第一次，也不会是最后一次。在并行 Agent 工作流以几十倍频率 commit/clone 的今天，传统 Git 平台的吞吐、并发合并、Actions 排队都成了被高频调用压垮的瓶颈。Origin 给出的小时级 clone 数（29.6 万）与每秒 commit 数（每仓库 22 次）是传统代码托管从未承诺过的 SLA——这不是噱头，是 Agent 时代的工程基线。
它改变了什么
Origin 重新定义了 AI 编码工具的边界：Cursor 从 IDE 走向平台，把「写代码」变成「运营代码」。当 Agent 接管代码托管，GitHub 失去的不只是用户停留时长，而是 AI 时代开发者工作流的入口位置。而 GitHub 当日的全球故障，则把这场平台战的脆弱性摆在了所有 CTO 面前——依赖单一平台的工程风险，从未像今天这样具体可感。