从 ReAct 到 Plan-and-Execute：Agent 决策链路的演进与取舍

数据结构与算法学习

213人浏览 · 2026-06-11 19:12:43

数据结构与算法学习 · 2026-06-11 19:12:43 发布

从 ReAct 到 Plan-and-Execute：Agent 决策链路的演进与取舍

标题选项

《从ReAct到Plan-and-Execute：AI Agent决策链路的演进、技术原理与落地取舍全解析》
《告别Agent随机瞎跑！一文读懂ReAct到Plan-and-Execute的决策逻辑迭代》
《万字长文拆解：大模型Agent核心能力——决策链路从ReAct到PAE的演进之路》
《AI Agent落地避坑指南：对比ReAct与Plan-and-Execute的适用场景与取舍策略》

引言

痛点引入

你是不是在做AI Agent开发的时候遇到过这些典型问题：

让Agent做一个跨城市的商务旅行规划，用ReAct模式的话，它一会去查机票价格，一会突然跳转去搜索目的地景点的历史典故，跑了12轮工具调用还没给出完整行程，甚至连出发时间都给搞错了；
换成Plan-and-Execute模式吧，遇到航班临时取消的突发情况，它又死抱着原来的计划不调整，最后输出的行程完全不符合实际，根本没法用；
更头疼的是做企业级的多步骤数据处理任务，ReAct跑一次花了2万多token，最后输出的结果还漏了3个关键指标，PAE虽然结果准，但是遇到数据口径调整的需求又要重新写规划提示词，灵活度完全不够。

这些问题的本质，都指向AI Agent最核心的能力模块：决策链路。作为Agent的“大脑中枢”，决策链路决定了Agent拿到任务后怎么思考、怎么行动、怎么调整、怎么输出结果，直接决定了Agent的任务成功率、资源消耗和落地适配性。

文章内容概述

本文将从技术原理、实现逻辑、性能对比、适用场景四个维度，完整拆解AI Agent决策链路从ReAct到Plan-and-Execute（以下简称PAE）的演进路径，不仅会带你从零实现两种决策范式的Agent，还会深入分析两种模式的优劣边界，以及实际业务中怎么根据需求做取舍、怎么搭建混合模式的决策链路。

读者收益

读完本文你将：

彻底搞懂ReAct和PAE的核心原理、算法逻辑和实现细节；
可以独立根据业务场景选择合适的决策范式，避免落地踩坑；
掌握混合决策范式的实现方法，兼顾灵活性和可控性；
了解Agent决策链路的未来发展方向，提前布局技术能力。

准备工作

技术栈/知识要求

熟悉大语言模型基础原理，了解提示词工程、工具调用（Function Call）的基本逻辑；
有Python开发基础，了解LangChain等Agent开发框架的基本使用；
对AI Agent的基本概念有认知，最好有过简单Agent的开发经验。

环境/工具要求

Python 3.9+ 运行环境；
已安装langchain、openai、langchain-openai、duckduckgo-search等依赖包；
可用的大模型API Key（推荐使用GPT-3.5-turbo/GPT-4，效果更稳定）。

核心概念：Agent决策链路的本质

问题背景

在大模型爆发之前，传统的规则式Agent、强化学习Agent的决策链路都是预先写死的规则或者训练出来的固定策略，只能适配非常窄的场景，几乎没有通用性。大语言模型的出现，让Agent具备了通用推理能力，但是怎么把大模型的推理能力转化为可落地的行动能力，一直是行业研究的核心问题。

早期的大模型Agent有两个明显的流派：

推理流：以Chain-of-Thought（思维链）为代表，只让大模型做逻辑推理，完全不跟外部环境交互，适合做数学题、常识问答这类不需要外部数据的任务，但是遇到需要实时数据、工具操作的场景就完全失效；
行动流：只让大模型输出工具调用指令，没有中间推理过程，很容易出现动作偏移，比如用户要查北京的天气，它跑去查上海的景点，完全没有逻辑可解释。

这两个流派的缺陷，直接催生了第一代通用决策范式ReAct的诞生。

核心定义

Agent决策链路是指Agent从接收任务到输出结果的完整闭环逻辑，核心包含四个环节：任务理解->规划决策->行动执行->反馈调整，核心目标是用最少的资源（token消耗、调用次数、响应时间）完成最高准确率的任务。

决策链路的两个核心评价维度：

可控性：Agent的行动是否符合预期，会不会偏离任务目标，结果是否可控；
灵活性：Agent能不能适配动态变化的环境、突发的需求调整，会不会僵化。

所有决策范式的演进，本质都是在这两个维度之间做权衡。

第一阶段：ReAct决策范式的原理与实现

问题背景

2022年10月，谷歌大脑和普林斯顿大学联合发布了ReAct论文《ReAct: Synergizing Reasoning and Acting in Language Models》，首次提出了把推理（Reasoning）和行动（Acting）结合起来的决策范式，解决了之前推理流和行动流的割裂问题，成为了第一代通用Agent的标准决策模式。

核心原理

ReAct的核心逻辑非常接近人类处理未知问题的方式：走一步想一步。每一轮决策都会先输出当前的思考（Thought），明确当前要解决的问题，然后输出对应的行动（Action），拿到行动的结果（Observation）之后再做下一步的思考，循环往复直到完成任务。

ReAct的决策过程可以建模为一个马尔可夫决策过程（MDP）：

状态 $S_t$ ：当前的上下文历史，包含所有之前的Thought、Action、Observation序列；
策略 $π(at∣St)\pi(a_t|S_t)$ ：大模型根据当前状态输出下一个动作或者最终结论；
奖励 $r_t$ ：当前动作对完成任务的贡献度，最终总奖励是整个轨迹的累积奖励：
$π∗=arg⁡max⁡πEτ∼pπ(τ)∑t=0Tγtrt\pi^* = \arg\max_\pi \mathbb{E}_{\tau \sim p_\pi(\tau)} \sum_{t=0}^T \gamma^t r_t$
其中 $τ\tau$ 是完整的决策轨迹， $γ\gamma$ 是折扣因子，用来权衡近期奖励和远期奖励的权重。

ReAct的核心要素组成

Thought生成模块：负责根据当前上下文输出中间推理过程，明确当前阶段的目标，避免行动偏移；
Action解析模块：负责从大模型输出中解析出符合格式要求的工具调用指令，包括工具名称、参数；
工具执行模块：负责调用对应的工具，获取返回结果（Observation）；
上下文管理模块：负责把每一轮的Thought、Action、Observation拼接成上下文，传给下一轮的大模型调用。

ReAct算法流程图

完整实现代码

我们用LangChain实现一个最简单的ReAct Agent，包含搜索和计算器两个工具，可以处理需要实时信息和数学计算的问题：

# 导入依赖
from langchain import hub
from langchain.agents import AgentExecutor, create_react_agent
from langchain_openai import ChatOpenAI
from langchain.tools import DuckDuckGoSearchRun, CalculatorTool
import os

# 配置API Key（替换成你自己的）
os.environ["OPENAI_API_KEY"] = "your-openai-api-key"

# 1. 定义大模型
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

# 2. 定义工具：搜索工具和计算器工具
tools = [
    DuckDuckGoSearchRun(name="Search", description="用于查询实时信息、未知常识、最新数据等"),
    CalculatorTool(name="Calculator", description="用于进行数学计算，所有计算问题都要用这个工具")
]

# 3. 加载ReAct官方提示词（也可以自定义）
prompt = hub.pull("hwchase17/react")
print("ReAct提示词模板：\n", prompt.template)

# 4. 创建ReAct Agent
agent = create_react_agent(llm, tools, prompt)

# 5. 创建Agent执行器
agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    verbose=True, # 开启详细日志，方便查看决策过程
    max_iterations=10, # 最大迭代次数，避免无限循环
    handle_parsing_errors=True # 自动处理格式解析错误
)

# 6. 测试运行
result = agent_executor.invoke({"input": "2024年巴黎奥运会中国代表团获得的金牌数比2020年东京奥运会多多少？"})
print("最终结果：\n", result["output"])

运行之后你会看到完整的决策过程：

第一轮Thought：我需要先查2024年巴黎奥运会中国的金牌数，再查2020年东京奥运会的金牌数，再计算差值；
第一轮Action：调用Search工具查2024年巴黎奥运会中国金牌数；
拿到Observation：40枚；
第二轮Thought：现在需要查2020年东京奥运会中国的金牌数；
第二轮Action：调用Search工具查2020年东京奥运会中国金牌数；
拿到Observation：38枚；
第三轮Thought：现在需要计算40-38=2；
第三轮Action：调用Calculator计算差值；
拿到Observation：2；
第四轮Thought：已经有足够信息，输出结果：多2枚。

ReAct的优劣势分析

优势

极致灵活：完全动态决策，每一步都会根据最新的观察结果调整方向，非常适合动态性强、不确定因素多的场景；
开发简单：只需要一套提示词、一个大模型、一套工具，不需要额外的模块，开发成本极低；
可解释性强：每一步都有明确的Thought，决策过程完全透明，方便排查问题；
上下文利用率高：所有历史信息都在同一个上下文中，不需要额外的存储模块，信息传递损耗低。

劣势

长任务容易漂移：当任务步骤超过5步之后，ReAct很容易忘记最初的目标，出现“注意力偏移”，比如做旅行规划的时候跑去查景点的历史；
资源消耗高：每一步都要把所有历史上下文传给大模型，步骤越多token消耗越高，10步的任务token消耗通常是PAE的2倍以上；
不可控风险高：没有全局计划，很容易做出不符合业务规则的操作，比如企业场景下不小心删除了生产数据；
成功率随任务长度骤降：根据LangChain官方测试，超过8步的任务，ReAct的成功率会从70%降到35%以下。

第二阶段：Plan-and-Execute决策范式的原理与实现

问题背景

2023年上半年，AutoGPT等基于ReAct范式的Agent爆火，但是大家很快发现，ReAct处理复杂多步骤任务的成功率极低，比如让AutoGPT写一个网站，它跑了几十轮调用，最后连基础的项目结构都没建对。核心原因就是ReAct没有全局规划，短视问题严重，遇到长任务很容易跑偏。

为了解决这个问题，行业借鉴了人类处理复杂任务的逻辑：先做全局计划，再按计划分步执行，执行过程中动态调整计划，这就是Plan-and-Execute范式的核心思路。2023年5月，LangChain官方推出了Plan-and-Execute Agent的实现，很快成为了复杂任务场景下的主流决策范式。

核心原理

PAE的核心是把规划模块和执行模块解耦，用两个独立的大模型分别负责全局规划和子任务执行，避免了ReAct的短视问题。它的决策过程是分层的马尔可夫决策过程（HMDP）：

上层规划层MDP：状态是当前的全局计划和已完成的子任务结果，策略是规划大模型输出调整后的全局计划，奖励是计划的合理性、覆盖度；
下层执行层MDP：每个子任务对应一个独立的MDP，状态是当前子任务的上下文，策略是执行大模型输出子任务的执行动作，奖励是子任务的完成质量。

总奖励公式为：
$R_{planner}(P_{final}) + \sum_{i=1}^n \alpha_i R_{exec}(p_i)$
其中 $P_{final}$ 是最终执行完成的计划， $p_i$ 是第i个子任务， $αi\alpha_i$ 是子任务的权重。

PAE的核心要素组成

任务理解模块：负责解析用户的任务需求，明确任务的目标、约束、交付要求；
计划生成模块：负责把大任务拆解成多个可执行的子任务，生成完整的全局计划，每个子任务有明确的输入输出、依赖关系；
执行调度模块：负责按计划调度子任务的执行，每个子任务可以用ReAct或者其他执行范式完成；
反思调整模块：负责在每个子任务执行完成后，判断结果是否符合预期，是否需要调整全局计划；
结果汇总模块：负责把所有子任务的执行结果汇总成最终的输出，交付给用户。

PAE算法流程图

完整实现代码

我们用LangChain实现一个PAE Agent，用来生成一份2024年上半年新能源汽车市场的分析报告：

# 导入依赖
from langchain.chat_models import ChatOpenAI
from langchain_experimental.plan_and_execute import PlanAndExecute, load_agent_executor, load_chat_planner
from langchain.tools import DuckDuckGoSearchRun, CalculatorTool
from langchain.utilities import WikipediaAPIWrapper
import os

# 配置API Key
os.environ["OPENAI_API_KEY"] = "your-openai-api-key"

# 1. 定义大模型：规划用GPT-4（更强的规划能力），执行用GPT-3.5-turbo（成本更低）
planner_llm = ChatOpenAI(model="gpt-4", temperature=0)
executor_llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

# 2. 定义工具：搜索、维基百科、计算器
wikipedia = WikipediaAPIWrapper()
search = DuckDuckGoSearchRun()
calculator = CalculatorTool()
tools = [search, wikipedia, calculator]

# 3. 加载规划器和执行器
planner = load_chat_planner(planner_llm)
executor = load_agent_executor(executor_llm, tools, verbose=True)

# 4. 创建PAE Agent
agent = PlanAndExecute(
    planner=planner,
    executor=executor,
    verbose=True,
    max_iterations=5, # 计划调整的最大次数
    return_intermediate_steps=True # 返回中间步骤，方便排查问题
)

# 5. 测试运行
result = agent.run("生成一份2024年上半年中国新能源汽车市场的分析报告，包含销量排名、市场占比、同比增速、TOP3企业的核心竞争力分析，字数不少于2000字")
print("最终报告：\n", result)

运行之后你会看到PAE的决策过程：

规划模块首先生成全局计划：
- 步骤1：搜索2024年上半年中国新能源汽车总销量、同比增速数据；
- 步骤2：搜索2024年上半年新能源汽车企业销量排名、市场占比数据；
- 步骤3：搜索TOP3企业（比亚迪、特斯拉中国、吉利）的2024年上半年核心动作、技术优势；
- 步骤4：汇总所有数据，计算相关指标，生成2000字以上的分析报告。
执行模块逐个执行每个子任务，每个子任务内部用ReAct范式完成；
每执行完一个子任务，反思模块会判断结果是否符合要求，比如如果销量数据缺失，就会返回规划模块调整计划，新增步骤补充数据；
所有子任务完成后，汇总模块生成最终的报告。

PAE的优劣势分析

优势

长任务成功率高：因为有全局计划，不会偏离目标，根据LangChain官方测试，10步以上的复杂任务，PAE的成功率比ReAct高40%以上；
资源消耗低：每个子任务的执行上下文是独立的，不需要携带整个任务的所有历史信息，token消耗通常是ReAct的50%-70%；
可控性强：可以给规划模块加上业务规则约束，比如“不能调用删除类工具”“所有数据必须来自官方渠道”，避免违规操作；
可并行性高：没有依赖关系的子任务可以并行执行，大幅提升响应速度，比如同时查销量数据和企业信息。

劣势

灵活性不足：全局计划生成后调整成本高，遇到突发情况（比如数据源失效、需求临时变更），很容易出现计划僵化的问题；
开发复杂度高：需要维护规划、执行、反思三个模块的提示词，还要处理计划调整、子任务依赖等逻辑，开发成本是ReAct的2-3倍；
信息传递损耗：子任务之间的信息传递依赖计划模块的调度，容易出现信息丢失的问题，比如上一个子任务的结果没有正确传给下一个子任务；
短任务效率低：对于1-2步的简单任务，PAE还要先做计划，反而比ReAct多了1-2轮调用，响应速度更慢。

ReAct vs Plan-and-Execute：全方位对比与取舍

核心属性维度对比

对比维度	ReAct	Plan-and-Execute
核心架构	单模型紧耦合，推理执行一体化	双模型分层解耦，规划执行分离
决策逻辑	走一步看一步，动态决策	先规划后执行，动态调整计划
上下文开销	随步骤线性增长，10步任务约12k token	随子任务数量平稳增长，10步任务约7k token
长任务（>8步）成功率	~35%	~82%
动态场景适配性	极强，实时响应环境变化	较弱，需要触发计划调整流程
开发难度	极低，一套提示词即可	较高，需要维护3个以上模块的提示词和调度逻辑
任务平均调用次数	是PAE的1.5-2倍	比ReAct少30%-50%
可控性	弱，容易出现违规操作	强，可通过规划约束全局行为
容错能力	弱，一步错就容易全链路跑偏	强，子任务错误可以单独重跑，不影响全局
适用场景	简单任务、动态性强的场景（实时客服、实时数据查询、故障排查）	复杂多步骤、目标明确的静态场景（报告生成、项目规划、批量数据处理）

核心组件交互关系对比

取舍策略：怎么选适合自己的决策范式？

我们可以按照以下的决策树来选择：

最佳实践：混合决策范式

大多数实际业务场景都不是非黑即白的，我们可以用混合模式兼顾灵活性和可控性：

规划模块只生成粗粒度的节点计划，比如“1. 数据收集 2. 数据分析 3. 报告生成”，不需要拆解到太细的步骤；
每个粗粒度节点用ReAct范式执行，灵活处理节点内的不确定情况；
每个节点执行完成后做一次反思，判断是否需要调整粗粒度计划。

这种混合模式的成功率比纯ReAct高30%，灵活性比纯PAE高50%，是目前企业级Agent落地的主流选择。

进阶探讨：决策链路的未来演进方向

1. 自适应决策范式

未来的Agent会自动根据任务的复杂度、动态性选择最合适的决策模式，不需要人工配置：简单任务用ReAct，复杂任务用PAE，动态场景自动切换模式。

2. 基于强化学习的决策优化

现在的决策范式都是靠提示词引导，未来会用强化学习对决策策略进行微调，让Agent自己学会怎么规划、怎么执行、怎么调整，大幅提升决策效率和成功率。

3. 多Agent协同决策

复杂任务会拆分给多个Agent，一个规划Agent负责全局调度，多个执行Agent负责不同领域的子任务，配合起来完成更复杂的工作。

4. 端侧轻量化决策

针对端侧Agent（比如手机Agent、车机Agent），会出现轻量化的决策范式，不需要大模型也能完成简单的决策任务，降低延迟和成本。

行业发展历史时间线

时间	事件	决策范式演进阶段
2022年之前	Chain-of-Thought思维链提出，大模型具备推理能力	推理流阶段，无行动能力
2022年10月	ReAct论文发表，首次结合推理和行动	第一代通用决策范式诞生
2023年3月	AutoGPT爆火，ReAct范式的缺陷暴露，长任务成功率极低	ReAct普及与问题暴露阶段
2023年5月	LangChain推出Plan-and-Execute Agent，分层决策成为主流	第二代决策范式诞生，复杂任务适配性大幅提升
2023年10月	OpenAI推出Assistants API，内置规划执行能力	PAE范式工程化成熟
2024年至今	混合决策范式、多Agent协同决策成为研究热点	决策范式向自适应、协同化方向演进