有一件事困扰了我很久。给 AI 装上搜索引擎和计算器后，它突然变得能干很多，但怎么让它‘想’清楚该用哪个工具、什么时候用？有两种截然不同的思路：一种是先想好全盘计划再一步步执行，就像建筑师画好图纸再施工；另一种是边想边干，遇到问题再调整，像你迷路时打开地图边走边看。前者叫 Plan-and-Execute，后者叫 ReAct（Reasoning + Acting）。我最早以为，既然 AI 能生成文本，那先规划肯定更稳妥。但后来我发现，这个直觉在真实世界任务里经常翻车。
ReAct：边想边干的循环
ReAct 是怎么工作的？想象你让 AI 回答“2024 年奥斯卡最佳影片的导演是谁？”它不能直接回答，因为知识截止到 2023 年。在 ReAct 模式下，AI 会进入一个循环：思考（Thought）→ 行动（Action）→ 观察（Observation）。它会先想：“我需要搜索最新的奥斯卡信息。”然后调用搜索工具，看到结果，再想：“搜索结果显示《奥本海默》获奖，导演是克里斯托弗·诺兰。”最后输出答案。这个循环可能重复多次，直到它认为信息足够。Yao 等人在 2022 年的论文ReAct: Synergizing Reasoning and Acting in Language Models中首次提出这一范式，核心发现是交替进行推理和行动能显著提升语言模型在知识密集型任务上的表现——比如多跳问答和事实验证。
说人话就是：ReAct 让模型每走一步都先嘀咕一句“我现在该干啥”，然后去做，做完再根据结果嘀咕下一步。这看起来很费 token，但好处是它随时能根据新信息调整方向。比如你问“iPhone 15 Pro 和 三星 S24 Ultra 哪个拍照好？”ReAct 可能先搜 iPhone 评测，发现一个参数没看懂，又搜解释，再搜三星对比，最后综合给出答案。整个过程像侦探破案，线索是逐步浮现的。
Plan-and-Execute：先画蓝图再施工
Plan-and-Execute 则完全不同。它要求 AI 在动手之前先制定一个完整的计划，然后按计划逐步执行。比如同样的问题，它可能先输出：“计划：1. 搜索‘2024 奥斯卡最佳影片’；2. 搜索‘该影片导演’；3. 回答用户。”然后依次执行这些步骤。这种模式在 LangChain 的 Plan-and-Execute agent 中实现，灵感来自经典的机器人规划。另外，Wang 等人的 Plan-and-Solve Prompting 也展示了类似思路：让模型在解决问题前先生成计划，再执行，能有效提升零样本推理准确率。
它看起来更“深思熟虑”，因为每一步都事先想好，不会随意跳转。但这也意味着：一旦计划制定，执行阶段往往不再重新思考。如果实际情况与计划假设不符——比如某个网页 404，或者中间数据格式不对——它很容易卡住，因为计划里没有“变通”这一步。
一张表说清核心差异
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 决策方式 | 逐步推理，行动和思考交替 | 先全局规划，再按步骤执行 |
| 灵活性 | 高，能根据中间观察实时调整 | 低，计划一旦制定不易改变 |
| 效率 | 可能多轮探索，token 消耗大 | 轮次少，但计划本身消耗 token |
| 错误恢复 | 容易，观察后可重新思考行动 | 难，除非重新生成整个计划 |
| 适用场景 | 信息检索、复杂推理、多步问答 | 结构化任务、已知流程的自动化 |
这个对比背后有一个更根本的差异：对不确定性的态度。ReAct 假设世界是动态的，每一步都可能改变下一步；Plan-and-Execute 假设世界是静态的，可以提前预知一切。这就是为什么前者在开放域问答、研究型任务中表现更好，而后者在固定工作流（比如每天从邮箱抓取附件、解析、入库）中更高效。
我踩过的坑：AutoGPT 的 Plan-and-Execute 为什么总翻车
我最早用 AutoGPT 时，它内置了一个类似 Plan-and-Execute 的机制，会生成任务列表然后逐个执行。但很快我发现，它经常卡在某个步骤，因为计划里假设某个网页存在，但实际点进去是 404，它却不会回头修改计划，只是傻傻地报错。后来我切换到 ReAct 模式的 agent，同样的任务，它会在遇到 404 时自动搜索替代链接。这让我意识到，先规划听起来很美，但现实世界充满不确定性，计划往往赶不上变化。
这个认知转折来自一次具体任务：我想让 agent 自动收集某会议的所有论文摘要。Plan-and-Execute 方案先规划了“访问会议官网→找到议程页→遍历每个链接→提取摘要”，但官网当日改版，议程页链接失效，它直接停止。ReAct 则先搜索“会议名称 2024 议程”，找到新链接，再继续。那一刻我明白了：Plan-and-Execute 的“执行”是机械的，而 ReAct 的“执行”是智能的，因为它把执行也变成了推理的一部分。
什么时候该用哪个？
如果你要构建一个客服机器人，用户问题千奇百怪，最好的选择是 ReAct，因为它能随机应变。但如果你要自动化一个固定的工作流，比如每天从邮箱抓取附件、解析数据、存入数据库，那么 Plan-and-Execute 更合适，因为步骤固定，提前规划还能提高执行效率，而且 token 开销更可控。
还有一个折中方案：分层架构。先用一个 Planner 生成任务大纲（Plan-and-Execute 的规划能力），然后每个子任务交给 ReAct 循环执行。这样既有了全局视野，又保留了执行时的灵活性。很多高级 agent 框架（如 LangChain 的 AgentExecutor）实际上支持这种混合模式。
常见误解澄清
ReAct 比 Plan-and-Execute 更聪明？
不，它们只是策略不同。ReAct 的聪明体现在每一步的推理，但整体可能缺乏统筹；Plan-and-Execute 的聪明体现在全局规划，但执行时可能无视细节。聪明与否取决于任务本身。
Plan-and-Execute 可以完全替代 ReAct？
不能，因为很多任务无法提前预知所有步骤，比如创意写作或复杂研究。你不可能先规划好一首诗的所有意象再动笔，那样写出来的诗会很僵硬。
两者可以结合吗？
可以，且已经在很多系统中实现，比如“先规划后执行，但执行时允许 ReAct 式微调”。这将是未来的主流方向。
边界在哪？
目前，Plan-and-Execute 的失效模式主要是计划僵化，而 ReAct 的失效模式是无限循环或错误推理累积。但有趣的是，ReAct 的循环出错时，你往往能通过观察中间步骤发现，而 Plan-and-Execute 的规划错误可能要到执行末尾才暴露，修正成本更高。所以，如果你需要可解释性和调试能力，ReAct 的透明执行过程是巨大优势。
未来，更强大的基础模型可能会模糊二者的界限，但核心矛盾依旧存在：我们对未来的预测能力有限，所以边想边干或许才是更普适的解决方案。选择哪种范式，取决于你愿意为确定性付出多少成本，以及你对不确定性的容忍度。
原创文章，作者：guanweilu，如若转载，请注明出处：https://guanweilu.cn/article/128.html