并行 coding agent 被讲得挺玄。说法一般是“多个 agent 一起写，快得飞起”——可我每次看到有人真跑起来，剧本都一样：俩 agent 改同一个文件，互相踩，一个把另一个的活儿覆盖掉。我一直想把这里面的岔路口画成图，前阵子翻到一篇论文刚好把这事儿量化了，顺手画了。
先画我以前脑子里的图：
agent A ──写──► 文件 f
agent B ──写──► 文件 g （A、B 各管各的，并行，没事）
我一直以为冲突的根源是“碰巧改了同一个文件”。论文的数字直接把这张图撕了：30 个特性配对里，一半提前标记成“冲突型”，另一半是“干净型”——就这样，不做任何约束地放开并行，配对通过率只有 23.3%。干净的那一半也没干净到哪去。所以问题根本不是“撞文件”，是两个 agent 对“我要动哪块地盘”压根没对过话。
论文的机制叫 Claim Plane，说白了一条土规矩：写之前先声明你要碰哪些文件，声明过了才准入。画出来：
agent A ──声明──► [准入闸门] ──► 写
agent B ──声明──► [闸门：A 占着呢，等着] ──► 排队
效果数字挺唬人：整体通过率 23.3% 到 50.0%，集成成功率 65.6% 拉到 96.7%，冲突型配对从 6.7% 翻到 60.0%。我第一眼看到 96.7%，心想这不就成了吗。
等等等等，先别急。
往下读才发现，静态版这个闸门把 96.7% 的执行直接串行化了——连 93.3% 的干净案例都在排队。也就是说，所谓“可靠性提升”，很大一块是把并行干成了接近串行。这哪是协调，这是把高速公路改成一车道，然后宣布事故率下降了。
打个比方：公司怕开会吵架，干脆规定所有议题一个一个过。会议确实“成功”了，可大家本来就是为了一起开会省时间才来的。这个比喻在这里漏风，得老实标出来——写代码不是开会，串行不一定错，如果串行完总耗时还是比单 agent 干完所有活儿短，那也赚。但论文自己承认了：没证实有用的墙钟加速，provider 那边的调用物理上就是串的，保守策略又把负载压成串行。所以“值不值”这题论文压根没答，它只答了“可靠”。
然后是我全文最喜欢的一段——动态版翻车实录。
作者显然也觉得全串行太怂，做了个动态准入：只在看起来真要撞的时候才拦。这版确实挑剔多了，冲突案例里 66.7% 被串行，干净案例只拦 13.3%。听着挺聪明吧？结果 90 次执行里 46 次因为“没声明范围”直接失败，配对通过率掉到 22.2%，比啥都不管强不了多少。
我盯着这 46 次看了半天，脑内只有羊叫。真正扎心的是后续分析：这 46 次阻塞里有 45 次，指向的文件在冻结的规划声明里其实写了。不是 agent 不知道自己要碰哪，是声明没覆盖住、出了岔子也没兜回来。翻译一下：不是没地图，是地图漏了一条街，而闸门按地图办事，铁面无私地把车拦在路口。
这格“声明从哪来、错了怎么修”，我第一版画图的时候根本没画。当时画的是“agent 声明→闸门放行”，一条线，挺顺。真跑起来声明本身就会烂——规划是 DeepSeek V4 Pro 一口气生成的 60 份、全程冻结，执行是 V4 Flash 干的，规划里漏一个文件，执行侧一点办法没有。看了一眼第一版那张图，想把自己关进小黑屋。重来，补一格：
规划声明（一次生成，冻结）──► 执行 agent ──► 实际要碰的文件
└──── 两边对不上？闸门只会说"没声明"，不会说"声明错了" ────┘
咔哒一下扣上了：静态版赢在笨——反正都排队，声明漏不漏无所谓；动态版输在聪明——它信声明，声明偏偏会漏。可靠性不是闸门给的，是“别太信中间产物”给的。
所以我现在对“并行 agent 冲突怎么解”的图长这样：真正的岔路不在“拦不拦”，在“声明这层是不是活的”。静态 Claim Plane 证明准入这个思路压得住冲突，代价是并行名存实亡；动态版证明的是，你拿一份静态地图去管动态施工，地图的误差会原样变成失败率。两版合起来读，比单独吹哪一版都清楚。
这玩意儿真的太酷了——一个“写之前先报备”的土规矩，能把整个问题的真实瓶颈暴露成“声明从哪来”。论文的工件和哈希都放了，我打算哪天把那 45 次指向已声明文件的阻塞捞出来看看，到底是怎么漏的。看懂了再补一段。
自检留一个：你能用自己的话讲明白，为什么动态版反而比不拦还容易翻吗？卡在哪一格告诉我——多半那一格我也还没画明白，咱们一起补。