Scion & Git它们到底差在哪
假设你让 AI 助手给学习室加一个搜索框。改动怎样留档、怎样交给别人、怎样确认读者能用？沿着这次任务，看懂 Git 和 Scion。
先带走这三个答案
这里的 Agent，指能按要求读写文件、执行任务的 AI 助手。Git 和 Scion 则是帮它保存、查询和共享代码版本的工具。
- Git：许多版本工作可以在正在使用的机器上完成。先记下这一轮修改，需要协作时再把修改传出去。
- Scion：把更多版本工作交给在线服务。大量 Agent 同时干活时，可以按需拿文件，并复用已取得的内容。[1]
- 你现在继续用 Git，先把任务和验收说清楚。让每项修改有明确范围，完成后实际操作，确认结果符合要求。
只想先弄懂？读完第一节的对比，再看第八节的 Agent 用法。技术细节可以之后展开；六张示意图放在对应解释旁边。
Git 和 Scion 差在哪
先分清版本记在哪里，再看文件怎样共享。
给学习室加搜索框，会改动页面和搜索程序。你需要知道改了什么、基于哪一份代码修改、能否找回之前的状态。Git 和 Scion 都在帮助管理这些修改。
- 版本
- 一份可追溯的修改存档，帮助比较前后变化、找回之前的状态。
- 本地
- 你或 Agent 正在工作的机器，不一定是你的个人电脑。
- 服务端
- 通过网络提供版本存储、查询等功能的系统。
Git：自己手里的项目档案
你手里有代码和版本记录。很多事情可以自己做：保存一次修改、比较前后差异、查看旧版本。准备和别人协作时，再把修改传出去。
Git 用来管理版本；GitHub 是常见的在线协作网站。使用 GitHub 分享代码时，你仍可以先在本地保存版本、查看已有历史。
Scion：一个在线档案馆
保存版本、查历史和合并修改等工作，更多由服务端处理。Agent 仍然负责改代码；需要的文件和记录，再通过网络取得。
这里比较的是工作机器与在线服务怎样分工。“在线档案馆”背后也可以有许多台服务器。
- Agent 修改文件例如加上搜索框和查找规则
- 在本地留下版本记下这一轮修改
- 需要协作时同步让协作方取得这些修改
- Agent 修改文件例如加上搜索框和查找规则
- 由服务端记录版本通过在线版本服务保存
- 协作方在线取得按权限读取相关修改
读图：两排的中间格是关键：同样要留下版本记录，Git 可以先在本地完成，Scion 把这项工作交给服务端。
再看具体操作的文字对照
留版本、合并、上线，是三件事。留版本是记下修改；合并是把多份修改放进共同使用的版本；上线是把结果发布到读者实际使用的网站。图中的“同步”只是让协作方取得修改。
Scion 把更多版本工作放到在线服务，也就更依赖服务器和网络。这是它为大量自动化任务做出的取舍。
沿着这个分工看，Agent 负责动手实现搜索功能，版本工具负责记下和共享这些修改。需求是否理解准确，仍需要靠任务说明和完成后的检查来确认。
为什么 Anthropic 要重做
当很多自动化任务同时开工，准备工作本身也会变成大工程。
一个人拿档案、改几页、交回来，通常很方便。换成大量 Agent 和检查程序不断开工，局面就不同了：很多任务可能花时间在准备文件、获取版本记录和等待整合上。
一个辅助任务只想查文章标题。如果它每次开工都先准备一大套不相关的文件，真正做事之前就已经花了不少时间。同样的准备重复很多次，总消耗就会变得可观。
解决方向有三个：不需要的内容少拿，大家都要的内容复用，查询历史时尽量由服务直接回答。这是理解 Scion 的入口。
每个任务各自准备
相同内容的准备工作重复发生
相同内容可以复用
- 任务 A按需读取
- 任务 B按需读取
- 任务 C按需读取
把可复用内容留给后续任务使用
读图：看右边的一分多：几个任务都需要同一版本的文章目录时，可以复用已经取得的内容。
两边展示的是两种准备方式，实际收益取决于任务、版本和缓存情况。Git 也有减少重复获取的功能。
Anthropic 披露，其日均合并量从 5 月约 2,500 次增至 9 月超过 3 万次；自动构建和测试流程（常称 CI）每天取出已有代码版本约 2,500 万次。[1]后一个数字统计的是取用次数：同一个版本可以被不同任务反复取用。
次数足够多时，每次取文件、准备工作目录省下一点时间，加起来也可能有可观收益。这就是它重做代码基础设施的背景。
Git 本身已有减少下载与减少工作目录文件的功能。[2][3]所以，判断自己的项目需不需要变化，先看时间究竟花在准备、执行还是返工上。
少搬文件，少重复劳动
接着图 02，把省下的准备工作拆成三件事。
这里的“缓存”，就是暂存已经取得的内容。后续任务需要同一份内容时，可以从近处复用。
- 只拿这次任务需要的材料。修一个页面，不必让每项辅助任务都提前拿到不相关的内容。
- 拿过的材料尽量复用。同一批机器上的任务，需要同一份内容时，可以从已有缓存中获取。
- 只想查一件事，就直接提问。例如查询某个版本的历史信息，可以由版本服务回答。
这三步主要改善的是“拿材料和管记录”的成本。Agent 是否能把功能写对，还需要需求、上下文和验证来保证。
展开技术细节：文件经过哪些服务器
下面的图沿着“需要一份文件内容”这个请求往下看：当前机器有就直接使用，没有就继续向下一层查找。daemon 是机器上的常驻程序，cache 就是缓存。
官方设计把保存版本、合并、变基和历史查询放到服务端。变基可以理解为：以更新后的共同版本为起点，重新接上自己的修改。客户端按需取得文件内容；内容经过节点、区域缓存和版本服务，后面连接 Spanner 数据库与文件存储。[1]
这台机器已有所需内容，可以直接使用；同一机器上的其他任务也有机会复用它。
原理解释 系统给一份固定内容一个对应标识，缓存就能认出它并复用。“固定内容”与“当前使用哪个版本”是两件事：内容可以复用，当前版本仍要按规则更新。Git 也会按内容标识数据。[4]
本文判断 工作机器做的事情少了，服务器就要承担更多责任。评估时要看断网能否工作、服务器故障怎样恢复、谁能读取哪些代码。缓存为空或失效时，后面的服务也得承受突然增加的读取请求。
它怎样记住每次修改
可以把“记账”和“查账”分开想。
Agent 改了文章标题和目录。你需要保存这次修改；过几天，又可能想问：“是谁改的？”“这次修改之前是什么样？”如果当时还写下了修改说明，以后也能查到为什么改。
保存修改，是记账；快速回答这些问题，是查账。系统先保留修改记录；以后你按文件或版本提问，就可以找到相关变化。技术细节中的“索引”，作用类似书后的检索表。
- 先记录一轮修改例如：文章标题和目录同步更新
- 后来问一个问题例如：标题上次是谁改的
- 查询相关版本记录找到作者与修改前后的内容
读图：先有这轮修改的记录，之后才能据此查到“谁改了标题、改成了什么”。
这是“保存记录—提出问题—查到记录”的概念示意，省略具体查询算法和接口。
这个比喻也帮助你理解一个常见误会：Git 保存一个新版本，不等于把整个项目重新复制一次。它会复用未变化的内容。[4]
展开技术细节：变更记录、内容对象和索引
Scion 把一次修改记为 changeset（变更记录），记录它相对前一个直接基础版本（第一父节点）改了哪些文件，以及到哪里读取对应内容。为了快速查“某行最后是谁改的”（blame）或某个文件的历史，再维护额外的查询结构。[1]
假设搜索页面和查找程序一起改变。系统先记录这两个文件的变化；以后查“某行是谁改的”时，可以使用索引快速定位相关记录，不必每次从头查看全部历史。
理解 Git 时也要避免另一个误区：提交描述一棵目录树，不等于每次把全仓库重新复制一遍。Git 里，commit 是一条版本记录，tree 描述目录结构，blob 保存文件内容；未变化的内容可以复用。[4]因此，把两者简单说成“Git 存全量、Scion 存增量，所以提速”并不充分。
本文判断 值得借鉴的是：可靠保留版本记录，查询用的索引则可以改进或重新生成。评估时还要确认，索引重建期间能查到什么、权限变化后谁可以看到哪些记录，以及失败后是否能正确恢复。
提速数字该怎么理解
先问“哪个环节快了”，再问“对我有没有用”。
先区分两个环节：准备代码，是把任务需要的文件取到工作目录；处理任务，是 Agent 用这些文件实现功能。官方的检出提速，说的是前一个环节。“检出”就是把某个版本的文件准备好。
下面还涉及 CPU，也就是机器执行计算的处理器。CPU 和内存用量，描述的是机器资源需求。
| 官方披露 | 比较的是什么 | 怎样理解 |
|---|---|---|
| 代码服务的 CPU、内存需求约为原来的 1/200 | 此前用于分发 Git 代码的那套服务 | 这部分机器资源更省；完整费用还要看数据库、网络和运维等开销 |
| 准备代码快约 100 倍 | 其自动构建测试及研究任务；由分钟级到秒级 | 缩短的是取得代码的等待；原文称“两个数量级” |
| 自动构建测试流程获得 25% CPU 容量收益 | 官方描述的该流程机器资源收益 | 具体任务能快多少，仍需另行测量 |
这些数字来自 Anthropic 自己的环境。对你来说，更有用的问题是：一次 Agent 任务的大头时间花在哪里？如果主要耗在理解需求、等待模型或返工，就应该先改善那些环节。
展开口径说明：这些数字还缺哪些验证
本文判断 评估架构迁移，至少要补齐三个维度：同一工作负载下的端到端延迟、完整资源账单、失败后的恢复代价。平均值下降，也可能伴随少数冷缓存任务变慢；CPU 减少，也可能换来数据库、网络或运维成本。这些都是应该验证的问题，不是已经发生的 Scion 缺陷。
本次材料没有提供可供外部复现的完整环境、数据集与成本拆分。因此，报告采用“官方披露”的表述，不把这些数值升级为独立测量结论，也不据此推算你的项目能节省多少。
能合并，不代表能用
版本系统能帮忙组合文件，实际效果仍要验证。
- 两人改同一段文字出现无法直接组合的修改
- 合并时发现冲突需要决定保留什么
- 处理后再检查确认组合结果符合预期
- 链接规则与搜索不一致一边改了格式，一边仍用旧规则
- 文本仍可合并合并操作可能不报错
- 点击结果却打不开实际使用才暴露问题
读图：上排在组合文件时卡住；下排可能顺利组合文件，却在运行搜索时出错。所以，合并后还要验证功能。
自拟的学习室示例，用于解释文本冲突与功能不一致；不是 Scion 专有流程。
以这个搜索任务为例，“代码写完”“修改能合并”“搜索能运行”“读者点得开”要分别确认。图 05 把这些确认串成一条流程。
Anthropic 在大量修改同时产生的场景下，更重视合并后、发布前的验证。[1]对当前的小团队，我建议保留关键检查，明确谁负责合并修改，以及用什么结果证明功能可用。
- Agent 完成修改先得到代码或文件
- 测试与评审运行检查，再核对是否符合需求
- 合并后再验证和其他修改放在一起，功能仍能工作
- 发布后实际验收需要发布时，打开正式网站试一遍
↺ 发现问题：修复后，重新运行受影响的检查
读图：每个箭头都多完成一层检查；发现问题，就修复相关修改，再重跑受影响的检查。
给个人和小团队的建议流程，按项目调整检查和存档时机；发布只在任务需要时进行。
继续了解：GitHub 怎样检查待合并的修改
GitHub 的合并队列会针对最新目标分支及队列中相关修改运行必要检查；严格状态检查也可以要求分支与目标保持同步。[5]是否调整检查时机，需要同时考虑吞吐、失败后果和恢复能力。
Git 也能处理大项目
遇到多人协作或项目变大，可以先用好已有能力。
Git 也有按需下载文件、只展开部分目录等功能，同一个仓库还可以配合多个工作目录使用。[2][3][8]如果以后取代码、准备目录真的占用了很多时间，可以先评估这些办法。
对你目前让 Agent 修改学习室这类项目，我建议先保留 Git，明确任务和验收方式。若以后测到准备代码确实很慢，再针对那个环节优化。
继续了解：Google、Meta 和 Scion 的大仓库思路
| 系统 | 可以确认的特征 | 阅读启发 |
|---|---|---|
| Git | 内容寻址对象；支持 partial clone 与 sparse checkout [2–4] | 先区分对象获取、工作目录与协作流程 |
| Google 大仓库体系 | Google 研究论文讨论单一代码源及配套工具的利弊 [6] | 大仓库的收益依赖工程系统共同支撑 |
| Meta Sapling | 为大仓库演进，公开客户端也可操作 Git 仓库 [7] | 用户体验和底层仓库格式可以分别演进 |
| Anthropic Scion | 针对 Agent 与作业负载的内部服务化版本控制 [1] | 重新审视机器任务反复承担的准备成本 |
Sapling 官方还明确提到，其部分设计面向公司内部、持续联网、单一主线的大仓库环境。[7]这提示我们：环境假设决定一种设计是否合适。“集中管理”与“分布式”都不能单独回答性能和可靠性问题，还要看读写路径、缓存、权限与团队工作方式。
本文判断 Scion 带来的观察窗口，在于 AI 生成修改的速度可能迫使评审、测试、代码分发一起演进。它并不证明此前的大仓库技术失效，也不能证明所有团队都会走向同一种架构。
你现在可以怎么用 Agent
把启发落到下一次给 Agent 的任务里。
先说清楚什么叫做完
继续用搜索功能举例。与其只说“加个搜索”，不如说清楚：输入关键词后要找到哪些文章，结果显示什么，点击后应打开哪里。完成条件越具体，越容易判断 Agent 有没有做对。
能独立交付，再拆开并行
查资料和制作一个独立示例，通常比较容易分开；两个 Agent 同时改同一页面，就可能互相覆盖。需要并行改代码时，可以让每个任务使用独立工作目录，并指定由谁整合结果。
工作目录可以理解成 Agent 实际编辑的一份项目文件。Git 的 worktree 功能能给不同任务建立各自的工作目录，分开保存编辑状态；部分仓库数据仍共享，也不会自动限制 Agent 的文件访问权限。[8]你可以让 Codex 处理设置，自己重点说明谁负责哪些修改。
- Agent A · 做搜索框独立工作目录
负责读者看见和点击的部分 - Agent B · 做查找规则独立工作目录
负责找出哪些文章、怎样排序
读图：中间分叉表示两项工作分别推进；下方汇合表示合并到同一个版本，再一起检查完整搜索功能。
示例先约定两项工作怎样连接、谁改哪些文件，再分别推进。独立目录分开编辑状态，仍需合并与验证。参见 [8]。
先看时间花在哪
是环境和代码准备慢，还是任务说不清导致反复重做？先分清再处理。只有大型仓库的准备成本真的成了问题，才值得进一步考虑按需下载、目录裁剪等优化。[2][3]
小步存档，再真正验收
一次围绕一个明确目标修改，完成后保存一个清楚的版本，方便查原因和退回。页面任务要看浏览器里的实际效果；涉及上线，就检查正式链接。验证过的代码后来又变了，应判断哪些检查需要重做。
假设下一次要改进搜索，可以这样描述任务
目标：输入关键词后，能从学习室文章标题中找到匹配文章。
范围：修改搜索相关部分，保留已有文章链接和阅读页面。
完成条件：结果显示文章标题；点击可打开正文；没找到时有明确提示。
验证：在电脑和手机上各试一次“能找到”和“找不到”的情况，逐个点击结果检查。
对你现在最实用的启发：把任务讲清楚，把同时进行的修改分开，再用实际结果验收。Git 已经能支持这样的工作方式。
你现在能用上 Scion 吗
把官方内部系统与网上同名项目区分开。
目前的官方公告没有提供通用安装包、源码入口或服务接入方式。Anthropic 也明确表示，Scion 面向特别大的代码库，采用它涉及评审、搜索和自动测试等整套流程。[1]
所以，你今天学到的可以先是工作方法。使用 Agent 不要求先安装 Scion；网上搜到同名工具，也应先核对是谁做的、解决什么问题。
同名 Google Scion 是另一个项目
GoogleCloudPlatform/scion 是开源 Agent 协作编排平台，与这里讨论的 Anthropic 版本控制系统不同。搜索结果中出现容器、Agent harness 和编排 CLI 时，应先核对组织与功能。[10]
社区 open_scion 链接已发生跳转
2026-10-18 核对时，feder-cr/open_scion 跳转至 feder-cr/git-ai，README 使用 gitai 名称，声明是独立实现、未获 Anthropic 背书。本文没有运行或审计该项目，不将其功能、正确性或基准结果归于 Anthropic。[9]
还缺少哪些能改变判断的证据
外部可复现的负载与性能测试；完整成本组成；延迟分布与冷缓存表现；故障恢复目标和演练记录；权限模型与迁移工具细节。公开资料未披露这些，不代表系统没有实现，只意味着本报告不能独立验证。
想继续了解，可以读什么
先读 Anthropic 原文；想学实际操作，再看 Git 官方资料。
- Anthropic · Redesigning source control at Anthropic2026-10-13 发布，10-15 更新。Scion 负载、设计、性能口径与适用边界的主来源；属于官方自述。
- Git · Partial Clone说明对象按需获取及联网依赖，帮助区分“完整克隆”与 Git 现有优化能力。
- Git · git-sparse-checkout工作目录稀疏化，与减少已下载对象不是同一件事。
- Pro Git · Git Objectscommit、tree、blob 与内容寻址的原理，支持“快照不等于重复复制全仓库”的解释。
- GitHub Docs · About protected branches严格状态检查与合并队列的工作方式，帮助理解吞吐与验证时机的选择。
- Google Research · Why Google Stores Billions of Lines of Code in a Single Repository2016 年论文索引与摘要，用于大仓库工程的历史背景；没有把历史规模数值当作当前指标。
- Meta · Sapling SCM Introduction大仓库设计起点、Git 互操作与环境假设；不用于证明 Scion 的性能。
- Git · git-worktree多工作目录的隔离范围和共享状态。
- feder-cr/git-ai · 项目 README仅用于核对社区项目身份、名称与独立声明，未验证其实现或宣传指标。
- GoogleCloudPlatform/scion · 项目 README仅用于同名消歧，与 Anthropic 内部 Scion 的架构及指标无关。
方法：查阅公开官方公告、项目维护者文档及 Git 官方资料；未访问 Anthropic 内部代码或基础设施。图示为自行重绘的逻辑说明，例子为明确标注的解释场景。没有使用搜索摘要替代主来源，也没有把社区项目当作官方开源版。