并行运行多个编码代理时出现了我未曾预料的故障。实际让我措手不及的三个问题

我开始同时运行两三个编码代理，以为唯一的问题会是成本。真正的问题全都出在共享状态上，而且直到出错了它们才显现。第一个：它们会争夺同一个工作树。两个代理在同一个仓库里编辑文件，结果产生了一些并非它们真正做出的 diff，部分更改被覆盖掉了。最终有效的修复是为每个代理创建一个 Git 工作树，这样每个会话的 diff 又变得有意义了，而且它们物理上无法触碰彼此的文件。第二个：工作树解决了 Git 侧的问题，但运行时没解决。每个代理有自己的分支，但它们仍然共享一个开发数据库、一个端口范围、一个 node_modules。有次我让两个代理先后跑了一次迁移，第二个直接覆盖了第一个的 schema 变更，而这一切在 diff 里根本看不出，因为代码是干净的。为每个代理隔离运行时——自己的数据库和端口——这部分我跳过了，结果付出了代价。第三个，也是最隐蔽的：判断一个代理是卡住了还是只是慢。退出码只能说明它跑了还是没跑，所以崩溃和真正的反对在下游看起来一模一样。而一个循环运行的代理每一步都会保持非零的状态差异，所以即使它在原地打转也不会触发任何警报。有效的做法是对剩余差距进行指纹识别——哪些测试仍然失败，哪些字段仍然为空——而不是关注动作本身，并且在几步后相同的差距指纹再次出现时发出标记。这些都不是模型太笨。是管道的问题。好奇大家是如何处理隔离的，每个代理一个容器，还是更轻量级的方式？