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 的实现流程可梳理为以下步骤：
- 生成提示词：将预设的 ReAct 模板（Question -> Thought -> Action -> Observation）与用户问题合并。Few-shot 示例需根据领域定制，例如将 Action 映射为具体的 API 接口调用。
- 调用大模型：发送提示词给 LLM，限制其输出 Thought 和 Action，通过 Stop Token 阻止其直接生成 Observation。
- 调用外部工具：解析 Action，将其转换为可执行的 API 请求。这通常涉及 Function Calling 功能，即微调模型以识别特定语言格式。
- 生成 Observation：API 返回结果后，将其转换为自然语言作为 Observation，连同之前的 Thought 和 Action 再次输入模型。
- 循环迭代：重复上述步骤，直到 Action 为 Finish。
- 完成输出：将最终 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 工作原理
常见于审批流等环环相扣的场景。例如：
- 从部门 A 获取文件 a。
- 持文件 a 去部门 B 办理文件 b。
