从 ReAct 到 Plan-and-Solve：大模型决策逻辑的进化史

从 ReAct 到 Plan-and-Solve大模型决策逻辑的进化史摘要大语言模型LLMs如 GPT-4、Claude 3 系列的横空出世标志着通用人工智能AGI从概念验证迈向了初步实用化的关键阶段。然而早期 LLMs如 GPT-3.5在复杂推理、长任务规划与执行、工具调用准确性等方面存在显著缺陷——这直接催生了一系列基于人类认知过程的“决策增强范式”。本文将以大模型决策逻辑的核心痛点为切入点系统梳理从纯链式推理Chain-of-Thought, CoT、直接推理Direct Reasoning, DR到反应式行动框架 ReAct、单/多轮规划与执行框架 Plan-and-SolvePaS、Reflexion、Self-Consistency Plan-and-SolveSC-PaS的完整进化链条。我们不仅会深入解析每个框架的核心算法原理、数学模型、架构设计还会通过Python 代码实现、Mermaid 流程图、ER 实体关系图、实际场景项目案例帮助读者直观理解其工作机制此外文章还会对比不同框架的边界条件、性能表现、资源消耗并展望未来决策增强范式的发展趋势与挑战。关键词大语言模型决策增强ReActPlan-and-Solve链式推理工具调用长任务规划目录问题背景与核心痛点约1200字1.1 通用任务中 LLMs 的局限性从“表面聪明”到“深度思考”的鸿沟1.2 人类认知过程的启发从直觉→推理→规划→行动→反思的闭环1.3 决策增强范式的定义与分类标准进化的起点纯推理框架的探索约1800字2.1 直接推理DRLLMs 的“直觉式解题”核心概念与问题背景数学模型与输出形式性能缺陷与适用边界2.2 链式推理CoT与自我一致性SC-CoTLLMs 的“显式逻辑推导”2.2.1 核心概念与工作原理2.2.2 数学模型条件概率最大化的链式分解2.2.3 Python 代码实现基于 OpenAI API 的 SC-CoT 数学题解答2.2.4 性能对比与适用场景表格2.2.5 局限性分析长任务断裂、幻觉、无工具调用能力第一次革命反应式行动框架 ReAct约2500字3.1 核心概念结合 Reasoning推理与 Acting行动的循环3.2 问题背景与提出动机弥补 CoT 的“无外部交互”与纯 DR/CoT 工具调用的“混乱”3.3 概念结构与核心要素组成Thought → Action → Observation → Thought 的闭环3.4 数学模型马尔可夫决策过程MDP下的状态转移与奖励优化3.5 算法流程图与交互关系图Mermaid3.6 Python 代码实现基于 OpenAI API LangChain简化版的 ReAct 问答系统开发环境搭建系统功能设计核心实现源代码与详细解读实际测试场景问答、数学计算、搜索结合3.7 核心属性对比ReAct vs CoT vs DRMarkdown 表格3.8 边界条件与局限性分析单轮短视、规划不足、幻觉残留第二次革命规划与执行分离框架 Plan-and-SolvePaS约3000字4.1 核心概念将任务分解为全局规划Plan与局部执行Solve两个独立阶段4.2 问题背景与提出动机彻底解决 ReAct 的“短视规划”与“执行冗余”4.3 概念结构与核心要素组成全局规划器Global Planner任务分解、子任务优先级排序、子任务依赖关系建模局部执行器Local Solver单个子任务的 ReAct/CoT 执行状态监控器State Monitor子任务完成度检查、子任务结果验证、全局规划调整触发4.4 概念之间的关系ER 实体关系图Mermaid4.5 数学模型分层马尔可夫决策过程Hierarchical MDP, H-MDP下的子任务规划与执行分层状态空间定义分层动作空间定义全局与局部奖励函数设计策略优化目标4.6 算法流程图Mermaid4.7 改进版本4.7.1 Self-Consistency Plan-and-SolveSC-PaS引入 SC-CoT 优化规划的稳定性4.7.2 Iterative Plan-and-SolveiPaS引入子任务失败后的局部规划迭代4.7.3 Reflexion-PaS引入全局反思Reflexion机制优化后续规划4.8 Python 代码实现基于 OpenAI API LangGraph简化版的 iPaS 旅行规划系统开发环境搭建系统需求分析系统功能设计系统架构设计系统接口设计核心实现源代码与详细解读实际测试场景复杂多约束旅行规划航班、酒店、景点、预算4.9 核心属性对比PaS vs iPaS vs SC-PaS vs ReAct vs CoTMarkdown 表格4.10 边界条件与局限性分析全局规划的“过度抽象”、复杂依赖关系建模困难、状态监控的“准确性瓶颈”实际应用场景与工具推荐约1000字5.1 实际应用场景复杂数学题/编程题解答多约束任务规划旅行、项目管理、资源调度长文档分析与知识问答自动化工具链开发DevOps、数据工程多模态任务协同文本→图像→语音→搜索→SQL5.2 工具与资源推荐框架类LangChain、LangGraph、AutoGPT、BabyAGI、GPT-4 Tools、Claude 3 Opus Tools评测类MMLU、GSM8K、HumanEval、MathBench、WebShop、HotpotQA学习资源类论文《ReAct: Synergizing Reasoning and Acting in Language Models》、《Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models》、《Reflexion: Language Agents with Verbal Reinforcement Learning》、OpenAI Cookbook、LangChain Docs、LangGraph Docs行业发展与未来趋势约500字6.1 决策增强范式的演变发展历史Markdown 表格6.2 未来发展趋势多模态分层决策增强元决策Meta-Planning让 LLMs 自主选择决策范式强化学习结合人类反馈RLHFMeta-RLHF优化决策策略分布式决策增强多智能体协同完成超复杂任务轻量级决策增强适配边缘设备与中小规模 LLMs6.3 未来挑战决策的可解释性与可控性复杂开放环境下的鲁棒性资源消耗的优化幻觉的彻底消除本章小结约500字1. 问题背景与核心痛点1.1 通用任务中 LLMs 的局限性从“表面聪明”到“深度思考”的鸿沟2020年 OpenAI 发布 GPT-3 以来大语言模型在文本生成、翻译、摘要、对话等纯文本生成类任务上展现出了惊人的能力——甚至可以通过微调在特定领域如医疗、法律、金融达到接近人类专家的水平。然而当我们把目光投向需要复杂推理、长任务规划、外部工具交互、多模态协同的通用任务时早期 LLMs如 GPT-3.5、Claude 2的表现却差强人意1复杂推理中的“断裂”与“幻觉”让我们先看一个经典的 GSM8K 小学数学题小明有 12 个苹果他送给小红一半多 1 个又送给小刚剩下的一半少 1 个最后还剩多少个苹果直接让 GPT-3.5-turbo 解答直接推理不做任何提示它可能会给出错误的答案比如 1 个、3 个甚至会编造不存在的中间步骤比如“小明送给小红 7 个剩下 4 个送给小刚 1 个剩下 3 个”——实际上“剩下的一半少 1 个”应该是 4/2 -1 1 个但如果剩下的是 5 个就可能出现计算错误。即使使用 CoT 提示“让我们一步一步地思考”早期 LLMs 在多步长、需要逆向推理、需要外部知识验证的复杂问题上仍然会出现“推理链条断裂”比如中间某一步突然跳转到完全无关的内容、“算术错误”即使是简单的加减乘除、“幻觉”编造不存在的外部知识比如“2024年巴黎奥运会的吉祥物是冰墩墩”等问题。2长任务规划中的“短视”与“冗余”再看一个更复杂的通用任务请帮我规划一个 2024 年 10 月 1 日-7 日从北京到日本东京、大阪、京都的 7 日亲子游方案预算为 3 万元人民币含机票、酒店、餐饮、交通、门票要求北京出发往返东京成田机场的直飞航班东京、大阪、京都各住 2-3 天亲子友好适合 6-10 岁儿童尽量避开人流高峰最后一天要在东京成田机场附近住方便第二天返程。直接让 GPT-3.5-turbo 规划它可能会给出一个完全不可行的方案机票可能是转机航班酒店可能不在亲子友好区域甚至不在成田机场附近预算可能超支 2-3 倍景点可能都是人流高峰区域甚至开放时间不对行程安排过于紧凑比如一天要逛 5-6 个景点甚至会编造不存在的航班、酒店、景点。即使使用 ReAct 框架让 LLMs 调用搜索工具、航班查询工具、酒店查询工具早期 LLMs 仍然会出现“短视规划”的问题——比如先订了东京的酒店再订东京到大阪的新干线结果发现新干线的时间与酒店的入住/退房时间冲突或者先订了成田机场附近的酒店结果发现最后一天的行程安排在东京市中心需要花 2-3 小时往返成田机场浪费了大量时间此外还会出现“执行冗余”的问题——比如重复调用搜索工具查询同一个景点的开放时间。3外部工具交互中的“混乱”与“错误”早期 LLMs 在使用外部工具如搜索引擎、计算器、Python 解释器、SQL 数据库、API 接口时主要存在以下问题工具选择错误比如明明需要用计算器计算却选择了搜索引擎工具参数错误比如调用 Python 解释器时输入的代码语法错误工具结果解析错误比如调用搜索引擎后无法从搜索结果中提取出有用的信息多工具协同错误比如先调用 Python 解释器生成了一个 CSV 文件再调用 SQL 数据库查询却没有正确地将 CSV 文件导入到 SQL 数据库中。1.2 人类认知过程的启发从直觉→推理→规划→行动→反思的闭环为什么早期 LLMs 在通用任务上表现不佳因为它们的决策逻辑与人类的认知过程存在巨大的差异。让我们回顾一下人类在解决复杂通用任务时的认知过程直觉感知首先人类会通过直觉快速地理解任务的目标、约束条件、可用资源全局规划然后人类会将复杂的任务分解为一系列简单的、可执行的子任务并对子任务进行优先级排序、依赖关系建模局部推理接下来人类会对每个子任务进行显式的逻辑推导制定具体的执行步骤行动执行然后人类会执行具体的行动步骤并在执行过程中不断地收集外部信息状态监控在执行行动步骤的同时人类会不断地监控当前的状态检查子任务是否完成结果是否符合预期局部调整如果子任务失败或者结果不符合预期人类会对子任务的执行步骤进行局部调整全局反思如果多次局部调整都失败或者全局规划出现严重问题人类会对全局规划进行调整甚至重新进行全局规划任务总结最后当整个任务完成后人类会对整个过程进行总结提取出有用的经验教训以便下次解决类似任务时使用。早期 LLMs 的决策逻辑要么是纯直觉式的直接推理DR跳过了推理、规划、行动、反思的环节要么是纯显式逻辑推导的链式推理CoT跳过了规划、行动、反思的环节要么是反应式的行动框架 ReAct将推理与行动结合但跳过了全局规划的环节——它们都没有完全模拟人类的认知闭环。1.3 决策增强范式的定义与分类标准为了弥补早期 LLMs 在通用任务上的局限性研究者们提出了一系列决策增强范式——简单来说决策增强范式就是通过设计特定的提示模板、架构设计、工具调用机制、反思机制等来增强 LLMs 的复杂推理能力、长任务规划能力、外部工具交互能力、多模态协同能力。根据是否引入外部工具交互、是否引入全局规划、是否引入反思机制我们可以将决策增强范式分为以下几类纯推理类决策增强范式不引入外部工具交互不引入全局规划不引入反思机制主要通过设计特定的提示模板来增强 LLMs 的显式逻辑推导能力——代表范式有 CoT、SC-CoT、Zero-Shot-CoTZSC、Few-Shot-CoTFSC反应式行动类决策增强范式引入外部工具交互但不引入全局规划不引入反思机制主要通过设计“推理→行动→观察→推理”的循环来增强 LLMs 的外部工具交互能力——代表范式有 ReAct、ToolFormer、GPT-4 Tools、Claude 3 Opus Tools规划与执行分离类决策增强范式引入外部工具交互引入全局规划部分引入反思机制主要通过将任务分解为全局规划与局部执行两个独立阶段来增强 LLMs 的长任务规划能力——代表范式有 Plan-and-SolvePaS、Self-Consistency Plan-and-SolveSC-PaS、Iterative Plan-and-SolveiPaS、Reflexion-PaS、AutoGPT、BabyAGI多智能体协同类决策增强范式引入外部工具交互引入全局规划引入反思机制主要通过多个 LLMs 智能体比如规划智能体、执行智能体、监控智能体、反思智能体的协同来完成超复杂任务——代表范式有 AutoGPT-5、Claude 3 Multi-Agent、GPT-4o Multi-Agent多模态分层类决策增强范式引入外部工具交互引入全局规划引入反思机制引入多模态协同主要通过分层决策的方式来完成多模态超复杂任务——代表范式有 GPT-4o Vision-Language PlanningVLP、Claude 3 Opus Multi-Modal PlanningMMP。全文剩余约10000字将按照上述目录继续展开包含详细的数学模型、Mermaid 图表、Python 代码实现、项目案例、性能对比表格等内容