5 种真正有效的多 Agent 模式

经过几个月的多 Agent 开发工作流实践，有些模式一直反复证明自己的价值。这些不是理论，而是我们每天在用、也能持续看到其他开发者采用的模式。

下面是 5 种真正有效的模式。

1. 代码审查流水线

配置：两个终端图块，单向连接。

Writer Agent → Reviewer Agent

工作方式：Writer Agent 实现一个功能或修复。完成后，输出会被路由到 Reviewer Agent，并附上诸如“审查 src/auth/ 下的改动，关注正确性、安全问题和边界情况”之类的提示词。

为什么有效：AI Agent 会因为提示上下文不同而看到不同的问题。Writer Agent 关注的是正确性和完成度。Reviewer Agent 则在明确的审查标准下，能发现 Writer 视野盲区里遗漏的问题。

提示：使用 on-idle 触发器，并设置 8 秒静默窗口。这样可以确保 Writer 确实结束后再开始审查。再加一个像 “LGTM” 这样的停止关键词，这样 Reviewer 批准后循环就会终止。

典型循环：1 次写作 + 1 到 2 轮审查。对于聚焦明确的变更，通常 10 分钟内就能收敛。

2. 测试生成器

配置：一个实现 Agent，一个写测试的 Agent。

Implementation Agent → Test Agent

工作方式：实现 Agent 构建或修改一个功能。完成后，路由系统把文件变更和提示词一起发给测试 Agent："为认证中间件的改动写单元测试，覆盖正常路径、错误情况和边界情况。"

为什么有效：在实现完成后立刻写测试，代码还新鲜的时候就能以最低成本发现 bug。测试 Agent 拿到的是完整上下文，知道改了什么、为什么改。

变体：反过来写 - 先写测试（TDD 风格），再把测试规范路由给实现 Agent。

3. 并行模块构建器

配置：多个终端图块，没有连接。中间放一个 note 图块用于协调。

Agent A (auth)    Agent B (api)    Agent C (database)
      \               |               /
       \              |              /
        Note: Architecture Plan

工作方式：把一个大任务拆成互相独立的模块。每个 Agent 拿到一个明确模块，并有清晰的接口边界。note 图块里写着所有 Agent 共同参考的架构计划和接口契约。

为什么有效：这是吞吐量最高的模式。三个处理独立模块的 Agent，比一个顺序处理的 Agent 快三倍。关键是先定义好清晰接口，这样模块才能顺利集成。

什么时候避免使用：如果模块之间耦合紧密或共享状态，Agent 会互相踩脚。只在真正独立、接口明确的工作上使用这个模式。

4. 迭代精炼循环

配置：两个双向连接的 Agent，带轮次上限。

Agent A ⇄ Agent B (max 3 rounds)

工作方式：Agent A 先给出初稿。Agent B 批评并提出改进建议。Agent A 根据反馈修订。如此重复，直到达到预设轮数（通常 2 到 3 轮）。

为什么有效：每一轮都会收紧方案。第一轮把结构搭好，第二轮抓 bug 和边界情况，第三轮做润色。3 轮之后收益递减 - 所以上限应该设在那里。

配置建议：使用 ai-routing transform，把每个 Agent 的反馈重写成可执行指令，而不是原始输出。设置 maxRounds: 3 和 cooldownMs: 5000，给每个 Agent 足够时间产出完整回应。

示例提示词：

• 第 1 轮（A→B）："审查这个限流实现的正确性和性能。"
• 第 2 轮（B→A）："应用这些修复：[具体问题]。然后验证这个修复是否处理了并发访问的边界情况。"
• 第 3 轮（A→B）："对修订后的限流器做最终审查。如果可以发布，就回复 LGTM。"

5. Scout 和 Builder

配置：一个轻量、快速的 Agent 负责侦察代码库；一个能力更强的 Agent 负责实现。

Scout Agent → Builder Agent

工作方式：Scout Agent（使用更小更快的模型或更简单的提示词）先探索代码库，回答一些前置问题："支付流程涉及哪些文件？代码库对错误处理通常怎么写？计费模块有哪些测试？"

Scout 收集到上下文后，它的发现会被路由给 Builder Agent，再附上真正的实现任务，这时任务已经带上了代码库特定上下文。

为什么有效：大型实现任务经常失败，是因为 Agent 对现有代码库上下文不够。Scout 阶段成本很低（快模型、只读操作），却能产出让 Builder 更精准工作的上下文地图。

提示：这个模式适合使用 full-output transform。Scout 的输出本身就是结构化信息（文件列表、模式描述），Builder 可以直接消费，不需要再做 AI 重写。

选择合适的模式

这些模式可以组合使用。一个真实的工作流可能先用 Scout 和 Builder 收集上下文，再用并行模块构建器实现，最后用代码审查流水线验证 - 全都在同一个画布上完成。

要避免的反模式

无限循环：两个 Agent 互相路由，却没有轮次上限或停止关键词。它们会开始产出越来越抽象的元评论。一定要设置 maxRounds。

大杂烩：把每个 Agent 的输出都路由给所有其他 Agent。信息会爆炸。每条连接都应该有明确目的。

过早路由：为了一个 2 分钟就能用单个 Agent 完成的任务，去搭复杂路由。配置连接的额外开销不值这个价。

最好的多 Agent 工作流，应该是看起来毫不费力 - Agent 并行工作，输出流向真正需要的地方，而你负责做战略决策，执行在你周围自动展开。