每日快讯 · 2026-10-22

GitHub 正在把 Git 存储架构从自建数据中心迁移到 Azure，以应对智能体化带来的流量激增。目前平台上 99.99999% 的仓库已同时存在于两处，其余最繁忙的仓库则受制于约 25ms 的跨区域往返延迟。GitHub 通过把写入仲裁的粒度从整个仓库缩小到单个引用，让这些仓库也能迁入 Azure，并为后续无状态副本和读写解耦铺路。

· 迁移由智能体化推动：Git 流量指数级增长，而自建数据中心及所在地区的电力容量已触顶，供应链也受限。GitHub 判断剩余扩容空间只够安全迁移、不够慢慢迁移，因此选择先搬数据、再改架构，避免同时更换存储与托管平台带来的风险。

· 迁移按副本推进：Git 操作属于 Tier 0 服务，几乎所有 GitHub 功能都依赖仓库数据。首个仓库副本于 2025 年 8 月落地 Azure 美国中部区域；如今多数仓库的五个副本中有两个在 Azure，Azure 承担约一半 Git 流量，迁移期间新增流量主要由 Azure 吸收。

· 瓶颈在于仲裁等待最慢副本：现有 Spokes 仲裁只需多数副本即可提交写入，但要等所有健康副本响应后才继续，因此最慢的健康副本决定每次写入的延迟；写入期间还持有仓库级锁，进而决定吞吐上限。跨区域副本让每次写入多出多个 25ms 往返，接近上限的仓库会越推越慢。

· 改为按引用串行化：Git 的一致性要求本就针对单个引用，不同引用的更新大多互不依赖。把仲裁范围从仓库缩小到引用后，只有写同一引用的操作才需排队，不同引用可并发在途。内部真实流量测试中，不同引用的写入吞吐提升 3–4 倍，延迟更低。

· 为读写解耦做准备：多数仓库读远多于写，读写比为 100 到 1000 比 1，目前却共用同一批副本、争抢资源。数据持久化到 Azure Blob Storage 后，读流量可与写仲裁分离、独立扩容；第一步是让对象存储成为仲裁成员，即所谓“虚拟副本”。

为什么值得关注：智能体大规模并发推送代码，正在把 Git 托管推向传统架构的物理与延迟极限。GitHub 按引用串行化、读写解耦的思路，是智能体互联网基础设施从“为人设计”转向“为智能体规模设计”的一个具体样本。

arXiv 上发布的一篇论文提出「混合推理智能体」（Hybrid Reasoning Agents），试图把大模型智能体的推理过程拆成两段：在潜空间（latent space）里完成内部思考，再通过文本与外部环境交互并执行动作。论文将这一思路作为方法框架提出，但摘要页面未给出具体实验数据或基准结果。

· 核心设计是把「想」和「做」分开：推理在连续的潜空间中进行，不生成可见的思维链文本；行动则仍走文本接口，以便调用工具、执行指令并与环境交互。

· 这一路线针对的是当前智能体普遍依赖显式文本推理的局限——逐步写出思考过程会带来冗长输出和额外开销，而潜空间推理有望压缩中间步骤、减少 token 消耗。

· 论文将自身定位为混合方案，而非完全抛弃文本：潜空间负责内部计算，文本负责对外表达与动作落地，两者在同一智能体循环中衔接。

· 需要说明的是，本次抓取到的 arXiv 页面正文主要是 arXivLabs 的平台介绍，未包含论文的完整摘要、实验设置与评测结论，因此具体性能提升幅度尚无法核实。

为什么值得关注：智能体的推理效率与可解释性一直难以兼得。若潜空间推理能在保持行动可靠性的同时降低推理开销，将为智能体互联网中的高频、多轮任务提供更轻量的决策范式，也带来可解释性方面的新问题。