Anthropic 重新设计源代码控制系统

在 AI 公司中，源代码管理不只是工程基础设施，更是模型训练、产品迭代和安全合规的交汇点。Anthropic 最近分享了其重新设计内部源代码控制系统的实践，引发了 Hacker News 上少量但值得关注的讨论。

为什么 Anthropic 要重新设计源代码控制

据 Hacker News 上的讨论，Anthropic 的工程团队对现有源代码控制方案进行了重构。虽然目前公开的信息有限，评论数为零，但从标题和背景可以推断，这一举措并非简单的工具替换，而是针对 AI 研发流程中特有痛点的系统性调整。

传统源代码控制系统围绕人类开发者的协作模式设计：分支、合并、代码审查、持续集成。但 AI 公司的研发流程有额外维度——训练数据的版本化、模型权重的追踪、实验配置的可复现性，以及对大规模并行实验的支持。当这些需求叠加在传统 Git 工作流之上时，工程团队往往会遇到瓶颈。

Anthropic 选择重新设计而非打补丁，说明其现有方案已经触及架构层面的限制。

AI 研发对源代码控制的特殊要求

从 Anthropic 的业务性质出发，可以梳理出几个关键技术需求。

实验可复现性是核心挑战之一。AI 研究涉及大量超参数调整和消融实验，每次实验都对应特定的代码版本、数据版本和配置组合。传统 Git 提交无法自然表达这种多维版本关系，研究者经常需要手动记录实验与代码的对应关系，效率低且容易出错。

大规模并行分支是另一个痛点。AI 团队可能同时运行数十个实验分支，每个分支的生命周期短、变更频繁。Git 的分支模型在这种场景下会产生大量合并冲突和分支管理开销，拖慢研究节奏。

安全与合规的要求同样不可忽视。Anthropic 以 AI 安全为核心使命，其代码库中可能包含敏感的训练方法、安全护栏逻辑和评估工具。源代码控制系统需要在不牺牲开发效率的前提下，提供细粒度的访问控制和审计能力。

多维版本化是理解 AI 研发版本控制困境的关键概念。在传统软件中，一次构建的产物由代码版本唯一确定；而在 AI 训练中，一个模型由代码、训练数据、超参数配置、随机种子乃至依赖库版本共同决定。这构成了一个多维笛卡尔积式的版本空间，任何一维的变化都会产出不同的模型。Git 只能对代码这一维做精确追踪，数据和配置往往散落在对象存储、配置文件或实验管理平台中，导致“复现某次实验”变成一项需要人工拼凑的考古工作。业界因此出现了 DVC、LakeFS、Weights & Biases Artifacts 等工具，试图用内容寻址（content-addressing）方式把数据与配置纳入版本体系，但其与 Git 的集成仍不够自然，这也是 AI 公司常自研一体化方案的原因之一。

内容寻址存储（Content-Addressed Storage） 是许多现代版本控制系统（包括 Git 本身）的底层机制：文件不以路径名标识，而以内容哈希值（如 SHA-1/SHA-256）标识，相同内容自动去重，任意历史版本可精确定位。这一机制对 AI 场景很有吸引力，因为数据集和模型权重往往体积巨大且版本众多，重复存储成本高昂。但纯内容寻址也带来挑战：大文件哈希计算耗时、垃圾回收复杂、与人类可读的分支命名语义存在张力。Perforce、Sapling 等系统在大规模二进制资产管理上做了针对性优化，这也是头部 AI 公司在选型时会权衡的方向。

对行业的启示

Anthropic 的实践反映了一个更广泛的趋势：AI 公司正在重新审视那些被认为“已解决”的基础设施问题。源代码控制经过数十年发展，已经被视为成熟领域，但 AI 研发的特殊性暴露出传统工具的不足。

这种重新设计可能会影响其他 AI 公司的技术选型。当头部实验室公开分享其内部工具链的改造经验时，往往会推动整个行业对最佳实践的重新思考。不过，由于目前公开信息有限，具体的架构决策和技术选型尚不明确，实际效果也有待观察。

对于中小型 AI 团队而言，直接复制 Anthropic 的方案未必合适，但其问题定义方式值得借鉴——先识别工作流中的真实摩擦点，再评估现有工具是否能够解决，最后才考虑自研。

值得注意的是，Anthropic 并非孤例。Meta 开源的 Sapling 正是为应对超大规模单体仓库和数十亿文件的历史而重建的 Git 兼容客户端；Google 的 Piper 与 CitC 工作流则支撑着数万名工程师在同一代码库上并行协作。这些案例共同指向一个判断：当代码库规模、协作人数或产物复杂度越过某个阈值时，Git 的分支模型与分布式假设会成为瓶颈，需要重新设计传输协议、存储后端或工作区抽象。AI 公司虽然人数未必达到巨头的量级，但其数据与模型资产的体量可能更快触及这类限制，因此“重新设计”在这一行业出现的频率可能高于传统软件公司。