Codex 把 OpenAI 的 Git 压垮了，于是有了 Pando，但协调难题还在楼上
agent 烧的不只是 GPU，它还会把最无聊的基础设施压垮。OpenAI 周一发的工程博客讲 Pando，到周二在 HN 拿了 261 分，里面有个难得的一手数字：大约从去年底开始，它 monorepo 背后的系统可靠性一度跌破 90%，fetch 慢，合并失败，原因是 Codex 让工程师可以同时干更多活。
Pando 是一个新的 Git 后端，客户端和协议还是 Git，所以没人需要改工作习惯。设计上的关键是放弃了 Git 托管通常承诺的一件事。每个分支单独协调，互不相关的分支推送不再抢同一把锁。代价也写得很直白：同时看几个分支的读者，看到的可能是不同时间点的状态。读取走缓存里共享的 packfile，不再给每个客户端单独打包。OpenAI 自报的数字是推送延迟中位数降了将近 5 倍，每天提供将近 1PB 的 Git 数据。这些都是自报，而且这种规模的问题目前没几家公司有。但凡在跑 agent 集群的团队，都在朝它的小号版本走。
同一周的两篇论文，说的正是 Pando 解决不了的事。ParallACT 拿并行 coding agent 和单 agent 上限对比，在需求相互矛盾的任务上，Claude Code 配 Opus 4.8 从 62% 掉到 16%，另外六种配置也有同样的落差。告诉 agent 有同伴存在，没有明显帮助。给它们开个沟通渠道，只能找回一小部分，还要多花 token。Switch-SWE 看的是另一种并行，也就是没做完的活穿插在一起，七个 coding agent 平均掉 11.5 分，加一个上下文管理插件能在 OpenCode 上找回 5.5 到 15.5 分。
合起来看：并行写入的存储问题，只要你有 OpenAI 的预算，已经能解决了，但合并这些写入背后的意图还没有。你的 Git 可以一小时吃下一千次推送，这些推送彼此是否一致是另一个问题，而 agent 越多越糟。
Pando：https://openai.com/index/scaling-git-at-openai/ ParallACT：https://arxiv.org/abs/2611.00314 Switch-SWE：https://arxiv.org/abs/2611.02017
← 返回所有文章
Pando 是一个新的 Git 后端，客户端和协议还是 Git，所以没人需要改工作习惯。设计上的关键是放弃了 Git 托管通常承诺的一件事。每个分支单独协调，互不相关的分支推送不再抢同一把锁。代价也写得很直白：同时看几个分支的读者，看到的可能是不同时间点的状态。读取走缓存里共享的 packfile，不再给每个客户端单独打包。OpenAI 自报的数字是推送延迟中位数降了将近 5 倍，每天提供将近 1PB 的 Git 数据。这些都是自报，而且这种规模的问题目前没几家公司有。但凡在跑 agent 集群的团队，都在朝它的小号版本走。
同一周的两篇论文，说的正是 Pando 解决不了的事。ParallACT 拿并行 coding agent 和单 agent 上限对比，在需求相互矛盾的任务上，Claude Code 配 Opus 4.8 从 62% 掉到 16%，另外六种配置也有同样的落差。告诉 agent 有同伴存在，没有明显帮助。给它们开个沟通渠道，只能找回一小部分，还要多花 token。Switch-SWE 看的是另一种并行，也就是没做完的活穿插在一起，七个 coding agent 平均掉 11.5 分，加一个上下文管理插件能在 OpenCode 上找回 5.5 到 15.5 分。
合起来看：并行写入的存储问题，只要你有 OpenAI 的预算，已经能解决了，但合并这些写入背后的意图还没有。你的 Git 可以一小时吃下一千次推送，这些推送彼此是否一致是另一个问题，而 agent 越多越糟。
Pando：https://openai.com/index/scaling-git-at-openai/ ParallACT：https://arxiv.org/abs/2611.00314 Switch-SWE：https://arxiv.org/abs/2611.02017
评论