北京
Git 是为人类开发者设计的。这句话听起来像常识，但 Anthropic 发现，当提交代码的主体从人变成 Agent，这套常识就失效了。
他们把源码控制系统从 Git 迁走了，换成一套内部构建的平台。原因不复杂：每天数万次的代码合并请求，原来的集中式模型扛不住。
瓶颈不在代码量，在提交者的数量级
传统 Git 基础设施的假设是：一个仓库背后是几个、几十个人类开发者。Anthropic 面对的场景是成百上千个 Agent 同时提交代码。这个数量级的差异，直接暴露了两个硬伤——集中式锁，以及单机读取限制。
用他们自己的话说：“We became bottlenecked by developer infrastructure built for human (rather than agent) scale.” 被为人类规模设计的开发基础设施卡住了脖子。
这不是性能调优能解决的问题。锁的粒度、读取的路径、权限的边界，全都建立在“人不会同时干这么多事”的前提上。
新系统长什么样
迁移后的平台是一个服务端中心、REST API 驱动的系统，后端用 MySQL。架构上有一句关键描述：中央服务器编排访问和状态，客户端（也就是 Agent）对数据做只读操作。
几个设计选择值得注意：
- 稀疏访问模型：Agent 可以只读取部分数据，不需要加载整个仓库图
- 严格权限治理：用来防止恶意操作
- 异步处理 + 分布式读取 + 优化的二进制序列化格式：支撑极高的请求速率
稀疏访问这一条，针对的正是 Agent 的工作方式。人类开发者习惯 clone 整个仓库再动手，Agent 不需要——它只需要拿到当前任务相关的那部分数据。省掉全量加载，吞吐量才有空间。
压力测试给出的答案
在内部压力测试中，这套系统证明了比传统 Git 解决方案更具可扩展性。注意这里的措辞是“更具可扩展性”，不是“更快”——它解决的是能不能撑住的问题，而不是单次操作快几毫秒。
把这件事放到更大的背景里看：当开发流程的执行者从人变成 Agent，被重构的不会只有源码控制。代码托管、CI、评审、权限体系，每一层都建立在“人类速度”的隐含假设上。Anthropic 先动的是最底层的那一块。
这套系统目前是内部构建、内部使用。它会不会成为某种范式，取决于有多少团队会走到“成百上千个 Agent 同时提交代码”这一步。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
