Git-fu：Pando 与 @tnm 团队的公开亮相

原文与翻译

原文（查看原帖）：

We know some Git-fu. Excited the team is finally able to talk about it a bit. Massive props to @tnm and team

中文翻译：

我们会一点 Git 功夫。很高兴团队终于能稍微公开聊聊这件事。向 @tnm 和团队致以巨大感谢。

来源标注：@thsottiaux · 原帖链接

背景

同日 OpenAI 工程博客发布 Scaling Git at OpenAI（2026-11-02）：介绍内部 Git 后端 Pando。作者署名为 Aaron Friel、Taylor Blau、Ted Nyman（即帖中的 @tnm）。

官方要点（可核实）：

• Codex 带来的并行开发使 monorepo 上的 push/fetch/merge 压力剧增，旧系统可靠性一度跌破 90%。
• Pando 在保持 Git 协议/客户端兼容的前提下重做后端；生产中 中位 push 延迟下降约近 5 倍（约 80%），每日可交付近 1 PB 的 Git 数据。
• 设计取舍包括：放宽全仓库强一致、复用 packfile 以服务海量并发读写；并向 Git 上游贡献改进。
• OpenAI Developers 等账号同步宣传；有报道称 Brockman 提及考虑向外部提供相关能力（属公开讨论意向，不等于产品已上架）。

Tibo 的「Git-fu」即对此工程叙事的非正式背书，并明确把功记在 @tnm 团队上。

意味着什么

• Agent 规模会压垮传统源码设施：不是口号，而是 OpenAI 用真实故障率与延迟数据讲清楚的原因。
• Codex 战略外溢：写代码的 agent 变多之后，公司必须自研「Git 的后端」，说明竞争下一阶段可能在工具链与托管基础设施。
• 开源姿态：保留 Git 兼容 + 回馈上游，降低内部工具与社区生态的割裂成本。

我的观点

这是本周信息密度最高、可核实度也最高的帖之一。对中国团队的启发很直接：评估 coding agent 时，别只看模型，还要看 CI、仓库、权限、包管理 会不会先被自己的 agent 流量打穿。Pando 是大厂答案；中小团队至少要提前做容量与合并冲突预案。