2026 年，Agentic AI 已从概念验证进入企业级落地阶段。但面对多种设计模式，工程师常常困惑：该用 ReAct 还是 Plan-Act？Reflection 和 ReAct 到底有什么不同？何时需要多智能体？本文系统梳理当前业界验证过的核心模式，并附上交互式流程图，帮助你快速定位最适合的架构。

---

一、单智能体模式：一个大脑的思考方式

基础推理层

1. CoT（Chain-of-Thought，思维链）

核心机制：要求 LLM 显式写出中间推理步骤，再给出最终答案。

适用场景：数学计算、逻辑推理、复杂问答。

与工具调用的关系：CoT 本身是纯推理模式，不定义工具调用机制。但可与 ReAct 等模式结合——例如在 ReAct 的 Reason 步骤中，LLM 用 CoT 风格写出推理过程，再决定调用哪个工具。

2. CoT-SC（Self-Consistency CoT）

核心机制：生成多条独立推理链，对最终答案投票。

适用场景：对准确率要求极高、可承受多次生成成本的场景。

与工具调用的关系：可与工具调用结合，例如生成多条包含工具调用的路径后投票。

⚠️ 成本提示：调用成本为 CoT 的 N 倍，适用于对准确率要求极高且可承受成本的场景。

---

行动-推理层

3. ReAct（Reasoning + Acting）

核心机制：推理与行动交替循环、紧密耦合。每步都调用 LLM：分析状态 → 决定行动 → 执行工具 → 观察结果 → 继续推理。观察结果立即反馈到下一步。

循环：Reason → Act → Observe → (回到 Reason)

适用场景：工具调用、网页浏览、实时数据查询——需要"边做边看"的开放环境任务。

关键权衡：

• ✅ 灵活性极高，能应对中途变化

• ❌ 延迟高：N 步任务 = N 次 LLM 调用

• ❌ 可能陷入循环，需设置 max_iterations

4. Reflection（反思迭代）

核心机制：完成任务（或一个阶段）后，停下来做全局评估，发现问题则调整计划并重试。

两种用法：

• 独立主循环：作为完整的自循环框架运行（完成任务 → 评估 → 修订 → 再尝试）

• 子模块嵌入：嵌入 ReAct 或 Plan-Act 中，提供自我修正能力

与 ReAct 的核心区别：

维度	ReAct	Reflection
反馈粒度	步级即时反馈	阶段级全局反馈
耦合方式	推理与行动紧密耦合	行动与反思阶段性分离
触发时机	每步都调整	一轮结束后整体评估
典型应用	工具调用、网页浏览	代码生成、写作、设计推荐

5. Plan-Act（先规划后执行）

核心机制：一次性生成完整执行计划，然后按步骤顺序执行。执行阶段不再做重新规划，但执行器仍可能调用 LLM 处理中间数据或理解指令。

适用场景：步骤明确、环境相对封闭的任务，如按固定模板生成报表。

关键权衡：

• ✅ 运行时延迟低：1 次规划 + N 次工具调用

• ✅ 执行路径确定，易于审计

• ❌ 灵活性低：环境变化时不会重新规划

• ❌ 前期提示词设计成本高（人力成本，非运行时成本）

6. ReWOO（Reasoning WithOut Observation）

核心机制：将规划与执行解耦为三个阶段：

1. Planner：一次性生成包含依赖关系的工具调用蓝图

2. Worker：按蓝图依赖关系执行（有依赖则串行，独立可并行）

3. Solver：拿到所有结果后，统一做一次最终推理

Planner(1次LLM) → Workers(按依赖执行) → Solver(1次LLM)

核心优势：大幅减少 LLM 与工具的往返交互次数，尤其在批量调用场景中效果最明显。工具间的数据依赖必须在蓝图中显式声明。

---

搜索与探索层

7. Tree of Thoughts（多分支推理，以下简称ToT）

核心机制：同时探索多条推理路径，投票或排序后选择最优。

适用场景：数学证明、策略游戏、创意头脑风暴。

工程实践：深度和广度应根据具体问题动态调整。生产环境中常限制深度来平衡成本与效果。避免用弱模型做早期硬性剪枝，以防丢失正确答案。

CoT-SC 是“多条腿走路，找最稳的那条”，而 ToT 是“前瞻性探索，走一步看三步”。

它们的主要区别如下：

对比维度	CoT-SC (自一致性思维链)	ToT (思维树)
核心思想	投票选优：生成多条独立的推理链，通过多数投票选出最一致的答案	规划搜索：构建一个树形的推理路径，通过自我评估和回溯来探索最优解
路径关系	相互独立。各条推理链之间没有关联，是“并行”生成的	层级关联。后续的“思维”是建立在前面“思维”的基础上，形成从根到叶的路径
决策机制	事后投票。所有路径生成完毕后，对最终答案进行统计，得票最高者胜出	过程评估。在每一步，模型都会评估当前各个“思维”的好坏，从而决定下一步往哪个方向深入
核心能力	提高可靠性。通过“群体智慧”来抵消单次推理的随机性错误	复杂规划与决策。具备前瞻性，能“向前看”或“回溯”，适用于需要战略性思考的任务
计算成本	中等。成本是生成 N 条独立链的 N 倍，但各链之间无额外交互成本	高。除了生成多个分支，还需要额外的评估和搜索步骤，计算开销远大于 CoT-SC

📝通俗解释

• CoT-SC 像是让好几个学生独立解答同一道数学题，最后对照大家的答案，把出现次数最多的那个作为最终结果。

• ToT 则像在下棋，棋手会思考当前局面下的多种可能走法（分支），评估每种走法的优劣，并选择最有希望的一条路继续深入探索

8. GoT（Graph of Thoughts）

核心机制：在 ToT 的基础上，允许不同推理路径之间交叉、合并和聚合。例如分支 A 的中间结论可以验证分支 B 的假设。

适用场景：需要多源信息融合验证的复杂问题。

⚠️ 成本警示：工程实现复杂度高，生产环境需谨慎评估投入产出比。

9. LATS（Language Agent Tree Search）

核心机制：ReAct + MCTS（蒙特卡洛树搜索）+ Reflection 三合一。每步视为树节点，用 MCTS 探索最优路径，自带反思和回溯。

适用场景：对质量要求极高的任务。

⚠️ 成本警示：算力消耗极大，仅限对质量要求极高且可承受成本的场景。

---

其他单智能体变体

10. 角色扮演（Persona / Expert Prompting）

要求 LLM 扮演特定专家进行推理。不改变工具调用逻辑，但改变推理风格和输出质量。

---

二、多智能体编排模式

业界常用的模式名称混合了不同分类维度。以下是更系统的理解框架：

按协作模式与控制流分类

	垂直协作（层级/链式依赖）	水平协作（对等）
集中式控制	Hierarchical（协调者委派）/ Sequential（流水线依赖）	Parallel（编排器调度）
分布式协调	—	Blackboard（共享工作区）/ Pub-Sub（事件总线）

注：Sequential 虽由编排器调度，但其协作本质是链式垂直依赖，故归入垂直协作维度。

具体模式

Sequential（流水线）：严格线性依赖，A 的输出是 B 的输入。适合内容生产（研究 → 写作 → 编辑 → 审核）。

Parallel（并行分派）：任务拆分为独立子任务，多 Agent 同时执行，最后聚合。适合竞品分析、批量处理。

Hierarchical（层级委派）：中央协调者分解任务、分配给子代理、聚合结果。

• Hub-and-Spoke 风格（CrewAI）：协调者始终控制，子代理只返回结果，适合严格管控

若需要更灵活的对等协作而非层级委派，可参考 AutoGen/AG2 的 Peer-to-Peer 模式（见决策树）。

Blackboard（共享黑板）：多专家 Agent 共享公共工作区，无中央指挥，协作涌现。适合医学诊断、科研发现。

Pub-Sub（事件驱动）：发布-订阅模式，松散耦合。适合实时监控、异步工作流。

Debate / Round-Table（辩论/圆桌讨论）：多个 Agent 就同一问题各自提出观点，通过多轮交锋、反驳和修正，逐步收敛到共识。适合复杂决策评审、方案选型、风险评估等需要多视角验证的场景。

⚠️ 成本提示：多轮对话的 Token 消耗显著，建议设置最大轮数（通常 3-5 轮）。

三、Agentic RAG

与普通 RAG 的核心区别：普通 RAG 按固定流程检索→生成；Agentic RAG 让 Agent 自主决策何时检索、从哪些源检索、是否需迭代重写查询或综合多源证据——检索本身成为 Agent 可调用的工具之一。

模式	机制	场景
Multi-Source Retrieval	Agent 自主选择多个数据源	跨系统查询
Query Rewriting & Iteration	根据初步结果重写查询	模糊意图澄清
Evidence Comparison & Synthesis	对比冲突文档，综合判断	法律/合规分析
Permission-Aware Retrieval	检索前做权限校验	多租户企业应用、细粒度权限管控场景
Human-in-the-Loop	检索→推理→人工审批→执行	高风险决策

---

四、Workflow 与 Agent 的混合态

严格来说，SOP / DAG 流程属于 Workflow 而非 Agentic 模式——它按预定义流程图执行，不允许自由规划，只在特定节点调用 LLM 做判断。但在企业落地中常与 LLM 混用，是"Workflow + 少量 LLM"的典型形态。

核心价值：用 Workflow 保证确定性和合规性，用 LLM 节点注入智能判断。当任务需要自主规划时，才升级到完整的 Agent 模式。

---

五、从设计模式到企业级架构

设计模式解决的是单个或少数智能体如何思考和行动的微观问题。当系统规模扩大，需要关注更上层的架构层级：

层级	职责	代表技术/概念
治理与执行层 (Harness)	安全策略实施、任务调度、资源管理、审计追踪。Harness 可理解为 Agent 的"执行沙箱"，负责为每个 Agent 实例提供安全隔离的运行环境，并对所有行为进行治理和审计。	企业 Agent 运行时框架
连接与标准化层 (MCP)	Agent 与外部工具、数据的标准化连接	Model Context Protocol
能力与执行层 (Skills)	Agent 可调用的原子化能力单元（如发送邮件、生成PDF、调用特定API），封装具体执行逻辑	领域专用工具包

Agentic Mesh 是上述架构的长期演进目标——一个去中心化、可互操作的智能体生态系统，成千上万个"Agent-Harness-MCP-Skills"单元互联互通。

落地建议：Agentic Mesh 是长期架构愿景。短期企业落地可从 MCP 标准化工具接口开始，逐步引入 Harness 治理能力，向 Mesh 演进。

---

六、选型决策树

任务是否需要多个领域专家协作？├── 否 → 单 Agent 模式│         ├── 需要多步内部推理？ → CoT / CoT-SC│         ├── 步骤明确、环境封闭？ → Plan-Act│         ├── 需要实时反馈调整？ → ReAct│         ├── 需要批量工具调用、减少LLM往返？ → ReWOO│         ├── 需要迭代精进（全局回头看）？ → Reflection（独立或嵌入）│         ├── 需要探索多条路径？ → ToT│         ├── 需要路径交叉融合？ → GoT（⚠️ 工程复杂度高）│         └── 需要最优搜索+反思+回溯？ → LATS（⚠️ 算力消耗极大）│└── 是 → 多 Agent 编排          ├── 需要严格顺序？ → Sequential          ├── 子任务相互独立？ → Parallel          ├── 需要开放协作探索？ → Blackboard          ├── 需要多视角验证/共识？ → Debate          └── 需要中央管控？                ├── 灵活对话 → AutoGen/AG2（Peer-to-Peer）                └── 严格管控 → CrewAI（Hub-and-Spoke）

---

七、反模式与正确做法

反模式	正确做法
共享服务账号凭证	每 Agent 独立工作负载身份
同步中央编排器作为主干	事件驱动 + 持久消息队列
Prompt 中嵌入安全策略	机器可执行策略门（OPA/Rego）
无评估的 Agent 循环	系统化的 Agent 评估框架
为每个任务都建多 Agent	先用单 Agent 验证，明确瓶颈后再扩展
ToT 用弱模型早期剪枝	根据问题动态调整深度，慎用硬性裁切
ReWOO 蓝图未声明工具依赖	蓝图中显式声明依赖关系
Agent 直连生产数据库/敏感系统	通过 Harness 治理层统一管控，实施权限校验和审计
Agent 决策过程不可追踪、无法调试	接入可观测性平台，记录每一步的推理链、工具调用和结果，支持回放调试

---

八、结语

设计模式是工程权衡的结晶。单智能体由 推理策略 + 行动策略 + 反馈策略 组合而成；多智能体由 协作模式 × 控制流 定义架构。

单智能体：开放环境优先 ReAct，封闭环境优先 Plan-Act，批量工具调用优先 ReWOO，需要回头看时用 Reflection，需要探索多条路径时谨慎使用 ToT。

多智能体：严格顺序选 Sequential，独立并行选 Parallel，中央管控选 Hierarchical（CrewAI 适合严格管控，AutoGen/AG2 适合灵活对话），开放探索选 Blackboard，异步解耦选 Pub-Sub，多视角验证选 Debate。

创作不易，禁止抄袭，转载请附上原文链接及标题