一天里我得有四五次，在同一个仓库里同时开三个 Claude Code 窗口：一个改接口，一个补测试，一个写迁移脚本。晚上合并的时候，我在那儿人肉对 diff，对了快四十分钟，还得回想哪个窗口先碰的这个文件。
十月底 arXiv 上挂了个基准，叫 ParallACT，测的就是这件事。场景设在一个多 agent 共享的代码仓库里，没有中央调度者，谁也不知道谁在干嘛。我那三个窗口，一模一样。
结果很难看。一个 agent 一次性拿到全部任务描述的“神谕”基线，大部分活儿都能干完；拆成几个并行 agent，成功率往下掉。互补型任务（各自单看都有价值，但得共享同一套接口才合得上）已经在掉；矛盾型任务（两个 agent 必须以互不兼容的方式改同一段代码）直接崩：Claude Code 配 Opus 4.8，62% 掉到 16%。
16%。我盯着这个数字看了一会儿，不算意外，是太符合体感。
论文还试了六种配置，两套运行框架搭三个开放权重模型，差距一样在。所以这不是哪家模型运气不好，是“没有调度者的并行”这个结构本身的问题。多智能体编排这阵子被演示得很多，五个窗口并排，进度条一起跑，看着特别唬人。问题在演示里从来没有 merge 那一步。
有个细节挺扎人：矛盾型任务里，合并出来的代码通常只满足其中一方写的规范。另一方那套逻辑等于白写。不是写错了，是写完了没人认。
最有意思的是他们动的那几个变量：执行顺序、彼此可见性、知不知道有同伴、有没有通信通道。只告诉 agent“你还有个同事”，基本没用。给一条通信通道能捞回来一点，token 花得更多，捞回来的还不够付账的。
⚡ 真正决定成败的不是通道，是一个 agent 手里有没有全部信息。信息给全，一个就够；信息拆散，五个也白搭。
所以我现在的做法特别土。开新会话之前先写一份简报，把几个窗口本来该互相知道的东西全塞进去：
只动 src/api/ 下这三个文件
接口签名定死在 docs/api.md，不许改
测试跑 pytest -k api，别碰 conftest
然后一个会话，从头做到尾。中途断了 resume 回来接着干，不留第二个窗口。五分钟写简报，换四十多分钟的人肉合并，一天一次的话这周就回本还带找零！
真要并行，按目录切，别按任务切。任务是纵向的，接口横穿所有任务；按任务切，接口必然打架。按目录切，冲突面积最小。这条我没法给你证明，就是这半个月试下来最不疼的切法。
开头那句“别开第二个窗口”得补个限定。仓库大到一份简报塞不进上下文的时候，你还是得分。那时候就老实承认自己是在做协调工作，别管那叫并行提速。协调是活，是要占时间的，把它算进预算里，很多决定立刻不一样了。
还有一条得回来更正。就上个月，我还在跟人说多开窗口是今年最值的肌肉记忆，一个卡住就切另一个。现在收回一半：切窗口确实爽，爽的是“我没被卡住”这个感觉，不是产出。感觉和产出中间隔着一次 merge，而 merge 从来没被算进那个“翻倍”里。为了省三秒钟研究一下午的事我干过，为了看起来忙而多开两个窗口的事，我也干过。
论文说这个难题会越来越普遍，独立 agent 各自开工，谁也没空看别人。我信，但不等谁来造调度器。眼下的调度器就是我自己：写好简报，定死接口，只开一个窗口。
你要是有一边并行一边还能合得上的写法，教教我，我是真没找到。