引言
随着大语言模型（LLM）能力的不断提升，Agent（智能体）已成为构建复杂 AI 应用的核心范式。对于产品经理和技术人员而言，理解 Agent 的设计模式至关重要，这有助于在架构层面规划系统行为、工具调用及决策逻辑。
本文将深入解析九种主流的 Agent 设计模式，包括 ReAct、Plan and Solve、REWOO、LLMCompiler、Basic Reflection、Reflexion、LATS、Self-Discover 以及 Storm。我们将结合原理图解与代码逻辑，分析每种模式的适用场景、核心优势及局限性，帮助读者建立系统的 Agent 设计思维。
1. ReAct 模式
ReAct (Reasoning + Acting) 是 LLM Agent 领域的奠基性工作之一，发表于 2022 年 10 月。在当时 ChatGPT 尚未普及的背景下，该论文提出了让 LLM 学会使用工具的关键思路，具有开创性意义。
1.1 原理详解
在 ReAct 出现之前，推理（Reasoning）和行动（Action）通常是割裂的。例如，让孩子去厨房拿胡椒粉，若仅使用思维链（CoT），孩子可能会列出所有步骤但无法根据环境反馈调整。ReAct 引入了 Observation（观察）环节，形成 Thought -> Action -> Observation 的循环。
- Thought: 模型对当前状态的思考。
- Action: 模型决定执行的具体操作（如调用 API）。
- Observation: 外部工具返回的结果，作为下一步推理的依据。
这种机制赋予了 Agent 短期记忆能力，使其能够根据执行结果动态调整后续策略。
1.2 实现逻辑
在 LangChain 等框架中，ReAct 的实现通常包含以下关键步骤：
- 提示词构建：将预设的 ReAct 模板（Question->Thought->Action->Observation）与用户问题合并。Few-shot 示例需根据具体领域定制，例如将 Action 映射为具体的 API 接口。
- 生成 Thought+Action：调用大模型生成中间思考过程和操作指令。通过设置 Stop Token（如 "Observation"），防止模型直接输出观察结果，确保流程可控。
- 工具调用：解析 Action 字段，判断是否为结束指令。若非结束，则利用 Function Calling 将自然语言转换为 API 请求参数。
- 生成 Observation：获取工具返回数据，将其转化为自然语言描述，作为新的上下文输入给模型。
- 迭代与输出：重复上述过程直至 Action 为 Finish，最终将结果转化为用户可读的自然语言。
1.3 优缺点分析
- 优点：逻辑清晰，可解释性强，适合需要多步推理和工具调用的任务。
- 缺点：每次交互都需要完整的上下文传递，Token 消耗较大；若工具响应错误，可能导致死循环。
2. Plan and Solve 模式
Plan and Solve 模式强调先规划后执行。如果说 ReAct 适合'厨房拿胡椒粉'这类简单任务，那么 Plan and Solve 更适合'西红柿炒鸡蛋'这类复杂任务，其中涉及计划变更的可能性。
2.1 核心组件
- Planner（规划器）：负责生成多步计划。初始 Planner 生成主计划，Replanner 则根据任务完成情况动态调整计划。
- Solver（执行器）：接受查询和计划步骤，调用工具完成具体任务。
2.2 应用场景
适用于长链条任务，如数据分析报告生成、多步骤业务流程处理。其 Zero-shot 能力提升显著，允许模型在遇到意外情况（如缺少食材）时重新规划路径。
3. REWOO (Reason without Observation)
REWOO 是对 ReAct 的优化，旨在减少上下文中的冗余信息。它去掉了显式的 Observation 字段，将上一步的执行结果隐式嵌入到下一步的输入变量中。
3.1 工作原理
在审批流等场景中，步骤 B 依赖步骤 A 的输出。REWOO 通过定义变量依赖关系，让 Worker 自动传递中间结果，无需模型反复读取 Observation 文本。这减少了 Token 占用，提高了并行处理的潜力。
3.2 架构组成
- Planner：生成相互依赖的链式计划。
- Worker：遍历任务，分配输出至变量。
- Solver：整合最终输出。
4. LLM Compiler
LLM Compiler 借鉴了计算机科学中的编译概念，核心目标是通过并行 Function Calling 提高执行效率。
4.1 任务编排
当用户提问涉及多个独立子任务（如'张译和吴京差几岁'）时，Planner 会生成一个有向无环图（DAG）。搜索两人年龄的任务可以并行执行，最后由 Jointer 合并结果。
4.2 优势
显著降低了等待时间，特别适合 I/O 密集型或计算密集型且子任务独立的场景。
5. Basic Reflection
Basic Reflection 模拟了'学生写作业，老师批改'的过程。Generator 生成答案，Reflector 提供修改建议，Generator 据此迭代。
5.1 交互机制
通过 Prompt 复刻师生对话，强制模型在输出前进行自我审视。这种模式能有效提升回答的准确性和完整性。
6. Reflexion
Reflexion 是 Basic Reflection 的升级版，引入了强化学习思想。它不仅要求反思，还引入外部数据评估回答准确性，并强制检查缺失或多余的信息。
6.1 批判性思考
Responder 自带批判式思考，指出 Missing（遗漏）或 Superfluous（冗余）部分。Revisor 基于这些反馈修正初始回答。这使得反思更具建设性，而非简单的自我否定。
7. Language Agent Tree Search (LATS)
LATS 融合了树搜索、ReAct、Plan & Solve 以及 Reflection 机制，是一种综合性的增强方案。
7.1 核心逻辑
通过树搜索探索多种可能的行动路径，利用 Reward 函数（强化学习）评估节点质量，并结合 Reflection 优化内容。最终目标是找到最优解路径。
7.2 架构特点
多轮 Basic Reflection 的变体，包含多个 Generator 和 Reflector 节点，支持回溯和分支选择。
8. Self-Discover
Self-Discover 的核心在于让大模型在更细粒度上进行任务反思。不同于 Plan & Solve 反思任务是否需要补充，Self-Discover 反思的是 Task 本身的执行方式。
8.1 结构组成
- Selector：从众多反省方式中选择合适的一种。
- Adaptor：使用选定的方式进行反省。
- Implementor：反省后重新 Reasoning。
9. Storm
Storm 专注于从零生成维基百科级别的文章。其思路是先利用外部工具搜索生成大纲，再逐段丰富内容。
9.1 工作流程
- Topic 确定：明确文章主题。
- 大纲生成：生成结构化目录。
- 内容填充：根据大纲生成详细段落。
该模式展示了 Agent 在长文本创作领域的强大能力，结合了搜索与生成的优势。
总结
以上总结了九种主流 Agent 设计模式。在实际落地中，没有绝对最好的模式，只有最适合业务场景的模式。产品经理应依据用户需求、任务复杂度及对延迟的要求进行选择。
- 简单任务：ReAct。
- 复杂规划：Plan and Solve。
- 效率优先：LLM Compiler。
- 高质量输出：Reflexion / LATS。
- 长文创作：Storm。
建议开发者查阅各模式的原始论文 Prompt 模板，理解人类思维模式的结构化体现，从而更好地定制符合自身业务需求的 Agent 系统。