Scion案例最值得借鉴的，不是“AI写代码多了就要换Git”，而是先问每个任务到底需要什么：只问一次差异，是否一定要准备工作区？只读取两个文件，是否一定要取完整快照？把这两件事分开，才看得清按需检出的节省来自哪里。

下面用一个可复现的字节模型比较全量、私有按需与共享按需三条路径，再讨论小文件往返、冷缓存和离线失败。数字全部是教学设定，不是Scion跑分。Read in English。

原文公布了什么

Google News收录的Anthropic原文发表于2026年10月13日，10月15日补充更新。公司介绍了内部源码管理系统Scion：将部分源码查询放在服务端，客户端按需取对象，并复用节点级缓存。原文明确说明它面向特殊的大型单仓库负载，不是通用Git替代品。

这是公司对自身系统的说明，不是独立测评。本文不复述其性能倍数，也不把内部案例推成迁移承诺。以下分流、成本公式和反例用于分析按需访问的取舍，并未运行Scion。

一个容易忽略的背景是：Git自身已有partial clone，允许先省略部分对象、需要时再从promisor remote获取。比较对象不应是“Scion按需”对“Git永远全量”，而应是具体工作负载与实际启用的能力。

有些任务根本不需要文件内容

查询某次改动涉及哪些路径，与执行编译器，不是同一种需求。前者可能由服务端直接返回元数据；后者通常需要文件字节。若流水线先无条件创建工作区，再判断任务类型，就已经付出了可能不必要的下载和落盘成本。

这并不意味着所有diff都不读取内容。只列路径、生成逐行补丁、计算语义差异，对数据的要求不同。应把请求说清楚，再决定它能否由查询接口完成；不能看到“metadata”这个词就假定成本为零。后面的空读取集只表示没有文件内容载荷，并不表示查询请求没有字节或计算成本。

对于确实需要运行的任务，也应区分声明目录与实际读取。目录范围可以减少搜索空间，但构建脚本、导入、生成器与配置可能把读取范围扩大。一个只看源文件名的过滤规则，不等于已经掌握了完整依赖。

四个对象，算清三种传输量

设一个固定版本只有四个不可变内容对象：a为1 KiB，b为3 KiB，docs为8 KiB，vendor为16 KiB，总计28 KiB。两个任务都依次读取a、b、a；同一个a重复读取不应重复下载。这里的KiB严格等于1024字节。

若每个任务都取完整快照，总内容量是56 KiB。若每个任务拥有空的私有按需缓存，两次各取4 KiB，共8 KiB。若两个任务使用相同对象标识、共享一个不驱逐的节点缓存，第一次取4 KiB，第二次内容命中，共4 KiB。

这个对照刻意只算内容载荷，没有压缩、目录树、索引、权限查询、请求头、磁盘写入与重试。它说明需求集和复用范围影响字节量，不能据此断言真实传输一定节省相同比例，更不能直接换算为耗时倍数。

八项检查复现字节模型

代码用对象名作为固定版本的教学标识，大小来自上面的人工设定。dict.fromkeys先消除同一任务内的重复读取，再排除已有缓存对象。真实系统应使用对应版本的不可变内容标识，而不是把会变的路径名直接当缓存身份。

# Payload accounting model, not Git or Scion execution.
sizes = {"a": 1024, "b": 3072, "docs": 8192, "vendor": 16384}
reads = ("a", "b", "a")

def fetch(read_set, cache):
    misses = [k for k in dict.fromkeys(read_set) if k not in cache]
    cache.update(misses)
    return sum(sizes[k] for k in misses), len(misses)

assert sum(sizes.values()) == 28*1024
cache = set()
assert fetch(reads, cache) == (4*1024, 2)
assert cache == {"a", "b"}
assert fetch(reads, cache) == (0, 0)
assert fetch((), set()) == (0, 0)
private = sum(fetch(reads,set())[0] for _ in range(2))
shared = set()
shared_bytes = sum(fetch(reads,shared)[0] for _ in range(2))
assert private == 8*1024
assert shared_bytes == 4*1024
assert 2*sum(sizes.values()) == 56*1024
print("8 payload checks passed")

八项检查已本地执行，覆盖全量大小、首次缺失、重复读取、空读取集，以及两个任务使用私有或共享缓存的差异。共享命中只在本例固定版本、相同内容、不驱逐的前提下成立。代码没有调用Git、网络或Scion服务。

字节少了，为什么可能更慢

一个粗略的串行模型是：内容传输耗时约等于B/v，外加k次未被隐藏的请求往返、服务端处理与本地写入。B是传输字节，v是有效传输速率，k是关键路径上的请求次数。按需访问减少B，却可能增加k；不能只盯着下载量。

设程序边执行边发现下一个文件，且每次缺失都必须等待远端。即使每个文件很小，依赖链仍会串行等待。能提前发现的一组对象若批量预取，可能减少等待；但把所有对象都预取，又会失去按需策略的主要收益。

因此要记录冷启动与热缓存两种路径，并区分首次文件可用、全部必要文件可用、程序完成三个时间点。一个只测“工作区创建完成”的结果，可能把后续读取缺失的延迟藏到了编译或测试阶段。

共享缓存扩大了复用，也扩大了责任

共享只描述复用边界，不自动解决正确性与权限。缓存身份应包含稳定的内容版本，写入应防止半成品被当成完整对象；读取还要在正确的访问控制边界内进行；知道对象标识本身不应被当作获得读取权限。内容相同不能被解释成所有调用者都获准读取。

容量、驱逐与并发同样会改变前面的4 KiB结论。第二个任务若落在另一台节点，或对象刚被驱逐，就可能重新获取；多个任务同时发现缺失时，还需决定是否合并获取。教学代码的串行set没有演示这些行为。

这与此前Bazel缓存命中验证的问题不同：本篇先讨论任务需要哪些源码对象、代价发生在何时；命中是否对应正确身份，仍是下一层必须满足的条件。

在线依赖要进入失败设计

按需策略推迟获取，也推迟了发现“缺失内容不可用”的时刻。任务启动时服务可用，不保证五分钟后读取新对象时仍然可用。要区分缓存已有内容是否能继续读、缺失内容是否可重试、失败时是否保留已取得的数据。

Git partial-clone说明也明确提醒：补取缺失对象需要在线，并要求相应远端可用；离线前可以有针对性地预取。对按需方案，离线能力应通过明确工作集验证，而不是从“本地有工作区”推断。

读者真正需要比较的是端到端任务成功率、延迟和资源成本，而不是单个缓存命中率。这里没有真实统计；测量时应记录版本、读取范围、缓存温度、任务放置与网络条件，避免把不同条件混成一个平均值。

把案例转成自己的验证问题

先用现有流水线识别哪些任务只问源码问题，哪些必须执行程序；再记录它们实际读取的对象与重复程度。若绝大部分内容都会被读取，且任务频繁离线，按需方案的收益与代价可能和大型在线Agent集群完全不同。

可以先减少一次不必要的工作区创建，或试验可回滚的局部预取，不必从更换源码管理系统开始。最终判断应包含构建正确性、工具兼容、故障恢复和维护成本。Scion原文提供的是值得分析的设计取舍，而不是人人适用的迁移路线。

若这个字节模型和观察点帮你定位了CI检出的浪费或隐藏等待，欢迎通过文末支持区自愿支持。

来源与验证范围

于2026年10月17日核对Google News条目对应的10月13日原文及15日更新、Git partial-clone官方说明。两幅图、字节模型与代码为原创教学内容，八项检查本地通过；未验证Scion内部性能，也未测量真实Git检出、压缩率或网络延迟。