一队编码智能体各自跑，单看每个都通过了自己的测试，合到一起代码却碎了——这种事正在变得常见。两个人改了同一个函数，一个按队友刚刚改掉的契约在写，集成在活干完之后才失败。随着编码 agent 从单人助手变成多人并行的小队，这种「集成期才暴露的集体失败」正从偶发变成常态。大多数单智能体评测根本抓不到这种「团队级」的失败，因为评价对象从一开始就是单独一个 agent。10 月 5 日挂出 arXiv 的 NP-Bench（编号 2610.07261）与它的规划器 Nerveplane，想解决的正是这个被忽视的角落。
把「撞车」从反应式警告，重写成提前调度
作者点出一个扎心的现实：现在多数协调工具是「反应式」的——盯着冲突，等它发生了再警告。可 agent 的速度下，警告到达时那次白改早就发生了。于是他们把问题重铸成调度：拿到每个工作项声明的作用域，预先把工作切成互不重叠的作用域，再沿「生产者到消费者」的依赖图，把合并顺序排好，而且这一切都在动手写代码之前就定下来。本质是把「谁会和谁撞」从运行期的意外，变成规划期的输入。
在真实 git merge 上验证，干净合并不再靠运气
这套思路被做进了 Nerveplane，并用 NP-Bench 来评。NP-Bench 是一个贴着真实环境的「三臂」基准：无协调、反应式检测、主动规划，它直接在真实的 git 合并上校验集成是否干净，而不是用玩具脚本糊弄。结果很说明问题：干净集成的比例从 1/9 升到 9/9，合并冲突从 13 个降到 0 个，而且 agent 数量越多，规划和「事后救火」之间的差距越大。面对「队友刚改了契约」这种破坏性变更，两个基线都是 0 成功率，规划器在强模型上救回到 1.0、在较小模型上也有 0.6，且 agent 守住了分配的作用域（5 次里有 0 次越界）。跨会话记忆把重复犯错率从 1.00 压到 0.00。
一个诚实的负结果
这篇值得尊敬的地方，是它把一条走不通的路也写出来了：把事实路由给 agent，并不能在上下文窗口被填满的尺度上挽救长上下文的精度。它的价值在成本与容量，不在注意力本身。这种「什么没用」的坦白，比一堆漂亮的正向曲线更有用，因为它替后来者省下了重复试错。作者还强调，收益来自「工作怎么分配」，而不来自「模型有多聪明」——跨两档能力、两家厂商，规划带来的好处都没有随模型变强而缩水，因为它动的是工作分配方式。
和本站近期覆盖的编码协调稿是互补关系
把 Nerveplane 放回近期智能体协调的演进里看：本站此前覆盖过 Synara Hubs，它协调 8 个并行编码 agent、靠共享上下文与实时同步来避免冲突，属于「运行期的协调层」；Nerveplane 则是把协调提前到「规划期」，在动手写代码前就拆好作用域、排好合并。两者不是替代，而是同一道题的两种切法——一个管「跑起来之后怎么对齐」，一个管「动手之前怎么不撞」。对正在把多个编码 agent 并行塞进同一个代码库的团队，这篇的提醒很直接：先别急着加更多协调消息，先把工作项的作用域划清、把合并顺序定死，大部分撞车在编码前就消失了。
NP-Bench 的意义，不在于它把某个数字刷得多高，而在于它把「并行编码 agent 为什么会集体翻车」讲成了一个可测、可调度的问题。当一行代码被五个 agent 同时改，决定成败的往往不是谁模型更强，而是那张依赖图有没有被提前排好。