Signal #34：源码管理也在为 Agent 重新设计

整理本期周刊时，Anthropic 的一篇源码管理复盘让我停了下来。

它披露，单体仓库每天合入的变更，从 5 月约 2,500 项增加到 9 月超过 30,000 项。团队为此开发了新的源码管理系统 Scion。

第一眼看，这很容易被理解成一个熟悉的故事：代码写得更多，后面的系统跟不上，需要扩容和优化。

但读到具体设计时，我更在意另一个细节：他们重新考虑了源码管理系统的主要使用者。

大量在线 Agent 和自动化任务访问仓库，与一个工程师长期使用自己的开发目录，对工具会提出不同要求。我想从这次复盘里继续追下去的，就是这些差别。

先设想一个简单场景：让 Agent 查清某项配置最近为什么发生变化。

任务最终需要的，可能只是几个提交之间的差异，以及一段文件历史。如果执行入口只有“准备一个代码目录，再在里面运行命令”，获取仓库、检出文件和初始化本地状态，就成了查明问题之前的准备工作。

换成修复代码，准备工作当然仍有必要。Agent 要读取相关实现，运行测试，检查修改后的行为。问题在于，不同任务需要的数据和执行条件并不相同。

工程师长期使用同一个目录时，许多准备成本可以被后续工作摊薄。自动化系统如果为每个任务新建环境，又频繁销毁和重试，就可能多次支付类似的成本。这里讨论的是一种执行方式，并非所有 Agent 都如此运行。

图 1：重复准备如何随任务增加而累积。作者绘制的示意场景，不是 Anthropic 的性能测量。

任务越短，准备过程在总耗时中的占比就越值得检查。 一个只需查询少量信息的任务，也可能被安排了一套远超自身需要的初始化流程。

这提供了一种看研发工具的方式：除了统计任务完成得多快，还可以检查每次开始工作之前，系统到底重复准备了什么。

在 Scion 的公开设计中，历史查询、提交、合并等操作由服务端处理；客户端按需获取文件，部分任务可以直接通过 API 工作，无需准备本地仓库。它把“客户端在线”作为明确的设计条件。[1]

这组设计可以用两类任务来理解。下面是对访问方式的解释，不是原文中的实际任务记录。

第一类任务，需要一个查询结果。

例如比较两个提交、查询某个文件的历史。如果服务端能够基于明确的版本返回结果，调用方就可以直接消费这些信息。是否还要创建本地仓库，取决于它接下来要做什么。

第二类任务，需要真正执行代码。

例如运行测试、修复模块。这样的任务仍然需要文件、依赖和可运行的工作区；按需获取可以减少不必要的数据准备，却不能替代完整的执行条件。

图 2：基于公开设计绘制的访问路径示意，省略了 Scion 的存储与缓存拓扑。构建、测试仍需要相应代码和依赖。

对我而言，这里有价值的设计问题是：一个任务究竟需要某些文件、一段可验证的信息，还是一个能够运行代码的环境？

如果这些需求始终通过同一种入口满足，工具就可能承担额外的传输和初始化工作。把需要的能力表达清楚，才有机会针对不同任务减少开销。

理解这些设计，还需要把它们放回源码管理已有的技术积累中。

Git 的部分克隆文档已经明确：仓库可以先省略部分对象，在后续操作真正需要时再获取。缺失对象需要远端提供，使用时也要考虑网络与服务的可用性。[2]

稀疏检出解决的是相关但不同的问题：让工作目录只呈现选定的一部分文件。减少下载哪些对象，与减少检出哪些文件，需要分别理解。[3]

Meta 在 2022 年介绍 Sapling 时，也已经讨论了按需下载历史、文件和目录，以及虚拟文件系统与服务端查询。这些探索服务于大型仓库的规模问题，早于今天这一轮 Coding Agent 的应用。[4]

因此，Scion 的价值不能简单概括为“Agent 发明了按需取文件”。

我更愿意把它看成一个新的观察样本：已有的源码管理技术，如何在高强度自动化工作负载下被重新组合和取舍。Anthropic 自己也明确说明，Scion 面向特殊规模，并不适合作为通用 Git 替代品。[1]

这里需要保留两层判断：技术有历史积累；主要使用者和工作负载的变化，仍可能改变系统的设计重点。

绝大多数团队距离这种规模还很远。读完这篇复盘，我首先想做的，是把自己的 Agent 执行过程看得更细一些。

一次任务的时间，可以先按实际过程拆开记录：获取代码、准备依赖、理解与修改、运行验证。再检查重试时哪些步骤被重新执行，哪些结果能够复用。

这样才能定位投入方向。如果大部分时间花在理解业务，换一种仓库获取方式未必有明显帮助；如果短任务反复消耗在准备环境，缓存、快照或工作区复用才值得进一步验证。

同时，还要看任务是否总在获取超出需要的信息。一个只读查询可以先尝试明确的查询接口；需要构建和测试的任务，则必须把依赖范围与执行条件补齐。这里的目标是减少重复劳动，并保留验证结果所需的依据。

复用也有边界。可以优先复用固定版本的数据和准备结果，写入工作区仍需要控制相互影响。 多个 Agent 共用一个可能被修改的目录，虽然省去了一部分准备，却可能引入文件覆盖和状态串扰。

工具选择之前，还应把这些条件写清楚：任务基于哪个提交，结果对应哪个版本，谁有权读取文件，网络失败后如何恢复。把操作放到远端，会让服务可用性与权限控制更直接地进入任务执行过程。

这些是我从案例中得到的工程检查方向，是否值得建设，需要用自己团队的任务记录判断。

Scion 让我们看到了一个具体变化：当在线 Agent 和自动化任务成为主要使用者，开发工具需要重新考虑数据怎样提供、操作在哪里完成，以及哪些准备值得复用。

Agent 的运行规模与访问方式，正在影响底层研发工具的设计。 接下来值得观察的，是这些调整能否在更多真实工作负载中成立。

参考资料