多 agent 协作的瓶颈，是版本控制

速评：Cursor 上半年那轮多 agent 实验，最值得抄的作业不是模型选型，是那套从零现写的版本控制。这话三个月前放出来没人信，数据砸脸上了，不信也得信。

旧 harness 什么样？Grok 4.5 跑了不到两小时失控被暂停，六万八千次提交，七万多次合并冲突——提交数比冲突数还少，等于每次动笔都跟人撞一次。单文件冲突最高 7771 次，一个文件被 1173 个代理碰过。这已经不叫协作，叫一千多号人同时在 54 个 crates 的工地上开工，还没有工头。

新 harness 四小时总冲突不到一千次，最忙的文件只有 47 次。测试通过率差距更直观：新系统最低 73%，旧系统最高 77%——一个的底线，是另一个的天花板。区别在约束：新系统让所有变更流经那层自研版本控制，冲突暴露的位置从“事后合并”挪到“写下来的那一刻”。规划者打架就翻共享设计文档，编译检查拿代码引用当威慑，合并冲突交给中立第三方仲裁，巨型文件膨胀就冻结新提交、由外部代理拆开。全是人类工程管理常识的自动化，只不过这次管的是 agent。

成本也拉开了：同样做到 100% 通过率，Opus 4.8 混合配置 1339 美元，GPT-5.5 单模型 10565 美元，差近八倍。代码量从六万四千行缩到九千九。不是模型变聪明了，是约束替它们删掉了废动作。

还有个八卦：GPT-5.6 Sol 本来是内定前沿配置，结果它对字面和强调措辞过度敏感，钻进自己的发散循环出不来，团队为了对比公平换回 GPT-5.5。一个被语气带沟里的模型，确实不适合带队。

要说这轮实验证明了多 agent 一定赢单模型，我不认。单任务的效率、成本、确定性都还差得远。但这轮实验确实回答了一个悬了很久的问题：一群 agent 到底能不能协作干成一件事。答案不在模型多聪明，在它们被关进什么样的笼子。

这里立个 flag：接下来半年，agent 编排赛道的竞争重点在协作基建，不在单模型跑分。谁先把每秒上千次提交的节奏接稳，谁就先赢了一半。