原以为，Cursor只是想干掉VS Code，但现在看来，GitHub才是它真正的「终极猎物」
GitHub发生大范围宕机的同一天，Cursor推出了面向AI Agent的代码托管平台Origin。
这个时间点很有戏剧性。但我认为，更值得关注的不是两家公司之间的攻防，而是软件开发的主力正在发生变化：过去的协作系统围绕人设计，接下来的系统必须同时服务于人和Agent。
Cursor开始争夺开发底座
Origin不是Cursor在云端保存的一份代码副本，而是一套完整的Git托管平台。
它能够创建仓库，支持标准的clone、push和pull，也能浏览代码、搜索代码、发起PR、审查合并和管理权限。GitHub最核心的一套能力，Cursor正在重新实现。
这意味着Cursor的边界已经越过编辑器。它过去挑战的是VS Code这样的开发入口，现在开始进入代码托管、协作和交付环节。
编辑器决定代码在哪里产生，代码托管平台则决定哪一份代码才算数。后者更接近软件生产的地基。
传统PR是为人设计的
GitHub现有的工作流形成于人类开发者主导的时代。
一个人完成修改，提交PR，等待其他人审查，再经过测试和合并。整个过程以小时甚至天为单位，并没有什么问题。
但Agent的工作节奏不同。多个Agent可以同时开分支、修改大量文件、提交代码并发起PR，协作的时间尺度可能缩短到秒。
原文披露，Cursor合并的PR中，已有35%到40%由Agent在云端虚拟机里自主完成。无论这个比例未来如何变化，方向已经很清楚：Agent不再只是补全几行代码，而是在参与完整的软件工程流程。
Origin重做了Agent协作
Origin提供堆叠式PR，可以把一个大变更拆成多个存在依赖关系的小PR，并用依赖图呈现。
这项能力对Agent很重要。Agent一次可以修改几十个文件，如果所有内容都塞进一个PR，人很难审查，其他Agent也不容易继续协作。把大任务拆成一组相互关联的小变更，才更适合高并发的软件生产。
Origin还设计了合并队列。当多个Agent同时提交代码时，系统负责安排合并顺序、重新检测冲突，并尽量保证主干测试始终通过。遇到跨文件冲突，它还可以调用AI自动处理。
另一个变化是机器可读的审查状态。传统审查主要给人看，往往是一个状态标记加一段自然语言评论。Origin把审查结果变成结构化接口，让Agent能够直接读取和更新，不必猜测评论的含义。
这些功能单独看都不是颠覆，放在一起却说明了一件事：Origin不是把AI加到旧流程里，而是在按照Agent的行为方式重新设计流程。
真正的争夺是权威数据源
Origin支持从GitHub镜像仓库，保留Git历史、分支和标签，PR也可以双向同步。刚开始时，GitHub仍然可以是权威数据源，团队不需要立刻改变原有工作流。
关键动作是“Detach from GitHub”。一旦解除关联，Origin就从镜像副本变成代码的主仓库。
同一份代码可以存在于很多地方，但一个团队最终必须确定哪一份说了算：CI从哪里拉取，上线以哪里为准，发生分歧时相信谁。
过去二十年，GitHub掌握了大量团队的这个位置。Cursor现在争夺的，正是这份权威。
Agent需要的不只是IDE
Origin原生支持MCP，Agent可以像调用接口一样操作整个代码托管平台，不必局限在编辑器内部。
它还接入了Vercel、Depot和Buildkite。前者可以为PR生成预览环境，后两者负责CI，并兼容既有的GitHub Actions工作流。
这套组合把代码生成、提交、审查、测试、合并和部署逐渐连在一起。Cursor要做的已经不是一个更聪明的编辑器，而是Agent参与软件生产时的完整工作环境。
原文还列出了高频clone、push、commit以及低延迟同步等性能指标。这些数字未必是普通开发者最关心的，却揭示了Origin的设计对象：它准备承接的不是偶尔写几行代码的助手，而是一批持续运行、并行工作的Agent。
现在还不是全面搬家的时候
我不认为团队会因为一次发布，就把核心项目整体迁出GitHub。
代码托管平台承载的不只是仓库，还有权限体系、CI、审计、社区关系和组织习惯。迁移成本不可能只用“点一下按钮”来衡量。
但Origin采用双向同步和随时解除GitHub关联的方式，把尝试成本降得很低。已经使用Cursor云端Agent执行后台开发任务的团队，可以先把它作为协作层使用，再判断是否让它成为主仓库。
这可能也是更现实的竞争路径：先做GitHub旁边的Agent工作区，等越来越多的软件生产发生在这里，再逐步接管代码的权威位置。
GitHub的宕机只是一个偶然事件。真正持续发生的变化，是写代码、审代码和合并代码的主体正在改变。
当生产者从人扩展到大批Agent，为人类节奏设计的基础设施就必须重做。Cursor看到的机会，远比替代一个编辑器更大。