For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/zh/articles/cursor-origin-is-live-what-the.md.
Cursor Origin 已进入 Early Beta，可托管 Git 仓库、镜像 GitHub、双向同步 PR，并让 Cursor Agent 直接操作代码库。但它尚未普遍提供原生堆叠 PR、合并队列、AI 自动解决冲突或 MCP Server，当前更适合先用非关键仓库测试。
8 月 17 日，开发者基础设施领域经历了戏剧性的一天。
GitHub 发生大范围全球故障，从首次记录影响到最终恢复共持续 7 小时 47 分钟。事故期间，GitHub.com 核心服务、API、Pull Request、仓库内容、认证相关系统和 GitHub Copilot 均出现问题。
几乎与此同时，Cursor 开始推出自己的 Git 托管平台 Origin。
这个时间点非常适合在社交媒体上传播：一边的开发者不断刷新 GitHub 状态页，另一边则分享 Cursor 新 Codebase 标签页的截图，开玩笑说该迁移仓库了。
原文将这一刻描述为 Cursor “一夜之间干掉 GitHub”。这个标题很吸引人，但不能按字面理解。
Origin 没有造成 GitHub 故障，一款 Early Beta 阶段的托管产品也不可能在一天内抹去 GitHub 庞大的生态。
真正值得关注的是：Cursor 正从主要提供 AI 编程环境，进一步进入源代码管理基础设施层。Origin 已经可以自行托管仓库，这意味着 Cursor 不再满足于让智能体编写代码、再把代码放到 GitHub。它希望仓库、Pull Request、智能体和开发工作流都存在于同一套系统中。
SpaceX 对 Cursor 的收购已于 8 月 14 日完成。三天后，Origin 开始面向付费用户进入 Early Beta。
Origin 并不只是 Cursor 内部对 GitHub 仓库的缓存副本。Cursor 将它定义为：
用于存储和共享代码的 Git Forge
当前 Early Beta 已支持：
这些能力足以让 Origin 成为真正的 Git 托管产品，而不是单纯的可视化界面。
不过产品仍明确标注为 Early Beta。Cursor 的发布说明称，目前先提供基础功能，更多面向智能体的原生能力将在以后推出。比较当前测试版与 Cursor 年初展示的宏大 Origin 愿景时，必须注意这条边界。
Cursor 当前文档列出的 Origin 代码存储权限如下：
| 套餐 | Origin 代码存储 |
|---|---|
| Free | 不可用 |
| Pro | 可用，分阶段开放 |
| Teams | 可用，分阶段开放 |
| Enterprise | 管理员未禁用时可用，分阶段开放 |
由于采用渐进式推出，付费账户也可能暂时看不到 Origin。企业组织还可以选择不启用。
Origin 会继承命名空间所有者的隐私模式。团队在存放敏感代码前，应检查 Cursor 隐私模式和仓库访问配置。
基本设置过程很熟悉。
进入 Cursor 的 Codebase 工作区：
cursor.com/codebase
选择：
+ New
输入仓库名称。Cursor 随后会显示安装 Origin CLI、克隆仓库或推送现有本地项目所需的命令。
用户或团队第一次创建 Origin 仓库时，所选 codebase 名称会成为仓库 URL 的一部分：
https://cursor.com/codebase/{owner}/{repo}
例如：
https://cursor.com/codebase/acme-corp/example-repo
Cursor 当前测试版文档提醒，测试期间无法重命名该命名空间，因此应慎重选择。
Origin 的重要设计决策之一，是不要求开发者放弃 Git。仓库仍可使用熟悉的命令：
git clone
git pull
git push
从新分支创建 Pull Request 时，流程同样标准：
git checkout -b my-change
git push -u origin my-change
分支推送到 Origin 后，即可从网页界面创建 PR。Cursor Cloud Agents 也可以针对 Origin 仓库创建分支、提交、推送并发起 PR。
这意味着团队可以逐步引入兼容 Git 的新平台，而不必一次替换所有本地开发工具。
每个 Origin 仓库都包含 Pull Request，当前 PR 界面提供四个主要视图：
审查者可以查看差异、评论具体代码行、提交审查、指定审查者，并在满足审查和 CI 条件后合并。
更大的产品构想是，开发者不必为每次修改反复切换：
Cursor 编辑器
→ Git 托管网站
→ AI 助手
→ CI 控制台
→ 返回编辑器
Origin 将仓库浏览和 PR 工作带入智能体本来就在运行的 Cursor 环境。
原文提出了三项激进的 Origin 能力：堆叠 Pull Request、面向智能体的合并队列，以及 AI 自动解决合并冲突。这些想法符合 Cursor 面向智能体规模化开发的愿景，但必须与当前 Early Beta 文档实际承诺的内容区分开。
仓库托管
标准 Git clone/push/pull
GitHub 镜像
代码浏览与搜索
Pull Request
审查与评论
Checks
手动合并
冲突提示
权限管理
应用集成
Automations
Cloud Agents
Origin CLI
原生堆叠 PR 工作流
Origin 合并队列
AI 自动解决合并冲突
Origin 专用结构化审查状态 API
将 Origin 作为 MCP Server
Cursor 的发布文案明确表示，更多面向智能体的原生功能将在以后推出。因此，这些能力应被视为早期演示概念、路线图方向或等待更明确发布文档的功能，而不是所有付费用户现在就能依赖的能力。
对 GitHub 的比较也需要修正。GitHub 并非只有一个供人阅读的巨大 PR 列表，它目前已经提供：
merge_group 工作流事件。这不代表 GitHub 在产品理念上与 Cursor 一样“智能体原生”，但技术差异并不是“GitHub 完全没有、Origin 全部都有”。更可信的差异在于产品哲学：Cursor 希望把仓库基础设施直接嵌入一个将大量编程智能体视为一等参与者的环境中。
Origin 最实用的迁移功能不是一键替换，而是镜像。团队可以把 GitHub 连接到 Cursor，选择组织和仓库，再创建 Origin 镜像。
当前同步范围如下：
| 同步到 Origin | 镜像不会迁移的内容 |
|---|---|
| Git 历史 | GitHub Issues |
| 分支 | GitHub Actions 平台配置 |
| 标签 | GitHub Actions secrets |
| 可浏览、可搜索的代码 | 其他 GitHub 专属平台配置 |
| 双向同步的 Pull Request | — |
| 持续的仓库更新 | — |
镜像创建后，GitHub 最初仍是事实来源。通过 Origin remote 推送的内容会继续流向 GitHub，开发者也能在 Origin 审查 PR，同时把活动同步回 GitHub。
这样团队可以先测试 Origin，而无需第一天就交出仓库控制权。
Cursor 表示，镜像仓库的 PR 会双向同步：
在 Cursor 评论
→ 出现在 GitHub
在 GitHub 回复或回应
→ 出现在 Cursor
在 GitHub 分配审查
→ 可在 Cursor 处理
Cursor 称这些更新会在数秒内出现。现有协作者可继续使用 GitHub，其他开发者则可以同时评估 Origin。相比立刻把关键单体仓库迁移到新测试平台，这是一条更现实的路线。
最关键的迁移步骤是 Detach from GitHub。
镜像刚创建时：
GitHub = 事实来源
Origin = 同步镜像
仓库设置的 Danger Zone 中提供：
Detach from GitHub
解除关联后：
Origin = 独立托管仓库 = 事实来源
之后推送到 Origin remote 的内容不再流向 GitHub。解除关联不会删除或修改原 GitHub 仓库，它改变的只是同步关系。
代码库可以有多个克隆和镜像，但开发流程通常需要一个权威仓库，用于决定新提交推向哪里、哪个 main 分支是标准版本、PR 在哪里合并、部署从哪个仓库拉取，以及双方历史分叉后以哪一份为准。
镜像状态下，权威性属于 GitHub；解除关联后，Cursor 将 Origin 视为该仓库的事实来源。此时 Origin 不再只是配套界面，而成为项目的主要 Git 托管平台。
Cursor 已开始让 Origin 接入部署和 CI 生态。
可从仓库 Apps 标签页连接 Vercel。Cursor 表示，每个 PR 都可以获得预览部署，便于团队在合并前测试和评论。
Depot 可以为 Origin 仓库运行 CI，也可以复用现有 GitHub Actions 工作流。
Buildkite 除了原生管线，还可以运行现有 GitHub Actions 工作流。
这能降低最棘手的迁移成本：即便仓库存储位置改变，团队也不希望同时重写整个 CI/CD 技术栈。
这里有一个重要细节。Cursor 文档称，GitHub Actions 工作流和 secrets 不会作为 GitHub 平台配置被镜像到 Origin；但 Depot 和 Buildkite 等第三方集成可以执行仓库中的现有 GitHub Actions 工作流定义。
两者并不矛盾：
GitHub Actions 平台状态
→ 不由仓库镜像迁移
仓库中的工作流文件
→ 可由受支持的 CI 集成解释执行
团队在解除生产仓库关联前，应验证 secrets、权限、事件触发器、缓存、部署凭证和分支保护。
Origin 更大的战略意义是与智能体深度集成。Cursor Cloud Agents 在隔离的云虚拟机中运行，拥有完整开发环境，能够克隆仓库、创建分支、修改代码、运行构建和测试、提交更改、推送分支、创建 PR，并在开发者电脑离线后继续运行。
有了 Origin，这些智能体可以直接操作同一平台托管的仓库：
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
目标
→ Cursor agent
→ Origin 仓库
→ 分支
→ 代码修改
→ 测试
→ Pull Request
→ 审查
→ 合并
智能体工作流的中心仓库不再必须由外部服务提供。
Origin 也与 Cursor Automations 集成。当前文档列出的事件包括推送到分支、创建 PR、更新 PR，以及其他相关 PR 事件。事件可以唤醒云端智能体，例如：
新 PR 创建 → 运行安全审查智能体
推送到 main → 总结本次修改
PR 更新 → 检查新增提交
这是目前已有明确文档支持的“智能体原生”能力。Cursor 8 月 19 日的智能体更新还允许 Cloud Agents 订阅事件，并持续处理 CI 修复、机器人反馈等工作，直到目标完成。
原文称 Origin “原生支持 MCP”，因此智能体可以像调用 API 一样操作 Git Forge。Cursor 整体产品确实支持 MCP，用于将智能体连接到外部工具和数据。
但当前并没有明确的 Origin 文档页面，把 Origin 本身作为仓库操作 MCP Server 对外提供。现有 Origin 集成文档重点是：
Origin CLI
Cloud Agents
Automations
第三方应用
因此更准确的说法是：Cursor 智能体生态支持 MCP，但 Origin 当前 Early Beta 文档尚未明确宣传专用的 Origin MCP 接口。
Cursor 早期 Origin 演示给出的吞吐量远超普通人类团队需求：
| 指标 | Cursor 演示值 |
|---|---|
| 仓库克隆 | ~296,000 次/小时 |
| 推送 | ~81,000 次/小时 |
| 单仓库提交 | 22.6 次/秒 |
| 全球同步 | <400 ms |
| 自动故障转移 | <10 ms |
核心观点是：人类开发者不需要每秒提交几十次，但智能体集群可能需要。
这些数字仍应视为厂商演示数据。Origin 当前文档没有公开完整基准方法、生产 SLA、工作负载分布、延迟百分位或独立验证。生产团队不应把舞台演示吞吐量直接当作保证容量。
智能体规模化 Git 基础设施并非纯粹假设。Cursor 在 2 月表示，其内部合并的 PR 中有**超过 30%**由云端沙箱中自主运行的智能体创建；到 6 月，Cursor 工程文章称：
超过 40% 的 PR 来自 Cloud Agents
原文引用的是中间阶段的 35% 至 40%。具体比例随智能体采用率增长而变化，但趋势很清楚：
2026 年 2 月：>30%
2026 年 6 月：>40%
Cursor 自己的开发流程已经产生足够多由智能体创建的 PR，仓库协调因此成为真正的基础设施问题。
传统仓库工作流假设的是人类节奏：开发者创建一个分支，工作数小时，推送若干提交，创建 PR，等待审查，处理评论，再完成合并。
智能体集群的运行方式不同。10 个甚至 100 个智能体可能同时克隆同一仓库、创建分支、修改重叠文件、运行 CI、推送提交、创建 PR、回应审查意见和修复失败。
瓶颈会随之转移。编写第一版代码可能变得很便宜，但协调、验证、审查并安全合并大量并发修改会更难。这正是 Origin 试图解决的基础设施问题。
原文将“2008 年式 GitHub 工作流”与智能体原生 Origin 对比。这个历史框架有启发性，但当前产品对比更复杂。GitHub 已持续加入合并队列、堆叠 PR、Copilot coding agents、GraphQL 和 REST API、Webhooks、GitHub Actions、Rulesets，以及自动审查和合并功能。
所以问题并不是 GitHub 能否自动化开发，它显然可以。战略问题是：一个围绕仓库和人类协作设计的平台，能否和一个把“AI 智能体执行软件工作”作为核心产品身份的平台一样快速适应。
Origin 是 Cursor 对新 Git Forge 仍有空间的一次押注。
GitHub 8 月 17 日的事故真实而严重。官方事故时间为：
13:28 UTC 至 21:15 UTC
总计：
7 小时 47 分钟
事故期间，网页和 API 流量、仓库内容访问都出现显著错误率，Copilot 也受到影响。发布时点的巧合形成了极具传播力的叙事：
GitHub 宕机 + Cursor 推出 Git 托管 = Cursor 取代 GitHub
但这并不是实际发生的情况。当 GitHub 仍是事实来源时，Origin 的 GitHub 镜像仍依赖 GitHub，Cursor 其他智能体工作流也可能依赖外部代码托管商。GitHub 故障并不能证明所有 Cursor 工作流都不受影响。
真正的教训是集中度风险：当一个源代码管理平台深度嵌入开发流程时，长时间故障影响的远不只是仓库浏览。
原文还把微软当日下跌约 3.2% 的股价截图与 Origin 新闻放在一起。这种并列很吸引眼球，却不足以得出“Origin 上线导致微软市值损失超过 1,000 亿美元”的结论。
大型科技股受许多因素影响。在没有证据隔离具体原因时，这次股价变化只能作为同日市场背景，不能归因于 Cursor 发布 Origin。
对多数团队而言，答案是：
不要一次全部迁移。
Origin 仍处于 Early Beta，更稳妥的方式是逐步评估。
选择内部工具、原型、小型服务或低风险库，不要先迁移负责整个生产平台部署的仓库。
保留 GitHub 作为事实来源，评估同步时效、PR 行为、代码搜索、访问控制、Cursor 智能体工作流和 CI 集成，以便随时回退。
在两边分别创建评论和审查，确认 Cursor 到 GitHub、GitHub 到 Cursor 的同步都正常，审查者分配没有变化，Checks 能正确显示。
使用 Vercel、Depot 或 Buildkite 时，应连接并验证 secrets、必需检查、预览部署、分支规则和部署门禁。不要假设 GitHub Actions 平台状态已经自动迁移。
在镜像仓库上运行 Cloud Agents，测量克隆和推送可靠性、PR 创建、CI 修复循环、权限行为和长任务完成情况。
检查仓库可见性、团队权限、Cursor Privacy Mode、组织管理员控制和外部应用访问。仓库托管商属于安全边界的一部分。
只有团队明确决定让 Origin 成为权威仓库后，才使用：
Settings → General → Danger Zone → Detach from GitHub
解除关联后，对 Origin 的推送不再同步回 GitHub。
如果团队已经大量使用 Cursor，Origin 尤其值得测试，例如：
当 Cursor 已位于工程工作流中心时，Origin 的集成优势最明显。
以下团队继续使用 GitHub 通常更保守：
Origin 文档也承认，一些 GitHub 专属平台功能不会随仓库镜像迁移。代码托管平台不只是 Git 对象存储，更是一整套生态。
目前最准确的描述是：
Origin 是真正的 Git 托管平台
+ GitHub 镜像
+ PR 与审查界面
+ 与智能体集成的仓库层
它还不是：
能够无缝替代 GitHub 每一项功能的平台
团队已经可以完全在 Origin 托管代码，但这不代表 GitHub Issues、Actions 配置、secrets、Marketplace 应用、策略、公共社区工作流和企业流程会自动迁移。
原文最后的论点比标题更有价值：Cursor 不只是在仓库存储层面与 GitHub 竞争，而是在争夺软件工作最终变得权威的地方。
传统技术栈：
开发者 → IDE → GitHub → CI → 部署
Cursor 正在构建的技术栈：
人类目标 → Cursor agent → Origin → PR → 自动检查 → 部署集成
如果智能体成为代码变更的主要生产者，负责协调这些智能体的仓库平台，就可能与编辑器同样具有战略价值。
因此，Detach from GitHub 比发布当天的玩笑更重要。镜像只是便利功能，新的事实来源才意味着平台迁移。
Origin 是 Cursor 的 Git 托管和代码共享平台。Early Beta 已支持托管仓库、标准 Git clone/push/pull、镜像 GitHub、浏览和搜索代码、创建与合并 PR，以及连接 Cursor 智能体和部分第三方应用。
不可以。当前文档称 Origin 代码存储面向 Pro、Teams 和 Enterprise 套餐，不对免费套餐开放。由于分阶段推出，部分符合条件的用户也可能稍后才获得访问权。
解除 GitHub 关联后，Origin 可以成为仓库的事实来源，但目前还不能逐项替代完整 GitHub 平台。GitHub Issues、GitHub Actions 平台配置、secrets 和许多生态集成都不会自动迁移。
支持。Origin 可以镜像 GitHub 仓库，包括 Git 历史、分支、标签、可浏览代码和双向同步的 PR。保持镜像时，GitHub 仍是事实来源，通过 Origin 的推送会流回 GitHub。
它会停止 GitHub 同步，并将 Origin 镜像转换为独立的 Origin 托管仓库。Origin 成为事实来源，后续推送不再流向 GitHub；现有 GitHub 仓库仍保持不变。
当前 Early Beta 文档没有把原生堆叠 PR 工作流或 Origin 合并队列列为普遍可用能力。Cursor 表示更多智能体原生功能即将推出，因此早期演示和路线图不能等同于当前测试版功能。
当前 PR 文档称 Origin 会显示合并冲突，由用户解决后再合并。早期公开报道介绍过 AI 冲突解决概念，但这不能视为 Early Beta 的正式保证。
没有证据支持这一说法。Cursor 在 8 月 17 日开始推出 Origin，当天 GitHub 恰好发生严重事故。Origin 此前已经宣布并演示过，因此故障并不是产品一夜之间诞生的原因。
Cursor Origin 已经是真正的 Git 托管平台，而不只是 Cursor 内部的 GitHub 浏览器。Early Beta 可以托管仓库、使用标准 Git、镜像 GitHub、双向同步 PR、浏览代码、管理审查、连接 CI 和部署应用，并让 Cursor 智能体直接操作 Origin 仓库。
原文把部分智能体原生能力描述得过于超前。当前第一方文档尚未把原生堆叠 PR、Origin 合并队列、AI 自动解决冲突或 Origin MCP Server 列为普遍可用的 Early Beta 功能，Cursor 也明确表示更多智能体原生能力仍在开发中。
GitHub 8 月 17 日的故障给 Origin 带来了极具戏剧性的发布时刻，但这不代表 GitHub 被一夜取代。对大多数团队，更合理的方式是先镜像一个非关键仓库，测试同步和 CI，再在 Origin 证明自己能够安全成为事实来源后解除关联。
真正的竞争变化不是 Cursor“杀死了 GitHub”，而是 Cursor 开始争夺 AI 智能体创建、审查和交付软件所依赖的仓库基础设施层。
从一句话开始，几分钟内拿到完整网站。
