边知识 · 边知道
智能体时代的源码管理：Scion、Origin 和 Git
智能体让代码变更量暴涨，Anthropic 自研 Scion 离开 Git，Cursor 推出 Origin 留在 Git 里重做服务端。两种思路有何不同、各自数字怎么看、普通团队该怎么应对，本文放在一起对比。
当写代码的主要是智能体，Git 还够用吗？
这周有两条消息让我思考了这个问题。10 月 13 日，Anthropic 发布工程博客，介绍了自研的版本控制系统 Scion。2026 年 5 月，他们每天合并约 2,500 个代码变更；到 9 月，每天超过 30,000 个。他们写道，团队被"为人类规模（而非智能体规模）设计的开发基础设施"卡住了。一个七人团队用五个月时间造出了 Scion 和代码审查工具 Antique，并把整个单体仓库从 Git 完全迁移了过去。
另一边，Cursor 在 8 月 17 日推出了 Origin 的早期测试版，官方称之为"为智能体时代打造的 Git 托管平台"（git forge）。10 月 13 日，Cursor 又宣布 Origin 已支持 20 多个集成，并向所有开发工具团队开放应用市场投稿。
两家公司都在回应同一个压力：智能体让代码变更量暴涨，原本为人类节奏设计的基础设施开始吃不消。但它们给出的答案很不一样，我觉得值得放在一起看。
两种不同的思路
Scion 选择离开 Git。Anthropic 的判断是：他们几乎所有的客户端都是一直在线的智能体和自动化任务，Git 的离线、全量克隆设计反而成了负担。他们的主分支历史接近 100 GB，CI 每天约 2,500 万次检出，高峰期运维了数百台 Git 镜像。Scion 改为客户端-服务端架构：提交、合并、变基、blame 都在服务端完成，数据存在 Spanner 和对象存储中；客户端只做稀疏或虚拟化检出，很多任务直接调 API，根本不需要检出。据他们公布的数据，基础设施的 CPU 和内存占用比原来的 Git 镜像体系小 200 倍，检出从几分钟变成几秒，仅 CI 就省下 25% 的 CPU。
Origin 选择留在 Git 里，重做服务端。Cursor 的工程博客（作者 Vicent Martí）介绍了 Origin 背后的存储系统 Continuity：每次 push 都先写入存放在 S3 上的预写日志（write-ahead log，可以理解为一本只能往后追加的操作账本），这本账才是唯一的事实来源；各个节点 NVMe 硬盘上的普通 Git 仓库只是热缓存，丢了可以从日志重建。客户端仍然是标准 git，push、pull、clone 都照旧。在用 Cursor 自家单体仓库做的合成压力测试中，他们报告读取能力随副本数线性扩展到 100 个副本；push 吞吐在 S3 Standard 上可达每秒 120 次，在 S3 Express One Zone 上超过每秒 300 次。CI 场景还有 CloneKit：先下载预构建的仓库快照，再增量补齐。
对比
从架构看，Scion 把智能是从客户端搬到服务端，彻底改变了客户端和协议；Origin 保留 Git 协议和客户端，把一致性和扩展性问题放到基于 S3 日志的服务端解决。
从 Git 兼容性看，Scion 与 Git 差异很大，Anthropic 自己说迁移意味着要替换开发流程的每一环，包括代码审查、代码搜索和 CI。Origin 兼容标准 git，还能镜像 GitHub 仓库：镜像仓库仍以 GitHub 为准，Origin 托管的仓库则以 Origin 为准。
从谁能用看，Scion 是 Anthropic 内部系统，他们明确表示不会以通用产品形式提供，也不是 Git 的通用替代品。Origin 是商业产品，目前为早期测试版，面向 Cursor 的付费计划，免费版不可用。
从规模假设看，Scion 针对的是极其庞大的单体仓库和"成群的智能体"；Origin 同时考虑了 CI 很重的大仓库，和智能体创建的海量小仓库。
| Git（典型托管） | Anthropic Scion | Cursor Origin | |
|---|---|---|---|
| 架构 | 分布式，每个克隆是完整仓库 | 客户端-服务端，服务端完成提交/合并/查询 | Git 托管平台，S3 预写日志为事实来源 |
| Git 兼容 | 原生 | 不兼容，需整套迁移 | 兼容标准 git，可镜像 GitHub |
| 检出方式 | 默认完整克隆 | 稀疏 / 虚拟化 / 免检出 | 标准克隆，CI 可用 CloneKit 快照 |
| 谁能用 | 所有人 | 仅 Anthropic 内部 | Cursor 付费计划（早期测试版） |
| 开放程度 | 开源 | 内部闭源，不打算对外提供 | 商业闭源服务，有公开 API 和应用市场 |
| 公布数字 | — | 2,500→30,000+ 次合并/天；资源占用小 200 倍 | 合成测试 120 / 300+ 次 push/秒；20+ 集成 |
需要提醒的是，这两组数字来源不同、口径不同：Anthropic 报告的是生产环境结果，Cursor 报告的是合成压力测试，不能直接拿来比高下。
对开发者意味着什么
我认为最重要的信号是：开发基础设施的瓶颈正在从"写代码"转移到"合并、测试和审查代码"。这次两家公司都只是在源码管理这一层动手，但 Anthropic 已经在追问更难的问题：当测试运行期间就有成百上千个变更合并进来，CI 到底意味着什么？他们的做法是转向合并后、部署前的自动化测试，冲突交给 Claude 修复；同时让审查工具区分只改注释的变更和敏感的逻辑变更，人只把精力花在最关键的地方。
对大多数团队来说，我的看法是：
- 现在不必急着离开 Git。Anthropic 自己也说，Scion 的思路只对超大单体仓库有意义，而且他们的 token 投入远超一般企业。
- 但值得检查一下流程中哪里默认了人类的速度：CI 排队、全量克隆、逐行人工审查、合并队列。这些可能是你下一个瓶颈。
- 是否把代码托管放到 Origin 这类平台，取决于你对迁移成本、厂商锁定和早期测试版稳定性的权衡。我建议先用镜像模式小范围试用，再做决定。
Anthropic 预计未来 6 到 12 个月，这类问题会变得更普遍，并希望与 GitHub、GitLab 和开源社区合作，把有效的思路带回 Git。这是他们的预测，我会保持谨慎；但从两家公司几乎同时出手来看，方向应该是对的。
希望你在给智能体搭建工作流时，也能把工具链本身当成值得重新设计的东西。
参考：