面试官：说一下 Agent 的常见范式，如何选型？

很多人一听到这个问题，就开始罗列一堆技术名词：ReAct、Plan-and-Execute、Reflection、Multi-Agent…

如果面试官继续追问：为什么会出现这些范式？各自解决什么？本质区别在哪？项目里怎么选？，很多人可能就会卡壳了。

这些范式实际上都在解决一个问题：当任务越来越复杂时，如何让 Agent 变得更可靠？

随着任务从简单的单工具调用，发展到多步骤长任务、跨领域复杂任务，再到企业级生产任务，Agent 暴露出一系列问题：长任务容易失控偏离目标、输出质量不稳定、单 Agent 上下文窗口有限、生产环境缺乏可控性与合规性等等。

不同范式针对不同阶段的核心痛点提出了解决方案，但同时也会引入新的成本和挑战。

作为工程师，我们的核心能力不是背诵名词，而是理解背后的权衡取舍（Trade-off），并根据实际场景选择最合适的技术方案。

---

一、ReAct

📌一句话总结：走一步，看一步，边想边做。

ReAct（Reasoning + 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 主要有以下三种协作形态：

1. 指挥官 - 工人模式（最常用）

• 核心特点：存在一个明确的中央协调者（指挥官），拥有最高决策权。它负责理解全局目标、拆解任务、分配子任务给工人 Agent、汇总结果并进行最终验收。工人 Agent 只负责执行自己擅长的具体子任务，不参与全局决策。

• 典型案例：一个软件开发团队，指挥官是产品经理，工人分别是前端工程师、后端工程师、测试工程师等。

3. 流水线模式

• 核心特点：任务被拆分成多个连续的、线性的阶段，每个阶段由一个专门的 Agent 负责。前一个 Agent 的输出是后一个 Agent 的唯一输入，信息沿着流水线单向流动，没有反馈回路。

• 典型案例：一个内容生产流水线：选题 Agent → 写作 Agent → 编辑 Agent → 排版 Agent → 发布 Agent。

5. 圆桌讨论模式

• 核心特点：所有 Agent 地位平等，没有中央决策者。它们通过轮流发言、交换信息、提出观点、互相辩论的方式，共同探索问题的解决方案，最终通过投票或共识来做出决策。

• 典型案例：一个战略决策团队，包括市场分析师 Agent、技术专家 Agent、财务专家 Agent、风险评估 Agent。

工业实现中还需要考虑很多关键问题：共享状态的存储方式（黑板、消息总线、分布式文件系统）、冲突解决机制、并行执行支持、人类介入节点设计等。

优缺点与适用场景

✅ 优点：

• 能力边界极大扩展：通过分工弱化了单个 Agent 的心智负担，能搞定端到端的超大型复杂项目。

• 专业化程度高：每个 Agent 都可以专注于自己擅长的领域，做到极致。

• 上下文隔离：不同 Agent 维护自己的上下文，避免了单 Agent 的上下文爆炸问题

• 可扩展性好：可以通过增加 Agent 的数量来提升系统的能力。

• 支持并行执行：多个独立的子任务可以同时进行，大幅提升效率

❌ 缺点：

• 复杂度急剧增加：系统设计和调试难度大大增加。

• 通信成本高：Agent 之间的通信和协调需要消耗大量资源。

• 可能出现冲突：不同 Agent 之间可能会有意见分歧或者任务冲突。

🎯 适用场景：软件开发、企业级项目管理、复杂市场调研等需要分工协作的超复杂任务。

---

五、Agentic Workflow

📌一句话总结：预定义好步骤，模型一步一步做。

前面几种范式都或多或少地追求 Agent 的『自主性』 ，但在真实的生产环境中，完全自主的 Agent 往往是不可接受的。生产系统最看重的是可控性、稳定性和合规性，而不是酷炫的自主能力。

教学 Demo 里，Agent 想查什么就查什么，想调用什么工具就调用什么，看起来很酷。但在真实业务里，你要考虑权限、合规、审计、成本、失败重试、人工兜底。如果让一个完全自主的 Agent 直接对接生产系统，它可能会调用不该调用的接口，生成不合规的话术，或者在关键流程里做出错误判断，造成不可挽回的损失。

为了解决生产落地可控性不足的问题，人们提出了Agentic Workflow范式（工作流式）。

它的核心思想非常简单：用规则和流程控制整体路径，用大模型处理每个节点的具体工作。

说白了，很多生产环境里的 Agent，不是『完全自主智能体』，而是『带 LLM 能力的自动化流程』。这并不低级，恰恰相反，这才是目前最务实的落地方向。

工作流程

1. 预先定义标准化的业务流程和执行规则。

2. 在需要智能处理的节点嵌入大模型能力。

3. 由规则引擎控制流程的流转和分支判断。

4. 在关键节点设置人工审核和兜底机制。

优缺点与适用场景

✅ 优点：

• 流程可控：关键节点可审计，符合企业合规要求。

• 容易接入：可以无缝集成到企业已有业务架构中。

• 成本更低：只在需要的地方使用大模型，避免不必要的调用。

• 稳定性高：规则和模型结合，比纯模型驱动更可靠。

❌ 缺点：

• 自由度下降：Agent 不能完全自主决策。

• 灵活性较差：流程变更需要修改 Workflow 定义。

🎯 适用场景：客服工单处理、审批流程、数据处理流水线等具有规定流程的企业级生产场景。

---

六、如何选型

这些范式之间不是互斥的，而是互补和组合的关系。每一种范式都有自己最擅长解决的问题，也有自己的局限性，没有一种范式是万能的。

在实际应用中，我们一般也不会单独使用某一种范式，而是会根据任务的特点，把多种范式组合起来使用。这就像构建一个软件系统：

• ReAct 是函数调用：处理单个具体的操作，灵活但缺乏全局结构。

• Plan-and-Execute 是模块划分：先把系统拆分成多个功能模块，再逐一实现。

• Reflection 是单元测试：对每个模块的输出进行质量检查，确保符合要求。

• Multi-Agent 是微服务架构：把复杂系统拆分成多个独立的服务，各司其职，互相协作。

• Agentic Workflow 是CI/CD 流水线：定义整个系统的执行流程和规则，确保稳定、可控、可审计。

常见的范式组合：

在真实的线上项目中，我们通常基于最小必要复杂度原则：能用简单的就不用复杂的，切忌过度设计。很多人一开始就想做一个无所不能的 Multi-Agent 系统，结果发现调试困难、成本高昂、稳定性差，最后还不如一个简单的 ReAct Agent 好用。

选型时可以问四个问题：

1. 步骤能否事先列全？能 → 偏 Plan 或 Workflow；不能 → 偏 ReAct。

2. 错了代价多大？高 → 必须 Reflection + 自动化测试/规则，最好加人工节点。

3. 是否需要多专业角色？是 → 再考虑 Multi-Agent；否 → 单 Agent 往往够用。

4. 合规与审计要求？强 → Workflow 为主，Agent 能力收进边界内。

---

七、面试怎么答

当面试官问你 ：“说一下 Agent 的常见范式" 时，最忌讳的就是直接背名词。你应该展现出你的工程思维和取舍观，可以参考以下回答框架：

1. 总述演化逻辑：Agent 的常见范式不是孤立的概念，而是一条随着任务复杂度提升逐步演化的路径。它们本质上都是在解决同一个问题：如何让 Agent 更可靠。

2. 逐一介绍范式：按照演化顺序，对每种范式，按照它解决了前一种范式的什么问题→核心思想是什么→适用场景是什么的逻辑来介绍。

3. 强调组合关系：这些范式不是互斥的。实际系统里经常是先 Plan 拆任务，再让 Executor 用 ReAct 执行，最后接 Reflection 做质量检查；如果任务很复杂，可以拆成 Multi-Agent；如果要进生产，可能还需要用 Workflow 约束关键路径。

4. 给出选型原则：最重要的选型原则是最小必要复杂度。能用简单范式解决的问题，绝对不要用复杂的范式。

5. 升华工程观：不同范式没有绝对好坏，核心看任务复杂度、不确定性、可控性要求和成本。生产环境里，通常不是追求 Agent 越自主越好，而是把模型能力放在合适的位置，让它在可控边界内解决问题。

这个回答逻辑清晰，层次分明，既有概念，也有工程判断，面试官一定会对你刮目相看。

---

如果觉得这篇文章对你有帮助，欢迎关注、点赞、分享三连支持。我是一枫，我们下篇文章见。

关注【一枫说码】，获取更多实战导向的 AI 技术文章。