第 4 课：协作模式：流水线、评审、投票

学习目标：

• 区分流水线、生产者-评审者、多视角投票三种协作模式的运作方式
• 判断一个具体任务适合哪种协作模式，说出各自的成本特点
• 理解 handoff 型协作和编排者-子代理型协作在控制权归属上的关键差异

前置要求：完成第 3 课，会写自包含、有明确范围的委派提示词 | 上一课 第 3 课 << | 下一课 第 5 课 >>

前两课讲的编排者-子代理，是「一个中心节点拆任务、多个子代理并行干活、再汇总」这一种结构。但多个 Agent 协作，不是只有这一种搭法。这一课讲三种更具体的协作模式——流水线、生产者-评审者、多视角投票——它们各自适合什么场景、成本花在哪里，最后再看一种跟编排者-子代理完全不同思路的协作方式：直接把控制权交出去。

流水线：一步接一步，下一步吃上一步的产出

流水线（prompt chaining）：「把一个任务拆解成一串步骤，每一次 LLM 调用处理的是上一次调用的输出。」¹ 流水线和编排者-子代理最大的不同在于：编排者-子代理是一个中心 LLM 拆解任务、委派给多个工作 LLM 再整合结果的并行结构¹，流水线是严格的一步接一步，后一步必须等前一步做完才能开始，而且直接拿前一步的产出当自己的输入。

举个例子：写一篇产品发布博客，可以拆成「先写一版初稿」→「把初稿翻译成英文」→「检查英文版有没有术语用词不一致的地方」这三步。第二步的输入就是第一步的输出，第三步的输入就是第二步的输出，谁都不能跳过前一步直接开始。这种结构适合那种天然有先后依赖、下一步必须基于上一步结果才能进行的任务——不像调研三家公司定价那样可以真正拆成互不依赖的几块，流水线里的每一步都离不开前一步。

生产者-评审者：一个写，一个挑毛病，循环几轮

生产者-评审者（evaluator-optimizer）：「一次 LLM 调用生成回复，另一次 LLM 调用提供评估和反馈，如此循环。」¹ 跟流水线的关键区别在这个「循环」上——流水线是走完固定的几步就结束，生产者-评审者是「写一稿→评审给意见→照着意见改→再评审」，直到评审这一方满意（或者达到设定的最大循环次数）才停下来，中间要循环几轮通常事先并不确定。

比如让一个 Agent 写一段处理支付逻辑的代码，另一个 Agent 专门检查这段代码有没有漏处理某些边界情况（比如金额为负、并发重复提交）。如果评审 Agent 挑出了问题，代码会打回给生产者 Agent 重新改，改完再送去评审，直到评审 Agent 认为没有明显问题。这种结构适合那种「有没有做好」不是一次就能判断准确、需要反复打磨才能收敛的任务——第一版产出往往不是最终版本，评审这一步存在的意义就是把明显的问题在正式交付前挑出来，逼着生产者再改一轮。

多视角投票：几个人各自判断，看法一致才算数

多视角投票：让几个 Agent 各自独立对同一份内容做判断，而不是接力式地一步步处理。官方给出的例子是代码安全审查：「审查一段代码有没有漏洞，用几个不同的提示词分别审查，如果哪个提示词发现了问题就标记出来。」¹ 这里的「几个不同的提示词」各自独立看同一段代码，谁都不依赖别人的判断，只要有一个提示词标记出了问题，这段代码就会被标记出来，值得进一步复核。

这种模式跟生产者-评审者不一样——投票不是「写一稿、改一稿」的循环，几个 Agent 是并行地、独立地对同一份已经存在的内容下判断，目的是靠多个不同角度的检查让「漏检」的概率降下来，而不是靠反复修改让内容变得更好。适合那种「宁可多花几次调用、也不想漏掉问题」的场景——安全审查、合规检查这类任务里，漏掉一个真实存在的问题，代价往往比多花几次 token 严重得多。

三种模式怎么选，各自成本花在哪

三种模式的成本结构不一样，选的时候得对着场景算这笔账：

• 流水线：总成本大致是几步调用的总和，步骤数固定、可预测，但因为是严格顺序执行，总耗时是每一步耗时的累加，跑不快；适合步骤之间有明确先后依赖、每一步范围都比较小的任务。
• 生产者-评审者：成本取决于要循环几轮才能收敛，轮数不确定，一旦生产者和评审者反复拉锯，成本可能远超预期——这也是为什么使用这个模式时通常要给循环设一个最大轮次上限，避免无限打转。适合「第一版大概率不够好、需要反复打磨」的任务。
• 多视角投票：成本大致是「单次审查成本 × 参与投票的 Agent 数量」，用几个 Agent 就多花几倍成本，是一笔直接的乘法账；适合「漏检代价高、宁可多花钱也要提高覆盖面」的任务，不适合成本敏感、内容本身风险不高的场景。

选哪种，先回到任务本身的形状：任务有没有天然的先后步骤——有就考虑流水线；产出质量需不需要反复打磨才能达标——需要就考虑生产者-评审者；漏掉问题的代价高不高、值不值得多个角度重复检查——值得就考虑多视角投票。三种模式也不互斥，一份完整的工作流里，可以先用流水线走完固定的几步，其中某一步再嵌套一个生产者-评审者循环，第 6 课会具体动手搭一个这样的组合。

另一种协作方式：控制权直接交出去

前面几种模式都有一个共同点：编排者（或者流水线里承上启下的那个节点）始终掌控着全局，子代理做完就把结果交回来，不会自己接着往下指挥。但还有一种完全不同的协作思路——handoff：「对等的 Agent 之间把控制权交给一个专门的 Agent，由它接管对话。这是去中心化的。」²

Handoff 跟编排者-子代理的核心区别，不只是「谁掌控全局」，还包括新接手的 Agent 看到的信息量完全不同。官方文档说得很明确：「发生 handoff 时，就好像新的 Agent 接管了对话，并且能看到此前的完整对话历史。」³ 这是默认行为——官方也提供了 input filter 之类的配置来改变新 Agent 能看到的历史范围。这跟第 2、3 课讲的子代理机制正好相反——子代理默认从全新、独立的上下文开始，看不到之前的对话⁴；handoff 接手的 Agent 默认反而能看到完整历史，因为它不是被临时派去做一件孤立任务再交回结果，而是真正接管了这场对话，之后由它继续跟用户或者下一个环节打交道。

这种差异决定了两种协作方式适合的场景不同：编排者-子代理适合「拆出一堆独立子任务，做完各自交结论，中心节点继续掌控全局」的场景；handoff 适合「随着对话推进，发现接下来该由另一个更专门的 Agent 来处理，把整场对话原封不动地交接过去」的场景——比如客服场景里，通用客服 Agent 判断出用户问题涉及退款，把整段对话交给专门处理退款的 Agent，退款 Agent 接手后不需要用户再重新描述一遍问题。不过这种控制权转移仍然发生在同一次运行内部：「handoff 停留在单次运行范围内。」³

小结

• 流水线把任务拆成一串有先后依赖的固定步骤，每一步处理上一步的输出¹，适合步骤之间天然有顺序、不需要往回打的任务。
• 生产者-评审者是「写一稿、评审给反馈、照着改、再评审」的循环，直到收敛为止¹，适合产出质量需要反复打磨才能达标的任务，成本取决于循环轮数，通常要设最大轮次上限。
• 多视角投票让几个 Agent 并行独立判断同一份内容，只要有一个角度发现问题就标记出来¹，适合漏检代价高、宁可多花几倍成本也要提高覆盖面的场景，成本约等于单次成本乘以参与判断的 Agent 数量。
• 三种模式选哪个，先看任务本身的形状：有没有天然的先后步骤、需不需要反复打磨、漏检代价高不高——三个问题分别指向流水线、生产者-评审者、多视角投票。
• Handoff 是另一种协作思路：Agent 之间把控制权直接交出去，由接手的 Agent 接管对话，默认能看到此前的完整对话历史³，这跟编排者-子代理里「子代理从全新独立上下文开始、只回传结论」的机制正好相反⁴——handoff 停留在单次运行范围内，适合「接下来该换一个更专门的 Agent 接着处理这场对话」的场景²。

>> 第 5 课：失败与协调