如果你最近在折腾 Autonomous Agent自主智能体一定会被这几个词反复刷屏ReAct、Plan-and-Execute、Reflexion、Tree of Thoughts。它们不是互相替代的关系而是解决同一个核心问题——Agent 该怎么决策、怎么规划——的不同思路。我是在把 Agent 真正放进业务流程里头踩过无数死循环、幻觉复读、工具乱用之后才慢慢把这四种范式吃透的。这篇文章不打算复述论文而是想用一个从业者的视角把这四种决策与规划范式掰开揉碎讲清楚它们各自解决什么问题、适合什么场景、怎么低成本落地以及我在给新项目选型时最看重的几个点。1. 为什么 Autonomous Agent 的决策与规划会成为核心难题1.1 从“能对话”到“能干活”的距离LLM 本身擅长生成文本但“生成文本”和“完成任务”是两码事。你让模型直接回答“帮我查一下今天上海到北京的航班”它可能编一个航班号。但如果你给它一个查航班工具让它先查、再答结果就变成了可信的事实。这一步跨越就是 Agent 区别于普通 Chatbot 的关键。决策与规划之所以难是因为 Agent 需要在不确定的环境里持续选择“下一步做什么”。打个比方普通对话像问路对方给你指个方向就够了Agent 干活像让一个人自己去陌生城市送快递他要自己看地图、查路况、绕开施工路段、确认收货人每一步都可能有意外。ReAct、Plan-and-Execute、Reflexion、Tree of Thoughts 正是四种不同的“带人干活”的方式。从我实际观察来看很多新手一上来就堆工具拖了二三十个 API 给 Agent结果模型根本不知道什么时候该调哪个。问题根源不是工具不够而是缺少一个决策框架——Agent 不知道怎么把任务拆解、怎么选择工具、怎么从错误中恢复。这就是为什么这四种范式值得逐个研究。1.2 四个范式背后的统一问题搜索与利用的权衡如果抽象一点看Agent 决策本质上是在一个巨大的“动作空间”里搜索可行路径。ReAct 是贪心搜索每一步都选当下最合理的动作Plan-and-Execute 是先有一个粗粒度计划再按计划执行Reflexion 是用历史经验修正搜索方向Tree of Thoughts 则是显式地维护多条候选路径做系统性搜索。理解了这个底层逻辑你就不会被名词绕晕。它们各自在“探索新路径”和“利用已有知识”之间取了不同的平衡点。ReAct 偏向利用执行快但容易走一步看一步ToT 偏向探索思考深但成本高Plan-and-Execute 试图减少重复决策Reflexion 则试图从失败中积累经验。生产环境里没有银弹组合使用往往是更务实的方案。2. 逐个拆解四种决策范式的原理与边界2.1 ReAct把思考外化成可被观察的动作ReAct 的全称是 Reasoning Acting核心循环是 Thought推理→ Action行动→ Observation观察。模型每产生一个思考就去调用一个工具拿到观察结果后再继续推理直到生成最终答案。我最早用 LangChain 的 Agent 时默认跑的就是这个循环。它最大的价值是让模型不再“闭门造车”。比如我问“对比一下 A 方案和 B 方案的运行成本”模型如果只凭训练数据回答很可能给的是过时价格但在 ReAct 模式下它会主动去查定价文档、调用计算器把数据拿到手再下结论。不过 ReAct 的坑也不少。最典型的是死循环模型反复调用同一个工具拿回同样的结果然后继续调用。因为模型没有“我已经查过了”的短时记忆机制它每一次循环都像失忆一样重新开始。后来我在工程上加了两道保险最大迭代次数比如 10 轮和动作去重检查同一工具同一参数重复 3 次就直接终止并输出中间结论。这类防护不是可选项是必选项。2.2 Plan-and-Execute先画地图再按地图走Plan-and-Execute 的思路很朴素执行之前先让 LLM 把整个任务拆成一个有序的步骤列表然后由一个执行器逐条执行。相当于你先在地图上画出路线再一步步走。这个范式的好处是省 token 且稳定。ReAct 每一步都要重新决策思考开销大Planner 只需要在任务开始和关键节点各规划一次执行阶段模型只需要关注当前步骤上下文压力小很多。我之前做过一个批量处理任务把 200 个文件分别做格式转写、摘要、归档。如果用 ReAct每个文件都要反复“该干什么”地绕圈改成 Plan-and-Execute 之后规划一次处理流程剩下 200 次执行都跟流水线一样干净。它的短板也很明显计划赶不上变化。如果任务中途出现意外情况比如某个文件缺字段、某个 API 返回异常固定计划就失效了。因此落地时不能只用一次性 Planner还要加一个 replan 机制——执行器发现某步失败且无法重试时把当前状态送回 Planner 重新制定剩余计划。这个“执行中重规划”才是 Plan-and-Execute 在生产环境真正好用的形态。2.3 Reflexion让 Agent 从错误中学习Reflexion反射的核心机制是语言化反馈。传统强化学习要更新权重Agent 很难做到但 LLM 有个天然优势它能用自然语言描述错误经验然后在下次决策时把这些经验当作提示词注入。简单说就是把“上次怎么失败的”写进记忆里下次不再犯。我实际用 Reflexion 最多的地方是写代码类 Agent。比如让 Agent 写一个脚本处理 CSV第一次它没考虑空值导致报错传统 ReAct 只会拿到错误堆栈后试着再修一次但同样的错误可能换个姿势反复出现。加上 Reflexion 后失败后会生成一条反思记录“这个数据集有空值处理前必须 fillna(0) 或 dropna()”下次遇到同类任务模型直接跳过踩坑过程。要注意的是反思记录不是越多越好。记忆太多会让模型注意力分散甚至把无关的失败经验当成“重要线索”。我的经验是每条反思记录要做结构化处理触发条件、错误类型、解决办法、适用边界。然后按相关性排序只注入当前任务最相关的前 3 到 5 条。否则 Reflexion 会从“经验增益”变成“噪音污染”。2.4 Tree of Thoughts用搜索空间换取决策质量Tree of Thoughts思维树是四种范式里最接近“系统性思考”的。它不再让模型沿着一条链往下走而是每到一个决策点先生成多个候选思路给每个候选打分再择优扩展下一层形成一棵树。最后走完整棵树选出最优路径。这个范式我在两个场景下用过一类是逻辑推理题比如“谁是小偷”这种条件约束题单链推理容易一条路走到黑另一类是任务拆解本身让 LLM 在规划阶段生成多个备选计划从中选一个最靠谱的再执行。它明显能提升决策质量但代价也大每个节点可能要调用 3-5 次 LLM计算成本线性上涨延迟也翻倍。如果任务本身就简单用它就是杀鸡用牛刀。ToT 工程化的难度主要在两点一是评估函数的稳定性让另一个 LLM 打分分数时高时低需要做归一化或多次投票二是搜索策略的取舍。我常用的是 beam search 变体每层保留 top-k 个节点既控制了树的宽度又不至于像 DFS 那样钻牛角尖。搜索宽度设为 3 到 5深度控制在 4 到 5 层成本和质量比较均衡。3. 怎么选型场景匹配、能力边界与组合使用3.1 一张表学会场景匹配很多朋友喜欢问“哪个范式最强”真实答案永远是“看场景”。我整理了一个选型参考表基本覆盖了常见任务类型任务特征推荐范式关键原因客服、问答、简单信息查询ReAct实时交互强能灵活调用知识库和计算工具批量数据处理、流水线作业Plan-and-Execute流程固定减少反复决策token 更省代码修复、数据清洗ReAct Reflexion错误可复盘经验可复用提升迭代效率复杂推理、谜题、策略设计Tree of Thoughts多路径搜索避免单链条走死长周期项目、任务多变计划 重规划 Reflexion既稳又能适应变化还能沉淀经验这套匹配逻辑背后的原则是任务的不确定性越高越需要显式的搜索任务的重复性越高越值得做规划和记忆沉淀。别在确定性任务上多花钱也别在不确定性任务上省思考。3.2 组合玩法ReAct Reflexion 是目前性价比最高的起点如果你只打算给现有项目加一个 Agent 能力我会优先推荐 ReAct Reflexion 这个组合。原因很简单ReAct 足够灵活能应对大多数工具有调用场景加上 Reflexion 后系统可以在失败中积累经验逐步变强。这就像带新人一个人边干边复盘的三四个月后通常比照着标准作业流程死干的人更能独当一面。更复杂一点的场景可以用 Plan-and-Execute 做外层框架ReAct 做执行器。外层 Planner 负责把任务拆成阶段进入某个阶段后ReAct 负责在该阶段内灵活决策。中间遇到无法处理的失败触发 replan 回到 Planner。这样既有整体规划又有局部灵活性。而 Tree of Thoughts 我建议留在真正需要深度思考的任务里作为单独的服务调用不要让它成为所有流量的默认入口。3.3 成本与延迟的量化账很多 TS 朋友忽略了一个事实决策范式直接决定了 token 消耗量。我用一个实际任务对比过同样是“总结一篇技术文章并提取行动项”ReAct 大约消耗 8000 tokenPlan-and-Execute 大约 5000 token而 Tree of Thoughts 如果展开 3 个分支、每个分支 3 层可能会消耗 25000 token 以上。延迟也是这样。ReAct 每个动作都要等一次模型返回通常 3-8 秒完成一次小任务Plan-and-Execute 因为减少了中间决策延迟更低ToT 因为多次串行调用可能跑到 20 秒以上。如果你的 Agent 是嵌在用户交互链路里的延迟超过 10 秒就很难接受。这时候你就要判断是不是可以把复杂推理挪到后台异步执行。成本不该等到账单出来才后悔应该在选型那一刻就算清楚。4. 实操用代码把四种范式落地4.1 先搭好最小工作台我这里以 Python LangChain 生态为例但核心思路可以平移到任何框架。第一步是先定义工具并把工具描述写得足够清楚。语言模型的工具选择能力很大程度上依赖描述文本的质量。我的习惯是给每个工具写清楚“何时使用”“输入格式”“返回内容”。from langchain_core.tools import tool tool def search_web(query: str) - str: 当你需要获取实时信息、验证事实或查找最新数据时使用。输入是搜索关键词返回网页摘要列表。 # 实际接入搜索 API这里省略 return 搜索结果是...工具描述里不要只写“搜索函数”而要写“什么时候用”。差一个关键词模型就可能在“要不要调用它”之间犹豫。4.2 自己写一个最小 ReAct 循环虽然框架里有现成的 AgentExecutor但我建议新手至少亲手写一次 ReAct 循环。这样你能清楚知道每一轮到底发生了什么排查问题才不会抓瞎。MAX_STEPS 8 for step in range(MAX_STEPS): # 1. 让模型基于当前整个对话历史决定下一步 response llm.invoke([ model_instructions, # 解释可用工具、要求逐步思考 *chat_history, ]) # 2. 解析输出分为 Thought / Action / Action Input action parse_action(response) if action Final Answer: print(最终答案:, response) break # 3. 执行工具 result tools_map[action.name].run(action.input) # 4. 把观察结果追加到历史里进入下一轮 chat_history.append((observation, result)) else: print(超过最大迭代数强制结束)写完之后你就明白为什么 ReAct 会出现死循环因为 history 在积累但模型不一定能判断“这个观察和前一轮是否重复”。所以要自己在代码里做重复检测如果 action 名称和输入完全一样且 observation 也一样就直接 break。这是我在生产环境里必加的防线。4.3 Plan-and-Execute 落地两步走加重规划第一步用 Planner 生成计划我习惯让它输出 JSON 列表而不是飘渺的自然语言。结构化输出可以直接映射到代码逻辑减少解析出错。plan_prompt 你是一个任务规划器。根据用户目标生成步骤列表。 要求 - 每一步必须可执行、且依赖的工具体现在步骤描述里 - 输出 JSON 数组格式为 [{step: 1, task: ...}] 第二步是执行器循环。执行器每完成一步就更新状态如果某一步连续重试 2 次仍然失败就调用 replan。for step in plan: ok execute_step(step) if not ok: if retry_count 2: plan planner.replan(goal, current_state, plan, step) break retry_count 1这里有个细节replan 时不要把旧计划全丢弃。我会把“已完成步骤”和“失败原因”一起传给 Planner它才能基于真实进度调整后续步骤而不是从零开始白干。4.4 Reflexion把反思变成结构化记忆Reflexion 的落地关键是建立一个“经验记忆库”。在每次任务失败后调用反思模型生成反思记录然后存回记忆库下次任务开始前从记忆库中检索相关经验放进 System Prompt。def generate_reflection(task, attempt, error): prompt f 任务{task} 尝试过程{attempt} 失败原因{error} 请生成一条结构化反思记录格式 【触发条件】什么情况下会出现这个错误 【解决办法】下次应该怎么做 return llm.invoke(prompt) def build_context(task): memories memory_db.search(task, top_k3) return \n.join(memories)我给你的忠告是反思记录一定要写“什么时候用”而不是只写“发生了什么”。比如“处理 CSV 时如果列里有空字符串先转换成 NaN 再聚合”比“上次报错 KeyError”有用得多。前者是可执行知识后者只是事故描述。4.5 Tree of Thoughts先理解评估与搜索ToT 的代码量不大但设计难度高。核心是一个节点类包含状态、思路内容和评分。class ThoughtNode: def __init__(self, state, parentNone): self.state state self.parent parent self.score 0.0 def generate_candidates(node, k3): # 让 LLM 基于当前节点生成 k 个不同的下一步思路 return [node.state ; thought for thought in llm.generate_k(k)] def evaluate_node(candidate): # 用规则或另一个 LLM 给候选打分 return llm.evaluate(candidate) # 0~1 分搜索时我常用 beam search每一层对每个节点生成 k 个候选保留全局 top-b继续下一层。树的宽度 k 设 3束宽 b 设 4深度设 5。这套参数在小规模任务上效果不错。如果任务规模更大建议退到离线做或者用异步队列慢慢算别堵在主流程里。5. 常见问题与排查技巧实录5.1 一张速查表解决大部分异常我整理了在项目里反复出现的几类问题后面接我的解决思路现象根源处理方式Agent 反复调用同一工具缺少重复检测机制加动作去重重复 3 次直接终止计划第一版就执行不下去Planner 没感知上下文边界重规划时把已完成步骤和失败原因完整传给 Planner反思记录注入后回答变差记忆太多、噪声干扰只注入 top-k 相关记忆并压缩每条记录长度ToT 打分忽高忽低评估模型太弱改用规则评分或多次采样取平均稳定评估器工具返回结果太长上下文被挤爆模型丢失重点对工具返回内容做摘要或截断保留关键字段这些问题的共性是模型本身没出错是工程上没有约束和反馈机制。把 Agent 当一个分布式系统来治理设置超时、重试、重试上限、状态观测点稳定性立刻上一个台阶。5.2 我在实践中踩过的两个最深的坑第一个坑是让 Agent 直接去改生产数据库。当时一个 Agent 在执行测试时误调了写接口把临时数据写进正式库。事后我加了两层保险所有具有副作用写操作、删除操作的工具默认禁止在测试环境直接使用必须经过人工确认开关同时所有工具调用记录都要有 trace 日志出了问题可回放。这个经验希望你们用不上但一定要提前配置。第二个坑是 Reflexion 的记忆库“脏数据”问题。有一次反思记录里混了一条错误结论结果模型每次遇到相似任务都被这条错误经验带偏。后来我意识到反思记录本身也需要评估和淘汰机制不能只增不减。我会设置一个置信度字段连续几次应用后任务都成功置信度上升反之下降低于阈值就淘汰。保持记忆库干净比往里面塞更多经验更重要。6. 进阶扩展记忆、评估与生产化6.1 记忆设计会反过来影响规划质量四种范式里除了 Plan-and-Execute 对记忆要求不高其他三种都强烈依赖记忆机制。Agent 的记忆至少分成三档工作记忆当前任务的上下文缓冲短期记忆当前任务里的工具结果和历史动作长期记忆跨任务的反思和经验沉淀。我见过很多团队在示例里直接把所有历史一股脑塞进 prompttoken 爆炸不说模型还抓不住重点。正确的做法是每轮对话只保留最近 3-5 条关键上下文长期记忆靠检索注入而不是全部加载。6.2 给 Agent 建立评测集而不是靠感觉调参没有评测集的 Agent 优化基本靠猜。我给每个规划范式都建了一套最小评测集20 到 30 条典型任务每一条都明确标注“正确的最终答案”和“关键步骤路径”。比如对于代码修复任务不仅看最终代码能否运行还要看它是否识别了根因。评测指标我会拆成任务成功率、平均轮次、平均 token 消耗、失败率分布。只有把这些数据量化你才能硬气地判断“到底是 ReAct 还是 ToT 更适合我的场景”而不是听谁的安利。6.3 生产化决策别一上来就全都要如果你正在规划一个真实的 Agent 产品我的建议是别一上来就上四种范式大满贯。先用 ReAct 简单记忆跑通最小闭环再逐步加 Reflexion、重规划、ToT。每一步都确认收益大于成本再往下一个阶段走。比如你的业务里 80% 请求是“查信息、写摘要”那 ReAct 足够只有那 5% 的复杂推理需求才值得单独起一个 ToT 服务。这样既控制了成本也避免了过早优化带来的维护地狱。我个人在实际操作中最大的体会是Agent 的决策与规划能力不是靠挑选一个“最强范式”获得的而是靠把基础循环做扎实再根据任务类型不断增加反馈机制。如果你能把 ReAct 的死循环防住把 Reflexion 的经验库保持干净把 Plan-and-Execute 的重规划触发条件设准你的系统就已经比大多数 Demo 级 Agent 强了。至于 ToT把它当作一把偶尔使用的重武器就好别天天扛着。