“智能体范式”这个词我印象里这半年已经开始满天飞了。打开任何科技社区的推送到处都是“基于智能体的自动化”“智能体重构业务流”可你要是追问一句“你用的是哪种范式是单智能体闭环、规划-执行分离还是多智能体协作”能三句话讲清楚的人其实不多。这个现象不奇怪。大多数人的注意力都被模型、框架、API这些东西牵走了很少有人真正停下来想一件事智能体内部的决策架构到底是怎么组织的。而在技术栈日新月异的环境下真正能沉淀下来、换模型不换逻辑的那一层恰恰是这个决策架构——也就是我们常说的智能体范式。我按“决策权在谁手里、决策流怎么走”这个维度把当下最具代表性的三种范式梳理了一遍单智能体闭环、规划-执行分离、多智能体协作。每种范式我都会讲清楚原理、给出可参考的最小实现思路、指出它擅长和不适用的场景最后再认认真真聊几个我在实际项目中踩过的坑。这篇文章适合两类人一类是正在做智能体应用、想在技术选型阶段少走弯路的开发者另一类是自己产品里已经塞了智能体、但总觉得效果不稳、想回头找原因的从业者。1. 智能体范式不是框架选型先看决策架构怎么分工很多人一听“选范式”就以为是在选框架比如LangChain、MetaGPT之类。这个理解其实是把两个维度混淆了。框架是工具箱范式是组织方式。这就好比装修框架是一堆电动工具范式是你决定让一个人从头干到尾还是让项目经理先出图纸再派施工队还是让水电工、木工、油漆工各管一段同时进场。工具可以换但组织方式决定了项目的上限和风险。1.1 为什么从“决策流向”切分范式我见过不少团队在方案评审时争论该用哪个开源框架争到最后发现效果差的根源根本不在框架而在决策流向不对。决策流向指的是任务输入进来之后由谁决定下一步做什么这个决定是否被回看和修正以及多个决定之间是串联、并联还是上下级关系。顺着这个维度市面上的智能体应用大体上归为三类决策权集中在一个闭环里智能体自己边想边做边看结果也就是单智能体闭环决策被拆成“先规划后执行”两段规划模块负责拆任务、排顺序执行模块负责一个子任务一个子任务地完成也就是规划-执行分离决策权分散在多个角色里每个角色有独立目标和上下文通过消息或共享状态协同也就是多智能体协作。分类方式决定了我后面所有讨论的坐标系。我自己在实际工作中也发现先把这个坐标系定下来再谈具体用哪个模型、哪个框架思路会清爽很多。1.2 三种范式的直观类比为了后面讨论方便先给三个类比把抽象概念压到日常经验里。单智能体闭环像一个经验丰富的师傅独立修车他看一眼现象猜一个原因动手拆零件验证看到新情况再调整判断一步步逼近问题根源。整个过程是一个连续的“想-做-看”循环。规划-执行分离像一个工程项目的运作方式项目经理先对接需求、拆解工作包、排出甘特图施工队按图施工遇到图纸和现场不符再反馈给项目经理调整。想和做是两拨人但通过计划和反馈机制对接。多智能体协作像一个开发团队产品经理定需求、后端工程师写接口、前端工程师做页面、测试工程师找漏洞每个人都只掌握自己那部分上下文通过会议和文档同步信息共同完成一个没人能独立搞定的项目。这三个类比会贯穿全文。你在设计自己的智能体系统时其实就是在选这三种“组织模式”这个选择比选哪个模型更影响最终效果。2. 单智能体闭环思考-行动-观察一种最接近直觉的范式单智能体闭环是目前最容易落地、也最容易讲明白的范式。它的核心思想是让大模型在一个循环里反复做三件事——思考当前状态决定采取什么动作观察动作产生的结果然后带着新信息进入下一轮思考。2.1 ReAct循环到底在做什么这个范式被大众熟知主要是靠ReAct这类模式带起来的。ReAct其实是Reasoning和Acting的组合意思是推理和行动交替进行。但很多人对它的理解停在表面以为只是“让模型调用工具”。实际上ReAct的闭环核心在于模型必须把“推理过程”和“行动结果”同时写进上下文作为下一步决策的依据。我举个电商售后的例子。用户说“我收到的吹风机有异味想退货”。单智能体闭环的过程大概是这样的第一次思考用户提到“异味和不满意”可能涉及退货流程我需要先查询订单信息确认购买状态和是否在退货期内执行动作调用查询订单接口传入用户ID观察结果系统返回订单状态为“已签收”签收日期在7天内符合退货条件第二次思考既然符合条件需要进一步获取退货政策和用户是否有历史异常记录然后给用户生成退货方案执行动作调用退货政策查询和历史风控查询观察结果无异常退货政策允许七天无理由退换第三次思考信息齐全生成最终退货指令并通知物流上门取件。这个过程就是典型的思考-行动-观察循环。每一步的观察结果都成为下一步思考的背景信息模型不是一次性拍板而是走一步看一步。2.2 一个最小实现长什么样在代码层面这个循环的核心逻辑非常简单。下面是一个去掉工程细节的伪Python实现重点展示循环结构def run_agent(task, tools): context [{role: user, content: task}] while True: # 1. 思考 thought llm_reasoning(context) # 2. 决定动作并执行 if thought[type] final_answer: return thought[answer] result call_tool(thought[tool_name], thought[tool_args]) # 3. 观察结果并回填到上下文 context.append(thought[message]) context.append({role: tool, content: result})我在实际项目里会在这个基础上加三层保护最大循环次数、中间结果的压缩策略、以及工具调用失败的兜底分支。没有这三层演示环境跑得很好的循环到了生产环境就会变成失控的连环调用。最大循环次数好理解防止模型陷入死循环或者反复做无用功。我一般根据任务复杂度设定在10到20次之间上限之外直接给出失败状态并且把当前上下文保存下来供人工排查。中间结果压缩策略是另一个关键。大模型上下文窗口虽然越做越大但推理质量并不会随着上下文长度线性提升。当循环超过七八轮时中间观察结果可能已经积累到几万token。这时候我会做两件事把早期的对话历史摘要成一两句话再让工具返回结果尽量结构化。2.3 单闭环的优势与天花板单智能体闭环最大的优势是简单可控。整个系统只有一个“大脑”决策链路短调试时只需要盯住这一个循环里的输入输出出问题用日志就能定位个七八成。对于任务目标明确、流程不超过几个步骤、工具调用清晰的应用它是最划算的选择。但它有两个明显的天花板。一是长任务容易迷失方向。二十轮以上的循环里模型经常出现“只见树木不见森林”的现象早期定的目标被后续信息淹没最后做出与原始需求偏离的决策。二是上下文消耗巨大。每个观察结果都进上下文成本随着循环轮数线性增长复杂任务的token耗用量会高得离谱。因为这两个问题我在任务复杂度明显上升的场景下一般会考虑下一种范式把规划从执行里剥离出来。3. 规划-执行分离把“想”和“做”拆给不同模块单智能体闭环最本质的问题是“想”和“做”没有分离。模型既当项目经理又当施工队员每走一步都要纠结“我该干什么”“我干完没”。实际效果不稳定消耗也高。于是就有了第二种代表性范式规划-执行分离。3.1 Planner与Executor的分工逻辑规划-执行分离核心是两个模块各司其职Planner只负责想接收用户目标拆解出子任务列表确定子任务之间的依赖关系和执行顺序Executor只负责做接收一个明确的子任务调用对应工具或模型能力完成它把结果返回给Planner或其他模块。这里我特别强调“明确的子任务”这个点。Executor的水平不需要很高因为它的任务边界已经被划得很清晰Planner反而是整个系统的智力核心它决定了任务拆得好不好、顺序对不对、遗漏了什么。用类比来说Planner是那个画施工图的项目经理Executor是照着图干活的施工队。施工队不需要知道整栋楼的结构力学怎么算他只需要把这一面墙砌直墙出了问题再反馈给项目经理。3.2 静态规划、动态重规划与子任务DAG规划-执行分离在实现上有一个重要的分支选择是静态规划还是动态重规划。静态规划是指Planner在开始时只规划一次生成完整任务列表之后Executor按顺序执行。这种方式适合任务结构清晰、环境变化少的场景比如批量生成周报、批量处理数据清洗、定时爬取信息并汇总。它的优点是消耗低、流程固定、便于审计缺点是一旦某个子任务失败后面全部跟着乱。动态重规划是指Executor执行过程中Planner会根据执行反馈定期调整后续任务。比如某一步发现数据源不可用Planner可以动态替换为备用数据源或者调整后续任务的优先级。这种方式更稳健但代价是每个任务节点都要决策一次延迟和成本都上去了。我在项目中更倾向于动态重规划但在实现时不是每个节点都触发重规划而是设置一个“失败阈值”。单个子任务失败时先由Executor重试两次重试还失败才把信息报给Planner让Planner修订计划。这种折中能够兼顾稳健和成本算是我实践中的一个优化技巧。在任务依赖关系比较复杂时我建议把任务列表建模成DAG。每个子任务是个节点依赖关系是边只有前置任务完成才能启动后续任务。这样整个流程的可解释性会好很多——什么问题卡住了、影响了哪些下游任务一眼就能看清楚。3.3 适合规划-执行的典型业务场景规划-执行分离最适合的任务是那些“步骤多、逻辑相对固定、每步有明确产出物”的业务流。举一个我们内部做过的数据报告自动化项目。输入是一份销售明细表输出是一份带图表的PPT周报。如果用单智能体闭环模型每次都要从零开始决定“先看数据还是先做图表”很容易在这种多步骤任务中迷失。用规划-执行分离之后Planner被设计成固定先输出四个子任务清洗数据、计算核心指标、生成图表素材、组装PPT页面。Executor每个任务只做一件事效果非常稳定且每一步都可以单独检测和失败重试。另一个例子是跨系统的流程操作比如“从邮件附件里提取合同信息在审批系统里创建审批单审批通过后同步到财务系统”。这类任务步骤跨系统、每个系统只有独立API特别适合规划-执行结构。Planner负责把多系统操作编排成有序步骤Executor逐项执行并反馈结果。不过规划-执行分离并不是万能的。当任务步骤本身足够简单时拆分的收益很低反而增加系统复杂度。此外当任务涉及大量主观判断和模糊信息、无法被清晰拆解时Planner也会很吃力。这种场景我往往会考虑引入多智能体协作。4. 多智能体协作用角色分工解决单体的智力瓶颈第三种范式是现在讨论度最高、也最容易被过度包装的多智能体协作。MetaGPT、AutoGen、CrewAI这些框架实在太火以至于很多人觉得“多个Agent聊天就是多智能体”。但真正落地时会发现如果不理解协作的结构设计多Agent系统很容易变成一堆模型在互相说废话效果和成本双双失控。4.1 为什么需要用多个智能体上下文与视角的双重限制先回答一个核心问题单智能体做不了什么需要多个智能体我总结成两个限制。第一个限制是上下文长度。任何单个模型能同时处理的信息量都是有上限的。一个复杂业务比如“处理一整套用户投诉工单”可能需要同时关注用户原文、订单数据、售后政策、库存状态、物流记录。把所有信息塞进一个上下文就算不超出窗口上限模型也容易顾此失彼。多个智能体各管一段上下文能从物理层面缓解信息过载。第二个限制是视角单一。一个问题从“用户满意度”角度和从“成本控制”角度出发判断结果会完全不同。单个智能体很难在同一轮决策里同时扮演利益不同的角色。多智能体通过角色分离天然给了不同视角独立发声的空间决策反而更接近多方博弈的真实场景。4.2 协作拓扑星型、层级与网状多智能体协作系统设计时最简单的分法就是按拓扑结构分。星型协作就是有一个中央调度智能体其余智能体都是执行者。所有任务由中央智能体接收、拆分、分发给对应执行者执行结果再汇总回中央智能体。这种结构适合团队职责清晰、需要统一调度中枢的场景。实现上逻辑最简单缺点是中央节点容易成为瓶颈。层级协作和公司组织架构类似上级智能体拆解任务后下发给下级下级可以再拆解给更下级。每一层只对上一层负责跨层不直接通信。这种结构适合任务天然有层级属性的场景比如总部-分部-门店的运营管理但设计起来稍复杂容易“级联放大错误”。网状协作是智能体之间可以自由通信每个智能体都知道其他智能体的存在。它最灵活但也最容易失控。多个智能体来回对话会产生大量无效信息实际调试难度极大。我一般不推荐非资深团队起步就做网状结构容易在工程上把自己淹没。我自己的项目大多从星型起步等业务逻辑稳定后再把局部几对协作关系改造成层级结构。这样既保证了风险可控又保留了优化空间。4.3 通信与记忆的工程细节多智能体协作里真正决定成败的往往不是模型智商而是通信和记忆的工程机制。通信方面最先要定的是消息格式。每个智能体之间的消息要有明确的schema包含消息类型、发送方、接收方、内容载荷、关联任务ID。没有结构化的消息协议智能体之间很快就会因为信息冗余而互相干扰。我在项目中会专门定义消息队列异步处理智能体间的消息避免同步等待造成的延迟堆积。记忆方面最容易踩的坑是“所有智能体共享一个全局记忆”。这样做会让每个智能体都读到不相关的信息反而削弱各自的专业性。更稳妥的方案是双层记忆每个智能体有自己的工作记忆只保留和自己职责相关的信息系统层有一个共享黑板存放全局进度和关键结论。共享黑板适合记录“什么任务完成了什么任务被阻塞”这类事实而不是具体内容。在调试方面多智能体系统比单智能体难一个数量级。我通常会给每个智能体加独立的trace ID并在所有消息里传递这个ID这样出现问题才能把通信链路完整串起来。还有一个比较实用的经验发现最终效果不好时先检查是不是某个角色接收到的信息质量太差而不是急着换更大的模型。很多多智能体项目效果差的根源是上游角色不干活或者信息在传递中失真而不是单个模型智力不够。5. 三种范式的选型边界结合任务特征决定用谁说清楚了三种范式各自的原理接下来是这篇文章最实际的部分我到底该用哪种我在做技术选型时习惯先画一张对比表把任务特征和范式强项对齐而不是凭感觉拍脑袋。5.1 一张表看差异对比维度单智能体闭环规划-执行分离多智能体协作任务复杂度低到中中到高高或需多视角上下文压力高循环内全量累积中每步相对独立分散到各角色可缓解成本消耗随循环轮数线性涨相对可控高成倍叠加调试难度低中高稳定性短任务好长任务差较好依赖Planner质量依赖通信设计易失控最适合场景客服问答、单点工具操作多步骤固定流程复杂业务、多方博弈这张表不需要背它反映的是一个朴素判断任务越简单、边界越清楚越应该用低复杂度的范式复杂度越高、越需要不同视角博弈才值得引入更重的协作结构。我见过不止一次的资源错配一个只要三步就能搞定的查询任务团队非要上多智能体框架结果成本涨了十倍效果反而没比单闭环强多少。反过来的案例也有一个需要统筹多方数据的业务流程用单智能体硬扛结果上下文爆炸逻辑漏洞百出。选型的第一原则是匹配复杂度而不是上线最先进的结构。5.2 选型路径先回答三个问题我在给团队评审新项目时会要求先回答三个问题答案直接决定范式选择。第一个问题这个任务能拆成独立步骤吗如果拆不出来、每一步都依赖前一步的模糊判断那就老老实实用单智能体闭环。如果任务天然就是有序步骤的集合规划-执行分离的性价比会更高。第二个问题需不需要不同决策视角如果任务只涉及单一目标比如“把这段语音转成文字并校对”多视角没有意义。如果任务包含目标冲突比如“既要控制成本又要保证用户满意度”那么多智能体协作能让不同视角充分表达最终得出折中方案。第三个问题系统对出错的容忍度是多少单智能体闭环出错影响面最小定位最快。多智能体协作一旦出错可能一串角色被连带带偏排查时间会显著拉长。对稳定性要求极高的系统起步阶段用小范围闭环而不是大张旗鼓上多智能体往往更稳妥。这三个问题我在多个项目里验证过效果稳定。哪怕最后结论是“先用单闭环起步后续再加协作结构”也远比一开始就选一个不适合的架构要好。5.3 组合使用是常态最后一定要说清楚这三种范式不是互斥关系在一个真实系统里经常组合出现。我自己见过最常用的组合是外层用规划-执行分离把大业务流程拆成子任务内部某个关键子任务再用单智能体闭环来处理动态情况。比如离线数据流转系统大流程固定分几步某一步的输入数据质量不稳定、需要实时判断处理策略时就在这一步内部塞一个ReAct循环让它根据数据实际情况选择清洗规则。另一种常见组合是多智能体协作决定策略每个策略再由一个规划-执行管道去落地。比如在某个企业智能客服系统里前台有多个角色智能体在分析用户诉求情绪分析、政策匹配、历史记录挖掘它们共同生成一个处理方案然后由一套规划-执行管道把这个方案拆解成具体的客服动作并执行。理解组合的前提是先把三种纯净范式想明白。范式本身不是终点真实业务不会恰好只长成某一副模样。会组合的人才真正掌握了这套架构语言。6. 从实践里攒下的四个教训能少踩一半坑范式讲再多到了真实环境里决定成败的往往是几个不起眼的工程细节。我在多个项目里踩坑总结下来下面这四个问题遇到的频率最高影响也最大。6.1 工具调用的失败要作为“一等公民”设计很多初版智能体代码把工具调用当成“必然成功”的操作这是生产事故的首要来源。现实里API超时、参数格式错误、权限不足、返回数据不完整几乎天天发生。如果代码里没有对工具调用失败做专项处理模型很容易在一个错误结果上继续推理输出看似合理实则是幻觉的结论。我现在的做法是给每个工具定义一个完整生命周期成功返回时带结果失败时返回结构化错误码和错误详情超时返回重试建议。同时在系统层设置统一的重试队列配合“最多重试两次、失败即上报”的策略。工具调用失败不再是异常而是系统预期内的一种状态整个推理循环才不会因此失控。6.2 上下文污染比能力不足更容易导致翻车我调试过的不少智能体第一版能力其实够用问题出在上下文太脏。模型被塞进了大量无关的历史消息、失败的工具返回、重复的总结导致真正有用的信息被淹没模型开始“抓不住重点”。上下文污染有三个主要来源一是失败调用的报错信息反复进上下文二是早期推理过程过长挤占了有效信息空间三是多个来源的信息格式不统一比如有的用JSON、有的用自然语言模型切换理解时消耗了大量注意力。应对手段也很明确每次工具调用失败只把最终的错误摘要放进上下文不保留完整堆栈超过一定轮数后对早期对话做压缩摘要所有工具返回都强制转成统一的结构化格式再进上下文。我在一版客服智能体上做了这三项改造后指令遵循准确率大约提升了十几个百分点成本也降了明显一截。6.3 成本要在架构阶段就估算而不是事后看账单很多团队上线智能体后才被账单吓一跳原因是他们在架构阶段把成本当成事后参数而不是设计约束。我现在的习惯是在选范式的时候就把token成本代入估算。单智能体闭环的估算方法是“平均循环轮数x每轮上下文的平均token数”多智能体则是“角色数量x每条消息的平均token数x消息往返次数”。先算一笔粗账再对照业务单次收益立刻就能判断这个架构能不能扛得住。有一个金融客服项目最初设计用多智能体协作三个角色来回对话单次请求成本预估就要几块钱。我们后来把其中一个角色换成规则引擎把另一个角色合并到主闭环里单次成本降到了原来的十分之一效果只下降了一点点。成本这件事在架构阶段算过和没算过命运天差地别。6.4 可观测性决定你能否走出原型阶段智能体的黑盒属性比传统软件严重得多。模型每一步为什么会那么想、工具调用结果为什么被采纳、某段上下文为什么会失效——这些问题在没有任何观测工具时几乎无法回答。我给所有智能体项目做的基础设施里必须包含三样东西全链路日志、状态快照、和控制台式的回放工具。全链路日志记录每次思考和工具调用的输入输出状态快照记录某时刻的完整上下文摘要回放工具可以复现某个请求从进入系统到输出的全过程。抛掉先做核心功能的惯性思维我建议早期就把可观测性做好。架构再精彩如果系统像一个黑洞出了问题只能靠猜那它永远只能停留在Demo阶段。做智能体应用这一路下来我最大的感受是范式不是学术名词它是决定你项目是“玩具”还是“系统”的分水岭。先把决策架构这一层想清楚再谈框架、模型、调参才能每一步都踩在实处。最后补一个自己常用的土办法接到任何智能体需求先别写代码用一两页纸把决策流向画出来标明每个节点谁在思考、谁在执行、谁负责观察和反馈。这张纸能画清楚架构的动作其实已经完成了一大半。