多智能体团队的三种协作模式，以及让我的团队不再陷入死循环的三条规则

我一直在把多智能体团队集成到一个浏览器自动化工具里，难点不在于智能体本身，而在于协作。下面分享最终奏效的几种模式，希望对正在做类似事情的人有所帮助。三种工作方式（团队选其一） **领队分派**：一个智能体拥有 `delegate_to(agent, task)` 工具，负责规划、分派任务并汇总结果。适合开放式目标。 **流水线**：成员按固定顺序运行，每个成员接收上一个的结果。适合步骤已知但每步需要判断力的场景（研究 → 写作 → 改写复用）。 **开放圆桌**：由用户通过 @提及 指定由谁回答，该智能体也可以转交任务。适合有人类主导方向的场景。 三条制止混乱的规则 **转交必须遵循拓扑图。** 智能体只能向拓扑图允许的队友委派任务，不允许"人人互相交流"。 **转交只携带任务本身和它需要的结果，而不是整个对话。** 上下文更小，跑偏更少，成本也更低。 **每条对话线程都有预算：步数、转交次数和云端 token 用量。** 一旦触及任一预算，线程会暂停（提供"继续 +N 步"的选项），而不是任由它空转。 还有两点我肯定会再次坚持： **团队规则只能收紧成员的规则，绝不能放松。** 在严格团队中，原本宽松的智能体也会变得严格。 **团队之外的智能体间请求不允许递归。** 被请求帮忙的队友不能再转而请求别人，因此请求永远不会循环。 编排逻辑是纯代码实现，只注入了"运行单个成员"这一步骤，因此可以用假的智能体做单元测试。相比纯提示词的协作方式，这让逻辑推理和调试容易得多。 披露：这些内容出自 AWFlow，一个由我开发的免费扩展（智能体在浏览器中运行，支持本地或云端模型）。 很好奇其他人的做法：你们会让智能体自由对话，还是对拓扑结构加以限制？