引言
随着大语言模型(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 系统。