2026 年 11 月 2 日，OpenAI 公开了一套名为 Pando 的 Git 兼容后端。它不是另一个代码托管界面，而是为“工程师与大量编码 Agent 同时工作”重新设计的仓库存储与传输层。官方披露的生产结果很醒目：中位数 push 延迟下降接近 80%，系统每天交付接近 1 PB 的 Git 数据，单小时曾发送超过 57 TB 的 pack 数据，超过 99% 的字节来自本地磁盘缓存。

这些数字背后真正值得研究的不是“OpenAI 又造了一个 Git”，而是一个更普遍的问题：当 Codex、Copilot、Claude Code、OpenCode 等 Agent 把分支、提交、CI 拉取和临时开发环境的数量同时放大时，已有源代码平台为什么会遇到新的上限？团队又应该如何判断自己的 Git 后端已经从“偶尔慢”进入“架构不匹配”？

本文基于 OpenAI 官方公开的《Scaling Git at OpenAI》整理 Pando 的核心设计，并把它转换为可以用于自建 Git、代码托管平台和 Agent 开发平台的工程方法。需要先说明：OpenAI 目前只是表示正在探索如何向用户分享 Pando 技术，并未把 Pando 宣布为可直接安装的通用产品；文中的配置、伪代码和迁移步骤属于架构推演与实践建议，不是 Pando 私有实现的复刻。

一、为什么 AI Agent 会把 Git 压力放大

1. 从人类并发变成机器并发

传统容量规划通常从“多少开发者在线”出发。一个人一天创建几个分支、提交若干次、触发有限数量的 CI。编码 Agent 改变了这个基本单位：同一位工程师可以同时启动多个任务，每个任务拥有独立 checkout、分支和验证流水线；一个 push 又可能触发多个执行器拉取同一提交。

可以把仓库读写压力粗略写成：

每日 Git 请求量
≈ 活跃工程师数
× 每人并行 Agent 数
× 每个任务的迭代轮数
× 每次迭代触发的 fetch / clone / CI 扇出

当四个因子一起增长，压力不是线性增加。分支数量扩大 ref 广告，提交频率增加 pack 数量，CI 扇出放大热点对象读取，短生命周期沙箱则让增量 fetch 退化为频繁 clone。

2. Agent 的访问形态与人不同

人类开发者通常保留本地仓库数周或数月，拥有较完整的对象历史。Agent 沙箱可能按任务创建，用完即销毁；它经常只有浅历史，甚至没有任何对象。人类会等待一次 push，Agent 则会在不同分支上并行推进，并在失败后自动重试。

维度	传统人工开发	Agent 规模开发
工作副本寿命	长，持续复用	短，按任务创建
并行分支	每人少量	每人可同时多个
push 节奏	人类思考后提交	自动循环频繁提交
fetch 来源	开发机为主	沙箱、CI、研究任务、服务自动化
容错行为	人工判断后重试	程序化重试，容易形成重试风暴

3. 最早暴露的三个信号

如果一个团队开始使用大规模编码 Agent，最先出现的往往不是磁盘耗尽，而是以下信号：

1. 不相关分支的 push 互相影响，P95/P99 延迟随并发显著抬升。
2. fetch-pack、repack、GC 的 CPU 与 I/O 持续占用，扩容应用节点却没有线性收益。
3. CI 明明拉取同一提交，服务端仍重复计算和压缩近似相同的 pack。

这三个信号分别对应写入协调、对象维护和读取计算。只优化其中一个，系统仍可能被另外两个环节卡住。

二、传统 Git 服务的扩展瓶颈在哪里

1. 全仓库 ref 视图带来的协调

Git push 前，服务端通常向客户端广告 refs。客户端根据自己拥有的对象和服务端已有的对象，生成尽量小的 pack。refs 越多，客户端越容易排除服务端已经拥有的对象，但服务端维护并一致地展示全仓库 refs 的成本也越高。

OpenAI 披露，在拥有数百万分支时，ref advertisement 本身可能超过 100 MiB。更关键的是，为所有 refs 提供一致的时间点快照，会让原本互不相关的分支更新争用共同协调点。

目标：Branch A push 与 Branch B push 互不阻塞

传统全局顺序：
  A ──等待全局 ref 序列──提交
  B ──等待全局 ref 序列──提交

按 ref 独立协调：
  A ──CAS(ref/A)──提交
  B ──CAS(ref/B)──提交

2. 为每个客户端动态生成 pack

fetch 时，客户端发送 have 和 want。常规服务端计算 want 可达对象与 have 可达对象的差集，然后压缩成 pack 返回。这个结果高度依赖客户端本地历史，因此两个客户端即使拉取同一分支，也可能得到不同的 pack。

动态 pack 的优势是传输精确，劣势是难以缓存：CPU 在遍历对象和压缩，磁盘在读取散落对象，结果又不能被下一个客户端完整复用。Agent 沙箱越多，这种重复工作越明显。

3. repack 与 GC 的维护窗口

Git 对象不断增长后，repack 和垃圾回收用于减少碎片、改善读取并回收空间。但它们通常消耗大量 CPU 和 I/O，还会与前台流量争夺资源。高频提交的 monorepo 很难找到真正安静的维护窗口。

把问题归纳起来，传统系统同时追求了三个昂贵目标：全仓库强一致视图、针对每个客户端的最小 pack、通过周期性重写维持对象布局。Pando 的思路不是把这三件事做得更快，而是重新判断哪些约束可以放松。

三、Pando 的核心取舍：保留 Git，放松内部假设

1. 为什么仍然兼容 Git

如果只考虑后端扩展性，设计新协议看似更自由。但源代码系统周围有庞大生态：命令行、IDE、代码评审、CI、Webhook、镜像、合规扫描和开发者习惯。更换协议会把后端问题转化为全公司的迁移问题。

Pando 保留 Git 协议和客户端兼容性，工程师与 Agent 继续使用熟悉的 clone、fetch、push。创新集中在服务端如何记录 ref 版本、保存 pack、规划读取和交付数据。这是一条很重要的架构原则：优先替换可控的内部实现，稳定外部合同。

2. 放松仓库级强一致，保留因果一致

Pando 不要求所有 refs 在任意时刻都形成一个全局一致快照，而是采用因果一致性，并保证 read-your-own-write。一个客户端成功更新某分支后，可以立即读取自己的结果；不相关分支不必为了共同的全局顺序互相等待。

这里不能误解为“允许覆盖别人的提交”。同一 ref 的更新仍需要原子保护。官方描述中，唯一争用的关键位置是 ref pointer，并使用类似 compare-and-swap 的机制守卫。

function update_ref(ref_name, expected_version, new_tip, pack_uri):
    begin multi_key_transaction
        current = read(ref_pointer[ref_name])
        assert current.version == expected_version

        version = append_ref_version(
            ref=ref_name,
            tip=new_tip,
            dependencies=negotiated_bases,
            pack=pack_uri
        )

        compare_and_swap(ref_pointer[ref_name], current, version)
        enqueue_compaction(version)
    commit

这段伪代码表达的是公开架构，不是官方源代码。重点是：同步路径只做保证新版本立即可读所需的工作，压缩等重任务异步化。

3. 把客户端生成的 pack 变成可复用资产

Pando 在 push 时接收客户端生成的 pack，一边校验，一边流式写入 blob storage；随后在元数据服务中记录 ref version、tip、依赖和 pack 的关联。这个 pack 不再只是一次 push 的临时载荷，而成为未来 fetch 可以直接选择的不可变数据块。

官方称，一次写操作只需要 O(1) 次元数据读写。与提交历史长度相比，写入路径的协调成本保持常数级，这正是水平扩展无关分支写入的基础。

四、写入路径：怎样让大量分支同时 push

1. 只广告选定的基础分支

Pando 默认在新功能分支 push 时只广告指定 trunk 作为基础，而不是展示所有 refs。这样做有两个效果：

• ref advertisement 不会随分支总数线性膨胀。
• 客户端生成 pack 时，只能排除服务端明确允许的依赖，服务端因而知道该 pack 依赖哪些历史。

广告 refs 太多，pack 更小但依赖更复杂、复用更困难；一个 ref 都不广告，pack 可以被所有人复用，但可能包含完整历史。只广告 trunk 是在大小与复用性之间取平衡。

OpenAI 公布的工作负载中，这种策略生成的 pack 中位数小于 20 KiB，P99 小于 3 MiB，因此为复用性接受少量冗余是合理的。其他团队不能直接照搬这些阈值，应先测量自己的二进制文件比例、分支堆叠习惯和 trunk 更新频率。

2. 流式校验与对象存储

push 数据不必先完整落到单机磁盘再处理。服务端可以单遍解码校验，并把字节流写入对象存储。元数据与大对象分离后，写入吞吐可以分别通过增加 Pando server、metadata store scaling unit 和 blob store 扩展。

git client
   │ push pack stream
   ▼
Pando server ───────► blob storage
   │ 单遍校验             │ immutable pack
   ▼                      ▼
metadata transaction ─► ref version + pointer
   │
   └──► async compaction task

3. 只在同一 ref 上解决冲突

如果两个 Agent 更新不同分支，它们可以独立完成。如果同时更新同一个分支，CAS 让后到者得到明确冲突，再基于最新 tip 重新计算。这样，冲突域等于业务上真正共享的 ref，而不是整个仓库。

团队在设计 Agent 分支策略时也应该配合这一点：避免大量 Agent 直接 push 到同一聚合分支；使用任务级分支、队列化合并和 --force-with-lease，让并发发生在分支层，收敛发生在明确的 merge 层。

五、读取路径：从“现场造包”变成“选择已有包”

1. 把 have / want 映射到 ref version

客户端 fetch 会提供已有提交 have 和目标提交 want。Pando 使用 push 时记录的提交映射，把它们解析到一组 ref versions，再选择覆盖缺失对象的已有 pack。

官方给出的规划复杂度是 O(log Δ)，其中 Δ 是客户端已有版本与目标版本之间的最短 ref version 距离。这里的关键不是某个数据库索引技巧，而是把“遍历对象图并重新压缩”改写成“在版本与 pack 索引中选覆盖集合”。

function plan_fetch(haves, wants):
    have_versions = map_commits_to_versions(haves)
    want_versions = map_commits_to_versions(wants)
    missing_ranges = subtract_dependencies(want_versions, have_versions)
    return cover_index.select_minimal_packs(missing_ranges)

2. packfile-uri 让多个 pack 并行交付

Git 协议传统响应只内联一个 packfile，但 packfile-uri 能返回额外 pack 的下载地址。Pando 大量利用这一能力：内联返回空 pack，把真实数据作为多个 URI 交给客户端并行下载。

这样做把协议协商与大文件传输解耦。后端负责回答“需要哪些 pack”，边缘交付服务负责“尽可能快地发送这些 pack”。客户端也能并行下载、校验和建立索引。

fetch negotiation response
├── inline pack: empty
├── packfile-uri: /packs/aa/001.pack
├── packfile-uri: /packs/b7/019.pack
└── packfile-uri: /packs/f2/144.pack

3. 为什么缓存命中率可以很高

动态生成的客户端专属 pack 很难复用，而 push 产生的不可变 pack 具有稳定标识。Pando 使用名为 Express 的交付服务缓存 blob store，并按一致性哈希把 pack 请求路由到节点；另有缓存服务处理元数据。

官方报告本地磁盘缓存字节命中率超过 99%，并在标准云虚拟机上验证 clone/fetch 能跑满 10 Gbps 链路。这说明系统的主要工作从重复压缩转向可缓存字节的网络交付，CPU 不再是每次读取的首要瓶颈。

六、分层 Compaction：不是删除旧 pack，而是增加更大覆盖

1. 为什么不能永远发送小 pack

每次 push 都产生一个小 pack。如果客户端落后数万次更新，逐个返回 packfile URI 会让协商、连接和索引成本变得不可接受。Pando 因此把小 pack 按 ref version 范围组成 covers，并以类似 LSM-tree 的层级在后台合并。

L0: [p1][p2][p3][p4][p5][p6][p7][p8]
L1: [----- cover 1 -----][----- cover 2 -----]
L2: [-------------- larger cover --------------]

OpenAI monorepo 当前使用到 L4 cover。高层 pack 改善压缩率，cover 索引同时像 skip list 一样帮助 fetch planner 跨越大段版本，从而让选择 pack 的成本次线性增长。

2. 与常规 GC 最大的不同

官方说明，Pando 会保留每一层的 pack，而不是在 compaction 后立即丢弃旧层。不同粒度的 pack 仍可根据客户端 have/want 组合使用。读取单个任意对象时，小 pack 甚至可能比大 pack 更省数据，因为对象在大 pack 中可能依赖更远的 delta base。

这是一种“用更多不可变存储换取前台可用性和选择空间”的设计。它并不意味着存储永远无需治理，而是把删除与前台重打包解耦。实际落地时仍要设计保留期、孤儿 pack 回收、引用计数校验和灾难恢复策略。

3. Compaction 需要观察什么

建议至少记录以下指标：

指标	含义	异常方向
fetch_plan_pack_count	单次 fetch 需要多少 pack	持续上升说明 cover 不足
cover_build_lag	最新 ref 到已完成 cover 的距离	过大导致落后客户端变慢
compaction_bytes_in/out	合并读写放大	突升可能挤压前台 I/O
pack_reuse_ratio	被多个客户端复用的 pack 比例	下降说明依赖规划失效
time_to_first_byte	首字节时间	区分协商慢与传输慢

七、Pando 的一致性模型该怎样理解

1. read-your-own-write 是开发体验底线

push 返回成功后，发起者必须能够立即 fetch 到新 tip，否则 Agent 会把传播延迟误判为提交失败，触发危险重试。Pando 在同步元数据事务中写入 ref version 并原子更新 pointer，从而提供 read-your-own-write。

2. 仓库级快照不再是默认能力

因果一致意味着读取多个无关 refs 时，不一定得到某个全局时间点的完整快照。多数 Git 工作流只关心一个分支及其依赖，这个取舍成立；但发布编排、跨分支审计或“读取所有 refs 后做全局判断”的工具可能依赖更强语义。

迁移前应该建立一致性需求矩阵：

场景	最小需要的一致性	处理方式
push 后立即 CI	read-your-own-write	同步提交 ref pointer
单分支 code review	ref 内顺序一致	版本链 + CAS
多分支发布快照	显式快照	生成 manifest，不依赖隐式全局视图
全仓库合规扫描	可重复读取	固化 ref 集合及版本号

3. 显式 manifest 替代隐式快照

需要跨分支一致视图时，可以创建不可变 manifest，记录本次操作涉及的 ref 与 version。后续任务只按 manifest 读取，不假设“现在列出所有 refs”天然形成一致快照。

{
  "release": "2026.11.0",
  "refs": {
    "refs/heads/main": 184205,
    "refs/heads/service-a": 9281,
    "refs/heads/service-b": 4127
  }
}

八、Agent 规模 Git 的容量模型

1. 不要只看仓库总大小

仓库大小决定首次 clone 成本，却不能单独解释生产压力。更有用的容量维度包括：每秒 ref 更新数、push pack 大小分布、每次 push 的 CI 扇出、短生命周期客户端比例、客户端落后版本距离和跨区域读取比例。

一个简化的出口带宽估算如下：

egress ≈ unique_pack_bytes × regional_replication_factor
       + cache_miss_bytes
       + cold_clone_bytes

如果 pack 能被大量复用，客户端数量增加不一定同比增加源站 CPU，但一定会增加边缘网络与缓存容量。因此需要同时观察计算成本和字节交付成本。

2. 建立四组 SLO

建议把 SLO 分成四组，而不是只看平均 clone 时间：

• 写入：push acknowledgement P50/P95/P99、同 ref 冲突率、验证失败率。
• 协商：ref advertisement 大小、fetch plan 延迟、计划 pack 数量。
• 交付：TTFB、吞吐、缓存字节命中率、跨区回源率。
• 后台：compaction lag、元数据积压、孤儿 pack 数、校验错误。

3. 用分位数识别 Agent 风暴

平均值会掩盖并发 Agent 带来的长尾。重点比较 P50 与 P99 的差距，并把指标按人类开发机、Agent 沙箱、CI runner、研究任务和自动化服务拆分。若 Agent 流量的重试率在延迟升高时同步上升，必须加入指数退避、幂等请求 ID 和全局并发预算。

九、普通团队可以先做的五项改造

1. 先减少无意义 clone

不是所有团队都需要重建 Git 后端。最先检查 Agent 平台是否每轮都全量 clone，能否使用持久工作区、对象缓存、浅克隆、partial clone 或共享 reference repository。先消除明显浪费，再判断服务端瓶颈。

# 示例：只取目标分支的浅历史。是否适用取决于任务是否需要完整历史。
git clone --filter=blob:none --depth=50 --single-branch \
  --branch main https://git.example.com/platform/mono.git

2. 把任务分支作为并发隔离单元

为每个 Agent 任务创建独立 ref，禁止无保护地 force push 共享分支；聚合分支通过队列合并。分支名中只放任务标识，不放用户隐私、访问令牌或内部故障详情。

refs/heads/agent/<team>/<task-id>
refs/heads/merge-queue/<repository>/<batch-id>

3. 缓存不可变对象，而不是页面结果

pack、commit、tree 和 blob 都是内容寻址对象，天然适合不可变缓存。缓存键必须包含对象或 pack 的稳定身份，并校验哈希；不要只按分支名缓存，因为分支指针会移动。

4. 把昂贵维护移出同步路径

push 的同步路径只保留认证、授权、协议校验、对象完整性和 ref 原子更新。索引扩展、统计、compaction、镜像和非关键 Webhook 尽量异步，但要提供可观测的积压与失败补偿。

5. 约束 Agent 的重试

Agent 不应该看到超时就立刻重复 push。客户端应先读取 ref 状态，判断前一次是否已经成功，再决定重试；使用带抖动的指数退避，并设置每仓库、每租户和每任务并发上限。

十、迁移方案：从代理层开始，而不是一次替换

1. read-through / write-through 双写

OpenAI 最初把 Pando 作为现有源代码系统的读写穿透代理，让新旧系统保持同步，再逐步迁移流量。这类路径的优势是：新系统出错时可以回退，真实流量会逐渐填充缓存，也能对比两个后端的结果。

clients
   │
   ▼
compatibility proxy
   ├── new pack/ref backend
   └── legacy Git backend

2. 建立影子校验

在不影响客户端响应的情况下，用新后端规划 fetch，并与旧后端返回的对象集合做哈希对比。对 push 则验证 ref tip、对象可达性、权限结果和 Webhook 事件是否一致。

3. 分阶段切流

一个稳妥顺序是：只读机器人 → 可重建的 CI → 内部 Agent 沙箱 → 少量开发者 → 关键仓库。每阶段都要定义回退开关、最大允许错误率和数据修复方法。

4. 不要漏掉 Git 之外的集成

真正困难的迁移往往不是 clone/push，而是数百个依赖旧 API、Webhook、archive download、代码评审和权限模型的集成。应建立调用清单，并为每个消费者记录协议、数据一致性要求、超时和负责人。

十一、测试：为什么 conformance 与确定性模拟都重要

1. Git 行为一致性测试

协议兼容不能只靠几个 happy path。至少覆盖 shallow clone、partial clone、tag、submodule、force-with-lease、并发 push、中断恢复、损坏 pack、不同 Git 客户端版本和大文件场景。

OpenAI 表示为 Pando 编写了 conformance test suite，让 Agent 能针对标准 Git 行为验证改动。对任何兼容层而言，这类测试都是防止“性能优化破坏语义”的第一道边界。

2. 确定性模拟并发故障

分布式 ref 更新与 pack planning 的 bug 常常依赖罕见时序。确定性模拟可以控制消息顺序、节点故障和存储响应，让同一随机种子稳定重现问题。

seed=42871
1. writer-A uploads pack P1
2. writer-B reads ref version V8
3. metadata node delays transaction T1
4. writer-B CAS succeeds: V8 -> V9
5. writer-A CAS must fail, P1 becomes reclaimable orphan

3. 形式化方法适合验证哪些性质

官方提到使用 GPT-6 Astra 编写 Lean 和 TLA+，形成“Pando 理论”并发现、修复实现问题。形式化方法不必覆盖全部代码，优先验证少数关键不变量：ref 不回退、成功 push 必可读、同一版本指向不可变 pack、planner 不遗漏 want 可达对象、失败事务不发布半成品元数据。

4. Agent 写代码，人类仍要定义判定标准

Pando 从启动到生产用了 10 周，核心设计由一名工程师完成，多个 Agent 团队参与实现，少量工程师部署。这个案例不能简单归纳为“Agent 可以无人造基础设施”。更准确的结论是：当协议合同、测试预言机、模拟框架和不变量清晰时，Agent 可以大幅扩大实现与验证并行度。

十二、安全与多租户边界

1. pack 是不可信输入

push pack 来自客户端，必须限制解压大小、对象数量、delta 深度、路径与协议字段，防止压缩炸弹、资源耗尽和解析器漏洞。单遍校验不等于减少安全检查，而是要求验证器能够在流式过程中维护完整性边界。

2. URI 不能绕过仓库授权

packfile-uri 适合 CDN 和并行下载，但下载链接必须绑定租户、仓库、对象范围和短期有效期。不能因为 pack 内容寻址就把它当成公开对象；一个 pack 可能包含用户无权读取的历史对象。

signed_uri claims:
  tenant_id
  repository_id
  pack_id
  expires_at
  audience

3. 日志避免泄露源代码与凭证

记录 pack ID、字节数、ref version、耗时和错误分类通常足够。不要把 Authorization header、完整 ref 敏感命名、commit message 或源代码片段写进普通运行日志。支持包和故障转储也应自动脱敏。

4. 元数据与对象存储都要审计

元数据事务决定“哪个 ref 指向哪个版本”，对象存储保存“版本实际包含什么”。备份、校验和审计必须覆盖两者，并能证明它们之间没有悬空引用或越权共享。

十三、故障演练清单

上线前建议至少演练以下场景：

1. blob 已写入但元数据事务失败，系统能识别并回收孤儿 pack。
2. ref pointer 更新成功但缓存未刷新，发起者仍能读到自己的写入。
3. compaction worker 中途崩溃，不发布不完整 cover。
4. 边缘缓存返回损坏 pack，客户端校验失败后安全回源。
5. metadata store 局部不可用，写入失败是明确且可重试的。
6. 单个 Agent 产生重试风暴，租户限流不影响其他仓库。
7. 某区域断网，客户端按策略切换且不会造成双写冲突。
8. 权限撤销后，已签发 pack URI 在短时间内失效或被阻断。
9. 旧客户端不支持 packfile-uri 时能够降级或被清晰拒绝。
10. 从备份恢复后，ref version、pointer、pack 和 cover 索引重新一致。

每次演练都要记录恢复时间、数据正确性、客户端可见错误和人工步骤。只证明“服务重新启动”不够，还要证明 Git 对象图与 ref 语义没有被破坏。

十四、Pando 带来的三个长期判断

1. 源代码系统正在从文件服务变成 Agent 基础设施

当大量 Agent 把仓库作为协作媒介，Git 后端不再只是开发者工具的一部分，而是调度、验证和审计链路的核心数据面。容量规划需要和 Agent 并发预算、CI 扇出与沙箱生命周期一起设计。

2. 可复用计算结果比更快的重复计算重要

Pando 最有启发性的设计不是某个数据库，而是把 push 产生的 pack 保存为可复用资产，让 fetch 主要做选择和交付。类似原则也适用于依赖缓存、构建产物、代码索引和测试结果：先问结果能否稳定标识、验证并复用，再问如何把重复计算优化得更快。

3. 兼容协议可以与重构内部架构同时成立

保留 Git 客户端和工作流，大幅降低了迁移阻力；通过因果一致性、版本化元数据、对象存储和 pack URI，服务端仍获得了新的扩展空间。成熟系统的创新往往不是推倒全部接口，而是在不破坏生态的前提下重新分解状态、计算和传输。

十五、结语

Pando 解决的是一个已经开始普遍出现的问题：AI 编码让软件产出更并行，也让源代码基础设施承受远高于人类开发时代的分支、push、fetch 和 clone 密度。继续堆更大的 Git 服务器可以缓解一段时间，却无法消除全局 ref 协调、客户端专属 pack 计算和前台 repack 的结构性成本。

它给出的方向很清晰：用 ref version 与 CAS 缩小写冲突域，用因果一致性换取无关分支的水平扩展，把 push pack 变成不可变可复用资产，通过 packfile-uri 与边缘缓存把读取转化为字节交付，再用分层 compaction 控制长期 pack 数量和规划复杂度。

对大多数团队而言，今天不需要复制 Pando。更现实的起点是测量 Agent 带来的真实流量，减少无意义 clone，隔离任务分支，缓存不可变对象，约束自动重试，并把昂贵维护移出同步路径。等这些措施仍无法满足 SLO，再评估是否需要版本化 ref 元数据、pack 复用和新的读取规划层。

架构升级的判断标准也不应是“我们有多少开发者”，而应是“仓库每分钟承载多少个独立软件生产者”。在 Agent 时代，这两个数字正在迅速分离。

参考资料

1. OpenAI Engineering：Scaling Git at OpenAI（2026-11-02）。
2. Git 官方文档：Git Wire Protocol, Version 2。
3. Git 官方文档：Pack Protocol。

本文中的性能数字与 Pando 生产事实来自 OpenAI 公开文章；伪代码、容量模型、SLO、迁移步骤和故障演练清单是基于公开架构提炼的工程建议。生产实施时，应以实际 Git 版本、托管平台能力、安全策略与压测结果为准。