GitHub新存储架构瞄准智能体高并发推送

GitHub 为 AI 智能体带来的代码读写压力，公布了代号为 Rubicon 的新 Git 存储架构。官方称，内部压测已支持单个仓库中 5000 个 Agent 并发协作，每秒承受 7200 次代码推送，同时保持极低的读取延迟。

对程序员更有参考价值的，是这次扩容背后的负载变化：Agent 持续提交代码，每次 Push 又会带动 CI、部署系统和其他 Agent 读取仓库。GitHub 准备应对的，是写入和读取一起增长的压力。

为什么现在就要准备每秒数千次推送

据报道，GitHub 当前最繁忙的仓库，单秒写入峰值也只是数十次，而且通常是短暂的脉冲式突发。Rubicon 内部测试达到的每秒 7200 次推送，显然不是照着当前常见峰值做的小幅扩容。

GitHub 的判断是，越来越多研发工作会交给全天候运行的 AI 智能体。人类开发者的提交存在工作节奏，Agent 则可能持续并发执行任务。官方预计，未来一年内，短时突发会逐渐变成持续的高吞吐负载。

这里要分清两类信息：当前头部仓库的写入特征，是官方对现有负载的描述；未来一年负载如何变化，则是预测。

报道也给出了一个增长案例：某个典型仓库在 3 月至 5 月期间，日请求量约增长了 4 倍，此后仍保持陡峭的指数级增长趋势。但原文没有说明仓库规模、请求构成，也没有交代其中多少增长来自 Agent。它能说明部分仓库正在快速变忙，不能直接证明所有团队都会走向同样的负载。

一次 Push，为什么会放大成一串读取

单看提交次数，容易低估代码托管平台的压力。

一次 Push 之后，CI 流水线会启动，部署系统会拉取最新提交，其他协同 Agent 也会获取代码作为上下文。同一次代码变更，可能带出多个消费者的读取请求。原文把这种现象称为读取扇出（Read Fan-out）。

写入越频繁，需要跟着获取代码的系统就可能越忙。

这也是 Rubicon 同时强调两项能力的原因：每秒处理数千次写入，以及让读取能力按需水平扩展。后者可以理解为通过增加服务资源来承担更多读取请求，而不是只提高写入端的处理能力。

但报道没有披露它具体怎样实现：数据如何分布、读取如何路由、一致性如何保证，都没说清。因此，目前能讨论的是它要解决的负载问题和官方公布的测试结果，还无法据此分析内部架构取舍。

我的判断

我认可 GitHub 把读取放大效应与写入吞吐放在一起考虑。代码仓库连接着 CI、部署和自动化协作，只提高接收 Push 的速度，并不能完整应对后续请求增长。

不过，5000 个 Agent 和每秒 7200 次推送，仍是官方内部压力测试结果。原文没有提供仓库大小、单次推送的数据量、测试持续时间，也没有给出「极低读取延迟」对应的具体数值。这两个数字不能直接当作一般团队可获得的性能承诺，更不能据此推导出 5000 个 Agent 的任务都能顺利完成。

存储能承受并发，不代表协作能产出正确代码。

分支冲突、测试资源、代码审查和任务依赖，仍可能限制实际开发效率。原文没有提供新旧架构的同条件对照，也没有比较减少无效推送、合并重复 CI 任务等做法的效果。

此外，Rubicon 目前处于小范围定向内测（limited private preview），计划于报道所述的明年初逐步扩大开放范围。对普通团队而言，它更适合作为观察基础设施变化的信号，还不是一个可以立即采用并验证收益的普遍方案。

能拿来做什么

• 接入 AI 编程 Agent 时，同时记录 Push 次数和随后触发的 CI、部署、代码拉取请求，判断一次提交究竟带出了多少后续工作。
• 如果团队已经让多个 Agent 持续操作同一仓库，区分短时峰值与持续负载；每秒偶尔出现几十次请求，和长时间维持这个水平，需要不同的容量准备。
• 评估 GitHub 新架构时，把仓库规模、推送大小、持续吞吐和读取延迟列入验证条件，不要只用 Agent 数量判断它是否适合自己的项目。