正在加载，请稍候
单月 Git 事件从 2182 亿涨到 4733 亿，智能体把开发负载挪到写路径、元数据读与审计三处。拆解自建代码平台的三笔改造成本，以及何时该跟着改、何时先限流。
去年一个 40 人的研发团队把 CI 流水线从 12 条扩到 40 条，代码提交总量只涨了不到两成，写路径的锁等待 P95 却涨了约三倍。原因不在人，在于他们把一批编码智能体接进了日常开发，每个智能体都在自己的分支上高频提交。
GitHub 在 2026 年 10 月 7 日更新的架构说明给了一组一手数据：平台单月 Git 事件从 2025 年 9 月的 2182 亿涨到 2026 年 8 月的 4733 亿，一年翻了一倍以上；2026 年 9 月开发者与智能体合计产生 73.8 亿次 commit，是去年同期的五倍多。
人手写代码时，负载是「稀疏—突发」的：工作日白天集中，夜里安静。智能体不是这样，它在一个紧循环里几乎每个动作就 commit 或 checkpoint 一次，负载变成持续、并发、颗粒度极细。同一份数据里，三处变化最能说明问题。
| 负载类型 | 智能体时代的形态 | 最先被打穿的瓶颈 |
|---|---|---|
| 写路径 | 每个动作一次 commit / checkpoint，单次推送延迟直接变成智能体的速度上限 | 单次推送延迟 + 引用（ref）锁 |
| 元数据读 | 一次 push 被 CI 与代码扫描放大成每分钟上千次 clone / fetch | 元数据服务读放大与缓存命中 |
| 合并 | 大量智能体分支汇入同一条 trunk | 单条 ref 上的 merge 争用 |
对应的量级：pushes 同比从每月 6.9 亿涨到 33.5 亿（4.9 倍），pull request 合并量约为一年前的 4 倍，Actions 单月运行 32.6 亿次（4 倍以上）。单看某一项都不算夸张，叠在一起就解释了为什么「按人天估的容量」集体不够用。
如果企业在自建 GitLab / Gitea 或采购托管版——自建还是买平台本身就是一笔决策成本——下面这三笔开销几乎绕不开。它们不是买机器就能解决的，而是要动架构。
写路径的瓶颈往往不在磁盘 IO，而在「所有写都收敛到同一个点」。智能体各自开分支写，看似并行，但推送与合并最终要落在那条 trunk ref 上。要花的成本是把写路径做水平扩展、把锁粒度从仓库级降到 ref 级，并支持批量推送合并——这是改造，不是扩容。
代码平台不只有 Git 对象，还有分支、提交、PR、权限这些元数据。一次 push 会触发上千次元数据读，读写比可能到几十比一甚至更高。成本在于把读路径独立出去：加只读副本、给 CI 的 fetch 走本地镜像或缓存，否则元数据库会先于 Git 存储被打满。
合规要求通常是「全量保留、随时可查」。当提交方从人变成持续运行的智能体，审计写入量按数量级上涨，保留期的存储成本也随之抬升。可行做法是分层保留：热数据留全量、温数据留摘要、冷数据只留索引，并明确审计写入的丢弃率上限——这一项要写进合同，而不是上线后再谈。
审计链路的完整性，最终会落回一个治理问题：机器写出来的改动由谁签发。这块可以延伸阅读AI 软件开发评审关：机器写的补丁该由谁签发。
不是所有团队都需要立刻改造。按并发智能体数与提交颗粒度分三档，判据如下。
| 阶段 | 并发智能体数 | 提交颗粒度 | 建议动作 |
|---|---|---|---|
| 观察期 | 少于 5 个 | 每个功能一次提交 | 先上监控：锁等待 P95、元数据读 P95，不动架构 |
| 压力期 | 5 到 50 个 | 每个动作一次 checkpoint | 先限流与分流：批量推送合并、CI 拉取走缓存、给智能体发独立的短期分支配额 |
| 改造期 | 超过 50 个 | 秒级小提交 | 动架构：写路径横向扩展 + 元数据读写分离 + 审计分层保留 |
判断的分水岭是「提交颗粒度」而不是「团队人数」。同样 30 个人，如果智能体按动作提交，写入压力会接近上百人团队按功能提交的水平。先看颗粒度，再决定投不投改造预算。
我们见过一个团队用「100 人 × 每人每天 5 次推送」做容量基线，结果上线智能体两周后写路径就出现排队。问题出在分布假设：人的提交是稀疏—突发的，集中在白天几小时；智能体的提交是持续、均匀、并发的小写入，峰值不一定更高，但持续占用与并发争用完全不同。
用平均值估算会系统性低估 P95，也会漏掉「所有写收敛到一条 ref」这个结构性瓶颈。更靠谱的做法是按「每小时的写操作数 × 并发度」建模，并把智能体与人类提交分开统计。
这四项要能复现、能量化，才谈得上「改造完成」。否则很容易出现「跑分好看、真机排队」的落差。
不必。判断起点是并发智能体数与提交颗粒度，处在观察期或压力期的团队，先做限流与监控的性价比远高于动架构。只有当颗粒度进入秒级、并发超过几十个时，写路径与元数据的改造才划算。
Git 的对象存储本身通常不是第一个瓶颈，写路径的收敛点和元数据服务更容易先打穿。所以单纯扩容存储往往解决不了排队，得先看锁与读放大。
取决于颗粒度。按动作 checkpoint 的团队，限流能争取几个月；一旦进入秒级小提交，限流会把压力转成「智能体变慢」，直接影响交付效率，那时改造就不能再拖。
要看合规要求。可行的折中是分层保留：热数据全量、温数据摘要、冷数据只留索引，并把丢弃率上限写进验收，而不是一刀切缩短保留期。
如果你们正在评估自建或托管代码平台，或要把容量规划写进交付验收清单，可以参考我们整理过的 研发基础设施相关案例；需要按团队并发量做一版容量估算，也可以直接 联系我们。