Cursor 做代码托管了。不是插件，不是集成，是正儿八经的代码托管平台，直接叫板 GitHub——这应该是本周 AI 编程圈最值得琢磨的一件事。
8 月 17 日，Cursor 宣布 Origin 代码托管平台上线，面向所有付费用户分批开放早期测试。功能清单很直白：仓库、Pull Request、代码浏览、GitHub 双向同步，还有 Vercel、Depot、Buildkite 三个部署和 CI 集成。听起来平平无奇？注意发布时间——同一天，GitHub 正经历一场持续数小时的全球宕机。
一、Origin 是什么：一个开在 Cursor 里的代码托管平台
先看它到底给了什么。Origin 的仓库直接从 Cursor 的 Codebase 标签页进入，你可以：
- 在 Cursor 里直接创建新仓库，用命令行 clone、push 本地项目；
- 连接 GitHub 账号，选择组织，把现有仓库同步进来——注意是「同步」不是「迁移」，你选什么同步什么，随时可以断开；
- 同步的仓库实时更新，PR 评论双向同步：你在 Cursor 里发的评论会发到 GitHub，GitHub 上的回复几秒内出现在 Cursor；
- 每个仓库都有 PR 功能，时间线、提交、检查、变更文件一应俱全，GitHub 上分配了评审的 PR 也能直接在 Cursor 里审、合；
- Agent 对所有仓库可用——代码、PR、AI agent 在同一个界面里，你可以直接对着正在看的代码问 Cursor 问题。
翻译成人话：Cursor 想让你在同一个地方完成「看代码、改代码、提 PR、合 PR」，把 GitHub 干的事搬进编辑器里，而且 AI agent 全程在场。
最值得注意的是它不逼你二选一。GitHub 依然是你现有仓库的「事实来源」（source of truth），Origin 只是多提供一个入口和一份同步副本。这是典型的「先并轨、再迁移」打法——先降低你的试错成本，让你把一部分日常开发挪过来，再慢慢做深。
二、为什么挑这个时间：GitHub 的宕机之痛
Origin 上线当天，GitHub 遭遇了一次持续 4-6 小时的全球性宕机，错误率一度接近 20%。而这只是今年一连串事故的又一次。
GitHub CTO Vlad Fedorov 自己承认过：平台「不是为它现在要承担的规模设计的」。去年 10 月，GitHub 就宣布要把基础设施容量提升 10 倍，今年 2 月又修正为 30 倍。年初那次著名的事故，部分原因是主流客户端应用的读流量突然暴增 10 倍以上，压垮了关键数据库集群。
一边是 1.8 亿开发者把全部身家押在 GitHub 上，一边是它频繁掉链子——这正是 Origin 切入的窗口。对开发者来说，代码托管是「不能出事」的基础设施，而 GitHub 这两年恰恰在稳定性上不断失分。
三、更大的背景：SpaceX 600 亿美元收购 + Agent 时代的海量代码
Origin 不是 Cursor 一时兴起。8 月 14 日，SpaceX 以 600 亿美元全股票收购 Cursor 母公司 Anysphere 刚刚完成交割，三天后 Origin 就上线了。
收购背景先放一边，单看代码量这个维度。Cursor 给出一组数据：AI Agent 产生的 Pull Request，从 2025 年 9 月的每月 400 万，涨到 2026 年 3 月的每月 1700 万。四倍多，半年。
这个数字意味着什么？传统的 Git 平台是围绕「人」设计的：人创建分支、人提交、人开 PR，速度是人的速度。但 AI Agent 一天能提交多少次？如果未来一个团队跑几十上百个 coding agent，仓库基础设施要面对的工作负载和今天完全不是一回事。
Cursor 自己的研究系统，已经做到让上千个 agent 在一周内连续协作完成一个软件项目，大多数提交由 agent 产出。这种规模下，仓库的并发、合并冲突、CI 调度都会变成新问题——而 Origin 的架构（NVMe 存储的 Git 文件服务器 + S3 作为最终数据源），宣称的 22.6 commits/秒、29.6 万 clones/小时、不到 400ms 的全球同步延迟，都是冲着「agent 规模」去的。
四、真正的野心：为 AI Agent 时代重写代码托管
所以 Origin 表面上是 GitHub 的替代品，实际上是在赌一个更大的事情：未来的代码托管平台，赢家不一定是最会存 Git 仓库的，而是最能承载「人和大量 AI agent 一起写代码」的。
GitHub 的路径是从代码托管出发，往上加 Copilot、Actions、安全、企业治理——一个围绕人类协作构建的庞然大物。Cursor 的路径正好反过来：先做 AI 编程体验，再向外扩展仓库、评审、部署、基础设施集成。
两条路殊途同归，但起点完全不同。GitHub 要把 Copilot 塞进一个为人类设计的体系里；Cursor 从第一天就在为「agent 是主要写代码者」的场景做设计。Origin 的「agent-native」特性还在路上，但它对合并冲突的自动化解、失败 CI 的处理、PR 的自动生成，已经明显是 agent 优先的思路。
五、争议：代码放在 SpaceX 手里，安全吗？
Origin 有一个绕不开的问题：代码托管条款至今没有公开。
开源媒体 Open Source For You 已经点名了顾虑——Cursor 没有发布 Origin 专属的服务条款，数据保留期限、是否用于模型训练、子处理商有哪些、代码导出和迁移怎么办，全是空白。叠加 SpaceX 收购背景，「把你的私有代码交给一家火箭公司」这个信任问题，不是所有人都能接受。
另一个槽点是默认开启（opt-out）：Origin 默认对所有付费用户开放，企业管理员可以选择关闭，但个人用户得自己去设置里处理。对一个存储核心资产的平台来说，「默认打开」这个姿态值得商榷。
六、老达点评
我判断这事的本质是：AI 编程的竞争，已经从编辑器打到了基础设施层。 前两个月各家还在卷 IDE、卷 agent、卷模型，现在 Cursor 直接去动代码托管这个最硬的地基——因为谁掌握了代码存放的地方，谁就掌握了 agent 干活的地方。
对普通开发者，短期内不用慌，也不用急着搬家。Origin 现在还是早期测试，GitHub 的生态（Actions、安全扫描、企业治理、开源社区）短时间内无法被复制。但值得留个心眼：如果你所在的团队大量使用 coding agent，GitHub 的频繁宕机已经在真实影响你的开发效率——这种时候，多一个 Origin 这样的备选，反而是好事。
真正值得观察的是两件事：一是 Origin 的代码托管条款什么时候补齐，这直接决定信任度；二是 GitHub 的反击——微软年初已经因为担忧 Cursor 和 Anthropic 抢市场而重组了内部团队，现在 Cursor 直接打到了 GitHub 的基本盘，接下来 Copilot 生态的动作值得期待。
AI 时代的代码托管会是什么样？答案还没出来，但至少，竞争开始了。想系统了解 AI 编程工具怎么选，可以看看我之前的 AI 编程工具专题 和 AI 智能体与自动化专题；如果你在用 Cursor，也可以读读 我用 Cursor Agent 模式写了 3 个月代码的实战技巧 和 2026 上半年 AI 编程工具复盘。
