什么是 Cursor Origin？专为 AI Agent 打造的 Git 托管平台详解

Cursor 现在不仅想帮你写代码，还想托管你的代码。2026 年 8 月 17 日，该公司开始推出 Origin，这是其自有的 Git 托管服务，目前在所有付费计划中处于早期 Beta 阶段。上线首日即支持仓库（Repos）、拉取请求（Pull Requests）、代码浏览以及与 GitHub 的双向同步，所有这些功能都集成在编辑器内全新的 Codebase 标签页中。

其核心论点非常直接：传统的 Git 托管平台是为人类设计的，人类每天只推送几次提交（commits）；而 Cursor 押注未来十年的版本控制将由 Agent 塑造，它们会全天候地创建分支、更新 PR 并合并工作。Origin 正是首个从一开始就围绕这一假设进行设计的托管平台。

如果你的团队负责构建 API，那么这股浪潮对你的影响将比想象中来得更快：你的 OpenAPI 规范、由 CI 驱动的契约测试，以及你的评审工作流，都取决于你的 Git 远程仓库指向何处。以下是 Origin 目前所能做的事情、它的不足之处，以及如果你尝试使用它，该如何确保 API 工作流（包括 Apifox 自动化测试）完好无损。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

什么是 Origin

Origin 是一个由 Cursor 运营的云端 Git 托管平台。初始 Beta 版本包括：

托管仓库：你可以通过 Codebase 标签页、网页端（cursor.com/codebase）或在任务执行中通过 Cursor Agent 直接创建。远程仓库的地址格式为 https://cursor.com/codebase/{owner}/{repo}，支持标准的 git clone、push 和 pull 操作。
拉取请求（Pull Requests）：包含你所期望的所有要素：时间线、提交（commits）、检查（checks）、差异比对（diffs）、评论和合并，且支持在编辑器内或浏览器中进行评审。
网页端代码浏览与搜索：提供仓库级和代码库（codebase）级的设置。
专用 CLI：用于终端工作流，与编辑器相互独立。
Agent 集成（这也是其真正的核心所在）：Agent 可以读取代码库、解答相关问题、进行修改、更新 PR，并在你评审其工作的同一个界面中推送分支。根据变更日志，更多“Agent 原生功能即将推出”。

可用性：仅适用于 Pro、Teams 和 Enterprise 计划。免费计划（Free）用户无法创建 Origin 仓库，企业组织（Enterprise）可以完全选择关闭此功能。存储配额、公共 API 和 Webhook 等细节尚未提供文档说明，在迁移任何重要内容之前，请务必注意这一点。了解当前状态请参阅 Cursor 的 Origin 文档。

Origin 的发布为该公司忙碌的一个月画上了句号；包括 SiliconANGLE 的报道在内的媒体报道也指出，此次发布是在 SpaceX 完成对 Cursor 的收购几天后进行的。如果你想重温该产品在编辑器端的表现，我们那篇“你需要了解的一切”的 Cursor 指南涵盖了所有基础知识。

GitHub 同步是其巧妙之处

没有人会在一个周末内将一家公司从 GitHub 迁移出去，Cursor 深知这一点。因此，Origin 的 beta 版本依赖于双向同步，而不是直接迁移：

将 GitHub 仓库镜像到 Origin，已同步的仓库会实时更新。
PR 评论和表态（reactions）在几秒钟内实现双向同步：在 Cursor 中留下的评论会发布到 GitHub，而 GitHub 上的回复也会显示在 Cursor 中。
对于任何源自 GitHub 的仓库，GitHub 仍然是唯一真实数据源。推送（Pushes）会继续流入 GitHub；Origin 是一个实时镜像，提供了更好的 Agent 体验，而不是替代的远程仓库。
访问权限会映射你的 GitHub 读/写权限设置，因此同步不会在无形中扩大能够接触仓库的人员范围。

这与 Cursor 针对 VS Code 取得成功的“低承诺”采用模式如出一辙：不要求任何人离开，与现有工具并存，让新的工作流凭借便利性取胜。你可以在周一尝试 Origin 的 PR 评审 UI，而无需告知你的平台团队，因为你的 GitHub 配置不会发生任何改变。

其战略潜台词更难忽视。十五年来，GitHub 一直是代码的默认归宿，而它自己的 AI 故事围绕着 Copilot 展开，这与 Cursor 形成了直接竞争；我们在 Cursor vs GitHub Copilot 中对两者进行了对比。Cursor 构建自己的代码托管平台是一个声明：它不再希望自己的 Agent 路线图受到竞争对手平台的制约。

缺失的功能（目前还很多）

该 beta 版本只是一个代码托管平台，而不是一个完整的 DevOps 平台。截至发布时，Origin 拥有：

没有原生 CI/CD。 作为替代，Depot 和 Buildkite 可以通过仓库的 Apps 标签页进行连接，并针对 Origin 仓库运行你现有的 GitHub Actions 工作流文件。这是一种务实的过渡方案，但相比 GitHub 拥有内置产品，这属于第三方依赖。
没有 issue、没有 discussion、没有 wiki。 代码审查是唯一的协作原语。
不支持自托管、没有提供文档说明的公开 API、没有 webhook，也没有说明存储限制。
一个值得注意的发布合作伙伴： 从 Apps 标签页连接 Vercel，每个 PR 都会获得一个预览部署，并在合并时发布到生产环境，这与 Vercel 为 GitHub 仓库运行的流程相同。（Vercel 最近发布动作频频；这也是目前运行 GPT-5.6 Sol 折扣的同一个 Gateway。）

只要 GitHub 仍然是同步背后的唯一真实数据源，这些差距就影响不大。但如果某天团队考虑将 Origin 作为主要平台，这些问题就变得极其重要。现阶段请将该 beta 版本视为一个“评审与 Agent”层，而不是基础设施。

这对 API 团队具体意味着什么

你的 API 工作流可能会在三个地方与代码托管平台发生交集：接口定义/规范保存在仓库中、契约测试在每次 PR 的 CI 中运行，以及评审人员批准这两者的变更。以下是目前它们与 Origin 的对应关系。

接口规范与设计评审。 如果您采用文档模式的工作流，您的 OpenAPI 文件就是仓库中被评审次数最多的产物。Origin 的 PR diff（差异对比）处理 YAML 文件就像处理任何其他文本一样，双向评论同步意味着 GitHub 上的接口评审人员与 Cursor 中的 Agent 操作员可以看到同一个讨论串。目前一切正常，但也没有太大的改进；最有趣的部分是当 Agent 开始以 PR 的形式提出接口定义/规范修改建议时，这正是 Origin 专为之构建的闭环。我们关于在 Cursor 中运行 Apifox CLI 的指南已经涵盖了如何在提交前让编辑器的 Agent 验证接口定义/规范。

CI 契约测试。 Apifox CLI 可以作为任何 CI 系统中的一个步骤运行，而 Origin 对 CI 的解决方案是“通过 Depot 或 Buildkite 导入您的 GitHub Actions 工作流”。在实际应用中，这意味着像 apifox run --scenario smoke-tests 这样现有的工作流步骤应该可以无缝迁移，无需任何修改，因为工作流文件的格式是完全相同的。坦白地说：我们还没有针对市面上所有的 Action 验证过 Depot 的 Actions 兼容层，本周其他人也没有做过这种验证。在信任它并用于发布分支之前，请先在一个镜像的临时仓库中运行您的流水线。

Agent 驱动的变更需要防 Agent 的门禁。 Origin 的整个前提是会有更多由 Agent 编写的代码更快地提交上来。这提高了对每个 PR 进行自动化、确定性检查的价值，因为人工评审人员会成为瓶颈。当响应数据模型（response schema）发生偏差时导致构建失败的契约测试套件，正是能够随着 Agent 吞吐量扩展的那种守卫门禁，而在 Apifox 中这只需五分钟的设置：针对您的接口定义/规范定义一次断言，然后在执行您的 Origin PR 的任何 CI 中通过 CLI 运行它们。下载 Apifox 如果您希望在您的 Agent 获得推送权限之前部署好该门禁，并参阅我们使用 Cursor 进行 QA 测试的演练以了解更广泛的测试闭环。

您应该尝试它吗？

决策快捷指南：

使用 Cursor 付费计划的个人开发者和小型团队： 是的，低风险。镜像一个仓库，使用 PR 视图，保持 GitHub 作为单一事实源。即使 Origin 没能坚持用下去，您也不会有任何损失。
在 GitHub Actions 上有重度投入的团队： 先在旁支项目上试用。您的工作流理论上可以通过 Depot 或 Buildkite 移植，但“理论上可移植”并不是一个真正的迁移计划。
任何合规性要求中明确指定了 GitHub 的人： 等等。目前 Origin 还不支持私有化部署、没有公开的接口文档，并且还处于早期 Beta 阶段，这对于受监管的代码来说是无法接受的。
已经在深度使用 Cursor Agent 的团队： 这正是 Origin 的目标受众。如果您每天都在使用 Cursor 的 Agent 功能，那么让 Agent 在一个将其视为一等公民的代码托管平台上创建和更新 PR，现在就能带来实实在在的工作流收益。

代码托管平台正在成为 Agent 的操作界面

真正的重点不在于 GitHub 出现了一个新竞争对手，而在乎于 Cursor 认为代码仓库本身即将成为 Agent 的主要交互界面，人类的角色将从“编写代码”转变为“审查代码变更”。无论 Origin 是否能最终胜出，所有的代码托管平台都将向这个方向演进。而 API 团队将首当其冲感受到这种变化，因为接口规范和契约测试正是软件工程中最易于实现自动化审查的环节。

无论未来如何，准备工作都是一样的：让你的 API 校验具备脚本化能力，且不绑定于特定的托管平台。Apifox 将你的接口规范、mock 以及测试场景集中在同一个地方，并通过 CLI 运行；它完全不关心 PR 是来自 GitHub 上的人类，还是 Origin 上的 Agent。立即免费尝试，无论谁赢得了这场托管平台之战，你的审查关口都能随你而动。

常见问题解答

Cursor Origin 是免费的吗？ 不是。使用 Origin 代码存储需要付费的 Cursor 计划（Pro、Teams 或 Enterprise）。免费计划用户无法创建 Origin 仓库，企业组织也可以选择完全停用 Origin。

使用它必须离开 GitHub 吗？ 不需要。发布设计假定你无需离开：将 GitHub 仓库镜像到 Origin，GitHub 依然是事实来源，推送、PR 评论和回执可以近乎实时地双向同步。

Origin 有 CI/CD 吗？ 原生没有。Depot 和 Buildkite 可以通过 Apps 标签页连接，并运行你现有的 GitHub Actions 工作流文件。Vercel 也已集成，用于 PR 预览部署。

Agent 可以直接使用 Origin 吗？ 可以，这是它的核心功能：Cursor Agent 可以创建仓库、回答关于代码库的问题、更新 Pull Request 以及推送分支。Cursor 表示未来会推出更多原生支持 Agent 的功能；我们的 Cursor Agent 模式指南涵盖了 Agent 目前在编辑器中已经能够实现的操作。

如何在 Origin 的 Pull Request 上运行 API 测试？ 方式与 GitHub 完全相同：将 Apifox CLI 作为 CI 的一个步骤运行。在 Origin 上，这意味着将 Depot 或 Buildkite 连接到仓库，并复用你现有的 Actions 工作流，无需修改任何 apifox run 命令。