做Agent开发有一段时间的人基本都会走到同一个路口大模型本身已经能聊天、能写代码、能总结文档但把它包装成能“自己决策、自己规划下一步做什么”的Agent时却总感觉差一口气。差在哪差在模型只会“生成下一个Token”而Agent需要的是“生成下一步行动”。这也是为什么大家开始研究ReAct、Plan-and-Execute、Reflexion和Tree of Thoughts这几种决策与规划范式。它们本质上是在回答同一个问题在什么时机用什么方式让模型把“思考”和“行动”正确连接起来并且在出错之后还能自己救回来。这篇文章我准备把这四种范式一次讲透。没有纸面空谈也不会只丢概念我会尽量还原我实际做Agent项目时的思考过程为什么选这个方案、哪里容易翻车、上线时要处理哪些脏活累活。如果你正在用LangChain、CrewAI、Dify这类框架搭Agent或者在纠结“我的业务场景到底该用ReAct还是Plan-and-Execute”这篇文章应该能帮你不靠猜做决定。1. 先理解Agent决策与规划的四条技术路线从串行循环到树状搜索1.1 Agent的“决策”到底指什么我们常说的Agent本质是一个“感知 → 决策 → 行动 → 观察”的闭环。感知是把用户请求、工具返回结果、历史记忆组装成上下文决策是决定“下一步调用哪个工具、输出什么内容”行动是真正执行一次工具调用或文本回复观察则是把执行结果再送回上下文。这里面最核心、最影响成败的就是决策环节——它不完全靠大模型的“灵感”而是靠一套决策框架把模型的推理能力约束在正确轨道上。没有决策框架的裸Agent通常会表现出两个毛病一是走一步看一步模型看到一个工具返回结果后就忘掉了原始目标在无关上下文里来回打转二是“自信地犯错”当推理出错时模型不但不能识别还会把错误沿着后续步骤放大最后给你一个格式整齐、逻辑全错的答案。ReAct、Plan-and-Execute、Reflexion、Tree of Thoughts这四种范式实际就是针对这些毛病给出的不同解药。1.2 四种范式的地图它们分别解决了哪一环我把这几种范式放在一张“心智地图”里会更容易理解ReAct推理和行动交织在同一个循环里模型边想边做每执行一步工具调用前先输出一段推理再把观察结果拼回上下文。解决的是“决策与行动脱节”的问题。Plan-and-Execute先让模型生成完整执行计划再按计划逐步调用工具遇到失败时可以做局部重规划。解决的是“长任务频繁决策后容易偏离主线”的问题。Reflexion在一个任务失败后模型对整条执行轨迹做自我反思把“哪里错了、下次怎么做”写入记忆然后重新尝试。解决的是“Agent没有记忆修正能力”的问题。Tree of ThoughtsToT不再只沿着一条推理路径走而是把每一步的多个候选想法展开成树用评估函数打分再通过搜索BFS/DFS探索不同分支。解决的是“复杂推理一步错步步错”的问题。这四种并不互斥实际项目里经常叠加使用。我自己的经验是ReAct是地基Plan-and-Execute是给地基上盖框架Reflexion是给框架装“事后复盘”ToT则是专门处理高难度推理点的“重型武器”。下面我会按这个顺序一个一个讲。2. ReAct把推理轨迹和行动轨迹缝在一起的循环2.1 为什么是“推理 行动”而不是“先推理再行动”ReAct这个名字来自论文《ReAct: Synergizing Reasoning and Acting in Language Models》核心思想非常朴素把模型的思维链Chain of Thought和工具调用交错进行。传统CoT是让模型从头到尾把推理写完最后给出答案ReAct则是每推理一小步就实际去查一下资料、调一下工具把真实返回结果作为下一轮推理的输入。这样做的直接好处是模型不会在第一步假设错误之后后面全都建立在一个错误地基上。我做第一个Agent时犯过很典型的错先让模型用CoT生成完整“解题思路”再统一调工具。结果模型在没有见过真实工具返回值的情况下写出了不少像样的中间结论但实际上每一步用的假设都是错的。后来切到ReAct模式每次只规划“当前这一步”然后立刻查数效果立竿见影。关键区别在于ReAct不是让模型一次性猜出整条路而是让它不断“看到路况再拐弯”。2.2 一个最小可跑的ReAct循环Python伪代码理解ReAct最快的方式是看一段最小实现。我在这里用最朴素的Python逻辑写不依赖框架方便你理解骨架def react_agent(query, tools, llm, max_steps8): context [{role: user, content: query}] for step in range(max_steps): # 让模型基于当前上下文输出Thought和Action response llm.generate(context) thought, action parse_response(response) # 如果模型认为已经可以给出最终答案 if action Finish: return thought, action[answer] # 执行工具调用 observation run_tool(tools, action) # 把思考、动作、观察结果全部拼回上下文 context.append({role: assistant, content: response}) context.append({role: user, content: fObservation: {observation}}) return Reached max steps代码里的parse_response需要按你使用的结构化输出格式来解析。实际项目里我会用JSON格式约束模型的Thought和Action例如{ thought: 用户想知道北京今天的天气我需要先查询天气接口, action: get_weather, action_input: {city: 北京} }这样把模型输出解析成结构化指令比直接调用工具函数更稳定也方便做日志审计和回滚。在我用LangChain搭的早期项目里AgentExecutor其实就是这套循环的工程化封装它帮你处理了Thought/Action/Action Input/Observation的格式约定但底层逻辑和上面这段代码是一回事。2.3 ReAct容易踩的坑循环控制、Token爆炸、工具异常ReAct最让我头疼的三个问题如果你不提前处理上线必炸。第一个是循环控制。真实世界的工具调用经常返回巨长的日志或异常堆栈模型看完之后可能一遍遍重复同一个失败的Action。所以我强烈建议在AgentExecutor外层加一个步数上限同时把“重复调用同一工具相同参数”的次数计入限制一旦超过就强制切换策略或者直接终止。第二个是Token消耗。ReAct每执行一步就会把Thought、Action、Observation全部追加进上下文10步下来上下文就可能破万Token。这会带来两个问题慢而且后面的步骤模型注意力会涣散。我常用的做法是给Observation做截断和摘要——比如工具返回2万字符只保留前2000字符加一个“若需要更多数据请再调详情接口”的提示。这本质上是在给Agent做“记忆压缩”。第三个是工具异常。实际业务里工具失败是常态接口超时、返回格式不对、权限不足都很常见。你必须在循环里预设“工具调用失败时的兜底动作”重试一次、换备用工具、还是在Observation里明确告诉模型“该工具失败请调整计划”。我以前在电商订单Agent里吃过亏库存查询接口偶发500模型没有收到失败信号反而把“查询失败”当成了“库存为零”直接对用户说商品下架。那次事故之后我在所有工具调用外面统一封装了返回状态码强制把失败原因写进Observation。3. Plan-and-Execute先画地图再走路必要时回退重画3.1 为什么“边想边做”在长任务里会散ReAct虽然灵活但在多步骤、跨系统、长时间执行的任务里有一个致命弱点每一步的决策都只基于当前局部上下文缺少对全局目标的强约束。举个我做过的人力资源系统Agent例子任务目标是“帮新员工完成入职流程创建账号、分配工位、配置权限、发送欢迎邮件”。如果用ReAct模型每一步都正常但走到第三步时突然发现权限配置缺少一个参数于是开始“自由发挥”去查其他接口结果把流程带偏到“修改组织架构图”上。这个偏差在实际日志里非常难追查因为每一步单独看都合理。Plan-and-Execute的核心差异在于在开始执行任何工具之前先让模型生成一份完整计划。计划通常是一系列有序的步骤描述比如1. 获取新员工基本信息HR系统 2. 创建企业邮箱账号IT系统 3. 分配默认权限组RBAC服务 4. 查询可用工位并分配行政系统 5. 发送入职欢迎邮件通知服务然后每个步骤由一个独立的“执行器”完成。执行器可以是一个简单的ReAct循环也可以是一个固定函数。关键设计是每完成一步就对比“计划中的预期结果”和“实际返回结果”如果不一致触发重规划Re-plan而不是继续按原计划走。3.2 实现分工Plan Agent、Executor Agent、Re-planner在工程上我把Plan-and-Execute拆成三个独立组件Plan Agent负责把用户目标拆解为带依赖关系的任务列表。我会要求它明确标注每一步的前置条件、预期输出、需要调用的工具名。这一步的输出质量直接决定整个链路的稳定程度所以我会在Prompt里给它提供“可用的工具清单及参数说明”让它不要把计划做到不存在的接口上。Executor Agent每个计划步骤可以单独执行。如果一个步骤本身需要多次工具调用我会给它挂一个子ReAct循环或者直接调用写好的函数。重点是执行器必须有明确的“成功/失败”判定不能含糊。Re-planner当执行器返回失败或结果不符合预期时Re-planner会把“已完成步骤、失败原因、原始目标”一起发送给大模型让它决定是修改剩余计划、跳过该步骤还是补充新步骤。这个机制让“先计划再执行”不至于变成死板的流水线。很多框架已经把这套模式内化了。比如CrewAI里创建多个Agent并设置process为sequential或hierarchical本质上就是在用不同Agent承担“规划”和“执行”的角色Dify里的“工作流”节点编排也可以看作一种手工版的Plan-and-Execute。但我更建议你先理解原理再选框架否则很容易被框架的抽象层限制住。3.3 我踩过的坑计划太细、重规划太频繁Plan-and-Execute听起来比ReAct靠谱但它有两个典型的反模式都是我亲身体会过的。第一计划阶段不要追求“每个步骤都精确到参数”。我曾要求Plan Agent在第一步就生成“调用createUser接口的完整JSON payload”结果计划阶段消耗了大量Token而且只要有一个字段猜错后面所有步骤都得重来。现在我会要求计划只做到“任务级”明确做什么、调用什么系统、期望得到什么交付物具体参数留给执行器临场去填。这样计划稳定得多也抗业务字段变动。第二重规划不是万能的别让Re-planner乱触发。我有一次把“执行结果不符合预期就重规划”设置得非常敏感结果Agent在一步轻微波动后重新规划了整条链路前面已经完成的步骤也被推翻重做。后来我给重规划加了约束只有“明确的目标偏离”或“出现无法恢复的硬错误”时才重规划局部小问题优先在当前步骤内补救。还要给全局重规划次数设上限比如最多3次超过就终止并呼叫人工。这既是技术约束也是风控要求。4. Reflexion用自我反思修补Agent的短期记忆4.1 核心思想Agent不仅要“想”还要“记得自己怎么想错的”ReAct和Plan-and-Execute都在控制“当下的动作”但都没有解决一个学习问题Agent在同一个任务上失败后如果换个用户再问一次类似问题它大概率以同样的方式再失败一次。因为每一次运行的记忆都随请求结束而清空了。Reflexion的思路非常直接在一条轨迹执行失败后让模型生成一段结构化的反思——失败的原因是什么、哪一步判断失误、下一次遇到类似情况应该怎么做然后把反思存起来。当Agent再次面对同类任务时把之前反思的内容作为额外上下文输入。听起来有点像给Agent加了个“错题本”。实际上很多团队用向量数据库保存反思按相似度检索注入Prompt就是最基础的落地方式。4.2 反思的内容比反思本身更重要我在实现Reflexion时踩过一个坎一开始我让模型“请总结为什么失败”结果生成的反思全是废话比如“工具可能超时需要更小心”。这类反思放进错题本里不但没用还会稀释有效上下文。后来我改成结构化Prompt强制模型按四部分输出反思目标回顾原始任务目标是什么我最终完成的交付物是什么。失败点定位在哪个具体步骤观察到什么信号偏离了目标。根因判断是计划缺陷、工具调用参数错误、上下文信息缺失还是对结果的解读有误。改进策略如果重来一次我会改变哪一个具体操作、补充哪一项信息、或者调整哪一步顺序。举个例子一个数据查询Agent失败后的反思可能是{ goal: 找出上季度销售额Top 5产品, failure_point: 在第三步误将‘订单状态’过滤条件收到全部订单导致结果包含大量退款单, root_cause: 漏看了工具参数说明里的status枚举值, improvement: 调用订单列表接口前先检查参数说明对status字段优先采用exclude_refunded }这样的反思文本检索效果好也能被后续运行真正用上。注意这里我强调“最终改进策略”必须可执行、可验证而不是“我要更仔细”。4.3 落地时最容易忽略的两个细节Reflexion落地时有两个容易被忽略的细节直接影响效果。第一是触发条件不是所有失败都要反思。如果一个任务成功完成了其实也可以生成“成功经验”沉淀下来这样错题本就不只是“避错本”还是“经验库”。我建议按任务结果分级失败任务强制反思部分成功任务只记录偏离点完全成功任务可以选择性记录可复用的路数。这样避免过度反思造成额外Token开销。第二是检索时机的设计。很多实现是在新任务开始前一次性检索相关反思然后塞进System Prompt。但如果任务中途发生了目标变化或分支探索最好在每次关键决策前都检索一次反思而不是只在开头注入一次。因为长期运行Agent的上下文会被后续工具输出冲淡开头注入的反思早就排到几千Token之外了模型根本“看不见”。我后来会在ReAct循环每轮生成Thought之前做一次向量检索把最相关的2到3条反思拼接成Observation片段喂回去效果比“只开头注入”稳定得多。5. Tree of Thoughts把决策路径展开成树带评估和回溯5.1 为什么会有ToT单步贪心在复杂推理里不够用ReAct和Plan-and-Execute本质上都是“贪心式”决策模型在每一步选择一个它认为最好的动作做完就走从不对其他可能性做系统性比较。这在简单任务上够用但一旦面对数学证明、逻辑谜题、代码调试这类“需要大量试错”的问题贪心就容易走进死胡同。比如在调试一段复杂代码时模型可能沿着一个错误假设一连改了三次每次都觉得“这次能行”结果都是白费工夫。它缺的是一种“搜索”的能力同时保留多个可能的修复方向哪个失败了能退回原点试另一个。Tree of Thoughts把单条推理链扩展成树形结构。模型在每一步不是生成一个想法而是生成多个候选想法每个候选想法会被一个评估函数打分然后根据搜索策略广度优先BFS或深度优先DFS决定下一步探索哪些分支。这个过程类似下棋时的“多算几步”不是只看眼前掉子而是要评估几个不同走法的后续局面。5.2 ToT的五个基本组件我参考原论文的框架把ToT拆成五个组件这样落地的时候你能清楚知道要写什么思维片段生成器Thought Generator给定当前状态让模型生成若干个下一步候选想法。例如在解数独时生成多个候选数字填空方案。这个环节的Prompt常要求“给出3种不同做法”而不是只给一个。状态评估器State Evaluator对每个候选想法打分或给出“可行/不可行/可能可行”的判断。打分可以用模型自己输出置信度也可以写基于规则的判定函数比如编译是否通过、约束是否满足。搜索算法最常用的是BFS和DFS。BFS适合每层分支数量不多且可以横向比较的场景DFS适合“先深入一条路看能不能走通不通再回溯”的场景。实际项目里我一般把DFS用得更顺手因为它对Token预算更友好。回溯机制当某个分支被评估为失败系统需要回到最近的分叉点选择另一个未探索过的候选分支。这是ToT区别于ReAct的核心能力。终局判定判断某个叶节点是否构成完整答案。这里需要用“验证器”而不是模型自己说“我完成了”。例如代码任务就实际跑测试用例数学题就做符号化简验证。5.3 一个高度简化的ToT实现思路这里我不给你完整代码那会很长而且业务绑定很深给一个可以照着改的伪代码逻辑def tree_of_thoughts(problem, llm, evaluator, max_depth5, branches3): # 初始状态还没任何想法 frontier [{state: , depth: 0, path: []}] while frontier: node frontier.pop(0) if evaluator.is_solution(node[state]): return node[path] if node[depth] max_depth: continue # 生成 branches 个候选想法 candidates llm.generate_candidates(node[state], nbranches) for cand in candidates: score evaluator.score(cand) # 只保留评分超过阈值的候选 if score 0.5: frontier.append({ state: node[state] cand, depth: node[depth] 1, path: node[path] [cand] }) # 可以按评分排序优先探索高分分支 frontier.sort(keylambda x: evaluator.score(x[state]), reverseTrue) return None当依赖的工具是代码解释器时evaluator可以直接执行片段并看是否通过测试当依赖的是纯语言推理时评估器可以用“模型二重采样”方式让另一个独立推理实例判断这个候选方向是否比当前最优方向更有利。实践里ToT的Token消耗通常比ReAct高一个数量级所以不要动不动就上ToT。5.4 什么场景才值得用ToT我的判断标准很简单如果这个任务你用CoT测试10次成功率还是低于50%并且每次失败都发生在不同位置那么值得试ToT如果只是偶尔一次参数传错那用ReAct加反思就够了。我曾在代码修复Agent里局部启用ToT当单元测试失败且Agent前面的修复尝试已经连续两次失败时系统自动切入ToT模式让模型同时生成3种不同的改动方案每个方案都先打补丁跑测试再根据结果回溯换下一个方案。这样把一次代码修复的成功率从不到40%提到了接近70%代价是单次耗时翻了3倍。所以ToT在我心里是“高价值难题专用路径”不是一个默认白天黑夜都开的服务。6. 落地选型四种范式怎么组合以及框架选择6.1 对照表一眼看清四种范式的差异我把它们放进一个对照表方便你给团队评审或做技术选型时直接粘贴范式决策方式是否回溯记忆能力相对成本典型适用场景ReAct单步交错推理行动否依赖上下文窗口低问答、工具调用、信息检索Plan-and-Execute先全局规划再逐步执行局部重规划计划保留在上下文中多步骤业务流程、跨系统操作Reflexion事后反思重试可重试但非搜索使用外部记忆库中高同一类任务反复失败需要经验沉淀Tree of Thoughts树状搜索评估回溯是搜索树辅助记忆高高难度逻辑推理、代码调试、复杂求解实际工作中把四种范式当成“方案A或方案B”是错的。它们是可以叠加的我在CrewAI里搭建过一个客服工单Agent主流程用了Plan-and-Execute把工单分类、知识检索、答复生成拆成三部曲每个步骤内部实际用的是ReAct循环当整个工单处理失败时Reflexion模块会生成反思记录写进向量库而对于那些“需要对比多个政策条款矛盾”的复杂工单我会额外挂一个ToT分支来做决策。这个组合跑下来比单独使用任何一种都稳定得多。6.2 选型建议从业务目标倒推架构不要先问“哪个框架好”先问自己我的Agent最多需要几步才能完成任务允许失败重试吗失败后是否有人在旁边兜底如果任务通常少于5步、目标明确、单次工具调用能完成ReAct足够。它简单、透明、好排查别为了显得“智能”硬上Plan-and-Execute。LangChain的AgentExecutor和OpenAI的function calling都能直接支持。如果是跨系统、多步骤流程比如“创建订单→通知仓库→更新库存”Plan-and-Execute比ReAct更不容易跑偏。Dify里的“工作流”模式和CrewAI里的sequential Process都能帮你落地。如果你们有一个高频失败场景并且Agent能在真实环境里反复尝试比如“自动修无效数据”那一定要上Reflexion。把每次失败原因沉淀成检索经验能肉眼看到失败率逐周下降。如果你们要处理的是“高难度单点问题”比如复杂SQL生成、多约束排期、数学求解那么ToT可能是唯一有效解但你要接受它的成本和延迟。6.3 从我自己的项目里拿来的“生产级”建议最后给你几条不一定写进博客但真实有用的经验第一不管用哪种范式日志里一定要保留完整的Thought/Action/Observation轨迹。ReAct类的Agent最难的不是实现而是出了问题你怎么快速定位。我习惯给每步打上step_id、trace_id并把模型当时的完整输出原样存档这样复盘Reflexion时才有的放矢。第二Prompt里给模型列举工具时顺序会显著影响决策。我试过把高优先级的工具放在列表前三位模型选择它们的概率明显更高。如果你不想让Agent频繁尝试低成功率工具直接调整工具列表顺序比在Prompt里写“尽量别用”更管用。第三所有重试和回溯都要有限次。Reflexion最多重试两次ToT最多回溯三次Plan-and-Execute最多重规划三次。无限重试会让一个失败任务消耗巨额Token最后还可能把API Budget烧完。给上限还有一个好处逼着你在Agent之外设计人工兜底这对生产系统是必须的。第四别忘了一开始的用户目标要始终可见。很多Agent跑偏是因为原始目标被上下文淹没。我现在的做法是在System Prompt里恒定保留一段“原始任务目标摘要”并且每隔若干步由另一个模型判断“当前动作是否仍然和目标相关”。这个“目标进度审计”机制比任何花哨的决策范式都更能兜住底线。说回选型如果你现在还在Demo阶段我建议你先用ReAct把一个最小闭环跑通观察失败模式然后在失败最多的地方引入Reflexion或Plan-and-Execute等到碰到单点难题再看ToT。这样比一开始就搭一个超复杂的多范式编排系统要务实得多。我身边见过太多团队一上来就堆CrewAI多Agent编排结果连最基础的ReAct轨迹还没稳定排错成本直接翻了好几倍。Agent架构不是越复杂越好而是“在刚好能解决问题的复杂度里给未来留出升级空间”。
原理与实现全解析)
