我差点打破了将代理编码与氛围编码区分开的那条规则

我在Claude Code之上构建了一个观点鲜明的多智能体设置。我尤其对其中两个智能体感到自豪：一个进行红绿TDD的软件工程师，以及一个运行对抗性边缘用例通过的独立测试员。系统运行正常，但也慢得令人痛苦。每次智能体来回交互时，测试员都会重新运行软件工程师刚刚运行过的linter、类型检查器、格式化工具和快乐路径套件。我为同样的检查支付了两次费用。这种重叠是导致系统能够工作但慢到无法使用的首要原因。显而易见的做法是合并两个智能体并消除重复。但那是错误的做法。原因在于那条将代理编码与氛围编码区分开来的规则：没有任何单个智能体应该既编写代码又判断其是否正确。这种结构分离至关重要的原因有四个。 1. **这界限是结构性的，而非风格上的。** 一旦某个智能体既是作者又是评判者，你就会停止验证，开始信任自己的输出。这就是带有额外步骤的氛围编码，无论该智能体拥有多少工具。 2. **当分离变得昂贵时合并角色会破坏规则。** 合并智能体会让你回到一个智能体自我批改作业的状态。治标不如治本。 3. **保持智能体分离，转而移动信任边界。** 正确的做法不是合并角色，而是缩小每个智能体对另一方的信任范围。作者永远不是攻击自己作品的合适人选。这正是分离所要防止的失败模式。 4. **通用化规则。** 当你赋予一个智能体两项职责，其中一项是“判断这是否良好”时，请拆分该智能体。当拆分代价高昂时，不要撤销它。缩小评判者重新运行的范围，仅限于作者无法可信地自我验证的部分。工作作者与工作评判者保持分离。信任边界发生移动。 当测试员重新运行软件工程师已经运行过的linter、类型检查器、格式化工具和快乐路径套件时，我们为所有内容支付了两次费用。这是导致系统能够工作但慢到无法使用的首要原因。修复方法不是合并角色，而是限制信任：测试员现在只运行软件工程师无法可信地自我验证的部分。 这条规则是我运行的一个名为Squid的六智能体Claude Code设置的核心。它使用一个项目经理/架构师、一个软件工程师、一个测试员、一个PR审查员、一个值班员以及一个可选的自我改进元智能体。我在整个生命周期中使用两个人工门控和五个重试上限。完整团队和生命周期详见链接文章。 诚实提醒：准确界定软件工程师能够可信地自我验证的内容本身就是一个判断问题。弄错了会导致虚假信心，这是此类系统中最糟糕的失败模式。我仍在迭代这条界限的位置。 在你自己的智能体设置中，哪个智能体既编写工作又判断其是否正确？当分离变得昂贵时，你是否合并了？ **TL;DR：** 代理编码与氛围编码之间的结构界限在于，没有任何单个智能体既编写代码又判断其是否正确。当这种分离变得昂贵时，缩小评判者重新运行的范围。不要合并角色。