我去，GitHub 昨晚史诗级故障，核心服务挂了好久。
昨晚我本来准备处理一下 Issue 和 PR，结果 GitHub 卡得不行。具体的 Issue 和 PR 根本打不开，刚开始还以为是我号出问题了，吓一跳。。。
折腾了一会儿，我才想起来去看 GitHub Status。
果然，不是我的问题。
GitHub 官方当时通报，Pull Requests、Issues、Actions、Webhooks、Copilot 等多项服务都出现了异常。网页端和 API 的错误率一度在 20% 左右，归档文件和仓库原始内容下载的错误率更是接近 50%。
今天早上 5 点的时候，事故才解决。不过，官方暂时还没有公布详细的根因分析。
巧的是，就在 GitHub 大面积故障的同一个晚上，Cursor 宣布自己的代码托管平台 Origin 已经上线，并开始开放早期测试。
这个时间点实在太巧了。
Cursor 刚上线自己的代码托管平台，GitHub 就出现大面积故障，还有网友专门拿这件事调侃了一番。
代码仓库、Git 推送和拉取、代码浏览、搜索、PR 评审和合并，这些 GitHub 上常用的能力，Origin 基本都做了一套。它还能直接连接 Cursor 的 Cloud Agent 和 Automations。
说它是"Cursor 版本的 GitHub"，其实并不算夸张。
我也是第一时间打开 Cursor 的 Codebase 页面，试着把自己的 GitHub 仓库同步进去。
Origin 目前没有让你直接扔掉 GitHub。同步仓库时，GitHub 仍然是权威数据源，Issue、Actions 工作流和 Secrets 也不会一起搬过去。
所以，Cursor 做 Origin 的目的到底是什么？
我自己的理解是，它想把代码仓库也变成 Agent 工作流的一部分。
Cursor 也开始做代码托管了
Cursor 官方把 Origin 定义成一个 git forge。
这个词国内开发者平时用得不算多，你可以把它理解成围绕 Git 仓库搭建的代码托管与协作平台。GitHub、GitLab 都属于这一类产品。
Origin 当前可以完成这些事情：
- 创建和托管代码仓库，包括由 Cursor Agent 创建的仓库；
- 使用标准 Git 命令克隆、推送和拉取代码；
- 从 GitHub 镜像已有仓库；
- 在网页中浏览和搜索代码；
- 创建、评审和合并 PR；
- 管理仓库权限、分支规则和合并保护；
- 连接 Cursor Cloud Agent、Automations 和第三方应用。
如果只看这份功能列表，确实很像一个刚起步的 GitHub。
Cursor 文档目前仍给 Origin 标着 Early Beta。已经上线，代表用户开始可以访问和使用；Early Beta 说的是产品成熟度，两者并不冲突。
Origin 目前向 Cursor 的付费方案开放，免费方案暂时用不了。访问权限还在分阶段推送，即使订阅方案符合要求，也不一定马上就能看到入口。
从目前的开放方式看，Origin 主要服务现有 Cursor 用户，尤其是已经在使用 Cloud Agent 和 Automations 的个人开发者与团队。启用 Origin 需要 Cursor 账号和对应的付费方案，团队仓库还要受团队权限控制。虽然它支持标准 Git 操作，但代码托管、Agent、自动化和 PR 评审连在一起，才是这款产品目前的主要使用场景。平时不用 Cursor Agent 的开发者，暂时没有太强的迁移理由。
我先把 GitHub 仓库同步进去
入口在 Cursor Codebase。地址：cursor.com/codebase 。
打开以后，左侧会出现一个带有 Early Beta 标记的 Codebase。
点击之后，跟着配置一下就可以了。
隐私模式这里，选择Privacy Mode ，这样不会使用代码训练模型。不过，为了运行 Cloud Agent 等云端功能，仓库代码仍可能被上传并存放在 Cursor 的云端基础设施中。
隐私设置完成后，Origin 会读取已经连接的 GitHub 组织。选择组织和仓库，再确认访问权限，就可以开始同步。
要同步某个 GitHub 仓库，当前账号还需要满足两个条件：已经安装 Cursor GitHub App，并且对源仓库拥有 GitHub 管理员权限。
Origin 和 GitHub 到底是什么关系
这块很容易理解成"把 GitHub 仓库复制一份到 Cursor"，但实际还多了一层持续同步。
Origin 会把 GitHub 仓库镜像过来，并在源仓库发生变化时继续更新。同步完成后，你可以在 Origin 中查看文件、提交历史和分支，也可以搜索代码、打开 PR。
镜像包含的内容主要有：
- Git 提交历史、分支和标签；
- 可在 Origin 中浏览和搜索的代码；
- 双向同步的 PR；
- GitHub 仓库后续产生的更新。
没有同步过来的内容同样重要：
- GitHub Issues；
- GitHub Actions 工作流；
- GitHub Actions Secrets。
镜像模式下，GitHub 依然是权威数据源。
你可以从 Origin 远程仓库克隆和拉取代码，也可以把代码推送到 Origin。对于镜像仓库，这些推送会继续传递到 GitHub。在 Origin 中创建或评审 PR，相关变更也会同步回 GitHub。
本地使用的仍然是标准 Git。Origin 的 HTTPS 地址格式如下：
text
https://origin.cursor.com/{owner}/{repo}.git第一次操作前，需要安装 Origin CLI 并完成登录：
bash
curl -fsSL https://downloads.cursor.com/origin/install.sh | sh
origin auth login之后就可以正常克隆：
bash
git clone https://origin.cursor.com/{owner}/{repo}.git如果只是想先评估 Origin，也可以同时保留 GitHub 和 Origin 两个推送地址，不用急着迁移现有工作流。
只有主动进入仓库的 Settings → General，在危险区域选择从 GitHub 分离，Origin 才会停止同步并转换成独立托管仓库。到了这一步，Origin 会成为新的权威数据源，之后推送到 Origin 的内容也不会再同步到 GitHub。
原来的 GitHub 仓库不会因此被删除或修改。
所以，至少在现阶段，我更建议把 Origin 当成 GitHub 上面多出来的一层 Agent 工作台。先镜像、先体验，把 CI、权限和 PR 流程跑顺以后，再考虑要不要分离。
代码仓库也开始围着 Agent 转了
如果只是重新做一套仓库列表、文件浏览和 PR 页面，Cursor 很难在短时间内补齐 GitHub 经过多年积累形成的功能和生态。
Origin 直接接入了 Cursor 的 Agent 工作流，仓库里的事件可以继续交给 Cloud Agent 和 Automations 处理。
现在的 Coding Agent 已经不只是在编辑器里补几行代码。一个相对完整的任务通常会经过这样一条链路：
text
读取仓库 → 创建分支 → 修改代码 → 运行测试 → 提交并推送 → 创建 PR → 等待评审和合并过去 Cursor 可以负责前面的代码修改，后半段仍然需要接入 GitHub、GitLab 等外部代码托管平台。仓库权限、Webhook、PR 状态和自动化触发都要跨平台协调。
Origin 把这条链路收进了 Cursor 自己的产品里。
Cloud Agent 可以直接克隆 Origin 仓库、创建分支、提交代码、推送更改并发起 PR。Automations 可以监听分支推送、PR 创建和 PR 新增提交等事件，再自动启动一个云端 Agent。
例如，可以配置一条自动化：Agent 提交 PR 后，再启动一个任务做代码评审、补测试或者处理检查结果。开发者主要看任务是否完成、测试是否通过、diff 是否合理，再决定要不要合并。
Cursor 对 Origin 的官方定位是"面向 Agent 时代的 Git forge"。它重点解决的，是多个 Cloud Agent 同时克隆仓库、创建分支和提交 PR 时，托管平台如何承接这些并发操作。
Cursor 在 Compile 大会上演示过 Origin 单仓库每秒 22.6 次提交，不过官方没有公布完整测试条件。
去年，Cursor 收购了 Graphite。
Graphite 原本就擅长堆叠式 PR 和 Merge Queue，后来 Tomas Reimers 又以 Origin 产品负责人的身份参加了 Compile 大会。不过，官方没有说 Origin 的底层基础设施直接来自 Graphite。
Origin 现在能代替 GitHub 吗？
暂时不能。
现阶段缺的功能还不少。
GitHub Issues 不会同步到 Origin，GitHub Actions 工作流和 Secrets 也留在 GitHub。对于已经把需求管理、CI/CD、Release、Packages 和各种 GitHub App 全部串起来的团队，仓库只是整套研发流程中的一部分。
Origin 当前能连接的第三方应用主要是 Vercel、Depot 和 Buildkite。其中 Depot 和 Buildkite 只支持 Origin 独立托管的仓库，不支持从 GitHub 镜像的仓库。镜像仓库还是继续在 GitHub 上跑 CI。
权限、分支规则和合并保护虽然已经有入口，但相关界面仍在调整，Early Beta 期间还可能继续变化。
昨晚 GitHub 故障也不代表 Origin 已经可以直接充当它的灾备方案。
镜像模式下，GitHub 仍然是权威数据源，PR 和代码更新还要在两边同步。
不过，对大量使用 Cursor Cloud Agent 和 Automations 的团队来说，Origin 依然值得试试。
尤其是新项目，或者暂时没有复杂 Issue、Actions 和第三方集成的仓库，可以更低成本地体验从 Agent 修改代码到创建 PR 的完整流程。
总结
Origin 目前仍处于 Early Beta，更适合已经在用 Cursor Cloud Agent 和 Automations 的个人开发者或团队。它把代码托管、Agent 和 PR 流程接在了一起，但暂时还不能替代 GitHub。
已有 GitHub 仓库可以先用镜像模式体验，GitHub 继续作为权威数据源。如果项目依赖 GitHub Issues、Actions 和第三方应用，没有必要急着迁移。