很多人一听到这个问题就开始罗列一堆技术名词ReAct、Plan-and-Execute、Reflection、Multi-Agent…如果面试官继续追问为什么会出现这些范式各自解决什么本质区别在哪项目里怎么选很多人可能就会卡壳了。这些范式实际上都在解决一个问题当任务越来越复杂时如何让 Agent 变得更可靠随着任务从简单的单工具调用发展到多步骤长任务、跨领域复杂任务再到企业级生产任务Agent 暴露出一系列问题长任务容易失控偏离目标、输出质量不稳定、单 Agent 上下文窗口有限、生产环境缺乏可控性与合规性等等。不同范式针对不同阶段的核心痛点提出了解决方案但同时也会引入新的成本和挑战。作为工程师我们的核心能力不是背诵名词而是理解背后的权衡取舍Trade-off并根据实际场景选择最合适的技术方案。一、ReAct一句话总结走一步看一步边想边做。ReActReasoning Acting是 Agent 领域最经典、最基础的范式也是绝大多数 Agent 系统的起点。它解决了 Agent 领域最原始的问题任务过程不确定无法预先知道需要哪些步骤。它的核心思想非常朴素让大模型在『思考』和『行动』之间交替进行通过与环境的持续交互来推进任务而不是一次性生成完整答案。很多任务根本不是一次工具调用就能完成的大模型无法通过单次推理预测出最终的执行路径必须依赖中间步骤的反馈来决定下一步动作。比如排查接口变慢问题我们事先根本不知道问题出在应用、数据库、缓存、网络还是下游服务。模型必须先查一个线索根据结果再决定下一步查什么像侦探一样一步步逼近真相。工作流程ReAct的核心是一个不断循环的动态过程思考分析当前收集到的信息与最终目标的差距生成下一步的行动意图。行动将意图转化为标准的外部工具调用参数如 API 请求、SQL 查询。观察接收外部环境或工具返回的真实数据并将该数据注入到下一次的上下文输入中。简单来说就是先基于当前信息思考下一步该做什么调用对应的工具执行这个行动观察工具返回的结果再将结果作为新的输入继续思考如此反复直到任务完成。优缺点与适用场景✅优点极其简单实现成本低新手半天就能上手。灵活性极强能动态适应环境变化遇到意外情况可以及时调整策略。可解释性好每一步的思考过程都清晰可见出了问题很容易调试和审计。❌缺点容易迷失方向在长任务中可能忘记最初的目标甚至陷入死循环或重复劳动。效率低 成本高每一步都需要调用一次大模型且每次调用都会携带之前的完整上下文延迟和成本随步骤线性增长。缺乏全局视野只能看到眼前的一步可能会做出短视的决策从而导致全局不一定最优。适用场景线上排障、信息搜索、探索性分析等过程不确定的任务。二、Plan-and-Execute一句话总结先规划做什么再一步一步做。ReAct 解决了『让 Agent 动起来』的问题但它的灵活性也带来了致命缺陷当任务变得复杂且漫长时模型很容易在执行过程中偏离目标、重复调用工具或者陷入过度思考的死循环。它就像一个没有导航的新手司机虽然能随机应变但很容易走弯路甚至迷路。为了解决长任务失控的问题人们提出了Plan-and-Execute范式规划执行式。它的核心思想非常符合人类的做事习惯在开始行动之前先做一个全局计划。把复杂的大任务拆解成一系列清晰有序的小步骤然后再按照计划一步步执行。工作流程Plan-and-Execute把整个任务分成了两个独立阶段可由不同的模型进行处理。规划阶段通常 1 次深入理解用户的最终目标把复杂大任务拆解成清晰有序的小步骤确定每个步骤的目标、输入、输出以及相互依赖关系最终生成完整的结构化执行计划。执行阶段按照计划依次执行每个小步骤每个步骤可以直接调用工具完成或者用简单的 ReAct 循环。由于执行过程中可能会遇到『计划赶不上变化』的情况成熟的系统一般还会加上重规划阶段当执行过程中发现原计划不可行、环境发生变化或出现新的信息时会根据最新的执行结果重新调整甚至完全重写计划。在实际应用中Plan-and-Execute 经常与 ReAct 组合使用Planner 负责全局任务拆解Executor 使用 ReAct 处理每个子步骤中的不确定性中途发现问题再触发重规划。这就像软件开发流程PRD 写得再完整实际编码时也会发现各种边界条件需要调整。优缺点与适用场景✅优点目标感强有明确的执行路线图不容易偏离目标。效率更高 成本更低复杂的全局规划只需要用大模型调用一次执行阶段的子任务可以分发给更小、更快、更便宜的模型。可预测性好可以大致知道 Agent 会做什么需要多长时间便于进度管理。❌缺点计划可能过时如果环境在执行过程中发生变化原来的计划可能不再适用灵活性较差遇到计划外的情况时调整能力不如 ReAct。规划难度大对于非常复杂或模糊的任务生成一个好计划本身就是挑战。适用场景写调研报告、生成长文、迁移代码、制定测试计划等目标明确、步骤较多的结构化长任务。三、Reflection一句话总结做完之后回头看看做得好不好。ReAct 解决了 『怎么让 Agent 动起来』 的问题Plan-and-Execute 解决了 『怎么让 Agent 不迷路』 的问题。但还有一个很重要的问题没有解决怎么保证 Agent 做的事情是对的无论是 ReAct 还是 Plan-and-Execute它们都有一个共同特点只向前走不回头看。Agent 执行完一个步骤之后默认自己做的是对的不会检查自己做得好不好有没有错误更不会主动修正。这在很多场景下是不可接受的。比如让 Agent 写代码往往有很多 bug让 Agent 写文章可能有很多逻辑错误或事实错误让 Agent 生成 SQL可能会有语法错误或逻辑漏洞。为了解决输出质量不稳定的问题人们提出了Reflection范式反思式。它的核心思想也来自人类的做事方式先执行再反思后修正。 Agent 完成一个步骤或整个任务后会站在一个旁观者的角度对自己的工作成果进行批判性评估找出存在的问题和不足然后根据反思的结果进行修正和改进。工作流程Reflection的核心是一个生成 - 反思 - 修正的循环生成根据任务要求和已有信息生成初步的结果。反思站在第三方视角按照预设的评估标准如正确性、完整性、可读性对结果进行批判性检查列出存在的问题和改进点。修正针对反思发现的问题对结果进行针对性修改和完善。优缺点与适用场景✅ 优点结果质量高通过多次迭代和自我修正显著提升输出的准确性和质量。错误率低能够主动发现并纠正自己的错误。学习能力强能够从错误中吸取教训不断改进。❌ 缺点速度慢每一次反思和修正都需要额外的大模型调用。成本高大模型调用次数是其他范式的 2-3 倍。可能陷入无限循环如果反思不够准确可能会反复修改同一个问题。 适用场景代码生成、文档写作、复杂推理、数据分析报告等对质量要求较高的任务。四、Multi-Agent一句话总结一个人做不完的活分给几个人一起做。当任务的复杂度超过了单个大模型的能力边界时即使有了规划和反思单智能体仍然会显得力不从心。一个 Agent 既要理解需求又要查资料又要写代码又要测试又要 Review很容易出现上下文爆炸也容易顾此失彼。为了解决单智能体能力和上下文有限的问题人们提出了Multi-Agent范式多智能体协作。它的核心思想来自人类社会的分工协作不要让一个 Agent 干所有事而是把复杂任务拆给多个具有不同专长的 Agent通过分工协作共同完成。常见协作模式在现代大模型工程落地中Mutil-Agent主要有以下三种协作形态指挥官 - 工人模式最常用核心特点存在一个明确的中央协调者指挥官拥有最高决策权。它负责理解全局目标、拆解任务、分配子任务给工人 Agent、汇总结果并进行最终验收。工人 Agent 只负责执行自己擅长的具体子任务不参与全局决策。典型案例一个软件开发团队指挥官是产品经理工人分别是前端工程师、后端工程师、测试工程师等。流水线模式核心特点任务被拆分成多个连续的、线性的阶段每个阶段由一个专门的 Agent 负责。前一个 Agent 的输出是后一个 Agent 的唯一输入信息沿着流水线单向流动没有反馈回路。典型案例一个内容生产流水线选题 Agent → 写作 Agent → 编辑 Agent → 排版 Agent → 发布 Agent。圆桌讨论模式核心特点所有 Agent 地位平等没有中央决策者。它们通过轮流发言、交换信息、提出观点、互相辩论的方式共同探索问题的解决方案最终通过投票或共识来做出决策。典型案例一个战略决策团队包括市场分析师 Agent、技术专家 Agent、财务专家 Agent、风险评估 Agent。工业实现中还需要考虑很多关键问题共享状态的存储方式黑板、消息总线、分布式文件系统、冲突解决机制、并行执行支持、人类介入节点设计等。优缺点与适用场景✅ 优点能力边界极大扩展通过分工弱化了单个 Agent 的心智负担能搞定端到端的超大型复杂项目。专业化程度高每个 Agent 都可以专注于自己擅长的领域做到极致。上下文隔离不同 Agent 维护自己的上下文避免了单 Agent 的上下文爆炸问题可扩展性好可以通过增加 Agent 的数量来提升系统的能力。支持并行执行多个独立的子任务可以同时进行大幅提升效率❌ 缺点复杂度急剧增加系统设计和调试难度大大增加。通信成本高Agent 之间的通信和协调需要消耗大量资源。可能出现冲突不同 Agent 之间可能会有意见分歧或者任务冲突。 适用场景软件开发、企业级项目管理、复杂市场调研等需要分工协作的超复杂任务。五、Agentic Workflow一句话总结预定义好步骤模型一步一步做。前面几种范式都或多或少地追求 Agent 的『自主性』 但在真实的生产环境中完全自主的 Agent 往往是不可接受的。生产系统最看重的是可控性、稳定性和合规性而不是酷炫的自主能力。教学 Demo 里Agent 想查什么就查什么想调用什么工具就调用什么看起来很酷。但在真实业务里你要考虑权限、合规、审计、成本、失败重试、人工兜底。如果让一个完全自主的 Agent 直接对接生产系统它可能会调用不该调用的接口生成不合规的话术或者在关键流程里做出错误判断造成不可挽回的损失。为了解决生产落地可控性不足的问题人们提出了Agentic Workflow范式工作流式。它的核心思想非常简单用规则和流程控制整体路径用大模型处理每个节点的具体工作。说白了很多生产环境里的 Agent不是『完全自主智能体』而是『带 LLM 能力的自动化流程』。这并不低级恰恰相反这才是目前最务实的落地方向。工作流程预先定义标准化的业务流程和执行规则。在需要智能处理的节点嵌入大模型能力。由规则引擎控制流程的流转和分支判断。在关键节点设置人工审核和兜底机制。优缺点与适用场景✅ 优点流程可控关键节点可审计符合企业合规要求。容易接入可以无缝集成到企业已有业务架构中。成本更低只在需要的地方使用大模型避免不必要的调用。稳定性高规则和模型结合比纯模型驱动更可靠。❌ 缺点自由度下降Agent 不能完全自主决策。灵活性较差流程变更需要修改 Workflow 定义。 适用场景客服工单处理、审批流程、数据处理流水线等具有规定流程的企业级生产场景。六、如何选型这些范式之间不是互斥的而是互补和组合的关系。每一种范式都有自己最擅长解决的问题也有自己的局限性没有一种范式是万能的。在实际应用中我们一般也不会单独使用某一种范式而是会根据任务的特点把多种范式组合起来使用。这就像构建一个软件系统ReAct 是函数调用处理单个具体的操作灵活但缺乏全局结构。Plan-and-Execute 是模块划分先把系统拆分成多个功能模块再逐一实现。Reflection 是单元测试对每个模块的输出进行质量检查确保符合要求。Multi-Agent 是微服务架构把复杂系统拆分成多个独立的服务各司其职互相协作。Agentic Workflow 是CI/CD 流水线定义整个系统的执行流程和规则确保稳定、可控、可审计。常见的范式组合在真实的线上项目中我们通常基于最小必要复杂度原则能用简单的就不用复杂的切忌过度设计。很多人一开始就想做一个无所不能的 Multi-Agent 系统结果发现调试困难、成本高昂、稳定性差最后还不如一个简单的 ReAct Agent 好用。选型时可以问四个问题步骤能否事先列全能 → 偏 Plan 或 Workflow不能 → 偏 ReAct。错了代价多大高 → 必须 Reflection 自动化测试/规则最好加人工节点。是否需要多专业角色是 → 再考虑 Multi-Agent否 → 单 Agent 往往够用。合规与审计要求强 → Workflow 为主Agent 能力收进边界内。七、面试怎么答当面试官问你 “说一下 Agent 的常见范式 时最忌讳的就是直接背名词。你应该展现出你的工程思维和取舍观可以参考以下回答框架总述演化逻辑Agent 的常见范式不是孤立的概念而是一条随着任务复杂度提升逐步演化的路径。它们本质上都是在解决同一个问题如何让 Agent 更可靠。逐一介绍范式按照演化顺序对每种范式按照它解决了前一种范式的什么问题→核心思想是什么→适用场景是什么的逻辑来介绍。强调组合关系这些范式不是互斥的。实际系统里经常是先 Plan 拆任务再让 Executor 用 ReAct 执行最后接 Reflection 做质量检查如果任务很复杂可以拆成 Multi-Agent如果要进生产可能还需要用 Workflow 约束关键路径。给出选型原则最重要的选型原则是最小必要复杂度。能用简单范式解决的问题绝对不要用复杂的范式。升华工程观不同范式没有绝对好坏核心看任务复杂度、不确定性、可控性要求和成本。生产环境里通常不是追求 Agent 越自主越好而是把模型能力放在合适的位置让它在可控边界内解决问题。这个回答逻辑清晰层次分明既有概念也有工程判断面试官一定会对你刮目相看。如果觉得这篇文章对你有帮助欢迎关注、点赞、再看三连支持。我是一枫我们下篇文章见。关注【一枫说码】获取更多实战导向的 AI 技术文章。
