Agent 这个Topic火了半年多各种框架像雨后春笋一样冒出来但你扒开任何一个号称智能体的项目看底层核心无非是这四件事让模型做决策、做规划、执行工具调用、从反馈里学习。标题里这四个范式——ReAct、Plan-and-Execute、Reflexion、Tree of Thoughts——几乎覆盖了当前生产级Agent的全部主流决策套路。这篇文章不聊框架API怎么拼而是把这四种范式的本质拆开讲清楚它们各自解决什么问题、代价是什么、什么时候该用哪种顺便把我自己在实际项目里踩过的坑和选型经验一并倒出来。适合正在做Agent开发、或者准备从对话机器人往会干活的Agent方向转型的工程师和产品同学作为内部参考。1. 为什么Agent的章法比聪明更重要先说一个反直觉的结论大模型本身并不擅长做成一件事。你让GPT写一首诗、总结一份文档、解释一个概念它一次生成就完成了这是单步任务。但Agent的定义是自主完成多步任务这意味着模型要在一个长期过程中反复做决策先做什么、后做什么、这个结果要不要接受、那个方向走不通要不要回头。这几乎是一个序列决策问题而单次Prompt调用根本承载不了这种过程。很多人刚开始做Agent时有个误解觉得模型能力强Agent能力强。实际不是。模型只是决策的原材料真正决定一个Agent能不能稳定完成任务的是外层那套决策与规划逻辑——也就是标题里这四个范式。打个比方模型像是新入职的员工聪明、知识面广但不知道公司的做事流程决策规划层就是SOP决定了这个员工是先查资料再动手还是先列计划再拆解执行还是撞了墙之后做复盘再来。SOP糟糕员工再聪明也会把事情干得乱七八糟。那一个合格的决策规划层需要回答哪几个问题不外乎这么五件事当前状态是什么——完成目标还有哪些子问题没解决下一步该做什么——是调工具、查资料还是直接生成最终答案做完了怎么评估——这一步执行结果是否正确和预期偏差大吗错了怎么办——是换个工具重试还是回到上一步重新规划整个计划的全局路径是什么——有没有一个统筹性的路线图而不是每一步都现想四种范式其实就是对这几个问题的不同解决方案侧重点差异很大。ReAct强调的是边想边干的实时交替Plan-and-Execute强调的是先谋后动的全局规划Reflexion强调的是记住教训的自我反思Tree of Thoughts强调的是多路探索的分支搜索。它们不是迭代关系而是从不同角度切入决策问题。在我自己带的Agent项目里我见过太多团队在模型调优上花大量精力却忽视决策层设计结果Agent在Demo里惊艳全场一上生产就频繁撞墙。原因几乎都不是模型不够聪明而是决策过程没有章法。搞清楚这一层你才能真正理解为什么后面的四种范式是Agent架构的核心。2. ReAct把思考-行动-观察变成可执行循环2.1 ReAct要解决什么问题ReAct是这四种范式里最基础、也最被广泛使用的一个。它的核心思想非常简洁让模型在推理Reasoning和行动Acting之间交替进行形成一个思考→行动→观察→再思考的循环直到任务完成。为什么要这样设计因为如果只让模型思考而不行动比如传统的Chain-of-Thought它最多只能根据已有知识推理想象遇到需要外部信息的情况就无能为力了反之如果只行动不思考比如早期的工具调用Agent模型很容易瞎打乱撞不知道该调哪个工具也不知道结果怎么解读。ReAct把两者缝合在一起每一步都先想清楚当前需要什么信息再决定调什么工具然后观察返回结果修正下一步计划。2.2 ReAct的一次完整轨迹长什么样假设你让Agent完成这样一个任务查一下上个月的销售数据找出同比下降超过20%的产品线并给产品负责人写一封提醒邮件。ReAct模式的内部轨迹大致如下Thought 1我需要先获取上月销售数据应该先看一下数据表结构确定字段含义。Action 1调用get_table_schema(sales_table)。Observation 1返回字段product_line, month, revenue, last_year_revenue。Thought 2字段清楚了我要查询上月逐产品线的收入以及去年同期收入计算出同比变化率。Action 2调用query_sales_data(SELECT product_line, revenue FROM sales WHERE month 2024-05)。Observation 2返回各产品线收入数据。Thought 3还需要去年同期的数据来做对比继续查询。Action 3调用query_sales_data(SELECT product_line, revenue FROM sales WHERE month 2023-05)。Observation 3返回去年同期数据。Thought 4我可以计算同比了。A产品线下滑25%B产品线下滑18%C产品线持平。A和B超过了20%的阈值需要提醒。Action 4调用send_email(recipientproduct_ownerexample.com, content...)。Observation 4邮件发送成功。Thought 5任务完成输出总结。注意这个过程里Thought和Action是交替出现的每个Observation都会修正下一步的方向。如果第一次查询发现字段根本对不上模型在Thought 4就可能改变策略。这种执行中持续感知的能力让ReAct在面对环境反馈时具备天然的自适应性这是它最核心的价值。2.3 落地ReAct时最常见的三个坑ReAct看起来简单实际落地时翻车的点却不少我一个个说。第一Thought的质量直接决定行动质量。ReAct的循环里Thought是唯一的方向盘如果模型在Thought阶段没有想清楚就贸然调工具后面很可能越走越偏。解决方式是在Prompt里强约束Thought的产出格式——必须包含当前已知信息和缺少什么信息两个部分确保它不是无脑行动。第二Observation过长会击穿上下文窗口。工具返回的结果可能是一张大表、一长段日志直接塞进上下文几轮之后模型就糊涂了开始胡言乱语。稳妥的做法是给每轮Observation做个截断或摘要层只把与当前决策相关的关键字段、摘要结果放进去。我习惯在工具调用外面包一层wrapper先把返回结果做结构化压缩再交给模型。第三循环终止条件不能只靠模型自觉。模型经常出现已经完成任务却还在继续思考的情况或者相反在错误路径上循环重试停不下来。需要在循环外面套一层硬性控制最大迭代轮数、最大token预算、以及一个可选的终止检查器——用一个轻量模型或规则判断当前输出是否已经算任务完成。老实说这一步在工程上比Prompt本身还重要很多生产级Agent框架大量工作就花在这。2.4 ReAct什么时候够用、什么时候不够我的经验是单一目标、步骤在5轮以内、每一步需要的信息可以通过现有工具获取的任务ReAct足够。比如问答机器人接入知识库和搜索、工单分类并自动回复、简单的数据查询助手这些场景ReAct稳定又便宜没必要引入更复杂的范式。但ReAct有一个明显短板它没有全局视野每一步都是局部决策。任务一旦超过10轮模型很容易迷失明明整体方向已经偏了它还在局部修修补补。这就是为什么Plan-and-Execute范式出现了——它试图在动手之前先把全局规划做出来避免走一步看一步的短视问题。3. Plan-and-Execute先交出计划再逐项打勾3.1 它和ReAct的本质差别如果你让带过团队的人来看ReAct他会觉得这像是没有项目计划的执行者——每个任务来了直接开干干到哪算哪。而Plan-and-Execute的思路正好相反先用一个Planner为大模型把任务拆解成一份明确的子任务清单然后由Executor逐条执行每条执行完再回到Planner审视进度。这里的关键在于规划和执行被明确分离成两个阶段。在LangChain框架里这种范式对应的是Plan-and-Execute Agent工作流上分成了planning阶段和execution阶段在Dify这类低代码编排平台里任务规划节点工具执行节点的call chain也是同一个思路CrewAI的Process模式就更明显了——先定义完整流程再按顺序交给不同角色执行。为什么要做这样的分离因为很多任务的复杂度集中在分解而不是执行上。比如帮我整理一份Q3季度竞品分析报告如果让ReAct直接上模型会在过程中反复横跳一会查竞品A一会想报告结构最终输出结构混乱。但如果你先让模型基于目标生成一份计划书第一步搜集竞品产品信息第二步分析定价策略第三步对比功能清单第四步撰写报告大纲第五步填充内容接下来每一步执行就变成了完成清单上的一个勾清晰可控。3.2 一个看得见的对比案例我用一个简化案例来解释两者的差异。任务分析电商平台上一款新品的用户评论输出三条产品改进建议。ReAct模式下模型大约会这样做尝试调用评论获取工具 → 发现需要先确定商品ID → 查询商品ID → 获取评论 → 直接分析 → 输出建议。Plan-and-Execute模式下Plan1. 确认商品基本信息ID、品类2. 获取近30天用户评论数据3. 对评论做情感分类4. 归纳高频问题点5. 结合竞品情况生成改进建议。Execute逐条执行每步完成做一个标记。第三步如果发现情感分类工具不可用Executor把这个问题汇报给PlannerPlanner决定改用规则关键词做粗分类或者跳过直接人工阅读Top评论。你会发现Plan-and-Execute模式下每一步都有上下文都有全局定位。Executor知道自己在执行整个计划的第几步而不是一个孤立的工具调用。对于步骤多、依赖关系复杂的任务这种全局性带来的稳定性提升非常明显。3.3 致命的弱点计划错了就一路错到底看到这里你可能已经注意到Plan-and-Execute的一个隐患了如果初始计划本身有重大问题比如漏掉关键依赖、目标分解错误那么执行阶段做得再完美也无济于事因为你在用高效的方式做错误的事。没有哪个Planner一次就能生成完美计划尤其现实任务里经常出现执行到一半发现需求变了或者某个数据源根本不存在的情况。所以成熟的Plan-and-Execute实现里都会加一个Replanner重新规划器执行过程中如果发现不可恢复的错误比如某个前提不成立、某个步骤缺失就触发重新规划生成一份修订版计划而不是硬着头皮继续。这里面有一个关键的工程判断什么时候触发Replan我建议给Replanner设一组明确的触发器执行器返回错误信息且表明该工具不存在/数据缺失/权限不足连续两次执行同一子任务失败执行结果与计划预期明显不符可以通过相似度或规则检测用户中途输入了新要求。绝对不建议让模型每次都自由决定要不要重新规划那样成本会失控而且容易陷入无限循环。触发条件要写在表层用if-else逻辑控制而不是靠模型自觉。3.4 什么场景下应该优先选Plan-and-Execute按我落地过的项目经验这些场景优先选这个范式流程固定且长周期的任务月度报告生成、批量数据处理、多阶段审查流程。这类任务天然有流程文档把它转录为Planner输入非常自然。需要人工介入确认的任务计划是可审查的颗粒度人可以在执行前先过一遍计划而不像ReAct那样边执行边猜。工具依赖关系复杂任务里存在明显的先后依赖先拉数据→再清洗→再建模→再可视化用ReAct极容易跳顺序Plan-and-Execute能把依赖关系固化。反过来说如果你的任务高度开放、需求模糊、方向需要边做边探索Plan-and-Execute就会显得笨重。这时候其实更值得看看Reflexion——它把试错变成一种正经的学习机制是处理模糊复杂环境的利器。4. Reflexion让Agent在下一次决策前带上教训4.1 Reflexion到底改进了什么前面两种范式都有一个共同缺陷Agent没有记忆同样的错误会以不同形式反复犯。ReAct在A任务里踩过的坑到了B任务里照样踩Plan-and-Execute发现计划有问题重试时Planner完全不知道上次为什么栽了。这和人不一样——人最强大的能力之一就是能从失败中总结教训下次避开。Reflexion正是为了解决这个问题。它的核心思路是给Agent增加一条自我反思的回路任务失败或结果不理想时用自然语言把失败原因和修正策略写下来存入记忆后续决策时把这份反思作为上下文注入指导新行动。注意这不是在微调模型也不改权重而是把教训变成文本作为额外信息参与决策。斯坦福那篇Reflexion论文里用了一个很清晰的框架Actor执行者 Evaluator评估者 Self-Reflection自我反思三者配合形成闭环。4.2 部署一个带反思回路的最小系统我实际搭过一个跑测试并修复Bug的Agent拿它来说Reflexion的具体运作。Actor一个负责改代码→跑测试的循环Agent它发现问题就尝试修复。Evaluator每一轮测试结束后判断测试是否通过。如果不通过返回具体的错误信息比如KeyError: name、TypeError: NoneType object is not subscriptable。Self-Reflection当Evaluator判定失败时额外让模型输出一段反思文本。我给的反思模板大概是这样的本次失败的直接原因是什么我之前遗漏了哪些信息或步骤下次遇到类似问题时我第一步应该做什么Memory把反思文本存入一个列表或向量库。下一轮尝试修复时把这个反思作为上下文的一部分注入。第一轮修复时Agent可能看到一个KeyError: name它自作聪明直接给字典加了个默认值{}结果下游拿到空字典照样崩。放到没有反思的普通Agent里第二轮它可能又犯同样的错误但有了Reflexion第二轮开始前模型会读到这样一条反思上一次我虽然修复了KeyError但没有检查下游对返回值结构的假设。下次修复前先确认调用方期望的字段结构而不是简单补默认值。于是第二轮它会先查调用方代码确认字段结构后再动手问题就能真正解决。4.3 反思的三个层次与落地形态我在实践中会把反思分成三个层次分得越清楚后续回溯效果越好层次关注点示例直接反思这一步为什么错我调用了query_sales_data但参数格式错了因为我没有先确认函数签名摘要反思这类任务怎么避免所有数据库查询前必须先查看schema信息策略反思我整体方向对不对我花太多时间在数据清洗上应该先确认最终输出格式再决定清洗粒度这三个层次在实际落地时对应不同的存储方式直接反思往往是一次性的适合放进短期上下文摘要反思是要反复使用的必须进长期记忆向量库或键值库按任务类型召回策略反思则适合在任务级别保存作为下一次同类任务的启动上下文。4.4 必须避开的反思陷阱Reflexion不是加上反思Prompt就能奏效我吃过几次亏总结出来三个要点第一反思必须具体可执行不能是空话。如果模型写出来的反思是我应该更加仔细地检查错误信息——恭喜你这条反思毫无价值。我在Prompt里会强制要求反思必须以下次行动的第一步结尾比如下次发生TypeError时第一件事是打印变量的类型和内容这种能落地的反思才有意义。第二反思不是越多越好。每条反思都占用上下文塞入几十条旧反思会稀释当前任务的焦点模型反而不知道该听谁的。实践中我通常只保留最近3-5条相关反思或者按语义相似度从向量库里召回Top-3多余的果断丢弃。第三Evaluator的质量决定Reflexion的天花板。如果Evaluator本身判断失误明明失败了却判定成功或反之反思就会建立在错误基础上整个回路变成有效率的犯错。所以生产环境里Evaluator不能完全靠大模型拍脑袋最好Mix规则检查测试有没有通过、接口有没有返回、数据有没有NULL这类客观信号用规则兜底规则覆盖不到的再用模型评估。5. Tree of Thoughts在思路树里做搜索而不是一条道走到黑5.1 为什么需要多路探索ReAct和Plan-and-Execute本质上都假设模型沿着一条路径往前走要么边走边修正要么按计划走但走错了不会回头看有没有更好的路。这在日常简单任务里没问题但遇到需要深度推理、探索性强的任务——比如逻辑谜题、数学证明、方案设计——一条道走到黑很容易走进死胡同而且不给你回头的机会。Tree of ThoughtsToT的思路完全不一样它把推理过程当成一棵树来搜索每一层都生成多个候选思路对每个候选思路做评估然后选择最有希望的方向继续深入如果走不下去就回溯到上层换一条路径探索。这在本质上把大模型的推理从贪心解码升级成了一次树搜索和传统AI里的BFS、DFS、beam search是一套血脉。5.2 ToT的关键机制和实现要点ToT的实现通常包含四个核心组件我用伪代码的形式梳理一遍State节点状态当前推理的中间状态其实就是上下文里的已完成部分。实现时建议把State封装成一个可序列化对象比如一个包含已收集的事实、当前结论、待验证假设的JSON结构。Thought Generator思路生成器给模型一个当前状态让它生成N个候选的下一步思路。Prompt里要明确给出多个不同方向的方案不要只给一个。State Evaluator状态评估器对每个候选思路打分判断沿着这个思路继续下去有多大概率成功。打分既可以是让模型直接给0-10分也可以用它对比各方案后再排序——后者在论文里被称为evaluating with voting比直接打分稳定得多。Search Algorithm搜索算法遍历思想树的整体策略比如BFS一层一层推进适合解空间较浅的任务DFS一条路挖到底不行再回溯适合深度推理。举一个我测试过的例子让Agent设计一款面向大学生的校园二手交易App的冷启动策略。普通ReAct模式会直接输出一个方案但它可能只覆盖线上推广这一个维度。换成ToT模式模型在第一层先生成三个方向——线上社区运营线下地推活动校园KOL合作计划然后对每个方向打分在地推方向内部再生成宿舍楼扫楼食堂摆摊社团联合活动等更多细化分支最后横向比较选出最优组合。整个输出过程明显更有穷举比较的味道。5.3 ToT的成本问题——为什么生产环境不能全量用讲了ToT的好处必须泼一盆冷水ToT是四种范式里计算开销最贵的。一次任务里ToT可能要让模型生成几十乃至上百条推理路径token消耗可能是ReAct的10到50倍延迟和成本都非常可观。我在项目里测过同样一个方案设计任务ReAct耗时约10秒、成本约0.05美元ToT耗时要几分钟成本翻了将近30倍。所以我的建议是不要把整个任务都跑在ToT上而是把ToT用在少数关键决策点上。比如一个任务流程里可能只有是否切换技术路线选择哪个方案作为主方案这两个点值得做多路探索在这些地方单独触发ToT其余环节继续用ReAct或Plan-and-Execute的线性模式。这种局部ToT的思路是我目前看到兼顾效果和成本的最实用落地方式。6. 四种范式怎么选、怎么组合实测中的倾向与防坑提醒6.1 一张表看懂四种范式维度ReActPlan-and-ExecuteReflexionTree of Thoughts核心思路边想边做实时交替先规划再执行失败后反思带教训重来多条思路并行、搜索、回溯典型成本低中低中高适合场景短流程工具调用、问答长流程、依赖关系明确的任务环境反馈多、错误率高、需要反复试错的任务开放探索、深度推理、方案比较主要短板无全局视野、容易迷失初始计划错了难回头反思无效时循环空转token开销巨大、难做全量落地工程实现难度低中中高高6.2 生产级Agent的推荐组合套路老实说单个范式扛起全部任务的情况在生产环境里很少见。我更推荐组合使用而且目前业界成熟产品大致也是这个方向Plan-and-Execute做外壳 ReAct做内胆。先用Planner把任务分解成子任务清单每个子任务再用ReAct循环去完成。这是最稳健的默认方案既能享受全局规划的稳定性又能保留执行阶段的灵活性。Reflexion做通用失败处理层。不管底层用哪种范式只要某个子任务失败就触发一次反思把教训注入后续行动。本质上它像一个包装器可以套在任意一个Agent循环外面。局部ToT做高风险决策。只有当任务里出现关键岔路口且选错代价大时才触发ToT去穷举评估几条路线其余时间不参与。6.3 我在电商Agent项目里的实测体会去年我参与了一个电商智能客服Agent的改造早期它是纯ReAct在一个订单售后处理业务里任务链条长、规则复杂Agent经常把退货和退款流程搞混用户问一句它答错一句。后来我们做了两步改造第一步把售后流程改成Plan-and-Execute的骨架——先判断用户属于哪一类售后场景再生成处理步骤清单包括校验订单状态、确认物流记录、核对用户诉求、执行退款或补发每一步都由ReAct去完成。改造之后流程完整率从78%提升到92%效果非常明显。第二步在失败分支加上Reflexion。每当Agent在某类场景连续两次处理失败比如用户修改地址后重新发货这种边界case就跑一次反思把修改地址需先检查货品是否已发出存入记忆库。后续同类case再进来反思信息自动注入处理成功率又往上涨了一小截。6.4 一个必须警惕的防坑清单最后把我在项目里踩过、或者看别人踩过的高频坑列一下Prompt混用冲突。同一个Agent里同时塞进多种thinking模式的Prompt比如ReAct的Thought-Action-Observation格式和ToT的多方案打分格式容易让模型精神分裂输出混乱。我的经验是不同模式用不同的系统提示词并且在切换时明确告知模型接下来进入规划模式/执行模式/反思模式不要混在一个Prompt里含糊带过。状态管理失控。尤其是ToT这种多分支搜索需要在每个节点保存完整的状态信息。很多人的实现里状态散落在各个变量中回溯时不知道从哪恢复。建议提前定义清楚State的数据结构比如一个JSON一切分支、打分、回溯都围绕这个结构操作别搞临时变量。迭代轮数和成本没有上限。Agent一旦进入循环模型会心安理得地一直转下去账单蹭蹭涨。无论你选用哪种范式必须在循环外层设置硬性上限最大迭代轮数、最大token、最大耗时。这些是整体最优的救急锁不能省。Eval标准模糊。如果你没有定义清楚任务成功的标准Reflexion的Evaluator就没法工作ToT的打分也会飘忽不定Agent调优就像无头苍蝇。再强调一次先把可量化的客观规则写好再让模型做主观判断两者结合才可靠。我个人现在的选型习惯是面对一个新的Agent场景先拿ReAct快速跑通一版流程把成本和时间基准测出来如果任务链条长就在外层加Plan-and-Execute如果发现错误率居高不下再套Reflexion做失败复盘只有在那种选错方向代价极大的任务节点上才舍得花成本上ToT。四种范式不是互相竞争的技术而是从不同角度逼近同一个目标——让模型像人一样有章法地完成任务。顺着这个思路做下去你会发现Agent的稳定性根本不需要靠更聪明的模型来兜底一套合理的决策规划层往往比换个更大的模型管用得多。 Agent四大决策范式拆解：ReAct、Plan-and-Execute、Reflexion、ToT实战对比
Agent 这个Topic火了半年多各种框架像雨后春笋一样冒出来但你扒开任何一个号称智能体的项目看底层核心无非是这四件事让模型做决策、做规划、执行工具调用、从反馈里学习。标题里这四个范式——ReAct、Plan-and-Execute、Reflexion、Tree of Thoughts——几乎覆盖了当前生产级Agent的全部主流决策套路。这篇文章不聊框架API怎么拼而是把这四种范式的本质拆开讲清楚它们各自解决什么问题、代价是什么、什么时候该用哪种顺便把我自己在实际项目里踩过的坑和选型经验一并倒出来。适合正在做Agent开发、或者准备从对话机器人往会干活的Agent方向转型的工程师和产品同学作为内部参考。1. 为什么Agent的章法比聪明更重要先说一个反直觉的结论大模型本身并不擅长做成一件事。你让GPT写一首诗、总结一份文档、解释一个概念它一次生成就完成了这是单步任务。但Agent的定义是自主完成多步任务这意味着模型要在一个长期过程中反复做决策先做什么、后做什么、这个结果要不要接受、那个方向走不通要不要回头。这几乎是一个序列决策问题而单次Prompt调用根本承载不了这种过程。很多人刚开始做Agent时有个误解觉得模型能力强Agent能力强。实际不是。模型只是决策的原材料真正决定一个Agent能不能稳定完成任务的是外层那套决策与规划逻辑——也就是标题里这四个范式。打个比方模型像是新入职的员工聪明、知识面广但不知道公司的做事流程决策规划层就是SOP决定了这个员工是先查资料再动手还是先列计划再拆解执行还是撞了墙之后做复盘再来。SOP糟糕员工再聪明也会把事情干得乱七八糟。那一个合格的决策规划层需要回答哪几个问题不外乎这么五件事当前状态是什么——完成目标还有哪些子问题没解决下一步该做什么——是调工具、查资料还是直接生成最终答案做完了怎么评估——这一步执行结果是否正确和预期偏差大吗错了怎么办——是换个工具重试还是回到上一步重新规划整个计划的全局路径是什么——有没有一个统筹性的路线图而不是每一步都现想四种范式其实就是对这几个问题的不同解决方案侧重点差异很大。ReAct强调的是边想边干的实时交替Plan-and-Execute强调的是先谋后动的全局规划Reflexion强调的是记住教训的自我反思Tree of Thoughts强调的是多路探索的分支搜索。它们不是迭代关系而是从不同角度切入决策问题。在我自己带的Agent项目里我见过太多团队在模型调优上花大量精力却忽视决策层设计结果Agent在Demo里惊艳全场一上生产就频繁撞墙。原因几乎都不是模型不够聪明而是决策过程没有章法。搞清楚这一层你才能真正理解为什么后面的四种范式是Agent架构的核心。2. ReAct把思考-行动-观察变成可执行循环2.1 ReAct要解决什么问题ReAct是这四种范式里最基础、也最被广泛使用的一个。它的核心思想非常简洁让模型在推理Reasoning和行动Acting之间交替进行形成一个思考→行动→观察→再思考的循环直到任务完成。为什么要这样设计因为如果只让模型思考而不行动比如传统的Chain-of-Thought它最多只能根据已有知识推理想象遇到需要外部信息的情况就无能为力了反之如果只行动不思考比如早期的工具调用Agent模型很容易瞎打乱撞不知道该调哪个工具也不知道结果怎么解读。ReAct把两者缝合在一起每一步都先想清楚当前需要什么信息再决定调什么工具然后观察返回结果修正下一步计划。2.2 ReAct的一次完整轨迹长什么样假设你让Agent完成这样一个任务查一下上个月的销售数据找出同比下降超过20%的产品线并给产品负责人写一封提醒邮件。ReAct模式的内部轨迹大致如下Thought 1我需要先获取上月销售数据应该先看一下数据表结构确定字段含义。Action 1调用get_table_schema(sales_table)。Observation 1返回字段product_line, month, revenue, last_year_revenue。Thought 2字段清楚了我要查询上月逐产品线的收入以及去年同期收入计算出同比变化率。Action 2调用query_sales_data(SELECT product_line, revenue FROM sales WHERE month 2024-05)。Observation 2返回各产品线收入数据。Thought 3还需要去年同期的数据来做对比继续查询。Action 3调用query_sales_data(SELECT product_line, revenue FROM sales WHERE month 2023-05)。Observation 3返回去年同期数据。Thought 4我可以计算同比了。A产品线下滑25%B产品线下滑18%C产品线持平。A和B超过了20%的阈值需要提醒。Action 4调用send_email(recipientproduct_ownerexample.com, content...)。Observation 4邮件发送成功。Thought 5任务完成输出总结。注意这个过程里Thought和Action是交替出现的每个Observation都会修正下一步的方向。如果第一次查询发现字段根本对不上模型在Thought 4就可能改变策略。这种执行中持续感知的能力让ReAct在面对环境反馈时具备天然的自适应性这是它最核心的价值。2.3 落地ReAct时最常见的三个坑ReAct看起来简单实际落地时翻车的点却不少我一个个说。第一Thought的质量直接决定行动质量。ReAct的循环里Thought是唯一的方向盘如果模型在Thought阶段没有想清楚就贸然调工具后面很可能越走越偏。解决方式是在Prompt里强约束Thought的产出格式——必须包含当前已知信息和缺少什么信息两个部分确保它不是无脑行动。第二Observation过长会击穿上下文窗口。工具返回的结果可能是一张大表、一长段日志直接塞进上下文几轮之后模型就糊涂了开始胡言乱语。稳妥的做法是给每轮Observation做个截断或摘要层只把与当前决策相关的关键字段、摘要结果放进去。我习惯在工具调用外面包一层wrapper先把返回结果做结构化压缩再交给模型。第三循环终止条件不能只靠模型自觉。模型经常出现已经完成任务却还在继续思考的情况或者相反在错误路径上循环重试停不下来。需要在循环外面套一层硬性控制最大迭代轮数、最大token预算、以及一个可选的终止检查器——用一个轻量模型或规则判断当前输出是否已经算任务完成。老实说这一步在工程上比Prompt本身还重要很多生产级Agent框架大量工作就花在这。2.4 ReAct什么时候够用、什么时候不够我的经验是单一目标、步骤在5轮以内、每一步需要的信息可以通过现有工具获取的任务ReAct足够。比如问答机器人接入知识库和搜索、工单分类并自动回复、简单的数据查询助手这些场景ReAct稳定又便宜没必要引入更复杂的范式。但ReAct有一个明显短板它没有全局视野每一步都是局部决策。任务一旦超过10轮模型很容易迷失明明整体方向已经偏了它还在局部修修补补。这就是为什么Plan-and-Execute范式出现了——它试图在动手之前先把全局规划做出来避免走一步看一步的短视问题。3. Plan-and-Execute先交出计划再逐项打勾3.1 它和ReAct的本质差别如果你让带过团队的人来看ReAct他会觉得这像是没有项目计划的执行者——每个任务来了直接开干干到哪算哪。而Plan-and-Execute的思路正好相反先用一个Planner为大模型把任务拆解成一份明确的子任务清单然后由Executor逐条执行每条执行完再回到Planner审视进度。这里的关键在于规划和执行被明确分离成两个阶段。在LangChain框架里这种范式对应的是Plan-and-Execute Agent工作流上分成了planning阶段和execution阶段在Dify这类低代码编排平台里任务规划节点工具执行节点的call chain也是同一个思路CrewAI的Process模式就更明显了——先定义完整流程再按顺序交给不同角色执行。为什么要做这样的分离因为很多任务的复杂度集中在分解而不是执行上。比如帮我整理一份Q3季度竞品分析报告如果让ReAct直接上模型会在过程中反复横跳一会查竞品A一会想报告结构最终输出结构混乱。但如果你先让模型基于目标生成一份计划书第一步搜集竞品产品信息第二步分析定价策略第三步对比功能清单第四步撰写报告大纲第五步填充内容接下来每一步执行就变成了完成清单上的一个勾清晰可控。3.2 一个看得见的对比案例我用一个简化案例来解释两者的差异。任务分析电商平台上一款新品的用户评论输出三条产品改进建议。ReAct模式下模型大约会这样做尝试调用评论获取工具 → 发现需要先确定商品ID → 查询商品ID → 获取评论 → 直接分析 → 输出建议。Plan-and-Execute模式下Plan1. 确认商品基本信息ID、品类2. 获取近30天用户评论数据3. 对评论做情感分类4. 归纳高频问题点5. 结合竞品情况生成改进建议。Execute逐条执行每步完成做一个标记。第三步如果发现情感分类工具不可用Executor把这个问题汇报给PlannerPlanner决定改用规则关键词做粗分类或者跳过直接人工阅读Top评论。你会发现Plan-and-Execute模式下每一步都有上下文都有全局定位。Executor知道自己在执行整个计划的第几步而不是一个孤立的工具调用。对于步骤多、依赖关系复杂的任务这种全局性带来的稳定性提升非常明显。3.3 致命的弱点计划错了就一路错到底看到这里你可能已经注意到Plan-and-Execute的一个隐患了如果初始计划本身有重大问题比如漏掉关键依赖、目标分解错误那么执行阶段做得再完美也无济于事因为你在用高效的方式做错误的事。没有哪个Planner一次就能生成完美计划尤其现实任务里经常出现执行到一半发现需求变了或者某个数据源根本不存在的情况。所以成熟的Plan-and-Execute实现里都会加一个Replanner重新规划器执行过程中如果发现不可恢复的错误比如某个前提不成立、某个步骤缺失就触发重新规划生成一份修订版计划而不是硬着头皮继续。这里面有一个关键的工程判断什么时候触发Replan我建议给Replanner设一组明确的触发器执行器返回错误信息且表明该工具不存在/数据缺失/权限不足连续两次执行同一子任务失败执行结果与计划预期明显不符可以通过相似度或规则检测用户中途输入了新要求。绝对不建议让模型每次都自由决定要不要重新规划那样成本会失控而且容易陷入无限循环。触发条件要写在表层用if-else逻辑控制而不是靠模型自觉。3.4 什么场景下应该优先选Plan-and-Execute按我落地过的项目经验这些场景优先选这个范式流程固定且长周期的任务月度报告生成、批量数据处理、多阶段审查流程。这类任务天然有流程文档把它转录为Planner输入非常自然。需要人工介入确认的任务计划是可审查的颗粒度人可以在执行前先过一遍计划而不像ReAct那样边执行边猜。工具依赖关系复杂任务里存在明显的先后依赖先拉数据→再清洗→再建模→再可视化用ReAct极容易跳顺序Plan-and-Execute能把依赖关系固化。反过来说如果你的任务高度开放、需求模糊、方向需要边做边探索Plan-and-Execute就会显得笨重。这时候其实更值得看看Reflexion——它把试错变成一种正经的学习机制是处理模糊复杂环境的利器。4. Reflexion让Agent在下一次决策前带上教训4.1 Reflexion到底改进了什么前面两种范式都有一个共同缺陷Agent没有记忆同样的错误会以不同形式反复犯。ReAct在A任务里踩过的坑到了B任务里照样踩Plan-and-Execute发现计划有问题重试时Planner完全不知道上次为什么栽了。这和人不一样——人最强大的能力之一就是能从失败中总结教训下次避开。Reflexion正是为了解决这个问题。它的核心思路是给Agent增加一条自我反思的回路任务失败或结果不理想时用自然语言把失败原因和修正策略写下来存入记忆后续决策时把这份反思作为上下文注入指导新行动。注意这不是在微调模型也不改权重而是把教训变成文本作为额外信息参与决策。斯坦福那篇Reflexion论文里用了一个很清晰的框架Actor执行者 Evaluator评估者 Self-Reflection自我反思三者配合形成闭环。4.2 部署一个带反思回路的最小系统我实际搭过一个跑测试并修复Bug的Agent拿它来说Reflexion的具体运作。Actor一个负责改代码→跑测试的循环Agent它发现问题就尝试修复。Evaluator每一轮测试结束后判断测试是否通过。如果不通过返回具体的错误信息比如KeyError: name、TypeError: NoneType object is not subscriptable。Self-Reflection当Evaluator判定失败时额外让模型输出一段反思文本。我给的反思模板大概是这样的本次失败的直接原因是什么我之前遗漏了哪些信息或步骤下次遇到类似问题时我第一步应该做什么Memory把反思文本存入一个列表或向量库。下一轮尝试修复时把这个反思作为上下文的一部分注入。第一轮修复时Agent可能看到一个KeyError: name它自作聪明直接给字典加了个默认值{}结果下游拿到空字典照样崩。放到没有反思的普通Agent里第二轮它可能又犯同样的错误但有了Reflexion第二轮开始前模型会读到这样一条反思上一次我虽然修复了KeyError但没有检查下游对返回值结构的假设。下次修复前先确认调用方期望的字段结构而不是简单补默认值。于是第二轮它会先查调用方代码确认字段结构后再动手问题就能真正解决。4.3 反思的三个层次与落地形态我在实践中会把反思分成三个层次分得越清楚后续回溯效果越好层次关注点示例直接反思这一步为什么错我调用了query_sales_data但参数格式错了因为我没有先确认函数签名摘要反思这类任务怎么避免所有数据库查询前必须先查看schema信息策略反思我整体方向对不对我花太多时间在数据清洗上应该先确认最终输出格式再决定清洗粒度这三个层次在实际落地时对应不同的存储方式直接反思往往是一次性的适合放进短期上下文摘要反思是要反复使用的必须进长期记忆向量库或键值库按任务类型召回策略反思则适合在任务级别保存作为下一次同类任务的启动上下文。4.4 必须避开的反思陷阱Reflexion不是加上反思Prompt就能奏效我吃过几次亏总结出来三个要点第一反思必须具体可执行不能是空话。如果模型写出来的反思是我应该更加仔细地检查错误信息——恭喜你这条反思毫无价值。我在Prompt里会强制要求反思必须以下次行动的第一步结尾比如下次发生TypeError时第一件事是打印变量的类型和内容这种能落地的反思才有意义。第二反思不是越多越好。每条反思都占用上下文塞入几十条旧反思会稀释当前任务的焦点模型反而不知道该听谁的。实践中我通常只保留最近3-5条相关反思或者按语义相似度从向量库里召回Top-3多余的果断丢弃。第三Evaluator的质量决定Reflexion的天花板。如果Evaluator本身判断失误明明失败了却判定成功或反之反思就会建立在错误基础上整个回路变成有效率的犯错。所以生产环境里Evaluator不能完全靠大模型拍脑袋最好Mix规则检查测试有没有通过、接口有没有返回、数据有没有NULL这类客观信号用规则兜底规则覆盖不到的再用模型评估。5. Tree of Thoughts在思路树里做搜索而不是一条道走到黑5.1 为什么需要多路探索ReAct和Plan-and-Execute本质上都假设模型沿着一条路径往前走要么边走边修正要么按计划走但走错了不会回头看有没有更好的路。这在日常简单任务里没问题但遇到需要深度推理、探索性强的任务——比如逻辑谜题、数学证明、方案设计——一条道走到黑很容易走进死胡同而且不给你回头的机会。Tree of ThoughtsToT的思路完全不一样它把推理过程当成一棵树来搜索每一层都生成多个候选思路对每个候选思路做评估然后选择最有希望的方向继续深入如果走不下去就回溯到上层换一条路径探索。这在本质上把大模型的推理从贪心解码升级成了一次树搜索和传统AI里的BFS、DFS、beam search是一套血脉。5.2 ToT的关键机制和实现要点ToT的实现通常包含四个核心组件我用伪代码的形式梳理一遍State节点状态当前推理的中间状态其实就是上下文里的已完成部分。实现时建议把State封装成一个可序列化对象比如一个包含已收集的事实、当前结论、待验证假设的JSON结构。Thought Generator思路生成器给模型一个当前状态让它生成N个候选的下一步思路。Prompt里要明确给出多个不同方向的方案不要只给一个。State Evaluator状态评估器对每个候选思路打分判断沿着这个思路继续下去有多大概率成功。打分既可以是让模型直接给0-10分也可以用它对比各方案后再排序——后者在论文里被称为evaluating with voting比直接打分稳定得多。Search Algorithm搜索算法遍历思想树的整体策略比如BFS一层一层推进适合解空间较浅的任务DFS一条路挖到底不行再回溯适合深度推理。举一个我测试过的例子让Agent设计一款面向大学生的校园二手交易App的冷启动策略。普通ReAct模式会直接输出一个方案但它可能只覆盖线上推广这一个维度。换成ToT模式模型在第一层先生成三个方向——线上社区运营线下地推活动校园KOL合作计划然后对每个方向打分在地推方向内部再生成宿舍楼扫楼食堂摆摊社团联合活动等更多细化分支最后横向比较选出最优组合。整个输出过程明显更有穷举比较的味道。5.3 ToT的成本问题——为什么生产环境不能全量用讲了ToT的好处必须泼一盆冷水ToT是四种范式里计算开销最贵的。一次任务里ToT可能要让模型生成几十乃至上百条推理路径token消耗可能是ReAct的10到50倍延迟和成本都非常可观。我在项目里测过同样一个方案设计任务ReAct耗时约10秒、成本约0.05美元ToT耗时要几分钟成本翻了将近30倍。所以我的建议是不要把整个任务都跑在ToT上而是把ToT用在少数关键决策点上。比如一个任务流程里可能只有是否切换技术路线选择哪个方案作为主方案这两个点值得做多路探索在这些地方单独触发ToT其余环节继续用ReAct或Plan-and-Execute的线性模式。这种局部ToT的思路是我目前看到兼顾效果和成本的最实用落地方式。6. 四种范式怎么选、怎么组合实测中的倾向与防坑提醒6.1 一张表看懂四种范式维度ReActPlan-and-ExecuteReflexionTree of Thoughts核心思路边想边做实时交替先规划再执行失败后反思带教训重来多条思路并行、搜索、回溯典型成本低中低中高适合场景短流程工具调用、问答长流程、依赖关系明确的任务环境反馈多、错误率高、需要反复试错的任务开放探索、深度推理、方案比较主要短板无全局视野、容易迷失初始计划错了难回头反思无效时循环空转token开销巨大、难做全量落地工程实现难度低中中高高6.2 生产级Agent的推荐组合套路老实说单个范式扛起全部任务的情况在生产环境里很少见。我更推荐组合使用而且目前业界成熟产品大致也是这个方向Plan-and-Execute做外壳 ReAct做内胆。先用Planner把任务分解成子任务清单每个子任务再用ReAct循环去完成。这是最稳健的默认方案既能享受全局规划的稳定性又能保留执行阶段的灵活性。Reflexion做通用失败处理层。不管底层用哪种范式只要某个子任务失败就触发一次反思把教训注入后续行动。本质上它像一个包装器可以套在任意一个Agent循环外面。局部ToT做高风险决策。只有当任务里出现关键岔路口且选错代价大时才触发ToT去穷举评估几条路线其余时间不参与。6.3 我在电商Agent项目里的实测体会去年我参与了一个电商智能客服Agent的改造早期它是纯ReAct在一个订单售后处理业务里任务链条长、规则复杂Agent经常把退货和退款流程搞混用户问一句它答错一句。后来我们做了两步改造第一步把售后流程改成Plan-and-Execute的骨架——先判断用户属于哪一类售后场景再生成处理步骤清单包括校验订单状态、确认物流记录、核对用户诉求、执行退款或补发每一步都由ReAct去完成。改造之后流程完整率从78%提升到92%效果非常明显。第二步在失败分支加上Reflexion。每当Agent在某类场景连续两次处理失败比如用户修改地址后重新发货这种边界case就跑一次反思把修改地址需先检查货品是否已发出存入记忆库。后续同类case再进来反思信息自动注入处理成功率又往上涨了一小截。6.4 一个必须警惕的防坑清单最后把我在项目里踩过、或者看别人踩过的高频坑列一下Prompt混用冲突。同一个Agent里同时塞进多种thinking模式的Prompt比如ReAct的Thought-Action-Observation格式和ToT的多方案打分格式容易让模型精神分裂输出混乱。我的经验是不同模式用不同的系统提示词并且在切换时明确告知模型接下来进入规划模式/执行模式/反思模式不要混在一个Prompt里含糊带过。状态管理失控。尤其是ToT这种多分支搜索需要在每个节点保存完整的状态信息。很多人的实现里状态散落在各个变量中回溯时不知道从哪恢复。建议提前定义清楚State的数据结构比如一个JSON一切分支、打分、回溯都围绕这个结构操作别搞临时变量。迭代轮数和成本没有上限。Agent一旦进入循环模型会心安理得地一直转下去账单蹭蹭涨。无论你选用哪种范式必须在循环外层设置硬性上限最大迭代轮数、最大token、最大耗时。这些是整体最优的救急锁不能省。Eval标准模糊。如果你没有定义清楚任务成功的标准Reflexion的Evaluator就没法工作ToT的打分也会飘忽不定Agent调优就像无头苍蝇。再强调一次先把可量化的客观规则写好再让模型做主观判断两者结合才可靠。我个人现在的选型习惯是面对一个新的Agent场景先拿ReAct快速跑通一版流程把成本和时间基准测出来如果任务链条长就在外层加Plan-and-Execute如果发现错误率居高不下再套Reflexion做失败复盘只有在那种选错方向代价极大的任务节点上才舍得花成本上ToT。四种范式不是互相竞争的技术而是从不同角度逼近同一个目标——让模型像人一样有章法地完成任务。顺着这个思路做下去你会发现Agent的稳定性根本不需要靠更聪明的模型来兜底一套合理的决策规划层往往比换个更大的模型管用得多。