为应对人工智能代理带来的空前需求，GitHub正从零开始重构其Git存储架构。初步测试结果显示，新架构在写入性能方面实现了35倍的显著提升。面对如此巨大的需求增长，GitHub确实需要这样的技术突破才能满足用户期望。此次重构计划包括将写入操作与读取操作分离、将系统维护任务外包处理，并借助对象存储技术来实现数据冗余管理。
Responding to unprecedented demand from AI agents, GitHub is rebuilding its Git storage architecture from scratch. Early tests with the new architecture show a promising 35x write improvement in internal tests. GitHub will need a miracle of that proportion just to keep up with customer demand. The plan involves decoupling writes from reads, offloading maintenance, and letting object storage manage redundancy.
最值得称道的是，整个改造过程均在后台悄然进行，旨在实现无缝过渡，确保开发者的工作流程、代码审查机制及安全管控措施均不受任何影响。GitHub首席软件工程师布莱恩·塞伦扎在介绍此次更新的博客中写道：“运营企业级代码仓库意味着要为庞大的工程团队提供支持——这些团队既要运行繁忙的持续集成流水线，又要管理日益增多的AI代理。要满足这些团队的需求，就必须构建出能够实现大规模并发读写操作的Git基础设施，而目前能达到这一规模的代码仓库寥寥无几。”
Most impressive is that the redesign is happening under the hood, with the goal of a non-disruptive change that won't alter developer workflows, review processes, or security controls. Running an enterprise-grade code repository means supporting “large engineering teams running busy CI pipelines alongside growing fleets of agents. Supporting these teams means building Git infrastructure for sustained, concurrent reads and writes at a scale few repositories reach today,” wrote Brian Celenza, GitHub principal software engineer, in a blog post describing the updates.
不过，塞伦扎并未透露此次大规模迁移的具体时间表。随着众多用户开始将开发重心转向人工智能代理，GitHub平台上的活跃度也大幅上升。2025年9月至2026年8月期间，平台上的月度操作事件数量从2182亿次激增至4733亿次；仅2026年9一个月，代码提交次数便达到73.8亿次，较2025年9月增长了5倍之多。如此巨大的流量压力正给系统带来严峻考验。
Celenza did not offer a timeline for this ambitious migration. When GitHub’s customers shifted their coding focus to AI agents, activity on the platform spiked significantly. Between September 2025 and August 2026, GitHub traffic doubled, from 218.2 billion events per month to 473.3 billion. In September alone, commits hit 7.38 billion, a 5x increase from September 2025. This shift in traffic is stressing the system.
根据GitHub发布的服务可用性报告，仅2026年4月，该平台就发生了10起导致性能下降的服务故障；5月份又出现了9起类似事件，每一次故障都引发了比前一次更为严重的负面舆论反响。GitHub目前的存储架构被称为“Spokes”，该架构采用三阶段提交协议，将代码库的完整副本分散存储于多个本地磁盘中，且每次写入操作都必须获得足够数量的副本确认后方可生效。
According to the GitHub Availability Report, the service suffered 10 incidents in April alone that degraded performance. Another nine incidents landed in May, with each generating more bad publicity than the previous one. So long, Spokes GitHub's current storage architecture, nicknamed Spokes, uses a three-phase commit protocol, storing full repo copies across multiple local disks and requiring a quorum of replicas to acknowledge each write.
虽然这种机制确保了极高的可靠性，却也限制了写入速度——因为每次数据推送的速度均受限于那些构成“法定数量”的副本中最慢的那个。
While this approach ensures strong reliability, it bottlenecks write speed, as every push is bounded by the slowest replica required for quorum.
新的架构只在 Azure Blob Storage（一个对象存储服务）中写入一次提交，该服务会自动处理复制（从而实现冗余），消除了仲裁瓶颈。GitHub 还通过将读取请求分离到自己的通道，由轻量计算工作者处理，从而提升性能。读取和写入之间唯一的协调是对引用分支指针的操作。维护任务——如压缩和垃圾回收——被移出服务路径，作为后台进程运行，进一步降低系统延迟。
The new architecture writes a commit only once, to Azure Blob Storage, an object store service that automatically handles replication (and hence redundancy) on its own, eliminating the quorum bottleneck. GitHub also gooses performance by separating read requests into their own channel, a job handled by lightweight compute workers. The only coordination between reads and writes is over the reference branch pointers. Maintenance duties – such as compaction and garbage collection — are moved from the serving path to operate as background processes, further reducing system lag.
Git 在代理时代的演进GitHub 似乎与其他公司在为代理时代重新思考 Git 的方向上保持一致。前 GitHub CEO Thomas Dohmke 推出了名为 Entire 的 Git 托管服务，该服务将代理流量卸载到镜像仓库，使客户的核心 GitHub 仓库仅承载核心开发流量。SpaceX 子公司 Cursor 使用 Git 为其代理支持服务提供后端，也对存储层进行了优化以提升性能。
Git in the age of agents GitHub seems to be on the same page with others in rethinking Git for the agentic age. Former GitHub CEO Thomas Dohmke launched a Git-hosting service called Entire, which offloads agent traffic to mirror repositories, allowing a customer’s core GitHub repos to just serve the core development traffic. SpaceX subsidiary Cursor, which uses Git to back its agent-support service, also refined the storage layer for better performance.
Cursor 的工程师们还放弃了 Spokes 的三阶段提交，转而将推送上传到对象存储的预写日志（WAL），将所有更改记录为不可变对象，并至少在超高速固态硬盘上缓存一份副本。对 Octocats 的敬意虽然对经常宕机的服务进行吐槽令人畅快，但我们也必须对当初创建该服务的 GitHub 工程师抱有同情——他们当初根本无法预料自己会面对怎样的挑战。
Cursor engineers also rejected Spokes’ three-phase commit in favor of uploading pushes into an object storage write-ahead log (WAL), which captured all changes as immutable objects, caching at least one copy on super-speedy solid-state disks. Respect for the Octocats While it's cathartic to hate on a service that often goes down, you have to feel empathy for the GitHub engineers who, when they created the service, couldn’t have guessed what they signed up for.
“我以前在极大规模的环境工作过，见过公司花三个月时间只为应对流量提升 10% 或 20% 的事件[…]，而这与 GitHub 现在面临的情况相比简直微不足道，”PlanetScale CEO Sam Lambert 在 X 上写道。我们都希望新的存储架构能让 GitHub 的工程师们得到应得的休息。
“I've worked at extreme scale before and seen companies spend three months just preparing for events that will increase their traffic by 10% or 20% [...], which is nothing compared to what GitHub's facing now,” wrote PlanetScale CEO Sam Lambert in an X message. We can all hope the new storage architecture will give GitHub's engineers some well-earned rest. ®