常见的Single-Agent三种推理范式与Multi-Agent四种协作模式

匙亮旭

发布于 2026-06-17 20:58:48

230

Agent的构建方式有很多种，今天给大家介绍下常见的Single-Agent（单Agent）三种推理范式与Multi-Agent（多Agent）四种协作模式。

Single-Agent

首先，先整体看一下我做的这页PPT截图，脑子里先有个印象，后面进行详细解释。

1、ReAct：Reasoning + Acting。这种是现在最常见的推理范式，其执行的每一步都是基于动态决策，并且会根据执行结果动态调整。所以整体的流程，就像上图所示，对于给出的一个任务，模型会先思考后选择合适的工具进行调用，依据返回的结果，再决策下一步如何做，随时都在进行动态调整，直至最后输出结果。整体过程，有些类似于敏捷开发。

适用场景：这种适用于需求相对简单，任务的步骤不确定但是需灵活应对，工具调用链短的场景。

2、Plan-and-Execute：从名字上就可以看出来，先规划，后执行，也很好理解。对于一个给定的任务，先让大模型规划完整的ToDo任务清单，然后智能体会参照已规划的步骤，一步步执行子任务，直到最后的任务结束，输出结果。在执行的过程中，如果遇到执行偏差，可以重新对任务进行规划（Replan操作）任务清单，再执行。整体过程，有些类似于我们使用瀑布式开发的感觉，先全局规划好再做。

适用场景：任务流程长，并且任务间的依赖性高。具体执行子任务时，可串行，也可并行，这取决于模型前期的任务规划。

3、Reflection Loop：自我反思 + 纠错。无论上面你用的是ReAct，又或是Plan-and-Execute方式，都建议和Reflection Loop模式结合起来使用，其对于最终的输出质量至关重要。其核心流程是，对于Agent输出的结果，需要进行质量评估，如果质量不符合要求，需要带着不符合的反馈信息重新执行去生成，如此反复，直至最后生成高质量的结果或是触及了最大的重试次数为止（如果不设置最大重试次数，可能会出现死循环）。

适用场景：对于输出质量要求高，尤其有严格的格式要求和高准确性的场景，一定加这个环节。

Multi-Agent

事实上，对于80%企业Agent场景，Single-Agent可以满足大多数需求，只有当一个Agent职责复杂到无法用清晰的System Prompt描述时，再考虑拆分成多Agent。首先，还是先看下我做的这页PPT截图。

1、Orchestrator-Worker：中央编排协作模式。由一个Orchestrator Agent（调度者，或者称之为编排者）负责理解任务、制定计划、然后分配各个子任务给各个Worker Agent去执行，各Worker Agent执行完成后汇报结果，最后由Orchestrator Agent统一进行聚合输出。

适用场景：任务可以被清晰地拆解为多个独立子任务，并且对最终输出的结果需要有统一的质量把控。

风险：Orchestrator是单点的，如果它理解错了任务，后续Worker的执行都是无用功。

2、Supervisor：监督者协作模式。简单理解，就是有一个领导（Supervisor），随时监控下面干活的人（Sub Agent）干的怎么样，要是干的质量不达标，要求其修改甚至重做。

适用场景：对输出质量有严格要求或者有审批流的业务流程。

风险：Supervisor的判断能力决定了整个系统的质量上限，如果Supervisor自己判断有误，会严重影响最后输出结果，所以Supervisor的背后一定要选择好的模型。

3、Peer-to-Peer：对等协作模式。这个很好理解，就是各个子Agent间相互调用，最后由某个子Agent负责生成最终结果。整体过程可以想象成类似于API间的互相调用。

适用场景：各Agent来自不同团队甚至不同组织，无需考虑各个Agent背后的框架或平台等信息，只需遵守既定的消息传递规范，即可按需灵活动态组合使用完成最终任务。

风险：无全局总控，难以跟踪调用Agent内部执行过程（因为可能是其他团队封装的各个子Agent，相当于黑盒，难以追踪内部执行过程），输出质量难以保证。

4、Fan-out/Fan-in：并行分发 + 聚合的协作模式。将一个大任务，分发给多个Worker Agent并行执行相同或相似的子任务，最后将结果聚合后统一处理。

适用场景：各个子任务之间相对独立，没有强依赖关系。

风险：需考虑部分Worker Agent执行失败、并行策略和返回超时等情况。

最后给这四种常见的Multi-Agent协作模式画了一个矩阵，帮助大家可以更好的理解，可以参考下图所示。