20260414_210315_为什么_ReAct_已经不够了?从_Plan-Then-Ac
如果你最近在做 Agent或者刚好在准备相关面试你大概率已经见过一种情况。系统明明一直在动一直在调工具一直在产出 observation看上去特别勤奋。但最后一看结果要么绕远了要么主线丢了要么干脆在错误路径上越跑越远。很多人会把这个问题归到模型不够强。我现在越来越觉得不完全是。现在如果你还把 Agent 理解成“ReAct 工具调用”已经有点落后了。更大的问题是你还在拿纯 ReAct 去处理那些本来就需要规划的问题。而 ReAct 真正解决的其实是“能不能动起来”但很多真实任务要解决的是怎么少走弯路怎么别在错误路径上越跑越远怎么在复杂任务里做全局最优而不是局部凑合这也是为什么最近越来越多 Agent 系统不再满足于纯 ReAct。它们开始往三个方向走Plan-Then-ActReAct 轻规划Tree / Graph Planning比如ToT、LATS很多同学的问题是这些词都看过但脑子里没有一张清晰地图。所以这篇文章我不讲空话直接帮你把这件事讲透ReAct 的局限到底卡在哪这三种范式的核心区别是什么各自适合什么任务为什么工业界不会只押一种方案如果你最近在做 Agent 项目或者准备 Agent / 大模型工程岗面试这篇建议直接收藏。一、先说结论ReAct 不是错了而是它只解决了“局部闭环”先把一句最重要的话放前面ReAct 很强但它本质上是一个“边看边走”的局部决策框架不是全局规划框架。ReAct 的核心循环大家都知道Thought - Action - Observation - Thought - Action - Observation它厉害的地方在于模型不再只是“想”而是可以执行动作可以接收环境反馈再根据反馈继续修正所以ReAct 是 Agent 真正从“文本生成器”走向“行动体”的第一步。这一步非常关键。但问题也恰恰出在这里它太强调“下一步该干嘛”却不擅长回答“整件事应该怎么做”。这就是很多 Agent 项目一跑起来很聪明一拉长就开始发散、绕路、循环、失控的根因。二、ReAct 的 6 个核心局限很多项目就是死在这里下面这部分你最好真记住。因为这不是论文里的抽象缺点。这就是你做 Agent 时最容易撞上的坑。1它天然偏“短视”容易做局部最优ReAct 每一轮都在根据当前 observation 决定下一步。听起来合理。但问题是局部合理不等于全局合理。比如一个复杂研究任务你需要先拆主题再补背景再定位关键证据再反证最后组织结论纯 ReAct 很可能出现这种情况看到一个相关网页就立刻深入深入之后又继续追一个细节追着追着整个任务主线丢了也就是说它会被局部反馈牵着走。这在搜索、调研、代码修复、GUI 操作里都很常见。一句话总结ReAct 擅长“下一步做什么”不擅长“为了最终目标当前这一步值不值得做”。2它没有显式全局计划长任务很容易漂移任务一旦变长问题就来了。因为纯 ReAct 的状态主要来自当前 prompt历史轨迹最新 observation这意味着它更像是在“顺着轨迹往前滚”。但长任务真正需要的是主目标子目标依赖关系完成顺序中间验收点如果这些东西没有被显式表示出来模型就容易出现中途改目标重复做已经做过的事跳过关键步骤后面才发现前面做错了很多人觉得自己的 Agent “有点随机”。本质上不是随机。而是没有稳定的任务骨架。3它缺少真正的回溯能力纯 ReAct 大多数时候是单路径前进。错了怎么办常见做法是重新思考再试一次或者追加一次修正动作但这和真正的回溯搜索不是一回事。真正复杂的问题经常不是“这一步做错了”而是你从第 3 步开始整条路线就选错了。比如代码修 bug误判根因研究问题选错调查路径数学 / 逻辑任务早期假设有问题Web Agent 点进了错误页面流程纯 ReAct 往往只能在错误轨迹上继续补。而不是回到岔路口重新选一条分支。4轨迹越长context 越脏模型越容易失真ReAct 非常依赖历史轨迹。但历史轨迹一长就会带来几个副作用问题结果历史 observation 太多关键信息被淹没中间错误思路残留后续决策被污染上下文持续膨胀token 成本升高、注意力变差无效步骤累积模型越来越难抓住主线所以你会发现很多 ReAct Agent 不是第一步错而是跑到第 12 步以后开始变笨。不是模型突然不聪明了。而是上下文里垃圾太多目标太散状态表示开始退化。5它对“高分支决策”不友好有些任务不是线性的。而是天然需要考虑多个候选路径。比如这个 bug 是配置问题、依赖问题还是并发问题这个研究主题应该从论文、博客、代码库还是 benchmark 切入这个工具应该先调用 A 还是 B这个网页流程应该点入口 1、入口 2还是先搜索这类任务的本质不是“执行”。而是选择。而选择的本质不是单步反应。而是探索多个分支再比较优劣。纯 ReAct 在这里会天然吃亏。6它容易形成“看起来在工作实际上在空转”的假忙碌这是最真实的工程问题。你看日志会发现 Agent 非常勤奋一直在思考一直在调工具一直在产出 observation但最后任务效果一般。为什么因为ReAct 天然鼓励“持续行动”。而很多任务真正需要的恰恰是先停一下先列清楚目标先评估路线先决定最值得探索的方向换句话说ReAct 很容易让系统进入“行动很密策略很弱”的状态。三、所以问题不是“要不要 ReAct”而是“ReAct 上面要不要加规划层”这件事想明白以后后面的三种范式就很好理解了。它们其实是在回答同一个问题Agent 的规划到底应该在什么时候发生、规划到什么粒度、允许探索多少分支四、三种范式一张表看懂你可以把它们理解成三种完全不同的工作方式Plan-Then-Act先画施工图再开工ReAct 轻规划一边施工一边盯 checklist 和里程碑Tree / Graph Planning先模拟多种施工方案再选最好的一条必要时回溯五、第一种Plan-Then-Act —— 先想清楚再动手它的核心思想是什么非常简单先生成一个显式计划再按计划执行。流程一般是Goal - Plan - Execute Step 1 - Execute Step 2 - … - Finalize和纯 ReAct 最大的区别是ReAct 把“思考”嵌在每一步里。Plan-Then-Act 把“全局思考”前置了。它适合什么任务适合目标清晰、路径相对稳定、步骤依赖明确的长任务。比如写一篇结构化报告做固定流程的数据分析跑一个有明确步骤的代码迁移完成标准比较清楚的企业工作流多步骤表单填写、批量信息处理它的优点是什么1全局一致性更强有了前置计划任务不容易中途漂。2更省工具调用因为先想过路线所以不容易东试一下、西试一下。3更容易做权限、预算、风险控制比如企业系统里你可以对计划先审一遍哪一步涉及外部 API哪一步涉及删改哪一步要人工确认4日志和复盘更清楚你可以区分计划错了还是执行错了它的缺点是什么1最怕一开始就计划错前置规划一旦偏了后面执行再稳定也没用。2环境一变计划容易过期如果任务是动态的比如网页状态变化、搜索结果变化、外部系统波动那前面那张计划很快就失效。3规划成本前置容易过度设计有些任务没那么复杂。你上来先做一版大计划反而比直接做更慢。4对不确定性强的任务不够灵活如果问题本身要边探索边定义纯 Plan-Then-Act 会显得僵。一句话理解Plan-Then-Act 适合“路线大体可知”的任务。它拿全局性换灵活性。六、第二种ReAct 轻规划 —— 不是推翻 ReAct而是给它加骨架如果你真做过 Agent 系统大概率最后都会走到这一层。因为纯 ReAct 太散纯 Plan-Then-Act 又太死。前者的问题是能一直动但不一定一直在主线上。后者的问题是起手很稳可一旦环境变了前面的计划又容易一下子僵掉。真落到工程里大家最后要的通常不是某个最优雅的范式而是一个别太贵、别太脆、还能跟着环境变的折中解。这也是为什么ReAct 轻规划往往才是工业界最常见的答案。更直接一点它做的不是推翻 ReAct。它做的是给 ReAct 补一层不会太重、但足够有用的小骨架。什么叫“轻规划”不是搞一个特别重的 Planner。而是加一些足够有用、但不太贵的结构比如任务分解列表当前子目标剩余待办成功标准阶段性检查点每 N 步重规划一次执行前先选策略再进 ReAct它和纯 ReAct 的核心区别是什么最核心的区别就一句话纯 ReAct 主要靠轨迹推动。ReAct 轻规划 主要靠“轨迹 小地图”共同推动。它适合什么任务适合中等复杂度、环境有变化、但又不值得上重搜索的任务。比如多轮资料搜集与整理中等复杂度的代码修改需要多工具配合的工作流中等长度的网页任务有阶段目标的研究、分析、自动化执行它的优点是什么1比纯 ReAct 稳很多2比纯 Plan-Then-Act 灵活很多3实现门槛相对低4工程性很好它的缺点是什么1它本质上还是“单主路径”2规划层如果太弱容易沦为装饰3规划和执行容易互相污染4在极复杂任务里依然不够一句话理解ReAct 轻规划适合绝大多数真实 Agent 任务。它拿一点复杂度换来明显更稳的执行。七、第三种Tree / Graph Planning —— 真正把“搜索”引入 Agent如果前两种方法本质上还是“先选一条路再往前走”。那 Tree / Graph Planning 做的事情就不一样了。它直接问为什么只走一条路既然复杂任务本来就可能有多条解法那系统为什么不能同时展开多个候选思路对每个分支做评估保留高价值路径淘汰低价值路径必要时回溯甚至合并共享状态ToT 的核心思想是什么ToTTree of Thoughts直译就是思维树。它的核心不是单轮长思维。而是把多个中间思路当成搜索节点展开、评估、选择。LATS 的核心思想是什么LATS 一般可以理解成Language Agent Tree Search一类方法。重点不是名字。重点是它把树搜索真正和 Agent 执行闭环结合起来了。也就是说每个节点不只是“想法”。还可能包含状态动作观测价值评估rollout 结果未来潜力估计为什么还会提到 Graph Planning因为真实任务不一定天然是树。树的问题在于很多路径其实会回到相同状态有些中间结果可以复用有些节点之间存在交叉依赖这时候用图比用树更自然。它适合什么任务适合高不确定性、高分支、高价值的复杂任务。比如复杂代码修复深度研究与证据链构建数学 / 逻辑推理多路径网页交互任务高代价决策任务需要显式探索备选方案的 Agent它的优点是什么1它真的能探索多个候选路径2它具备回溯能力3更有机会拿到全局更优解4天然适合和 value model、critic、reward 结合它的缺点是什么1贵非常贵2分支爆炸是真问题3评估器一旦不靠谱整个搜索会被带偏4工程复杂度高很多一句话理解Tree / Graph Planning 适合“路径选择本身就是难点”的任务。它拿高成本换更强的探索与回溯能力。八、真正的核心区别不在名字而在“规划的位置”和“搜索的宽度”下面这张表最关键。维度Plan-Then-ActReAct 轻规划Tree / Graph Planning规划位置执行前执行中持续存在搜索过程中反复发生默认路径数1 条1 条主路径多条候选路径是否允许回溯弱有限强适合任务稳定长流程动态中复杂任务高分支复杂任务核心优势全局一致平衡稳定与灵活探索与全局最优核心风险计划僵化仍偏单路径成本和复杂度爆炸你可以把它压缩成一句话Plan-Then-Act先有地图再走ReAct 轻规划边走边看地图Tree / Graph Planning先探索多张地图再决定走哪条九、真实工程里到底该怎么选核心不是谁更高级。而是谁更匹配任务结构。场景一流程明确、变化不大比如固定步骤的数据处理结构化报告生成企业审批链明确 SOP 的自动化流程优先考虑 Plan-Then-Act。场景二任务中等复杂、环境有反馈变化比如网页检索 汇总多工具协作的普通 Agent中等复杂代码任务一般研究和执行类任务优先考虑 ReAct 轻规划。场景三分支多、试错贵、路线选择本身很难比如复杂 bug 修复高价值 research agent数学 / 逻辑推理长链条复杂决策任务优先考虑 Tree / Graph Planning。十、很多人还有一个误区以为 ToT / LATS 是为了替代 ReAct更准确地说它们不是替代关系而是分层关系。很多更强的系统其实是这样的外层搜索 / 规划内层局部节点仍然用 ReAct 执行也就是说用 Tree / Graph 来决定探索哪些候选路径在每个具体节点上依然用 ReAct 来完成动作-反馈闭环这很合理。因为 ReAct 解决的是行动闭环问题而 ToT / LATS 解决的是搜索与规划问题。十一、如果面试官追问为什么现在越来越多系统不满足于纯 ReAct你可以直接这样答因为纯 ReAct 本质上是局部贪心式闭环。它能让模型行动但不能稳定解决长周期、高分支、强不确定性的复杂任务。所以工业界开始在 ReAct 外面加规划层。如果任务路径比较稳定就用 Plan-Then-Act如果任务动态但复杂度中等就用 ReAct 轻规划如果任务本身需要探索多个候选解并支持回溯就用 Tree / Graph Planning比如 ToT、LATS。本质区别在于规划发生的时机、搜索空间的宽度以及是否支持显式回溯。十二、最后给你一个最实用的判断标准别再问“哪个范式最先进”。你真正该问的是这 3 个问题你要判断的事如果答案是“是”更适合路线是否大体已知是Plan-Then-Act执行时是否需要频繁根据反馈调整是ReAct 轻规划是否必须同时探索多个候选路径是Tree / Graph Planning再压缩成一句最接地气的话任务越像走流程越适合先计划。任务越像边做边修越适合轻规划 ReAct。任务越像走迷宫越需要树和图搜索。十三、最后说一句所以问题从来不是 ReAct 过时了没有。问题是你面对的任务到底是一路往前走就能解决还是本来就该先停下来想路。这两个任务看起来都叫 Agent。做法其实差得很远。真正成熟的工程思维也不是先选你最喜欢的范式。而是先看任务结构再选控制结构。ReAct 很重要但它不万能。Plan-Then-Act 很稳但它不通吃。ToT、LATS 很强但也不是每个系统都值得上重搜索。所以如果你真的在做 Agent不要只会背名词。你更需要先把任务看明白再决定系统该怎么长。不然最后特别容易出现一种假象系统一直在动但就是没有真正靠近答案。你要学会问这个任务是流程问题还是探索问题它需要全局计划还是局部反馈它是一条路走到黑还是要保留多条候选路径错误是能局部修还是必须回到岔路口重来当你开始这样想问题时你才真正开始进入 Agent 系统设计。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】