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。
- 持文件 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 工作流程
- Topic 确定:明确文章主题。
- 大纲生成:利用搜索工具构建结构化大纲。
- 内容生成:根据大纲填充详细内容。
架构上包含大纲生成器和内容生成器两个核心模块。
总结
以上总结了目前主流的九种 Agent 设计模式。在实际落地中,没有绝对最好的模式,只有最适合场景的模式。产品经理应根据用户需求复杂度、实时性要求及资源成本进行选择:
- 简单任务:ReAct 即可满足。
- 复杂规划:Plan & Solve 或 LATS 更适合。
- 高并发需求:LLM Compiler 可提升效率。
- 高质量输出:Reflexion 或 Basic Reflection 可增强准确性。
建议查阅各设计模式的 Prompt 模板,理解其背后的思维模式,以便灵活组合应用于实际业务场景中。
注:文中涉及的代码逻辑参考自开源社区 LangChain 教程,具体实现细节可根据项目需求调整。