8 月 17 日，Cursor 上线 Origin，一款面向大量 Agent 任务设计的代码托管平台，把仓库、拉取请求（PR）与代码浏览直接放进 Cursor 编辑器。就在同一天，GitHub 遭遇持续 6 小时 42 分钟的全球性降级，Actions、API、PR 与 Copilot 一度不可用；就在同一周，SpaceX 刚完成对 Cursor 的全股票收购（报道口径约 600 亿美元），把 Cursor 并入 SpaceXAI 部门。
Cursor 扩展代码托管业务的顺序，与 GitHub 不同。GitHub 先做代码托管与协作，再向外扩展到 CI/CD、安全和 AI 编码；Cursor 从 AI 编码环境起家，如今反向把托管补进来。当同一家公司同时提供编辑器、代码审查 Agent 和仓库，企业还需要确认源代码由谁持有、可以如何使用，以及访问权限如何管理。
编辑器内支持托管、PR 审查与 GitHub 同步
Origin 是 Cursor 编辑器里的一个新 Codebase 标签页。团队给代码库命名、用命令行 push，仓库就托管在 Cursor 上；每个仓库都带 PR 的时间线、commits、checks 与文件改动，开发者可以在编辑器里直接 review、评论、合并，CLI 与 Git 完全兼容。
对已有 GitHub 仓库，Origin 提供同步功能：连接 GitHub 组织后可以同步仓库，但「推送仍然发往 GitHub，GitHub 保持 source of truth」；PR 评论双向同步，在 Cursor 里评论会发到 GitHub，在 GitHub 上的回复几秒内回流到 Cursor。首日还接了三个集成——Vercel 为每个 PR 建预览部署、合并后上线，Depot 与 Buildkite 跑 CI，且都能原样执行既有的 GitHub Actions 工作流。
这些兼容功能允许团队继续使用已有构建和部署流程，从 Cursor 访问 GitHub 代码。团队可以先尝试新的操作界面，再决定是否迁移代码库，因此采用和退出的成本可能更低。
GitHub 频繁故障，Agent 又带来更多提交
Origin 发布时，代码托管平台正面临两项变化。
其一，GitHub 的可靠性出了问题。VentureBeat 引述 LeadDev 的统计：2025 年 5 月至 2026 年 4 月，GitHub 记录了 257 起事故，其中 48 起为重大事故，几乎每周一次；仅 GitHub Actions 一年就有 57 次中断，2 月以 37 起成为最差月份。GitHub CTO Vlad Fedorov 承认平台「不是为现在这个规模建造的」，需按当前约 30 倍的负载设计；CEO Thomas Dohmke 2025 年 8 月离职后从未被正式接替，业务被并入微软 CoreAI 部门。Zig 已迁往 Codeberg、Ghostty 宣布离开，OpenAI 据报也在自建 GitHub 替代品。
其二，提交代码的不再只有人。VentureBeat 引述 RuntimeWire 的报道称，Cursor 内部合并的 PR 中约 35% 由运行在云虚拟机里的自主 Agent 提交。过去，审核者可以直接向提交代码的人追问意图。当三分之一合并的改动来自软件，团队还需要安排审核优先级、追溯 Agent 的任务要求，并确定谁对改动负责。
Cursor 借助 Graphite 扩展协作，GitHub 则接入外部 Agent
Cursor 补上托管，靠的是它 2025 年 12 月收购的代码审查公司 Graphite。Graphite 做堆叠 PR，让开发者不必等审批就能持续提交相互依赖的改动；其联合创始人 Tomas Reimers 在 6 月的 Compile 大会上发布 Origin，并主导开发。Cursor 当时说「写代码与协作代码的边界越来越武断」，如今 Origin 就是那个「激进想法」。
面对 Origin，GitHub 的回应是 Agent HQ——在 GitHub 内部接入和管理 Anthropic、OpenAI、Google、Cognition 与 xAI 的第三方 Agent，同时继续提供代码托管基础设施。Origin 则进入了这项托管业务。
企业控制尚未补齐，默认开启也需要管理员审视
Origin 目前是 early beta，离「替代 GitHub」还远。InfoWorld 引述分析师与工程师指出，它缺少分支保护、CODEOWNERS、强制审阅、签名提交、SSO/SCIM、细粒度角色、审计日志、密钥扫描、SBOM 等企业控制；其中一位 Broadcom 的 SRE 还提醒，即便有 Depot、Buildkite 集成，企业仍需考虑 ISO 27001、数据驻留、代码是否会被用于训练模型、FedRAMP 等合规问题。
数据处理方式也需要进一步说明。Origin 对全付费用户默认开启，企业管理员需主动退出。企业因此需要检查，默认设置是否会涉及专有代码的镜像，以及哪些操作需要管理员决定。数据驻留、保留期、训练使用、次处理器等条款至今未公开。而就在 7 月，Mindgard 披露 Cursor 会在用户打开项目时无提示执行被植入项目根目录的恶意 git.exe，Cursor 拒绝修复、称其为范围外——同类缺陷也出现在 Copilot CLI、Gemini CLI 与 Codex，这些处理方式也会影响企业是否信任 Cursor 来托管代码。
是否进一步迁移，要看数据条款与 GitHub 同步方式
Origin 当前允许团队保留 GitHub 作为主仓库，继续使用 Actions，并双向同步 PR。开发者因此能把更多日常操作放在 Cursor 中完成，而无需立即迁移整个代码库。不过，试用仍需评估数据访问与集成成本。
企业与信息安全负责人可以据此检查三件事。第一，GitHub 的可靠性可以通过工程改进提高；源代码的持有、使用和责任归属，则需要通过持续有效的规则和条款约定。第二，在 Cursor 补齐企业控制与数据条款之前，可先将 Origin 用作访问 GitHub 的辅助界面，继续保留已有主仓库和管理流程。这也符合它目前支持同步的使用方式。第三，后续应观察数据导出和同步条件是否变化。如果 Cursor 开始限制数据导出，或不再默认以 GitHub 为主仓库，团队就需要重新评估迁移成本和退出方式。
