2026 年 6 月 16 日，Cursor 在 Compile 大会上正式亮出 Origin——一个从底层为 AI agent 并行开发而设计的 Git 兼容托管平台。演示数据炸裂：单仓库 22.6 次 commit/秒、30 万次 clone/小时、同步延迟低于 400 毫秒。分析师 @mark_k 的判断直接刺穿了所有表象：未来代码的绝对主力将从人类切到成百上千并行运行的 AI agent，而 Origin 正是为这场切换准备的底座。GitHub 为人类规模而建，Origin 则为 agent 洪流而生。
舞台中央：一个「从零为 agent 设计」的 Git 平台
6 月 16 日 Compile 大会，Graphite 联合创始人、现 Cursor 团队核心 Tomas Reimers 走上台，宣布了当天「第二大重磅」。
台下炸了。
@swyx 第一时间发帖：「Cursor/Graphite 的 @TomasReimers 刚刚宣布 Origin。@cursor_ai 期待已久的 Git 竞争者，专为 agent 工作负载设计，通过 API 和 MCP 可扩展，内置合并冲突和 co-failure 的 agent 解决方案。」
▲ @swyx 的现场总结帖，配图来自 Compile 舞台。Origin 的 agent-native 特性与吞度量数据首次曝光
@morganlinton 以「Breaking」标签点燃第一波扩散——Origin = Cursor 的 GitHub 竞争者。帖子冲到 20 万查看、1700 多个赞。
Cursor 官方随后确认：「我们正在推出代码存储和 git 托管。Origin 为团队和 agent 提供一个托管、审查和协作代码的地方。今秋推出。加入等候名单。」
官方帖 80 万次查看、6400 赞、近 600 次转发。Cursor 的用户群对这件事有多饥渴，数字本身就是答案。
▲ Cursor 官方确认帖子：Origin 明确服务于「teams and agents」，今秋可用
22.6 次/秒、30 万 clone/小时——这套数字不是给人看的
Origin 最具冲击力的部分是一组硬数据：
-
单仓库22.6 次 commit/秒 - 30 万次 clone/小时
-
同步延迟低于 400 毫秒
一个中等规模的 GitHub 活跃仓库，一天可能几十次 commit、几百次 clone。Origin 的吞吐直接跳了两个数量级。
底层怎么做到的？S3 存储支持的「无限副本」（infinite replicas）。每个 AI agent 拥有一个独立的完整工作副本，存储成本可控，互不踩踏。传统 Git 服务器上共享工作树、多人争锁的瓶颈，在「一 agent 一副本」的模型下被从根上消除。
更进一步——Origin 内置了agent 辅助的冲突自动解决和CI 失败自动修复。两个 agent 同时改同一文件？系统不会丢回给人类排错：agent 之间自己协商、自动合并。CI 挂了？agent 自己诊断、自己修。
@mark_k 的核心分析帖直接定义了这场讨论的框架。他写道：
"Origin is Cursor's attempt at an agent-native GitHub competitor: a Git-compatible forge built around the assumption that lots of AI agents will be cloning, branching, committing, rebasing, reviewing, and fixing failures in parallel."
「Origin 是 Cursor 打造的 agent-native GitHub 竞争者：一个 Git 兼容的 forge，其核心假设是大量 AI agent 将并行执行 clone、branch、commit、rebasing、review，并修复失败。」
▲ @mark_k 的分析帖，精准拆解 Origin 的底层假设：agent 并行才是第一设计原则，Git 兼容只是入口
他紧接着挖出了更深的洞察：
"GitHub was built for human-scale development. Origin is being framed around the next bottleneck: coordinating, reviewing, and safely merging agent-generated code at massive scale."
「GitHub 是为人类规模的开发而建的。Origin 则是围绕下一个瓶颈构建的：在大规模下协调、审查并安全合并 agent 生成的代码。」
Origin 真正的靶子，是「人做主角」这层底层假设。
Graphite 这把钥匙，半年前就插进了锁孔
2025 年 12 月，Cursor 收购了 Graphite——一家做 stacked PR、AI code review 和 merge queue 的纽约初创，估值超过 2.9 亿美元。
当时行业普遍把这件事解读为「Cursor 要补 review 能力」。没人把 Graphite 和「自建代码托管」联系到一起。
直到 6 月 16 日，逻辑才完整闭合。
@mark_k 的分析说得很透：「Graphite 带来了 stacked PRs、review flow、merge queues 和更干净的协作。Origin 在其下增加了托管层。」
这才是收购背后的完整拼图——缺少 Graphite 的 review 层，Origin 只是一个吞吐量更大的 GitHub。叠上 Graphite（stacked PR + AI 聊天修 CI + merge queue），Cursor 才真正拥有了让 agent 代码产出安全落地、规模化合并的闭环。
打开 graphite.com 首页，顶部醒目地标注：「Cursor Cloud Agents are now in Graphite. Create, review, and ship without leaving your PR.」Stacked PRs 把大改动拆成可独立审查的片段，AI code review 在 PR 页内直接对话修复，merge queue 确保语义正确的变更安全合并。
▲ graphite.com 首页：Stacked PRs + AI code review + Chat + Merge queue，Cursor Agents 已在顶部 banner 深度整合
Shopify 用这套工具把交付速度翻了 3 倍，Asana 每周省下 7 小时。这些能力一旦与 Origin 的托管层打通，agent 代码产出就从「写完了卡在 review」变成了「写完→自动审查→自动修复→安全合并」的流水线。
Cursor 走的是一条更快的路径：IDE → Review → Hosting → Agent 全闭环
回头看 Cursor 过去 18 个月的轨迹：
- IDE 起家
：VSCode 深度定制，Composer 等 agent 功能快速迭代 - 连续收购
：Graphite（review）、Continue（AI 工具链） - 垂直整合
：编辑器 → 云 agent → CLI - 估值跃迁
：数百亿美元级别，ARR 逼近甚至突破 10 亿美元
加上 Origin，全链路闭环成型：在 Cursor 里写代码 → 跑 agent 并行执行 → 推送到 Origin → Graphite 自动审查 + agent 修复 → 安全合并。
@mark_k 的结论毫不含糊：「Cursor 不再只是『带 AI 的 VS Code』。他们正试图拥有整个 AI 软件工厂。」
当 GitHub 的「人类瓶颈」撞上 agent 的并行洪流
一个对比足以拆开两者的本质差异：
GitHub 的底层假设：人类开发者一天开几个 PR，review 以小时甚至天计，冲突可控，并行量有限。
Agent 时代的现实：一个高层任务瞬间 spawn 50 个 agent。每个 agent 在独立 clone 上疯狂 branch、edit、test、commit。同一文件被多个 agent 同时触碰的概率暴增；CI 挂了从偶发事件变成了系统常态；review 吞吐的瓶颈从「人够不够」变成了「机器够不够快」。
同样的 Git 协议，两种完全不同的使用密度。Origin 的 S3 无限副本让每个 agent 拥有独立完整环境——传统 Git 服务器在这个密度下的共享工作树模型，直接从设计上就撑不住。
API 和 MCP（Model Context Protocol）扩展也让 agent 能以结构化方式与 forge 交互，不必模拟人类 git push、网页点 PR 按钮那一整套操作。
Origin 官网的 waitlist 页面直截了当地宣告：
"Code is moving faster than any infrastructure was built to handle. Origin was designed for this moment."
「代码的演进速度，已经超过了任何现有基础设施的设计承载。Origin 就是为这个时刻而设计的。」
▲ cursor.com/origin 当前 waitlist 页面：「A git forge for the agentic era」，定位清晰，无一句废话
有人拍桌子叫好，有人在 HN 上直接泼冷水
社区反应远非一边倒。
Hacker News 上，@gen220（自曝身份为 Graphite→Cursor 团队成员）确认：「Origin 由 Cursor 内部的 Graphite 团队拥有，项目由 Graphite 联合创始人 Tomas 在 Cursor 的 Compile 大会上宣布。」
但另一位用户 @newaccountman2 直接泼了冷水：「我愿意看到一个 GitHub 的替代品，但从这帮人手里出来的就算了。而且，用 LLM 生成大量代码这件事，感觉用正常的 PR 和审查流程来处理也没问题。」
▲ HN 讨论帖：确认 Origin 由 Graphite 团队在 Cursor 内部打造，社区赞赏与质疑的声音并存
最清醒的那批声音集中在同一个问题上：并行 agent 可以随便开 branch，真正的硬仗是「哪些变更允许合并、谁为 agent 的输出承担风险」。
Origin/Graphite 解决的是执行层效率——让成百上千个 agent 的分支、合并、冲突处理跑得更快。但策略层——human-in-the-loop 审批、审计日志、权限模型——仍然是未解难题。再好的 merge queue 也替代不了「谁批准这段代码上线」的问责。
还有 GitHub 的护城河。GitHub 不只是代码托管，它有 Issues、Actions、Package Registry、数亿个仓库的历史分发惯性。「默认的 git remote」这个位置，光靠性能优势撬不动。
正面声音同样不小。Digg 聚合的情绪分析显示约 73% 正面，核心兴奋点只有一个：「终于有人认真对待 agent 并行开发的基础设施了。」负面约 27% 集中在成本疑虑和未经验证的技术主张。
@swyx 帖下的一条评论道出了另一个现实：「GitHub 最近让很多人不爽。」对新进入者来说，这是一个难得的窗口。
今秋见真章——以及那个没人能替 Cursor 回答的问题
Origin 目前处于 waitlist 阶段，要求填写 work email（已经引发「Gmail 算不算 work email」的吐槽）。正式发布窗口定在 2026 年秋季。
放在更大的坐标系里——软件开发的本质正在从「人类写代码 + 工具辅助」转向「人类定义意图 + agent 洪流执行 + 新型协调层仲裁」。Origin 是这一转变在版本控制层的最早投影。
同样的转变会出现在 CI/CD、监控、部署、甚至产品管理领域。Cursor 的路径选择很明确：谁能先定义并拥有这层 agent-native 基础设施抽象，谁就能抓住下一代开发者平台的定义权。
就像云计算时代先有 VM、后有容器编排——先有人类的 GitHub，后有 agent 的 Origin。
唯一悬而未决的问题是：当数百个 agent 的代码洪流真的涌进 Origin 的那个秋天，这套系统能不能扛住。以及，人类开发者在那张新的协作图景里，到底坐哪把椅子。
— END —