ARTICLE · 1234291
Signal #34:源码管理也在为 Agent 重新设计
Signal #34｜当大量 Agent 和 CI 任务持续读写代码，准备仓库的开销也会被反复放大。Anthropic 的 Scion 提供了一个具体案例：让查询在服务端完成，让文件按需进入执行环境。它值得关注的地方，是 Agent 的工作方式如何影响研发工具的设计。
整理本期周刊时，Anthropic 的一篇源码管理复盘让我停了下来。
它披露，单体仓库每天合入的变更，从 5 月约 2,500 项增加到 9 月超过 30,000 项。团队为此开发了新的源码管理系统 Scion。
第一眼看，这很容易被理解成一个熟悉的故事：代码写得更多，后面的系统跟不上，需要扩容和优化。
但读到具体设计时，我更在意另一个细节：他们重新考虑了源码管理系统的主要使用者。
大量在线 Agent 和自动化任务访问仓库，与一个工程师长期使用自己的开发目录，对工具会提出不同要求。我想从这次复盘里继续追下去的，就是这些差别。
一次小任务，可能先付出一笔准备成本
先设想一个简单场景：让 Agent 查清某项配置最近为什么发生变化。
任务最终需要的，可能只是几个提交之间的差异，以及一段文件历史。如果执行入口只有“准备一个代码目录，再在里面运行命令”，获取仓库、检出文件和初始化本地状态，就成了查明问题之前的准备工作。
换成修复代码，准备工作当然仍有必要。Agent 要读取相关实现，运行测试，检查修改后的行为。问题在于，不同任务需要的数据和执行条件并不相同。
工程师长期使用同一个目录时，许多准备成本可以被后续工作摊薄。自动化系统如果为每个任务新建环境，又频繁销毁和重试，就可能多次支付类似的成本。这里讨论的是一种执行方式，并非所有 Agent 都如此运行。
图 1：重复准备如何随任务增加而累积。作者绘制的示意场景，不是 Anthropic 的性能测量。
任务越短，准备过程在总耗时中的占比就越值得检查。 一个只需查询少量信息的任务，也可能被安排了一套远超自身需要的初始化流程。
这提供了一种看研发工具的方式：除了统计任务完成得多快，还可以检查每次开始工作之前，系统到底重复准备了什么。
查询与执行，可以需要不同的入口
在 Scion 的公开设计中，历史查询、提交、合并等操作由服务端处理；客户端按需获取文件，部分任务可以直接通过 API 工作，无需准备本地仓库。它把“客户端在线”作为明确的设计条件。[1]
这组设计可以用两类任务来理解。下面是对访问方式的解释，不是原文中的实际任务记录。
第一类任务，需要一个查询结果。
例如比较两个提交、查询某个文件的历史。如果服务端能够基于明确的版本返回结果，调用方就可以直接消费这些信息。是否还要创建本地仓库，取决于它接下来要做什么。
第二类任务，需要真正执行代码。
例如运行测试、修复模块。这样的任务仍然需要文件、依赖和可运行的工作区；按需获取可以减少不必要的数据准备，却不能替代完整的执行条件。
图 2：基于公开设计绘制的访问路径示意，省略了 Scion 的存储与缓存拓扑。构建、测试仍需要相应代码和依赖。
对我而言，这里有价值的设计问题是：一个任务究竟需要某些文件、一段可验证的信息，还是一个能够运行代码的环境？
如果这些需求始终通过同一种入口满足，工具就可能承担额外的传输和初始化工作。把需要的能力表达清楚，才有机会针对不同任务减少开销。
Git 和 Meta，早就在解决类似问题
理解这些设计，还需要把它们放回源码管理已有的技术积累中。
Git 的部分克隆文档已经明确：仓库可以先省略部分对象，在后续操作真正需要时再获取。缺失对象需要远端提供，使用时也要考虑网络与服务的可用性。[2]
稀疏检出解决的是相关但不同的问题：让工作目录只呈现选定的一部分文件。减少下载哪些对象，与减少检出哪些文件，需要分别理解。[3]
Meta 在 2022 年介绍 Sapling 时，也已经讨论了按需下载历史、文件和目录，以及虚拟文件系统与服务端查询。这些探索服务于大型仓库的规模问题，早于今天这一轮 Coding Agent 的应用。[4]
因此，Scion 的价值不能简单概括为“Agent 发明了按需取文件”。
我更愿意把它看成一个新的观察样本：已有的源码管理技术，如何在高强度自动化工作负载下被重新组合和取舍。Anthropic 自己也明确说明，Scion 面向特殊规模，并不适合作为通用 Git 替代品。[1]
这里需要保留两层判断：技术有历史积累；主要使用者和工作负载的变化，仍可能改变系统的设计重点。
对自己的团队，先把准备成本量出来
绝大多数团队距离这种规模还很远。读完这篇复盘，我首先想做的，是把自己的 Agent 执行过程看得更细一些。
一次任务的时间，可以先按实际过程拆开记录：获取代码、准备依赖、理解与修改、运行验证。再检查重试时哪些步骤被重新执行，哪些结果能够复用。
这样才能定位投入方向。如果大部分时间花在理解业务，换一种仓库获取方式未必有明显帮助；如果短任务反复消耗在准备环境，缓存、快照或工作区复用才值得进一步验证。
同时，还要看任务是否总在获取超出需要的信息。一个只读查询可以先尝试明确的查询接口；需要构建和测试的任务，则必须把依赖范围与执行条件补齐。这里的目标是减少重复劳动，并保留验证结果所需的依据。
复用也有边界。可以优先复用固定版本的数据和准备结果，写入工作区仍需要控制相互影响。 多个 Agent 共用一个可能被修改的目录，虽然省去了一部分准备，却可能引入文件覆盖和状态串扰。
工具选择之前，还应把这些条件写清楚：任务基于哪个提交，结果对应哪个版本，谁有权读取文件，网络失败后如何恢复。把操作放到远端，会让服务可用性与权限控制更直接地进入任务执行过程。
这些是我从案例中得到的工程检查方向，是否值得建设，需要用自己团队的任务记录判断。
Scion 让我们看到了一个具体变化：当在线 Agent 和自动化任务成为主要使用者，开发工具需要重新考虑数据怎样提供、操作在哪里完成，以及哪些准备值得复用。
Agent 的运行规模与访问方式，正在影响底层研发工具的设计。 接下来值得观察的，是这些调整能否在更多真实工作负载中成立。
参考资料
1. Anthropic：Redesigning source control at Anthropic，2026-10-13 发布，10-15 更新。文中的公司数据和 Scion 能力均来自其公开披露，本文未独立复现。 2. Git：Partial Clone。 3. Git：git-sparse-checkout。 4. Meta：Sapling: Source control that’s user-friendly and scalable，2022-11-15。
