Cursor 高调宣布，代码以后我来管。
2026-08-17，Cursor 发布了代码托管平台 Origin，官方 changelog 里的第一句话是「Cursor can now host your code」。定位说得毫无遮掩，就是一个 GitHub 替代。
然后第二天，GitHub 抖了一下，我眼看着 Origin 跟着晃倒了。
讽刺得藏不住，我先把它放这儿，后面再拆。
三天前，2026-08-14，Cursor 刚宣布被 SpaceX 收购。收购后第一个动作不是整合编辑器，是去碰 GitHub 的地盘。这个时间点本身就在说话，但今天不聊马斯克，聊产品。
先说已上线的部分。
Origin Repos，自有仓库托管。你在 Cursor 界面里建一个 codebase，起个名，repo 的 URL 长这样 cursor.com/codebase/{org}，然后用 Cursor CLI 直接 clone 和 push，标准 Git 流程，没学新东西。
Pull Requests，完整对齐 GitHub 的 PR 体验。Timeline、commits、checks、diff review、评论合并，一条不少。
Code Browsing，网页上浏览和搜索代码。
还有 Apps 生态，首发接了三家。Vercel 负责 PR 自动 preview 部署，Depot 和 Buildkite 负责 CI，都能跑 GitHub Actions 的 workflow。
状态是 Early Beta，所有付费计划可用，Enterprise 组织的管理员可以选择关掉。定价没有单独披露，隐含在 Cursor 订阅里。
Origin repo 的 Apps 界面，Vercel、Depot、Buildkite 一键连接（来源：Cursor changelog）
看功能清单你会觉得，这不就是一个换了壳的 GitHub 吗。
HN 上真有人这么问了。
What I don't understand from the blog post is what's different in this offering than github
-- HN 用户 @jjcm
好问题。答案藏在两个地方，一个是同步机制，一个是 Agent。
双向同步，才是真正的产品策略
Origin 跟 GitHub 的关系，官方设计是双向同步，镜像只是它的最低配形态。
你在 Cursor 里建的 repo 可以推回 GitHub。你连上 GitHub 账号，可以挑哪些 repo 同步过来。在 Cursor 的 PR 里评论，几秒内出现在 GitHub；在 GitHub 那边点了个 review，Cursor 这边也实时更新。GitHub 仍然是原始仓库的 source of truth，push 照常往 GitHub 送。随时可以断开。
这套设计聪明，也鸡贼。
聪明在于迁移成本几乎为零。你不用做选择题，两边同时活着，先用起来再说。这是寄生式的进入策略，先用同步把用户圈进来，慢慢养成在 Origin 界面里工作的习惯，等 agent-native 的功能铺开，GitHub 就退化为一个兼容层。这一步棋走得很贴脸，刀就架在 GitHub 的同步协议上。
鸡贼在于，你嘴上说要替代人家，身体还狠狠拴在人家身上。
记住这一点，马上要用。
底牌是 Graphite
发布当天 HN 评论区有人问 Graphite 集成的事，Cursor 团队的 tomasreimers 直接回了一句。
we actually built this all on Graphite tech
-- Cursor 团队成员 tomasreimers，HN
Origin 整个底座是 Graphite 的技术。Graphite 是 Cursor 之前收购的 PR 工作流平台，stacking（把多个 PR 堆叠成一条链依次 review 的工作流）、review 流程这些能力早就打磨过了。这也解释了为什么一个「刚出生」的托管平台，第一天就有完整的 PR review 体验，不是从零写的，是把收购来的引擎彻底重装了一遍。
tomasreimers 还留了个钩子，说已经把 Graphite 账号连到 Cursor 的用户，「there might be a surprise」。
Cursor 团队成员 tomasreimers：「we actually built this all on Graphite tech」（来源：HN）
Agent 才是真正的野心
如果说同步是入场券，Agent 就是 Origin 的胜负手。
changelog 里最能代表野心的一句是，你的代码、PR 和 agent 现在在同一个地方。浏览代码的时候直接问 Cursor，它能回答，能改代码，能更新 PR，能推一个新分支。
注意这个设计。
Agent 不是挂在托管平台旁边的插件，是内嵌在 repo 里的原住民。你在 review 一个 PR，看不懂某段逻辑，当场问；发现小问题，当场让 agent 修了推上去。
官方还承诺「未来数周」会上线一批 agent-native 功能，原话是要 change source control to better understand and work with agents。翻译一下，传统 source control 是给人类设计的，Origin 要重做一套给 agent 设计的。
Cursor 之前写过一篇 self-driving codebases（自动驾驶代码库）的博客，设想 agent 自己合并 PR、管理发布、盯生产环境。Origin 就是这个愿景的物理地基。agent 得先有自己的家，才谈得上自治。
这个方向我觉得是对的。AI 编程工具这两年卷疯了，但代码托管层几乎没动过，GitHub 的产品形态还是十年前那个为人类 review 设计的样子。谁先把托管层重构成 agent 优先，谁就摸到了下一代开发的入口。
然后第二天，翻车了
2026-08-18 凌晨，GitHub 出现 degradation，Cursor 自己的状态页 status.cursor.com 随后挂出事故公告，Origin 在受影响服务之列，一同被拖下水的还有 Automations、Review Agents 和 Cloud Agents。六个小时后，随着 GitHub 恢复，Cursor 宣布事件解决。
Cursor 官方状态页的事故公告，Origin 名列受影响服务之中（来源：status.cursor.com）
时间线上，Origin 的「替代」人设只撑了不到 24 小时。
原因不复杂，前面埋的雷炸了。从受影响的服务清单看，我有理由推断 Origin 的 GitHub Sync 在实时同步上依赖 GitHub 的 API，GitHub 一抖，同步链路跟着断，Origin 的「GitHub 替代」叙事当场漏气。
替代者被被替代者拖下了水……
HN 上立刻出现了新帖讨论这件事，楼里一条评论直接把窗户纸捅破了。
HN 新帖「GitHub degradation affects Cursor Origin」，评论区火力全开（来源：HN）
So they announce this to try and take people away from GitHub, but it also depended on GitHub? Am I reading this irony correctly?
-- HN 用户 @techgnosis
有人对着状态页逐项拆解，受影响的全是跟 GitHub 深度绑定的功能。主帖下面的质疑派说得更狠，直指 Cursor 没有运营这种级别系统的经验。这话难听，但不算冤枉。运营 Git 级别的基础设施，跟做一个爆款编辑器，是两种完全不同的工程能力。GitHub 用十几年事故换来的稳定性肌肉，不是 Early Beta 能带着的。
不过我倒觉得这次翻车未必是坏事。它把 Origin 最真实的处境提前摆上了台面。现在的 Origin 只有前端，地基还在别人院子里。真要替代 GitHub，它必须建自己的独立存储层，把同步从生命线降级成可选功能。这次事故等于把作业清单提前发下来了。
怎么看这件事
回到开头那个讽刺。
它表面上是个乌龙，底下是个结构性问题。所有走「同步 + 渐进迁移」路线的挑战者，都会经历这个阶段，你的每一步都踩在对方的 API 上。同步是桥，也可能是命门，取决于你过桥之后拆不拆。
短期别急着迁移。Early Beta，功能还缺 agent-native 那批核心差异点，GitHub API 兼容性也没说清楚，HN 上不少开发者担心锁定问题。但如果你已经在付费用 Cursor，可以去 Codebase tab 建个 repo 玩玩，体验一下在 PR 页面里直接指挥 agent 改代码是什么感觉，那个体感确实回不去。
至于 GitHub 会不会反击，SpaceX 收购之后 Cursor 的弹药有多厚，这些是下一集的事。
今天只需要记住一个画面。一个宣战的产品，第二天被宣战对象的服务器波动放倒了。
年轻，但也真是年轻……
这次的乌龙不改变方向，只提醒了难度。
Macaron 🧁 | 同步是桥，也可能是命门
