https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/ 这篇博客里面提到了什么提升？有什么用？

回 群友 9359： 这篇是 GitHub 官方 10 月 6 日发的《Building Git infrastructure for agent-scale development》，作者 Brian Celenza（GitHub 存储与核心服务的 principal engineer）。核心就一句：GitHub 正在重写自己的 Git 基础设施，因为 agent 大规模并发干活把现有架构顶到天花板了。 先说它摆出来的压力数据（都是 到 这个区间）： - Git 总活动量翻了一倍多，从每月 2182 亿次事件涨到 4733 亿次。 - 仅 9 月一个月，人和 agent 合计提交了 73.8 亿次 commit，是一年前的 5 倍多。 - push 从每月 6.9 亿涨到 33.5 亿，4.9 倍。 - PR merge 涨到接近一年前的 4 倍；GitHub Actions 单月跑了 32.6 亿次，也是 4 倍多。 - 最忙的那个仓库 8 月收到大约 10 亿次请求。分布是极端长尾。 它点出的瓶颈有五个，我觉得前两个最值得记： 一是 per-agent 的 commit turnaround。agent 在一个紧循环里几乎每步都 commit 或 checkpoint，它的速度上限就是单次 push 的延迟，人根本察觉不到的延迟对它就是限速器。 二是写入吞吐量级增长。几千个 agent 各自开分支同时写一个仓库，写请求最后汇聚到架构里的同一个点。 剩下三条是 merge 都抢同一个 ref、每次 push 被放大成上千次读（CI 和代码扫描每分钟 clone 同一个分支 tip 上千次）、以及 compaction 和 GC 这类维护成本随着写入量复利增长。 然后是它承认的老架构问题，这段讲得挺实在：现在每个仓库由 Spokes 存，在几台 fileserver 本地盘上各放一份完整副本，默认 5 份，push 更新 ref 时用三阶段提交加 quorum 保证 CI、Web UI、API 看到一致状态。问题在于——它用来做持久化的机制，同时就是它用来扩容的机制。磁盘副本本身就是 source of truth，所以加读容量等于加一份持久副本，而每个副本都要参与每一次写，一次 push 的快慢取决于最慢的那个副本。结果就是加读副本反而让写变慢。到了最高负载这一档就成硬顶了：加副本给写加负担、掉副本减读容量、掉 quorum 干脆停写。 解法两条设计原则： 一是 minimize coordination，只协调真正需要达成一致的东西。一次 push 里真正需要共识的只有 ref 更新本身，而存对象、校验对象连通性、secret scanning 这些更重的活儿都可以跟其它写并行做，于是 push 的关键路径被压到只剩那一小步。同时把 compaction 和 GC 从服务路径上挪走，交给独立 worker 直接对着持久存储跑，仓库可以在后台持续优化而不拖慢 push 和 fetch。 二是 decouple storage from compute。读容量改由轻量缓存 worker 提供，权威副本放在底下的持久存储层（用 Azure Blob Storage，持久性和复制交给 Azure 那一层）；compute 层只管低延迟高吞吐。好处有三个：加读不增加写负担；故障恢复从"重建整个仓库副本"变成近似 cache miss，替换的 worker 立刻开始服务并边收流量边回填缓存；容量能跟着流量伸缩，不用按峰值预留，release 或者新一批 agent 上线这种突发可以临时加、过去就撤。 效果它给了一个数：内部 benchmark 下写吞吐最高提升到 35 倍，读容量可独立按需扩展。而且强调保留现有的控制——分支保护、必需 review、审计日志、仓库可见性、可观测性都还在，开发者也完全不用改自己的工作方式。 对咱们的实际用处，我看是三层： 一是判断基础设施风向。GitHub 把"agent 是并发写的洪水"当成一等公民在设计，说明 agent 规模开发这件事已经从玩具走到主干道上了，官方给的信号比任何厂商 PR 都硬。顺着这个思路，你要给自己的团队或项目设计 agent 工作流，就该假设 push 和 clone 会变成瓶颈、merge queue 会成争抢点，而不是假设这些是免费的。 二是如果你们在跑大量 agent 对同一仓库操作，可以拿这篇文章的词汇去对照自己的痛点：是 commit turnaround 卡住了 agent 循环，还是 CI fan-out 打爆了读取，还是维护成本在涨。它列的五个瓶颈基本就是一张体检清单。 三是它说的"为最重的负载建，同时也抬高所有人的地板"这个逻辑对个人开发者也不是空话，clone 更快、并发更稳、故障恢复更平滑，这些你都会吃到。文章是系列第一篇，下一篇会细讲未来架构的具体形态和演进过程。 原文：https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/