Agent 的九种设计模式详解：原理、图解与代码实现

Agent 的九种设计模式详解：原理、图解与代码实现

引言

本文深入解析 LLM Agent 的九种核心设计模式，涵盖从基础的 ReAct 到复杂的 Tree Search 等架构。通过图解与代码逻辑梳理，帮助产品经理与技术团队理解不同模式的适用场景及实现原理。

1. ReAct 模式

ReAct (Reasoning + Acting) 是 LLM Agent 领域的奠基性论文之一，发表于 2022 年 10 月。在 ChatGPT 尚未普及的背景下，该研究提出让 LLM 学会使用工具，具有开创性意义。

1.1 ReAct 原理

在 ReAct 出现之前，推理 (Reasoning) 与行动 (Action) 往往是割裂的。例如，让孩子去厨房拿胡椒粉，若仅使用思维链 (CoT)，孩子可能会列出所有步骤但不会根据反馈调整；而 ReAct 要求模型在执行每一步后都进行自我观察（Observation），形成'思考 - 行动 - 观察'的闭环。

• Action: 执行具体操作（如查看台面）
• Observation: 获取环境反馈（如台面无货）
• Thought: 基于反馈决定下一步

这种机制相当于赋予了 Agent 短期记忆能力，使其能够维持上下文状态并动态调整策略。

1.2 ReAct 实现逻辑

通过 LangChain 等框架，ReAct 的实现流程可梳理为以下步骤：

1. 生成提示词：将预设的 ReAct 模板（Question -> Thought -> Action -> Observation）与用户问题合并。Few-shot 示例需根据领域定制，例如将 Action 映射为具体的 API 接口调用。
2. 调用大模型：发送提示词给 LLM，限制其输出 Thought 和 Action，通过 Stop Token 阻止其直接生成 Observation。
3. 调用外部工具：解析 Action，将其转换为可执行的 API 请求。这通常涉及 Function Calling 功能，即微调模型以识别特定语言格式。
4. 生成 Observation：API 返回结果后，将其转换为自然语言作为 Observation，连同之前的 Thought 和 Action 再次输入模型。
5. 循环迭代：重复上述步骤，直到 Action 为 Finish。
6. 完成输出：将最终 Observation 转化为自然语言回复用户。

落地 ReAct 场景需定制两项内容：Prompt 模板中的 Few-shot 内容及 Function Calling 的外部工具定义。Prompt 模板本质上是人类思维模式的结构化体现。

2. Plan and Solve 模式

Plan & Solve 模式适用于需要多步规划且计划可能动态调整的任务，例如'西红柿炒鸡蛋'。相比 ReAct，它更强调先制定全局计划，再逐步执行。

2.1 核心组件

• 规划器 (Planner)：负责生成多步计划。包含初始 Planner 和重规划器 (Replanner)。Replanner 会根据任务完成情况更新计划，提示词中需包含目标、原计划及已完成步骤。
• 执行器 (Solver)：接受查询和计划步骤，调用工具完成任务。

2.2 提示词策略

该模式旨在提升 Zero-Shot Chain-of-Thought 推理能力。提示词结构明确区分了计划阶段和执行阶段，确保模型在开始行动前已有清晰路径。

3. Reason without Observation (REWOO)

REWOO (Reason Without Observation) 是对 ReAct 的优化，旨在减少交互延迟。它去除了显式的 Observation 步骤，将上一步的输出隐式嵌入到下一步的执行单元中。

3.1 工作原理

常见于审批流等环环相扣的场景。例如：

1. 从部门 A 获取文件 a。
2. 持文件 a 去部门 B 办理文件 b。
3. 持文件 b 去部门 C 办理文件 c。

其中，B 和 C 部门对文件的审查即为隐式的 Observation。提示词中会定义每一步依赖上一步的输出变量。

3.2 架构组成

• Planner：生成相互依赖的链式计划。
• Worker：遍历任务，分配输出给相应变量，并在后续调用时替换变量。
• Solver：整合所有输出为最终答案。

4. LLM Compiler

LLM Compiler 的核心思想是通过并行 Function Calling 提高计算效率。原论文《An LLM Compiler for Parallel Function Calling》指出，对于独立子任务，应同时执行而非串行。

4.1 应用场景

例如查询'张译和吴京差几岁'，Planner 可同时搜索两人的年龄，最后合并结果。这要求 Planner 生成有向无环图 (DAG) 来描述任务依赖关系。

4.2 架构组成

• Planner：生成 DAG 任务编排。
• Jointer：合并并行任务的执行结果。

5. Basic Reflection

Basic Reflection 类比于学生写作业、老师批改的过程。通过 Generator 生成内容，Reflector 提供建议，Generator 根据建议修改，形成迭代闭环。

5.1 交互模式

提示词复刻师生交互，强制模型在生成后进行自我批判或寻求外部反馈，从而提升输出质量。

6. Reflexion

Reflexion 是 Basic Reflection 的升级版，引入强化学习思路。论文《Reflexion: Language Agents with Verbal Reinforcement Learning》表明，通过引入外部数据评估回答准确性，反思内容更具建设性。

6.1 核心机制

• Responder：自带批判式思考，检查回答是否有遗漏 (Missing) 或冗余 (Superfluous)。
• Revisor：基于 Critique 上下文参考，对初始回答进行修改。

7. Language Agent Tree Search (LATS)

LATS 融合了 Tree Search、ReAct、Plan & Solve 以及 Reflection 机制。通过树搜索方式探索多种路径，并结合强化学习的 Reward 机制选择最佳结果。

7.1 公式化表达

LATS = Tree search + ReAct + Plan&solve + Reflection + 强化学习

7.2 架构特点

由多轮 Basic Reflection 组成，包含多个 Generator 和 Reflector，支持回溯和分支评估。

8. Self-Discover

Self-Discover 的核心是让大模型在更小粒度上对 Task 本身进行反思。不同于 Plan&Solve 关注任务补充，Self-Discover 关注任务定义的合理性。

8.1 组件结构

• Selector：从众多反省方式中选择合适的策略。
• Adaptor：应用选定的反省方式进行自我修正。
• Implementor：反省后重新进行 Reasoning。

9. Storm

Storm 专注于从零生成维基百科级别的文章。主要思路是利用外部工具搜索生成大纲，再逐段丰富内容。

9.1 工作流程

1. Topic 确定：明确文章主题。
2. 大纲生成：利用搜索工具构建结构化大纲。
3. 内容生成：根据大纲填充详细内容。

架构上包含大纲生成器和内容生成器两个核心模块。

总结

以上总结了目前主流的九种 Agent 设计模式。在实际落地中，没有绝对最好的模式，只有最适合场景的模式。产品经理应根据用户需求复杂度、实时性要求及资源成本进行选择：

• 简单任务：ReAct 即可满足。
• 复杂规划：Plan & Solve 或 LATS 更适合。
• 高并发需求：LLM Compiler 可提升效率。
• 高质量输出：Reflexion 或 Basic Reflection 可增强准确性。

建议查阅各设计模式的 Prompt 模板，理解其背后的思维模式，以便灵活组合应用于实际业务场景中。

---

注：文中涉及的代码逻辑参考自开源社区 LangChain 教程，具体实现细节可根据项目需求调整。