并行 Coding Agents 真正缺的不是更多模型，而是可失败的验证器

过去一周，AI agent 相关讨论里有一个很实在的方向：让多个 coding agents 并行跑研究任务。这个方向听起来像“多开几个 Claude Code 或 Codex CLI”，但真正难点不在并行，而在验证。

arXiv 6 月 25 日提交的 Glite ARF 论文，把这个问题讲得比较具体。它的场景是经验型研究：人类研究者提出假设，多个 coding agents 在同一个研究仓库里实现实验，最后由确定性 Python verifier 检查任务隔离、产物不可变、修正覆盖层和项目总览。

这篇论文值得关注，不是因为它宣称 agent 能自动做科研，而是因为它把 agent 失败这件事当成系统设计前提。

多 agent 会放大低频错误

单个 coding agent 偶尔漏看一句指令，用户还能靠人工审查补回来。多个 agent 并行跑 100 个实验时，这种低频错误会叠加成灾难：

• 某个任务偷偷改了共享文件。
• 已完成实验被后续任务覆盖。
• 指标表里混入了过期结果。
• 某个 feature set 发生目标泄漏。
• 总结文档和实际文件状态不一致。

这些问题靠“请严格遵守要求”解决不了。agent 的可靠性不能只写在提示词里，必须写进会失败的程序里。

Glite ARF 的核心思路就是 verifier-driven research：研究流程规则放在代码里，违反规则时直接失败，而不是把规则写成一段长提示词，期待模型每次都记住。

三层角色比“全自动”更现实

论文里的角色分工很清楚：

• 人类研究者决定要测试哪些假设。
• coding agents 执行单个任务，负责实现、运行、修正。
• verifier scripts 负责检查结构性约束。

这个分工比“agent 自己提出想法、自己实现、自己判断结果”更接近现阶段可用产品。人仍然控制研究方向，agent 提供吞吐量，验证器提供边界。

论文给出的案例也有工程含金量：在一个 BEA 2026 词汇难度 shared task 中，系统跟踪了 273 个任务，其中 146 次是实验运行，覆盖 129 组特征，最多 12 个并行 agent 从一台笔记本协调执行。作者还提到，通过结构化 provenance 发现并剔除了 4 组目标泄漏特征。

这里最有价值的不是名次，而是 provenance。没有可追溯记录，agent 跑出来的好成绩反而危险，因为你不知道成绩来自真实信号、偶然运气，还是泄漏。

对工程团队的启发

如果你想在团队里用多个 coding agents，先不要急着做“agent 管理平台”。更值得优先做的是一组可执行约束：

• 每个任务只允许改自己的 worktree 或任务目录。
• 已完成产物默认不可改，修正必须走 overlay。
• 所有实验参数和结果都要结构化落盘。
• 总览文档由脚本生成，不靠 agent 手写。
• 每次任务完成必须通过 verifier，失败就不能进入汇总。
• agent 的成本、运行时间、失败原因要可统计。

这样做的结果是，agent 变成可替换劳动力，而不是系统里唯一知道发生了什么的黑盒。

这不是把人拿掉，而是把人放到更高层

并行 coding agents 最容易被包装成“一个人顶一个团队”。这个说法没什么工程意义。更准确的说法是：人类从逐行实现者，变成假设设计者、验证规则编写者和异常裁判。

只要验证规则不够强，agent 数量越多，风险越大。只要验证规则足够硬，agent 数量才会变成吞吐量。

这也是最近 agent 工程的一个变化：大家不再只讨论“模型会不会写代码”，而是在讨论代码进入仓库、实验进入论文、改动进入生产之前，谁负责把不可靠的步骤挡住。

参考资料

• arXiv: Glite ARF: Verifier-Driven Research with Parallel LLM Coding Agents
• Anthropic Engineering: Building effective agents