做AI应用开发这几年我最大的感受是大模型本身的能力边界正在被快速摸清真正拉开项目差距的其实是你在模型外面套的那层智能体设计。从最早的一句提示词跑遍天下到现在的Agent系统遍地开花业界其实已经收敛出了几套相对固定的范式。不管你是做客服机器人、流程自动化还是复杂数据分析工具只要出去参加技术分享、翻看团队技术总结反复被提到的就是最具代表性的三种智能体范式——ReAct、Plan-and-Execute、以及多智能体协作。这篇文章我结合自己做过的几个项目把这三种范式的原理、适用场景、实现要点和踩过的坑一次性说清楚给正在做技术选型的同学一个可以落地的参考。1. 三种智能体范式全景拆解1.1 为什么是这三种范式我最早接触Agent时觉得智能体是个特别玄的概念什么都能干又好像什么都没说清。后来代码写多了项目也上了几个慢慢发现不管形态怎么变大家在工程上真正用的翻来覆去就是三种——单智能体的循环决策、先规划再执行的两段式结构、还有多角色协作的群体模式。这三种范式恰好回答了一个核心问题大模型的不确定性应该如何被约束在可控的工程结构里ReAct把推理和行动揉在一个循环里用模型自己的输出来引导下一步适用于开放性强、没法提前穷举步骤的任务Plan-and-Execute把想和做分开先让模型生成一个完整计划再按计划逐步执行适合步骤清晰、周期较长的任务多智能体协作则干脆让多个各司其职的模型角色互相配合用专家团队代替全能选手解决单一角色能力宽度不足的问题。这三个范式不是谁取代谁的关系而是不同约束条件下的不同解法。我见过不少团队在同一个项目里混着用比如用ReAct做细粒度工具调用但外层再套一个计划器来控制节奏。理解清楚每种范式的能力边界你才知道什么时候该选哪种。1.2 三种范式的能力对比速览在往下拆之前我先给一张我在选型时经常看的对比表方便你带着全局去读后面的细节维度ReActPlan-and-Execute多智能体协作核心思想边想边做推理-行动交替先规划后执行两段分离多角色分工群体协作适用任务工具调用密集、探索型任务多步骤、有明确产物、长周期复杂综合体需多视角/并行能力实现复杂度低单循环即可中需要计划维护与状态跟踪高需设计通信与协调机制Token消耗高常出现无效推理中计划阶段一次投入很高多角色上下文叠加稳定性依赖模型推理质量容易跑偏计划锁死后较稳但灵活性差依赖角色定义质量易冲突调试难度低日志清晰中问题可能出现在计划期或执行期高需要追踪多角色交互这张表只是定性参考。实际项目里模型的版本、工具的质量、任务的复杂程度都会影响最终表现。下面我分别展开讲每种范式怎么实现、有什么坑。2. ReAct范式让模型边想边做的经典循环2.1 核心原理Thought-Action-Observation循环ReAct这个思路本质上就是把人类解决问题的过程搬给模型面对一个问题先想一想当前局面Thought决定做哪个动作Action然后看动作返回的结果Observation再基于新信息继续想下一步。这个循环一直持续到模型觉得问题解决了为止。举个我实际做过的例子。用户提问我们上个月华南区的销售额环比变化是多少如果只用普通对话模型它可能干脆胡编一个数字。但在ReAct范式下模型会先生成思考我需要查询销售数据库然后调用一个query_sales工具传入时间和地区参数拿到原始数据后再思考下一步——还需要查上上月的数据才能算环比继续调用工具直到最后给出基于真实数据的结论。这个循环里的三个组成部分在工程上分别对应Thought就是让模型输出的推理过程通常通过提示词要求先给出你的思考再决定调用什么工具。它不参与实际逻辑但对模型决策质量至关重要Action模型输出一个结构化指令比如工具名(参数)程序解析后去执行对应的函数Observation工具执行后的结果文本拼接回模型的下一次输入提供给模型继续推理。这里有一个关键设计整个循环的画布其实就是上下文。Action的结果不能脱离Thought存在必须把历史信息全部保留模型才能做出连续的判断。我见过不少初版实现为了省Token截断历史结果模型倒着倒着就忘了自己刚才在查什么这是非常典型的坑。2.2 工具定义与调用格式设计ReAct能不能跑通一半的功夫在工具定义上。我建议每个工具的描述里写清楚这个工具是干什么的、参数是什么类型、什么场景下该调用它。模型是靠描述理解工具的描述写得太笼统它就会乱调。我常用的工具注册格式长这样{ name: query_sales, description: 查询指定区域、指定时间范围的销售数据。仅当用户问及销售额、销量、同比、环比时使用。, parameters: { region: {type: string, enum: [华南, 华北, 华东]}, start_date: {type: string, format: date}, end_date: {type: string, format: date} } }三个要点说下description要写使用时机不要只写查询销售数据。模型看到仅当用户问及销售额时使用误调用率会明显下降参数用枚举约束能枚举就别开放字符串模型填参数的自由度越大出错概率越高返回结果要带结构工具函数返回的内容建议用JSON封装同时包含数据本身和必要的元信息如查询成功、共10条记录别让模型面对一坨没有上下文的裸文本。调用格式上如果你用支持函数调用的模型直接用原生的工具调用协议最省事如果用的模型不支持常见做法是让模型输出一段固定格式的文本比如{action: query_sales, params: {...}}然后用正则或解析器提取。我更喜欢后者因为日志里可以直接看到模型的完整决策链调试起来非常直观。2.3 Re范式的优劣与适用边界ReAct最大的优势是灵活。它不需要你提前穷举任务步骤遇到超出预期的中间结果模型可以自行调整策略。对用户需求不明确、需要多次查证的任务比如竞品调研、数据核对、信息检索它表现相当好。但它的短板同样明显Token消耗大。每走一步所有历史对话都要重新拼给模型步数一多上下文膨胀得很快。我一个项目中跑20多步的查询流程单次请求的Token量轻松破万错误会累积。模型某一步的思考错了后面的Actions大概率会在错误方向上继续走。我见过模型在错误数据上绕了好几圈最后得出了一个振振有词的错误结论对长周期任务不稳定。步骤超过10步之后模型迷失目标的概率显著上升容易陷入重复调用同一个工具的死循环。所以我的经验是ReAct适合控制在个位数的步数内建议在循环外层加一个最大步数限制通常是8~10步超过就强制收敛并让模型基于已有信息给出部分结论。你可以在提示词里加上一句如果你认为已经收集到足够信息请停止调用工具并直接回答用户。这句话在长任务里能明显降低空转率。3. Plan-and-Execute范式先规划再执行的稳健路线3.1 从边想边做到先想再做在做月度经营分析报告的项目时我发现ReAct有个很尴尬的问题任务太复杂了。要拉数据、要算指标、要生成图表、要写结论二三十个步骤ReAct跑着跑着就乱。后来我引入了Plan-and-Execute范式问题一下简单了很多。这个范式的核心改动是让模型先花一次推理生成一个完整的任务计划然后再按计划逐步执行。整个过程分成两个角色Planner规划器负责把用户的复杂需求拆解成一个个子任务子任务之间可以标出依赖关系Executor执行器负责逐个执行子任务每个子任务用一个工具调用或一段生成逻辑完成。还是拿销售分析举例。Planner会生成这样的计划查询华南区本月销售数据查询华南区上月销售数据计算环比变化率生成环比变化图表撰写分析结论执行阶段就按这个列表一步步来。步骤之间没有强依赖的比如步骤1和2完全可以用并行方式触发。这就比ReAct一个个串行循环省时间。3.2 动态重规划计划不是写死就完了我特别想强调的是Plan-and-Execute不是计划完就埋头跑中间必须有检查点。现实业务里计划经常在执行中失效。比如你规划要查某张表结果数据权限报错你规划要调某个接口结果接口升级了参数。如果执行器只是机械地按计划走整个流程就卡死了。所以我会在每个子任务完成后加一个轻量级的复核环节执行结果是否符合预期如果不符合是重试、跳过、还是触发重规划重规划的实现不复杂本质上是把当前已执行的结果 剩余未执行的任务 失败原因重新扔给Planner让它调整计划。我习惯给Planner加一个指令模板当前计划执行过程中遇到如下问题{错误信息} 目前已完成的子任务及结果{已完成列表} 剩余未执行的任务{剩余列表} 请根据现状重新给出剩余任务的最优执行计划。加了这一层之后整个系统的容错能力会有一个非常明显的提升。我有个同事开玩笑说这就像打游戏先看攻略攻略不对就换个攻略而不是一条路走到黑。3.3 规划粒度与上下文管理这节的内容来自我实际踩过的坑。Plan-and-Execute一个隐藏难点是拆到什么粒度才算合适拆太粗每个子任务仍然很大执行器还是一头雾水。比如分析销售数据这种任务执行器根本不知道该干什么最后还是得自己瞎猜。拆太细计划本身长达几十项规划和维护计划的开销把收益吃掉了大半。我的经验是每个子任务应该对应一个能直接用工具完成的原子操作。如果某个子任务还需要两步以上推理说明拆得不够细。比如计算环比变化率是原子的生成图表是原子的分析销售数据则不是它隐含了查询、计算、分析三步。上下文管理上一定要做任务隔离。每个子任务执行时只把相关的上下文片段传给执行器而不是把整个历史都塞进去。因为执行器看的内容越少被无关信息干扰的概率越低。我在实现时会给每个子任务维护一个独立的输入上下文由Planner在生成计划时顺便指定它依赖哪些已完成的产出。这样既能保证信息链条完整又不会让上下文一路膨胀到失控。3.4 这个范式的代价与限制Plan-and-Execute也不是银弹。它最大的代价是规划是一次性投入但规划错误会被放大。如果Planner把任务拆错了或者漏掉了某个关键步骤后面的执行再完美也没用。我在一个数据集成项目里就遇到过Planner漏掉了数据去重这一步结果执行器一路顺畅地跑完产出的报表里所有用户被统计了两次排查了很久才找到源头。所以在这种范式下我会在计划生成后加一个计划审查环节用另一条提示词检查计划是否遗漏了数据清洗、权限校验、异常处理这类隐性步骤。另外规划阶段本身也有Token成本。任务越复杂规划消耗越大。如果任务本身只有两三步没必要上Plan-and-Execute直接用ReAct更省。如果任务步骤很多、且每个步骤相对独立Plan-and-Execute的优势就非常明显。4. 多智能体范式一群专家而不是一个全能手4.1 让多个角色各司其职第三种范式是我觉得最有意思的也是工程复杂度最高的一种。ReAct和Plan-and-Execute的核心都还默认一个模型扮演所有角色但多智能体范式直接把这个假设打破了一个Agent做不了的事就让几个各有所长的Agent协作完成。我在一个内容生产的项目里实践过这个思路。整套系统有三个角色研究员Agent负责检索资料、汇总信息源输出事实素材清单写手Agent基于素材清单撰写初稿专注于表达质量和结构审校Agent负责检查事实错误、逻辑漏洞和表达问题返回修改意见。流程是研究员先把素材整理好写手拿到素材写稿审校再挑毛病意见返回给写手迭代修改。整个系统跑起来之后明显能感觉到每个角色的专注度比单智能体高很多。原因是每个角色只被塞了自己负责的那部分上下文不会被无关信息稀释注意力。4.2 多智能体的两种协作模式工程上多智能体的协作方式可以归成两类我会根据任务性质混着用流水线模式一个Agent的输出作为下一个Agent的输入链路清晰适合流程固定的任务比如上面说的内容生产。优点是逻辑好梳理、每个环节质量容易卡控缺点是前一个环节错了后面全跟着错所以每个环节最好带个校验。会商模式多个Agent针对同一个问题分别独立给出方案再有一个决策Agent汇总讨论。适合没有标准答案的复杂问题比如产品方案评审、技术选型评估。它能在一定程度上防止单人思维盲区但Token消耗相当大而且很容易出现多个Agent各说各话、最终讨论不下去的情况。所以我会给会商模式加一个轮次上限比如最多讨论三轮到点必须由决策Agent拍板否则会无限发散。4.3 共享记忆与通信协议的设计这是多智能体范式里最容易被低估的工程点。多个Agent之间怎么说话如果只是把A的输出原样丢给B很快上下文就被污染了。我推荐的方案是所有Agent的通信都通过一个结构化的共享记忆空间进行。所谓共享记忆本质上是一组规范化的数据实体比如- 需求描述用户原始的、未改动的需求 - 事实素材带来源标注的信息条目 - 草稿版本写作中间产物带版本号 - 修改意见审校意见每条带上问题类型每个Agent被提示从共享记忆中读取你需要的内容再把你产出的结果写回记忆空间而不是直接跟其他Agent对话。这有几个好处记忆内容可追溯每条数据是谁写的、什么时候写的都清楚单个Agent独立运行通信顺序可以灵活调整甚至可以并行调试时直接看记忆空间的状态就能定位是哪个环节出了问题。用共享白板而不是即时聊天的模式多智能体系统的稳定性和可维护性完全不是一个量级。这是我强烈建议你一开始就按这个思路搭的原因。4.4 多智能体范式的钱包问题最后说一个很多人不好意思提但绕不开的问题贵。多智能体范式是目前三种范式里Token消耗最高的。三个Agent各看一遍上下文消耗就直接乘三会商模式下多轮讨论Token量更是指数级增长。我在做原型阶段一个复杂的多Agent流程单次跑下来成本经常是单智能体方案的3到5倍。所以我的建议是优先用小模型承担低难度角色比如格式整理、简单检索把大模型留给推理密集的环节尽量设计按需唤醒不是所有Agent都同时激活只有前置条件满足才触发下游Agent线上对Token消耗做监控和告警一旦单次会话成本超过阈值立刻人工介入检查。5. 范式选型实战拿同一个需求跑一遍5.1 同一个任务的三种实现理论讲了这么多不落地等于白讲。我拿一个实际工作中遇到的需求说下三种范式各自的实现思路和结果。需求是做一个技术方案快速评审助手输入一段方案描述输出评审结论、风险清单和优化建议。用ReAct实现主循环负责解析输入、调用两个核心工具——check_arch架构检查和check_cost成本估算。模型每个工具调用之间自己判断还要查什么。这个方案最灵活评审结论能根据中间结果动态调整。但问题在于工具调用次数多了之后模型容易在架构细节上绕圈拉长响应时间。用Plan-and-Execute实现Planner先拆成解析需求→检查架构→评估成本→汇总风险→给出建议五步。每一步执行器独立完成产出结构化片段。这个方案最稳输出格式完全可控但要求输入描述足够规范输入质量太差时Planner的第一步就会出错。用多智能体实现一个架构专家、一个成本专家、一个安全专家并行评审最后汇总Agent整合。这个方案评审质量最高三个角度的盲区互补明显。但一次完整的评审要消耗约4倍于单智能体的Token而且三位专家偶尔会对同一问题给出矛盾意见分布在汇总时需要额外处理。5.2 我的选型经验总结跑完这个需求我的结论非常清晰如果追求快且便宜且评审深度要求不高选ReAct如果产物的结构化程度是刚需比如要对接下游系统选Plan-and-Execute如果评审质量是第一位、成本预算充足选多智能体。我更想说的是这三种范式完全可以组合使用。我目前比较满意的系统架构是一个Plan-and-Execute为骨架、ReAct为单步执行器、局部引入多Agent并行的混合体。大计划用Planner拆清每个子任务用ReAct灵活执行碰到需要多视角的节点再拉起两个Agent并行干活。整体稳定性和灵活性都兼顾了。6. 踩坑实录常见问题与排查技巧6.1 ReAct的三大常见问题问题一工具调用格式不稳定。模型偶尔会输出自然语言而不是结构化的Action调用。我在提示词里加了必须严格输出JSON格式不要输出任何解释文字同时解析器做好容错解析失败时把错误信息回传给模型让它重试一次。重试仍然失败的直接终止循环返回提示。问题二死循环。模型反复调用同一个工具参数都不变。我的解法是维护一个最近N次调用指纹表检测到重复Action就把历史重复信息追加给模型你已经连续调用该工具3次且参数相同请放弃当前路径换一种方法。实测这招能救回大部分死循环。问题三Observation太长导致上下文溢出。工具返回了大规模数据一次塞爆上下文。我最初的方案是截断后来改成先总结再上送工具返回后先由模型对内容做一次提炼只把提炼后的摘要写回循环上下文。6.2 Plan-and-Execute的常见问题问题一没有检查点错误星链式传播。执行器某一步返回了空结果但计划仍继续往下走后面的步骤全部建立在空数据上。解决方法是强制在每个子任务完成后做一次有效性校验校验不通过立刻触发重规划绝不硬着头皮继续。问题二状态丢失。执行器执行子任务B时需要A的产出但A的产出在上下文中已经被挤掉了。这个问题通过我在3.3里说的子任务独立上下文 显式依赖声明解决每个子任务能看到的上下文范围完全由Planner决定。问题三重规划时计划漂移。重规划次数多了之后任务目标和最初用户需求渐行渐远。我给Planner的每次重规划请求里都附上用户原始需求全文并明确要求任何调整都不得违背原始目标有效减少了跑偏。6.3 多智能体的常见问题问题一Agent之间互相甩锅。审校Agent说内容不准确写手Agent说是研究员给的素材有问题一圈讨论下来没有结论。根治方法就是我在4.3里说的共享记忆——每个Agent只对写回的记录负责问题定位直接看记录不靠争论。问题二角色定义模糊。两个Agent的职责范围重叠同一件事抢着干最后产生两份冲突的产出。我的经验是给每个角色写职责边界声明明确写清你负责什么、不负责什么、遇到什么情况必须移交其他角色。问题三上下文污染。下游Agent接收了太多上游无关信息输出质量下降。建议在通信层就做字段过滤下游Agent只能读取共享记忆里被授权的字段其他一概不可见。6.4 给新手的最终建议如果你刚接触智能体开发我的建议是不要一上来就上最复杂的多智能体架构。先用ReAct把工具调用跑通感受一下模型在想-做-看循环里的行为模式再往上拆出Planner把流程稳定下来最后才是多角色协作。这个顺序能让你在每一步都积累足够的调试经验而不是在架构初期就被一堆并发问题淹没。我自己在项目里反复用到的一个技巧是所有范式都留人工接管的口子。无论是循环步数超限、校验不通过、还是Token消耗异常都提供一个人工介入的界面。智能体系统的价值是提高效率不是完全替代人。留一个紧急刹车比什么都重要。跑过这几个范式之后我个人的体会是范式本身没有高低之分只有匹配不匹配。一个简单任务用多智能体是杀鸡用牛刀一个复杂任务用ReAct是让模型硬扛它扛不住的担子。最好的做法是把这三种范式当成工具箱里的三把扳手用之前先想清楚任务特性再决定用哪个——或者组合着用。最后再分享一个小技巧无论用哪种范式一定要从第一天就做好完整的日志记录把每次调用的输入输出、Token消耗、耗时和中间决策全部结构化保存。你会惊讶地发现百分之八十的线上问题靠翻历史日志就能定位根本不需要重新跑一遍。这句经验是我踩了无数坑之后最想告诉你的。