帮我看下github最新的博客关于 the bridge to agent-scale Git 那个

kami：这篇是 GitHub 官方工程博客，并不是博客文章；标题为《The bridge to agent-scale Git infrastructure》，来自 github.blog。核心内容如下。 背景和动机：agent 带来的流量在暴涨，而 GitHub 自有数据中心的供电容量和供应链已经到顶，所以整个迁移是被逼出来的。从 2025 年 8 月起，99.% 的仓库已经在 Azure 上有一份拷贝；每个仓库有 5 个副本，多数仓库已有 2 个在 Azure，Azure 承担约一半的 Git 流量。 剩下的 0.% 是最忙的那批仓库，卡在一个 25ms 的跨地域往返上。现在的 Spokes quorum 虽然只要求多数副本提交，但还会等所有健康副本响应；而每次写入会持有整个仓库范围的锁，直到提交完成。因此最慢的副本决定了每次写入的延迟，也决定了吞吐上限。跨地域加上多次往返，这些仓库一 push 就会越落越远。 解法一，把串行化的范围从整个仓库缩小到单个 reference。Git 的一致性要求本来就是按 ref 粒度计算的；不同 ref 的更新互不依赖。比如 agent 和开发者各自推自己的分支，原来要在一个队列里排队，现在可以并发在途。内测显示，在不同 ref 上写入时，吞吐提升到 3 到 4 倍，延迟也更低。 解法二，读写解耦。仓库数据落进 Azure Blob Storage 后，引入一个“虚拟副本”作为 quorum 成员：它不提供读，只把写入流式写入对象存储，写入在对象存储中持久化后才算 ack。它还会把不同 ref 的事务合并成一次网络 IO。之后按需扩容任意多个虚拟读副本，它们从 Blob 预热缓存，不参与 quorum，以对象存储为准。 还没解决的问题：读副本是后台状态对齐，不适合所有读负载，需要改成在请求处理路径中即时对齐；写吞吐的真正瓶颈仍在 quorum 本身。下一步思路是：Git object 本身按内容寻址且不可变，不需要共识，剩下需要排序的东西很少，难点在于如何在不转移瓶颈的前提下把它排得足够快。这是系列的倒数第二篇，最后一篇会在 GitHub Universe 讲终态。 我的判断：这篇真正的信号是，GitHub 把 agent 当成一级负载，不再是人类开发者的附加流量。它选择了“先搬数据、再改架构”的保守路径；瓶颈的根源不是存储容量，而是协调成本。per-reference 串行和虚拟副本本质上都在做同一件事：减少必须全局排队的东西。这也是自建 Git 服务或平台的人值得借鉴的经验：先问哪些一致性要求其实被过度放大了。