Git 基础设施重建智能体规模开发下的读写解耦原文GitHub Blog - 《Building Git infrastructure for agent-scale development》https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/写 Agent 的人平时关心模型、提示词和工具设计很少有人往下再看一层Agent 每跑一步都要 commit 或 checkpoint这些写请求最后落到了哪里。GitHub 在 10 月 6 日发布的这篇技术博客把这件事讲透了——它们落在 Git 的存储层而且所有写入都要挤过同一条需要达成一致的路径。作者 Brian Celenza 是负责 GitHub 存储与核心服务的首席工程师。这篇文章拆解三件事规模数字说明了什么、读好扩、写难扩在智能体场景下具体卡在哪、新架构用什么方法把两者解开。一、三组数字Agent 把写负载推到了什么量级原文给出的数字不多但每一组都指向同一个方向。指标变化时间口径月度 Git 事件量218.2 亿 → 473.3 亿2025 年 9 月 → 2026 年 8 月翻倍以上月度 commit 量73.8 亿次2026 年 9 月是一年前的 5 倍以上月度 push 量6.9 亿 → 33.5 亿同比增长 4.9 倍PR 合并量接近一年前的 4 倍—GitHub Actions 运行次数32.6 亿次2026 年 9 月是一年前的 4 倍以上顺手做个量级换算按 30 天口径把上面的月度数字摊到秒473.3 亿次 Git 事件约等于每秒 18 万次73.8 亿次 commit 约等于每秒 2847 次32.6 亿次 Actions 运行约等于每秒 1258 次。这不是峰值是平均值。原文还提到一个常被忽略的分布特征8 月份 GitHub 上最忙的那个仓库单月大约收到 10 亿次请求。也就是说头部仓库和普通仓库之间的差距比大多数人想象的要大得多——而智能体开发恰好集中在头部。二、五个具体的瓶颈规模本身不是问题问题在于这种负载的形态。原文列了五条每一条对应一个不同的压力点。单次 push 的延迟变成智能体的速度上限。Agent 在一个紧循环里几乎每做一个动作就 commit 或 checkpoint它的推进速度被一次 push 要多久完成卡住。人类完全感知不到的延迟在这里成了限制因素。写吞吐的需求涨了两个数量级。push 同比增长 4.9 倍而同一个仓库里可能有几千个 Agent 各自在自己的分支上写这些写入最终会汇聚到架构里的同一点。合并争抢同一个引用。Trunk-based 开发、发布列车、合并队列都会把全部工作挤到一个必须吸收每次合并的 ref 上。一次 push 会放大成几千次读。CI 和代码扫描每分钟会反复 clone 或 fetch 同一个分支尖端这个扇出必须足够廉价。仓库维护本身也在变贵。为了保持操作快GitHub 要持续做数据压缩和失效对象清理而每一次新写入都会增加这份工作成本随量级叠加。这五条放在一起能解释为什么把 clone 做快只解决了一部分问题读相对容易扩写难得多。读可以加缓存、加副本把同样的字节发给更多客户端写则必须先把数据持久化、并保证一致性可见后面的人和 CI 才能在此基础上继续构建。三、现在的架构为什么在头部仓库撞到天花板理解新架构得先理解旧架构的耦合点。现在每个仓库由 Spokes 存储它把一份完整的仓库副本放在若干台文件服务器的本地磁盘上默认是 5 份。本地快盘让 Git 操作能以低延迟读到原生仓库数据多副本既提供冗余也把读负载分散到不同文件服务器上。当一次 push 更新引用时用一个三阶段提交协议配合仲裁保证 CI、Web 界面和 API 客户端看到一致的仓库状态。这套组合目前支撑着十亿量级的仓库。问题出在一句话上持久化机制和扩展机制是同一个机制。磁盘上的那些副本就是事实来源所以增加读容量就等于增加一个持久化副本而每个副本都要参与每一次写于是加读副本会让写更慢。极端情况下加副本给写带来额外开销丢副本会减少读容量丢仲裁则直接停写。对绝大多数仓库来说这个权衡完全可接受只有活动量最高的那一小撮会撞到它。但智能体开发恰好都挤在那一小撮里。四、新架构的两条原则原文把方案归结为两条分布式系统设计原则。第一条最小化协调。一次 push 里真正需要所有副本达成一致的其实只有引用更新这一步。存储底层对象、校验对象连通性、密钥扫描这些工作量大得多但它们大多可以和其他写入并行进行。把需要协调的路径压缩到最小的那一步其余工作就不再拖慢响应。配套的另一件事是把维护搬离服务路径。压缩和垃圾回收是仓库最重的工作之一而现在它们和响应实时 Git 请求用的是同一批主机。新架构里单独的 worker 直接对持久化存储做维护繁忙仓库可以在后台持续被优化不影响 push 和 fetch。第二条存储与计算解耦。现在的架构里本地磁盘上的完整副本同时扮演两个角色既是持久化存储又是响应 Git 请求的那一层。拆开之后各自独立扩展读容量来自轻量的缓存 worker权威副本放在下面的持久化存储层。这样 CI 扇出、Agent 集群、大 clone 带来的读尖峰不会给每次 push 增加额外工作。权威数据放在 Azure Blob Storage持久性和复制直接借用 Azure 的规模计算层只管用最低延迟跑出最高吞吐。故障恢复的形态变了。存储和计算耦合时丢一台主机同时损失容量和持久性恢复要重建完整仓库副本拆开之后丢一个计算 worker 更接近一次缓存未命中替补 worker 立刻开始服务边跑边从持久化存储填充缓存。容量可以跟着流量走。发布或新 Agent 集群上线带来的突发可以临时加容量过去之后再释放不用提前按峰值配置。五、收益以及边跑边换这个约束原文给出的内部基准结果是新架构实现了最高 35 倍于当前的写吞吐读容量可以独立按需扩展。这句话有个前提条件值得单独记一下——整套重建是在 GitHub 持续运行的状态下做的没有维护窗口也没有让用户改工作方式。原文的表述是为最苛刻的工作负载而建抬高的是所有人的下限无论是受严格监管要求约束的企业、要给操作系统仓库落地一次改动的团队还是跨时区评审志愿者贡献的维护者、提交第一个 PR 的学生用的是同一套更快也更稳的地基。同时新架构必须保留团队已经在用的控制维护者需要分支保护和必需评审确保未经审查的改动进不了默认分支安全团队需要审计日志和仓库可见性值班工程师需要有可依赖的自动化和足够的可观测性。原文把原则概括成三句建立在开发者已经信任的工作流上、可靠性优先、让人保持对代码的控制。六、这套思路对 Agent 开发者意味着什么即使你不做 Git 平台这篇文章里的两个模式可以直接搬进自己的 Agent 系统。第一个模式是识别哪些工作真的需要串行。Agent 编排里常见的错误是把所有步骤都做成同步等待而实际上真正需要集中一致的往往只有最终的状态提交。用一个很小的骨架来感受这种拆法# 自拟示意非官方代码把必须协调的部分压到最小defhandle_agent_step(state,action):resultrun_tool(action)# 可并行无需所有副本同意artifactspersist_artifacts(result)# 可并行内容写入对象存储scan_secrets(artifacts)# 可并行校验异步做# 只有引用更新这一步需要达成一致它是关键路径所以越短越好returncommit_ref(state.ref,artifacts)在这个骨架里run_tool、persist_artifacts、scan_secrets 都能和其他步骤重叠执行commit_ref 才是必须串行的那一小段。换句话说不要因为要保证一致就把整条链路都串起来。第二个模式是Agent 的写入频率要有上限。每步都 commit 看起来最安全实际会把写吞吐乘以步数。更实际的做法是按可恢复价值而不是按动作发生来定 checkpoint 粒度——比如一个逻辑子任务完成、或累计改动达到某个规模时才落一次中间状态留在内存或本地暂存。小结这篇文章的技术内核并不复杂把持久化和扩展拆成两件独立的事再把不需要协调的工作全部移出关键路径。难的地方在于它必须在线完成且不能动用户已经依赖的评审、审计、分支保护这些控制。对 Agent 开发者最值得带走的一条判断是当你说系统变慢了先分清慢的是读还是写。读慢通常加缓存就能缓解写慢往往意味着有一处不该串行的协调卡住了吞吐而这个瓶颈会随着 Agent 数量的增加被成倍放大。文中数据、架构描述与引用来自 GitHub Blog2026-10-06Azure Blob Storage 的具体形态与 35 倍基准的测试条件以官方后续文章与文档为准此处未验证最新版本。