20 个编程智能体并行，构建缓存成关键

大家都在争论哪个模型写代码最好。但当我在一台 PC 上并行运行 20 个 coding Agent 时，拖慢进度的从来不是模型，而是编译器。

并行运行的 Agent 通常各自在独立的仓库副本（git worktrees）中工作。20 个 Agent 就意味着 20 份副本，而每个 Agent 都想在每次修改后构建项目并运行测试套件。

这相当于同时启动 20 次冷构建。在普通台式机上，最先耗尽的是 RAM，接着 CPU 也会成为瓶颈。Agent 只能等着 cargo test 跑完，而运行模型的 GPU 却闲着。

改进 1：按内容缓存测试结果

这些构建大多是重复劳动。处理同一个任务的 Agent 往往会写出完全相同的代码，而且每次修改通常都不会触及大部分文件。

所以，我对输入（源码树、toolchain、命令）计算哈希，并缓存结果。输入相同，结果就相同，无须重新构建。在我的运行记录中，83% 到 85% 的检查直接命中了缓存。

改进 2：Agent 永远不能给自己判分

“完成”不是 Agent 自己说完成了。真正的完成，是由 Agent 之外的独立机制执行实际构建和实际测试，并且全部通过。

改进 3：严格限制它们能修改的内容

源码可写，测试和评分器只读。否则，一个卡住的 Agent 最终会去“修复”失败的测试，而不是修复代码。这不是恶意行为，只是让测试变绿的最短路径。

改进 4：给机器设定资源上限

我限制 RAM 用量（我的机器有 32 GB，只允许使用其中的 21 GB），并限制构建任务的并发量。一个把 PC 搞崩溃的 Agent 集群，什么也完成不了。

改进 5：逐个合并，每次合并都重新评分

Agent 并行工作，但改动必须逐个合并。只有当更多测试通过，并且没有新增失败的测试时，一项改动才能合入。工作可以并行，最终结果必须串行验证。

20 个 Agent，4 轮运行，1,770 项检查全部通过。

结论是：只有当验证成本足够低，而且无法造假时，增加 Agent 才有帮助。在此之前，更多 Agent 只意味着以更快的速度产出更多有问题的代码。

你的环境里，瓶颈是什么？

如果还想采取进一步措施，可以考虑屏蔽此人和／或举报滥用行为。