Agent 写基础设施的 4 道验收：OpenAI 用 Codex 10 周重写 Git 后端
拆解 OpenAI 工程博客 Scaling Git at OpenAI：Codex 让并发 push 暴增后，OpenAI 用 agent 10 周做出兼容 Git 的后端 Pando。重点整理 agent 写基础设施的 4 道验收——一致性测试集、确定性模拟、agent 写 Lean/TLA+ 形式化、透传代理双跑切流，并给出个人项目可抄的验收清单。数字均为 OpenAI 自述。
Agent 写基础设施的 4 道验收：OpenAI 用 Codex 10 周重写 Git 后端
让 AI 写个页面、写个脚本，大家已经习惯了；但让 agent 去写一套所有工程师每天都要用的核心基础设施，问题就从「能不能写出来」变成了「凭什么敢上线」。
OpenAI 在 2026-11-02 发布的工程博客 Scaling Git at OpenAI 正好给了一个完整案例：他们为 monorepo 新做了一个兼容 Git 协议的后端 Pando，据 OpenAI 称从立项到上生产只用了 10 周——核心设计由 1 名工程师完成，实现交给多组 agent，少数几名工程师负责部署。
这篇不复述 Git 内部原理，重点拆两件事：他们为什么要重做，以及他们用哪 4 道关来验收 agent 写的代码。后者才是普通开发者能抄回自己项目里的部分。
说明：文中数字均来自 OpenAI 原文，属于厂商自述，本文未做独立验证。
一、起因：Codex 让并发量翻了几番
原文的说法很直白：Codex 让一个工程师可以同时推进多件事，于是分支更多、push 更多、merge 更多，开发环境、研究任务和 CI 发起的 fetch / clone 也成倍增加。一个人同时有好几个改动等 CI，每次 push 又会触发好几个 job 去拉同一个 commit。
结果是：从去年底开始，monorepo 背后的系统撑不住了——fetch、push 变慢，merge 失败，可靠性一度跌到 90% 以下（据 OpenAI 称）。
这其实是 AI 编程普及后的一个通用信号：agent 不只是让你写得快，还会把你下游的基础设施压垮。CI 队列、代码仓库、预览环境、数据库连接，都可能是下一个瓶颈。
二、关键取舍：放弃「全库一致快照」
OpenAI 对比了两种常见的分布式 Git 方案：
| 方案 | 怎么协调写入 | 瓶颈在哪（据原文分析） |
|---|---|---|
| 三阶段提交（3PC） | 多副本各存完整仓库，多数派接受才算 push 成功 | 每次 push 多轮往返，副本磁盘与网络延迟都压在写路径上，负载高时写延迟明显上升 |
| 共享 WAL 清单 | 所有 ref 更新追加到 blob 存储里同一份 manifest，用 CAS 原子替换 | 无关分支的 push 也抢同一个 manifest；副本消化日志跟不上时读延迟上升 |
| Pando | 每个分支独立协调，packfile 作为不可变 blob 存储并复用 | 只在同一个 ref 同时被 push 时才冲突 |
Pando 的核心取舍是：不再保证整个仓库所有 ref 在某一时刻的一致快照，只保证单个 ref 的更新是串行的（原文称为因果一致性）。代价是：一个客户端同时读多个分支时，看到的可能不是同一时刻的状态。OpenAI 的判断是，实际使用中人和 agent 都只在乎单个分支的更新顺序，不在乎全局顺序。
另一半是读：传统 Git 服务端要给每个客户端现算一个 packfile，CPU 和磁盘 I/O 开销大、也难缓存；Pando 改为复用 push 时收到的 packfile，再用类似 LSM 树的后台 compaction 把小包合成大包，配合区域缓存分发。
这一段对做后端的读者很有参考价值：先想清楚业务真正依赖的是哪一级一致性，再决定把哪个「默认要求」砍掉。很多扩展性问题，本质是在为没人用的一致性付费。
三、重点：agent 写的基础设施，靠这 4 道关验收
原文「Building Pando」和「Deploying Pando」两节信息密度最高。我把它整理成 4 道验收：
第 1 关：一致性测试集（conformance suite）
OpenAI 写了一套 conformance test suite，让 agent 每次改动都能对照标准 Git 行为自测。
为什么这是第一关：Pando 的承诺是「客户端无感」，那么「行为和 Git 一样」就是最硬的验收标准。把这个标准变成 agent 可以自己跑的测试，agent 才能在没人盯着的情况下迭代。
抄到个人项目：如果你让 agent 重写一个模块（换框架、换语言、换存储），先把旧实现的外部行为固化成测试——接口输入输出、错误码、边界值——再让 agent 动手。没有这套测试，「重写完成」这句话没有意义。
第 2 关：确定性模拟测试（deterministic simulation）
他们搭了确定性模拟测试框架，用来检查系统的不变量和性质，原文说借此找到并修掉了协商（negotiation）和打包规划（pack planning）里隐蔽的竞态和回归。
并发系统的 bug 往往只在特定时序下出现，普通单测很难复现。确定性模拟的意思是：把时间、网络、调度都变成可控、可重放的输入，同一个随机种子跑出同一个结果，出错就能稳定复现。
抄到个人项目：不一定要上完整框架。最低成本的做法是把并发相关逻辑里的「当前时间」「随机数」「外部调用」都抽成可注入的依赖，测试里用固定种子和假时钟跑大量随机序列，并写清楚哪些不变量永远不能被打破（比如余额不能为负、同一订单不能扣两次款）。
第 3 关：让 agent 写形式化规约
据原文，他们用 GPT-6 Astra 让 agent 编写 Lean 和 TLA+，形式化出一套「Pando 理论」，用它找出并修复实现中的 bug，并证明系统的一些性质；还有多个连续会话跑了数百小时专门找边界情况，另有 agent 全天候对 Git 和 Pando 做红队测试。
这一关门槛最高，但思路值得记住：以前写形式化规约太贵，现在可以交给 agent 写，人负责审规约是否表达了真实意图。规约比实现短得多，人审得过来。
抄到个人项目：普通项目不用上 TLA+，但可以退一步——让 agent 先用自然语言 + 伪代码写出「系统必须满足的性质清单」，人审过后，再让 agent 把每条性质转成属性测试（property-based test）。
第 4 关：透传代理双跑，逐步切流
上线方式是这样的：Pando 最初作为旧系统前面的读写透传代理部署，两套系统保持同步，再把流量一点点迁过来，全程不停机。迁移过程中，Pando 还能先对请求去重、合并再转发，反而减轻了旧后端的压力。
客户端侧，他们通过一个内部的 Git CLI 封装分阶段迁移客户端，同时迁了数百个依赖旧 API、webhook 和仓库下载的集成；还做了 Codex skill，开发者可以直接让 Codex 帮自己迁移开发环境和服务。
抄到个人项目：新旧系统并存一段时间，几乎是重写类项目最稳的上线方式。哪怕只是个人工具站换后端，也可以先让新接口「影子运行」——同一请求两边都跑，只返回旧结果，记录差异，差异清零再切。
四、结果（据 OpenAI 称）
- 切换后 merge 可靠性提升，中位 push 延迟降低近 80%（原文另一处表述为「近 5 倍」）；
- 每天可交付近 1PB 的 Git 数据，曾在单小时内送出超过 57TB 的 pack，其中 99% 以上字节来自本地磁盘缓存；
- 用标准云虚拟机即可让 clone / fetch 跑满 10Gbps 链路；
- 生产流量自今年 4 月开始接入，多项客户端改进已提交到 Git 上游。
再次提醒：以上都是 OpenAI 的自述数据。另外，原文中的架构对比动画被明确标注为「教学用合成模型，不是生产基准」，引用时别把模拟图当实测。
五、给普通开发者的验收清单
把上面压缩成一张可以直接用的清单，下次让 agent 写任何「别人要依赖」的东西前过一遍：
- 行为基线：旧实现的外部行为是否已固化成 agent 能自己跑的测试？
- 时序与不变量：涉及并发、重试、缓存的部分，是否有可重放的随机测试和明确的不变量？
- 性质先行：系统必须满足的性质，是否先写成清单并由人审过，再让 agent 去实现和证明？
- 双跑切流：上线是否有新旧并行、差异可观测、随时可回退的过渡期？
- 压力外溢：agent 提效之后，CI、仓库、预览环境这些下游会不会成为新瓶颈？
这次 OpenAI 案例里最值得带走的一句话不是「10 周」，而是：agent 能写多快，取决于你给它的验收有多硬。测试集、模拟、规约、双跑，每一道都是让人可以放手的前提。
参考
- OpenAI：Scaling Git at OpenAI（2026-11-02）
- Hacker News 讨论：news.ycombinator.com/item?id=50345924