Cursor 推出 Origin 代码托管平台：AI 代理时代下的 GitHub 替代方案

Cursor 开始向付费用户推出 Origin——其自有的代码托管平台——于周一上午。大约三个半小时后，GitHub 的状态页面亮起，演变为一场持续六小时四十二分钟的全球性服务降级——根据 GitHub 的事故日志，拉取请求（pull requests）、议题（issues）和 API 的错误率接近 20%，归档文件和原始文件下载的错误率则接近 50%。企业级单点登录（SSO）随之中断：SAML、OIDC、SCIM 配置以及团队同步（Team Sync）全部失效，Copilot 同样无法使用。

开发者互联网做了开发者互联网惯常做的事。

“你现在可以在 Cursor Origin 上托管你的代码仓库，并通过 Cursor Origin 部署至 Vercel，而 Cursor Origin 本身即托管于 Vercel。” Vercel 首席执行官 Guillermo Rauch 在 X 平台发帖称。“而且与 GitHub 不同，它在线运行 😁” 当被问及为何微笑时，Rauch 回应道：“试图轻松看待当前局势。我们自己目前也因 GitHub 瘫痪而卡住了！”

Matt Palmer——Cursor 公司员工——转发了自家产品发布的推文，并配上了当天最妙的一句：“我们本打算更早发布此功能，但 GitHub 当时宕机了。” 换言之，一次 GitHub 中断延迟了一款 GitHub 竞品的发布。

产品发布通常提前数周锁定，且无任何证据表明 Cursor 此次刻意择时。但这一巧合却为该公司带来了巨大利好，因为它戏剧化地凸显了 Origin 存在所要论证的核心主张：十八年来，为团队源代码选择托管位置，一直是工程组织所作的最无趣决策。Cursor 押注的是，AI 代理（agents）已使其再度变得有趣——而对技术决策者而言，这才是此处真正的新闻：并非一款新产品，而是一个附带治理问题的新采购议题。

Origin 内部解析：Cursor 的代码托管平台实际功能

Origin 位于 Cursor 内一个全新的 代码库（Codebase）标签页 中。团队为代码库命名，该名称即成为其 URL 的一部分，随后可通过命令行推送代码至该代码库。此后，用户即可获得你期望从代码托管平台（forge）获得的各项机制——即封装 Git 并处理存储、权限、检查与合并的服务层。每个代码仓库均支持拉取请求：包含时间线、提交记录、检查项及变更文件。审阅者可直接阅读差异（diff）、留下评论并执行合并，全程无需打开浏览器标签页。

Cursor 在该机制之上构建的内容才真正值得研究。如今，AI 代理可在与代码及所修改拉取请求相同的界面中运行。“你的代码、拉取请求和 AI 代理现在处于同一位置，” 更新日志（changelog） 写道。开发者可就屏幕上显示的文件提问，将审阅意见交予 AI 代理并令其就地修订拉取请求，或指示其推送分支——所有操作均在编写代码的编辑器内完成。

首发当日上线三项集成，其合作伙伴的选择颇具深意。Vercel 为每个拉取请求启动预览部署，并在合并时交付至生产环境，该功能面向 Pro 和 Enterprise 客户开放公开测试版， 其开发者账户声明称。Depot 和 Buildkite 执行持续集成（CI），且关键在于二者均原样运行现有 GitHub Actions 工作流。Buildkite 还额外提供原生流水线（pipelines）。

该兼容层正是其整体策略的缩影。Cursor 并未要求团队重写构建系统、重新培训工程师或拆除现有部署流水线。它仅邀请团队尝试一个通往已有代码的第二窗口——这是一项远易获批的请求。

该公司表示，更多合作伙伴即将加入；而首批落地的合作伙伴，恰是平台团队在评估 Origin 是否能承载真实工作负载时最关注的对象。一个缺乏部署与 CI 功能的代码托管平台，不过是个代码查看器；而一个既能运行你现有 Actions 工作流、又能将预览版本部署至你已付费使用的 CDN 的代码托管平台，则具备候选资格。

为何允许 GitHub 继续作为事实权威（source of truth）是 Origin 最精明的设计选择

这是企业买家最应深入研究的决策，因其将决定 Origin 能否通过任何安全审查。

Cursor 并未要求你离开 GitHub。连接一个 GitHub 组织，选取若干代码仓库，它们便会与 Origin 原生代码仓库并列显示。“推送操作仍持续发送至 GitHub，后者对所有始于该处的操作保持事实权威地位，” 更新日志指出。访问权限镜像 GitHub 现有的读写设置，而非另建一套平行系统。拉取请求的讨论双向同步——在 Cursor 中评论，即同步至 GitHub；在 GitHub 中回复或添加反应（reaction），则会在 Cursor 中“数秒内”呈现。

这是一种经典的楔入式（wedge）策略，且执行得当。源代码控制系统的“撕裂-替换”（rip-and-replace）迁移，属于工程组织所能开展的最高风险项目之一。它牵涉持续集成、合规性证据、审计追踪、分支保护规则、工具链中的每一项集成，以及全体工程师的肌肉记忆。几乎没有任何首席技术官（CTO）会批准为一款尚处早期测试阶段的产品实施此类迁移。

一种以 GitHub 为权威、仅以只读为主进行镜像的方案，可自行通过审批。尝试零成本，弃用亦无破坏，同时悄然转移开发者日常工作的场所。倘若 Cursor 的审阅体验确证更优——而 Cursor 已投入真金白银确保其如此——那么事实权威最终将随注意力迁移。

这笔资金投向了 Graphite——这家代码审阅初创公司，Cursor 于 2025 年 12 月收购了它，据 Axios 报道，收购价远超其 2.9 亿美元 B 轮融资估值。Graphite 构建了堆叠式拉取请求（stacked pull requests），该工作流使开发者能在不等待审批的情况下持续交付相互依赖的变更。宣布该交易时，Cursor 写道 ：“你在何处编写代码与在何处协作审阅代码之间的界限，正日益显得武断”，并承诺“一些我们暂不能分享的更激进构想。” Origin 正是这一激进构想。Graphite 联合创始人 Tomas Reimers 于 6 月 Cursor 首届 Compile 大会现场揭晓 Origin，并主导其开发。

AI 代理如何将代码审阅转变为软件领域的新瓶颈

主张构建 AI 代理原生代码托管平台（agent-native forge）的依据，是一条易于陈述、且在此市场中罕见地拥有充分实证支撑的论断：编写代码已不再构成约束，审阅与集成代码才成为瓶颈。

谷歌的 2025 年 DORA 报告基于近 5,000 名科技从业者的调研发现，目前 90% 的开发者在工作中使用 AI，日均使用时长中位数达两小时，且逾 80% 的人表示 AI 提升了其工作效率。但 AI 采用率与软件交付吞吐量呈正相关，与交付稳定性却呈负相关：产出越多，故障越多。报告作者将 AI 描述为一种“放大器”，它“既放大高绩效组织的优势，也放大困境组织的机能障碍”。

信任度并未跟上产出量的增长。Stack Overflow 的 2025 年开发者调查 来自177个国家的49,009名受访者中，84%的人正在使用或计划使用AI工具；但对其准确性的信任度从一年前的43%下降至33%，不信任度则从31%升至46%。三分之二的受访者将‘几乎正确、但又不完全正确’的AI解决方案列为他们最主要挫败感。GitLab第九次年度 DevSecOps调查由哈里斯公司（Harris）对3,266名从业者开展，量化了运营层面的拖累：73%的受访者遭遇过‘氛围编码’（vibe-coded）输出问题，70%表示AI使合规管理变得更困难，仅有37%愿意在无人工审核的情况下让AI处理日常任务。

代码量仍在持续攀升。GitHub的 Octoverse 2025 统计显示，全球开发者达1.8亿人，代码仓库达6.3亿个，每月合并的拉取请求（pull request）达4,320万个，同比增长23%。而 RuntimeWire报道称 最能解释Origin存在理由的内部数据是：在Cursor内部合并的拉取请求中，有35%由运行于云虚拟机中的自主代理（agents）发起。

一个为人而建的代码托管平台默认假设拉取请求代表人类意图，且由可当面询问其本意的人发起。一旦三分之一的已合并变更源自软件，该待审队列便不再是一场对话，而变成一个调度问题。这是一个真实存在的架构论点，也是Cursor目前最具说服力的优势所在。

GitHub的可靠性危机为Cursor提供了一个无需主动争取即可获得的入场机会

替代方案的供给侧逻辑更简单：GitHub一直不可靠，其自身高管也承认了这一点。

由 LeadDev 开展的一项分析统计了2025年5月至2026年4月期间共257起事故，其中重大事故48起——平均每周发生一起重大中断。2月是有记录以来最糟糕的一个月，共发生37起事故。仅GitHub Actions一项，在十二个月内就导致了57次中断。首席技术官弗拉德·费多罗夫（Vlad Fedorov）表示，该平台“并非为当前所需承载的规模而构建”，必须按今日负载的30倍进行设计。在InfoQ于4月报道的一篇工程博客中，该公司承认其“未能达到自身的可靠性标准”，并指出原因包括快速增长、架构耦合过紧以及负载削减机制不足。周一发生的中断是GitHub状态页面在十五天内报告的第七起事故。 InfoQ，该公司承认其“未能达到自身的可靠性标准”，并指出原因包括快速增长、架构耦合过紧以及负载削减机制不足。周一发生的中断是GitHub状态页面在十五天内报告的第七起事故。

疲惫感清晰可闻。“GitHub真的感觉不像为代理（agent）时代而构建的，”一位开发者在Origin上线时于X平台写道，“它宕机太过频繁，但此前一直缺乏真正可行的替代方案。”

叛离潮在Origin诞生前就已开始。Zig编程语言项目 于2025年11月迁移至Codeberg ，并将Actions故障列为迁移原因之一。今年4月，米切尔·哈希莫托（Mitchell Hashimoto）宣布终端模拟器Ghostty——一款拥有逾5.2万星标（stars）的项目—— 也将离开，理由是近乎每日发生的中断致使代码审查与CI流程数小时无法进行。《The Information》3月报道称，微软持有大量股份的OpenAI公司正着手构建自己的GitHub替代品，部分原因正是GitHub频繁中断导致其工程师数小时无法提交代码， 据Tom's Hardware转述。

微软的组织架构并未起到助益作用。托马斯·多姆克（Thomas Dohmke） 于2025年8月辞去GitHub首席执行官职务，此后该职位一直空缺；GitHub业务单元的领导权被并入微软CoreAI组织，由执行副总裁杰伊·帕里克（Jay Parikh）统管。《The Information》5月一份报告指出， 并于2025年8月出任GitHub首席执行官，此后该职位一直未再任命继任者；该部门的领导层已并入微软CoreAI组织，由执行副总裁杰伊·帕里克（Jay Parikh）负责。《信息》（The Information）在5月的一份报道中写道 帕里克曾向下属发出警告 ，称Cursor与Anthropic推出的编码工具最终可能令GitHub变得过时。GitHub自身针对代理时代的回应—— Agent HQ——允许客户在GitHub内部编排来自Anthropic、OpenAI、Google、Cognition及xAI的第三方代理，这一策略逻辑自洽，但实质上承认了代理层的主导权，仅保留底层基础设施。Origin所攻击的，恰恰就是这一底层基础设施。

如今SpaceX已收购Cursor，那么谁实际掌控着你的源代码？

Cursor的崛起即便放在此轮科技周期中亦属非凡。该公司由四名麻省理工学院（MIT）学生于2022年创立，Anysphere公司于2023年10月获OpenAI Startup Fund 800万美元投资， 据TechCrunch报道，随后又分别以25亿美元估值融资1亿美元、以99亿美元估值融资9亿美元、并于去年11月以293亿美元估值融资23亿美元。今年5月，彭博社报道称其年化营收达30亿美元，且已有逾3,000家客户每年支付至少10万美元。

随后，在Origin发布前三天，彭博社报道称SpaceX已完成对Cursor价值600亿美元的全股票收购——该协议早于6月由TechCrunch 报道 ，时间点恰在SpaceX创纪录的IPO之后数日，以及其吸收xAI六个月后。Cursor现隶属于一个名为SpaceXAI的新部门。这家要求托管你专有源代码的供应商，上周五起已成为一家火箭公司的下属单位；该公司拥有自己的前沿模型（frontier-model）部门，其创始人亦以不拘泥于制度性审慎而闻名。

摩尔洞察与战略公司（Moor Insights & Strategy）的杰森·安德森（Jason Andersen）早在交易完成前的6月就向 Tech Times 提出了模型路由问题：“xAI的模型及其对护栏（guardrails）的处理方式，与Cursor一贯所秉持的理念存在显著差异。”该报道框定了首席信息安全官（CISO）如今必须回答的问题：当一家公司同时控制着代理编写代码所用的编辑器、代码所寄存的托管平台，以及代理所运行的模型时，什么机制来约束其对代码的处置行为？

Cursor尚未公布相关答案。RuntimeWire在Origin发布前即指出，其定价、安全架构、数据处理条款及迁移工具均未公开；而周一发布的更新日志亦未补充任何上述内容。日志仅声明Origin“即日起面向所有付费计划用户开放，企业组织（enterprise orgs）除外——除非其管理员选择退出”。注意是“选择退出”（opt-out），而非“选择加入”（opt-in）——这句表述值得管理员仔细阅读两遍。

此外，还有一段需审慎评估的历史记录。今年7月，Mindgard公司的研究人员披露，Cursor会在用户打开Windows项目根目录下植入的恶意git.exe文件时立即执行该文件，且不作任何提示——该仓库污染（repository-poisoning）漏洞最早于2025年12月上报。 《The Hacker News》 报道称，Cursor拒绝修复该漏洞，称其在共担责任（shared-responsibility）模型下属于“范围之外”（out of scope），同时承认其“未能及时与研究人员闭环沟通”。该漏洞未被分配CVE编号。同类漏洞亦在未经修复状态下出现在GitHub Copilot CLI、谷歌Gemini CLI及OpenAI Codex中——但供应商拒绝修复的漏洞，对于一款核心卖点本质上是“请让我们托管您的代码仓库”的产品而言，无疑是一个尴尬的注脚。

工程负责人应在允许Origin接入工具链前明确解决的事项

Origin 目前处于测试阶段（beta），而非正式迁移；若将其作为测试版本对待，则值得评估。同步模式（sync mode）为平台团队提供了低风险方式，用以衡量面向代理的评审界面是否能缩短开发周期，且无需修改任一分支保护规则（branch protection rule）。但在任何具有权威性的操作启动前，有三件事必须先行解决。

第一种情况是默认设置。Origin 对付费用户默认开启，除非企业管理员选择退出；这意味着，若某组织尚未就是否允许专有代码镜像至新主机做出明确决定，则该决定实际上已被代为做出。确认您的立场是一项周一早晨即可完成的任务，而非要等到下一季度才处理的事宜。

第二种情况涉及文书工作。数据保留、数据驻留地、训练用途、分包商，以及Cursor并入SpaceX后各项条款的变更，目前均未公开披露；而产品页面不构成合同。在这些条款以书面形式正式发布之前，可辩护的立场是将Origin视为GitHub之上的便利层，而非权威记录系统——而这恰好也正是其现有架构的本质。

第三种情况关乎退出机制。Origin对Actions的兼容性及其以GitHub为事实来源（source-of-truth）的设计，正是使其采用具备安全性的关键特性；但与此同时，随着Cursor的激励重心逐渐从借用底层基础设施转向拥有底层基础设施，这些特性也最有可能被削弱。请趁当前镜像仍仅为镜像之时，即刻厘清退出路径的具体形态。

以上各点并未否定Cursor论点的正确性。GitHub凭借其乏味却可靠的基础设施地位赢得市场主导权，但在过去十八个月中，它既不再乏味，也不再可靠——与此同时，抵达其平台前端的代码中，有三分之一已不再由人类编写。Origin是对一个真实问题提出的严肃解决方案，其开发团队收购了恰当的公司来构建这一产品。

但GitHub的失败与Cursor的失败性质不同，企业不应混淆二者。 周一的中断于协调世界时（UTC）20:22恢复。可用性是一个工程问题，而工程问题终将得到解决。但谁持有您的源代码、他们可对源代码采取何种操作、以及他们最终向谁负责——这些问题并无此类时效限制；而在这一关键问题上，这家在周一竭力兜售信任的公司，至今仍未公布其相关条款。