ReAct与PlanReAct的定义及区别
ReAct与PlanReAct的定义及区别（基于文献《BMW Agents - A Framework for Task Automation Through Multi-Agent Collaboration.pdf》）
一、核心定义（文献3.3.1节）
1. ReAct
ReAct是一种迭代式提示策略，核心是通过“Thought（思考）-Action（行动）-Observation（观察）”的循环，引导大语言模型（LLMs）结合外部工具解决任务，实现“推理与行动的协同”。
- Thought阶段：LLM分析当前任务目标，思考“下一步该做什么”（如“需要调用语义搜索工具获取部门销售数据”）；
- Action阶段：LLM以JSON格式定义“选择的工具”及“工具所需参数”（如指定“语义搜索工具”，参数为“部门编号：001，时间范围：2024-01至2024-06”）；
- Observation阶段：工具执行Action后返回结果（如搜索到的销售数据），该结果以“User Message”形式反馈给LLM，作为下一轮循环的输入；
- 终止逻辑：当LLM判断任务完成时，会生成预设的“终止序列”，框架检测到该序列后停止迭代，输出最终结果。
ReAct的核心价值是让LLM摆脱“纯文本推理”局限，通过工具调用与外部世界交互，适用于需要获取实时/私有数据的任务（如文献5.1节“问答系统调用语义搜索工具”）。
2. PlanReAct
PlanReAct是文献基于ReAct改进的增强型迭代提示策略，在ReAct的“Thought-Action-Observation”循环基础上，新增“Planning（规划）步骤”，形成“Plan（规划）-Thought（思考）-Action（行动）-Observation（观察）”的迭代序列。
- 新增的Planning阶段：LLM在每一轮循环中，先明确“当前步骤的具体小计划”（如“先验证已获取的销售数据是否完整，若不完整则补充调用数据库工具”），再进入后续思考与行动环节；
- 核心定位：PlanReAct并非替代文献3.1.1节的Planner Agent（规划智能体），而是与Planner Agent协同——Planner Agent负责将用户复杂指令分解为“任务DAG（有向无环图）”，PlanReAct则负责对DAG中“仍较复杂的单个子任务”进一步细化执行步骤。
例如，Planner Agent将“生成部门销售报告”分解为“收集数据→计算同比→生成图表”，若“收集数据”需调用多个数据库，PlanReAct会在每一轮循环中规划“先调用A数据库查销量，再调用B数据库查成本”，确保子任务有序执行。
二、核心区别（从“步骤设计”“功能定位”“适用场景”三维度对比）
| 对比维度 | ReAct | PlanReAct |
|---|---|---|
| 迭代步骤序列 | 固定为“Thought-Action-Observation”，无规划步骤 | 新增“Planning”步骤，序列为“Plan-Thought-Action-Observation” |
| 任务分解能力 | 无显式任务分解逻辑，依赖LLM自发判断下一步行动 | 具备显式“子任务规划”能力，可细化单个复杂子任务的执行步骤 |
| 与Planner Agent的关系 | 独立于Planner Agent，无法利用DAG中的任务依赖信息 | 与Planner Agent协同，基于DAG中的子任务进一步规划执行细节 |
| 适用场景 | 适用于“步骤简单、工具调用逻辑直接”的任务（如单轮语义搜索、简单文档纠错） | 适用于“子任务仍复杂、需多轮工具调用”的任务（如多数据库数据整合、复杂代码开发中的步骤规划） |
三、文献中的协同逻辑
文献明确指出，PlanReAct是ReAct的“补充而非替代”，二者在框架中形成“分层协作”：
- 首先，Planner Agent将用户复杂指令分解为“任务DAG”（如“生成销售报告”→“收集数据→计算指标→生成图表→撰写报告”）；
- 若DAG中的子任务（如“收集数据”）较简单，执行该任务的智能体（如BMW Assistant Agent）采用ReAct策略，直接通过“思考-行动-观察”调用工具完成；
- 若子任务（如“计算指标”需先清洗数据、再计算同比/环比、最后验证数据合理性）较复杂，智能体则采用PlanReAct策略，通过“规划-思考-行动-观察”的循环，逐步细化执行步骤，确保任务准确完成。
这种设计既保留了ReAct在简单任务中的高效性，又通过PlanReAct提升了复杂任务的执行可靠性，符合框架“模块化、适配多样化任务”的核心目标。