我在这里询问了大家使用什么作为协调器，以下是你们的回答实际改变的内容。

大约一周前，我在这里发帖询问了大家在多智能体设置中使用什么作为协调器。收到的回复比我预期的多得多，其中很多改变了我的实际做法，因此觉得后续跟进是公平的。讨论中得出的三点共识，来自一些彼此不知情的人：基于命名条件升级，而不是基于模型自身感觉有异常。arthaudm 说验证器不一致或不可逆操作。HeyZaney 说验收标准失败或范围变更。Low_Box_752 说模式验证失败或两个角色意见不合。三个人，独立地，形成了相同的模式。触发器必须是你可以命名的东西，而不是模型报告的感觉。一个简单的确定性协调器配以智能工作者，而不是大语言模型决定控制流程。Low_Box_752、_Ojin 和 saltexx 都从不同方向得出了这个结论。将确定性作为协调器席位的标准，而不是原始能力。RPG-Nerd 和 onlya_shadow 都这样认为。这一点我之前确实没有重视，我过去选择协调器是基于它的聪明程度。这三点的共同之处是状态不应该存在于对话中。这对我是真正重要的改变。计划是磁盘上的真实文件，任务是行，依赖关系被声明，执行在任务旁写报告，验证写独立证据。会话可能终止，上下文可能压缩，模型可能被替换，新会话读取工作停止的地方，而不是让我重建它。plan.md ┌──────┬──────┬──────────┬────────┬─────────────┐ │ 任务 │ 依赖 │ 角色 │ 状态 │ 报告 │ ├──────┼──────┼──────────┼────────┼─────────────┤ │ 1 │ — │ worker │ done │ work_1.md │ │ 2 │ — │ worker │ done │ work_2.md │ │ 3 │ 1,2 │ worker │ ready │ — │ └──────┴──────┴──────────┴────────┴─────────────┘ │ ▼ 依赖解析器 │ ┌─────────┴─────────┐ ▼ ▼ 任务 1 任务 2 ← 波次 A，一起运行 │ │ （可能来自不同提供商） └─────────┬─────────┘ ▼ 任务 3 ← 波次 B，等待 1 和 2 │ ▼ 验证 ← 当可用时使用不同提供商一旦依赖关系明确，波次就自然形成。没有依赖的任务一起运行，任何依赖它们的任务则等待。一个区分让我花了比应该更长的时间，它来自 arthaudm 的追问。波次回答任务何时可以运行，路由回答谁运行它。不同的维度。一个波次可以将三个任务交给三个不同的提供商。在验证方面，我最初制定了一条规则，即验证器不能是编写代码的模型。听起来足够，但并非如此。opus 被 sonnet 检查是两个模型，但属于同一提供商后的同一家庭，我希望验证器具有更独立的故障面。因此，现在它跨越提供商边界，当池子允许时，并在调度行中说明，当链没有替代方案时。真正改变代码的评论是 saltexx 的。我有一个代理调用退出码为 0，基本上什么都没做，写了一份令人信服的报告，并被评为通过，因为报告是唯一被检查的东西。saltexx 的观点是这是一个文件系统问题，而不是判断调用，给工作者自己的工作树，空的差异就能回答它。我发布的就是这个想法。对工作区进行内容哈希，排除任务自己的报告文件夹，这样写报告不能看起来像在做工作。如果代理写证据，它就不是证据。我运行所有这一切的工具是一个名为 wb-flow 的小型 MIT 许可工具。免费，无需注册，33 个 markdown 命令过程，没有协调守护程序。它不是本文有趣的部分，我更愿意讨论上面的内容，但上次有人问，所以它出现在这里而不是隐藏起来。仍然存在缺陷：跨提供商验证意味着验证器不共享执行器的环境，我因此得到了两个误报（验证器的沙箱无法启动它应该测试的 CLI）。因此，独立验证给我带来了独立性加上一种新型的假阴性。正在努力解决。对于任何回答了第一个线程的人，升级条件这一点是我最低估的，而且几个月来我对协调器席位的判断都是错误的。