前言
前段时间，有位求职者去面试蚂蚁集团，岗位与大模型应用开发相关。面试官在几轮项目讨论后，随口提了一个问题：“你来说说，Agent 都有哪些设计模式？”
他听到这个问题后，立刻来了兴致，一口气列举了十几个：ReAct、Plan-and-Execute、Reflection、Self-Refine、Tree of Thoughts、Graph of Thoughts、Tool Use、Memory、Router、Supervisor、Multi-Agent、Loop Engineering……一口气说出来，相当顺畅。
面试官等他说完后，笑了笑，换了一个角度追问：“那这些模式各自的核心侧重点是什么？”
他顿时愣住了。支支吾吾了半天，只勉强说出了“这个是用来推理的”“那个是多个 Agent 一起干活”，然后就再也讲不下去了。
回来之后，他找我复盘这次面试，说自己把这些专业名词全背下来了，但从来没深入思考过它们之间的层级关系。帮他梳理清楚之后，他才恍然大悟——这些东西根本不是同一层级的概念，它们回答的是四个截然不同层面上的问题。
读完这篇文章，你能够清晰掌握：
- 为什么单纯背名词等于零分回答——面试官真正想听的是系统化的分析能力
- Agent 设计模式的四层架构体系——推理、能力、调度、运行机制
- 13 种模式各自归属于哪一层——从此不再混淆概念
- 模式之间并非互斥，而是可以灵活叠加——生产级 Agent 如何组合设计
- 面试话术的三层表达模型——60 分回答与 90 分回答之间的本质差距在哪
无论你是从事 Agent 开发的工程师，还是需要在面试中清晰阐述设计模式的开发者，这个问题都值得提前深思。现在，开始拆解！
一、问题出在哪：它们根本不是同一个维度的东西
很多介绍 Agent 设计模式的文章和示意图，常常把十几种模式并列排在一张图里。看起来非常全面，但也极易让人误以为它们是“同级”的、可以互相替代的选项。
实际情况并非如此。这 13 种模式分别回答的是四个不同层级的问题：
- 有些模式在回答“Agent 如何进行思考”——属于推理算法层
- 有些模式在回答“Agent 能够执行什么任务”——属于能力组件层
- 有些模式在回答“多个 Agent 之间如何协同”——属于系统架构层
- 有些模式在回答“Agent 如何持续稳定运行”——属于运行机制层
面试官所问的那个“侧重点”，其实指的就是这四层分类。如果在当时能够把这十几个名词清晰地归入这四个抽屉里，那场面试的分数将会完全不同。
二、四层框架：推理、能力、调度、运行机制
把这十几个模式按照四层架构重新梳理一遍，整个框架就会变得异常清晰：
第一层：推理(Reasoning) — Agent 如何进行思考
ReAct / Plan-and-Execute / Reflection / Self-Refine / ToT / GoT
第二层：能力(Capability) — Agent 能够执行什么任务
Tool Use / Memory
第三层：调度(Orchestration) — 多个 Agent 如何协同工作
Router / Supervisor / Multi-Agent
第四层：运行机制(Loop) — Agent 如何持续稳定运行
Loop Engineering
这四层结构是自下而上构建的：推理层是最核心的“大脑”，能力层是“手脚”，调度层是“组织结构”，运行机制层是“让整套系统持续运转的引擎”。接下来，我们逐层进行详细拆解。
三、第一层：推理（Agent 如何进行思考）
这一层解决最核心的问题：当 Agent 接收到任务之后，其内部的思考过程是如何进行的。
Single Agent 是最基础的原始形态：用户输入什么，LLM 就直接输出什么。没有规划能力、没有工具调用、也没有循环机制。适用于问答、内容总结、文本翻译这类一次性任务。
ReAct 是思考(Thought)→行动(Action)→观察(Observation)→再次思考的迭代过程，边执行边根据观察结果动态调整策略。这是当前绝大多数 Agent 依赖的推理基础，几乎无法绕过。
Plan-and-Execute 将 ReAct 拆分为“规划”和“执行”两个独立阶段。首先由 Planner 生成完整执行计划，再交由 Executor 逐步实施。这种方式减少了反复调用大模型的计算开销。Claude Code 这类编程 Agent 大量采用这种模式。
Reflection 是在执行完毕后，让 Agent 自己回头进行审查——检查代码是否存在错误、逻辑是否存在漏洞。这是一种“事后复盘”机制，而非重新生成内容。
Self-Refine 比 Reflection 更进一步：不仅仅是检查一次，而是“生成→批评→改进→再批评→再改进”的循环优化过程。许多写作类 Agent 使用这种模式来持续提升输出质量。
Tree of Thoughts (ToT) 不再沿着单一推理路径进行到底，而是同时展开多个思路分支。每个分支继续扩展，最后采用 DFS、BFS 或 Beam Search 搜索最优解。
Graph of Thoughts (GoT) 是 ToT 的升级版本，从“树状”结构演变为“图状”结构。节点之间可以合并、回流、交叉引用，特别适用于知识推理、科研分析这类需要复杂关联关系的场景。
这一层的共同特征：它们都在解决“如何思考问题”这个核心议题，与工具如何调用、多 Agent 如何协作无关。
四、第二层：能力（Agent 能够执行什么任务）
这一层不涉及推理逻辑，只是让 Agent 从“只会思考”变为“真正具备执行能力”。
Tool Use 让 Agent 能够调用 Python、Shell、搜索引擎、SQL 数据库、浏览器以及各类 API。如果没有工具调用能力，即使推理能力再强的 LLM 也只能是“纸上谈兵”。如今大多数 MCP 场景本质上都在解决这一层的问题。
Memory 分为短期记忆和长期记忆两类。短期记忆包括对话上下文、临时草稿等信息；长期记忆则依赖向量数据库、用户画像、历史项目经验等持久化存储。Memory 本身不负责推理，只是为推理过程提供更完整、更丰富的上下文信息。
这一层的共同特征：它们回答的是“Agent 的能力边界在哪里”，与“如何进行思考”是两个完全不同的问题。
五、第三层：调度（多个 Agent 如何协同工作）
当单个 Agent 无法完成复杂任务时，就需要多个 Agent 相互配合。这一层专门解决协作方式的问题。
Router Pattern 首先进行意图识别分类，判断任务属于编程、金融还是旅行等类别，然后将其分发给对应的专用 Agent 进行处理。
Supervisor Pattern 设置一个“总管”Agent，负责向下属的搜索 Agent、代码 Agent、金融 Agent 分配任务、汇总执行结果、判断任务是否完成。OpenAI Swarm 的设计思路与此类似。
Multi-Agent 没有明确的中心领导者，多个 Agent (如 Research、Writer、Reviewer、Planner 等) 以平等身份协作，互相通信。AutoGen 是这类架构的典型代表。
这一层的共同特征：它们解决的是“组织结构”问题，与单个 Agent 内部的推理过程无关。
六、第四层：运行机制（Agent 如何持续稳定运行）
这一层只包含一个模式，但它是近期讨论热度最高的一个。
Loop Engineering 既不是推理算法，也不是系统架构。它是确保 Agent 能够持续稳定运行的核心机制。具体来说，就是：设定目标(Goal)→进行思考(Think)→执行行动(Act)→观察结果(Observe)→评估反馈(Evaluate)→判断是否继续，如此循环往复。
while not finish:
think()
act()
observe()
evaluate()Claude Code、Codex、Cursor、Gemini CLI——目前主流的 Agent 产品，其底层几乎都采用这种持续循环的运行方式。
Loop Engineering 与前三层之间的关系：它并非替代推理或调度机制，而是在推理+能力+调度的基础之上，增加一层“让整套系统持续运转”的外围循环。没有这一层，Agent 只能完成一次性任务；有了这一层，Agent 才能像人类工作者一样持续稳定地执行任务。
七、不是互斥选择题，而是可叠加的组合
讲解完四层架构之后，有一个关键认知需要明确：这些模式并非互斥的选择题，而是可以灵活叠加的组合方案。
一个生产级 Agent 系统通常采用如下组合方式：
- 推理层采用 Plan-and-Execute（先进行规划再执行）
- 能力层叠加 Tool Use + Memory（能够调用工具、具备记忆能力）
- 调度层采用 Supervisor（由总管统一分发任务）
- 运行机制层套用 Loop Engineering（实现持续循环运行）
每一层选择哪种模式，完全取决于具体的业务场景。简单的问答任务只需 Single Agent 即可满足需求；复杂的编程任务可能需要 Plan-and-Execute + Tool Use + Loop 的组合方案；多角色协作场景则需要 Multi-Agent + Memory 的配置。
工程判断建议：不要一开始就采用最复杂的组合方案。先以最简单的模式起步（Single Agent + Tool Use），待核心流程跑通之后，再根据实际需求逐步增加层级。过度设计是 Agent 项目中最常见的陷阱——核心功能尚未跑通，就先搭建了 Multi-Agent + ToT + Loop 的架构，结果却陷入了调试的地狱。
八、从架构师视角看 Agent 设计模式的几个工程取舍
从架构师的角度来看，几个 Agent 设计模式存在明显的工程取舍考量。
取舍一：ReAct vs Plan-and-Execute——边执行边思考 vs 先规划后执行。 ReAct 灵活度高，但每一步都需要调用大模型，计算开销较大；Plan-and-Execute 先生成完整计划再执行，开销较小，但一旦计划出现错误就需要整体重新规划。简单任务建议使用 ReAct，复杂多步骤任务则更适合 Plan-and-Execute。
取舍二：Reflection vs Self-Refine——审查一次 vs 循环打磨。 Reflection 成本较低（只需多调用一次模型），适合代码审查这类“对错明确”的场景；Self-Refine 成本较高（需要循环多次），适合写作优化这类“质量可以持续提升”的场景。
取舍三：Router vs Supervisor vs Multi-Agent——如何组织多 Agent。 Router 适合“意图明确、任务互不交叉”的场景（如编程/金融/旅行分类）；Supervisor 适合“任务可分解、需要结果汇总”的场景；Multi-Agent 适合“需要多视角碰撞讨论”的场景（如 Research+Writer+Reviewer 协作）。选错方案的代价：Router 遇到跨领域任务时容易出现分类错误；Supervisor 遇到需要平等讨论的任务时可能变得过于集权；Multi-Agent 处理简单任务时会造成资源浪费。
取舍四：ToT vs GoT——树状结构 vs 图状结构。 ToT 适合“多路径探索但路径之间不交叉”的场景（如解题推理）；GoT 适合“路径之间需要合并和回流”的场景（如科研分析）。GoT 的实现复杂度远高于 ToT，如果没有明确需求，不建议贸然使用 GoT。
取舍五：Loop Engineering 的终止条件设计。 Loop 最大的风险是“无限循环”——Agent 一直运行却永远达不到终止条件。工程上必须设置硬性上限（最大循环次数/最大 Token 消耗/最大执行时间），一旦超出上限，强制终止并执行降级处理。Loop 的终止条件设计比 Loop 本身更为关键。
取舍六：Memory 的存储分层——短期记忆 vs 长期记忆 vs 摘要记忆。 短期记忆用于存储对话上下文（全量信息），长期记忆依赖向量数据库（按需检索），摘要记忆用于存储“已完成步骤的浓缩信息”（注入到上下文中以维持状态连续性）。三层 Memory 分层是生产级 Agent 的标配方案，如果不做分层，会导致上下文快速膨胀或状态信息丢失。
九、面试话术：面试官真正想听的是什么
回到面试的具体场景。这道题考察的并非“你背诵了多少个名词”，而是“你是否能够系统性地分析这些模式之间的层级关系”。
常见错误回答一：单纯背诵名词。 一口气报出十几个模式名称——但当面试官追问“各自侧重点是什么”时，立刻无法深入回答。
常见错误回答二：平级罗列。 把所有模式当作同级别的选项逐一介绍——面试官会觉得你只了解名词概念，却不理解它们之间的内在关系。
高分答题模板：三层结构表达。
第一层（点明本质）： “这十几个模式并非平级概念，它们分别回答的是四个不同层次的问题。”
第二层（阐述四层框架）： “第一层推理（ReAct/Plan-and-Execute/Reflection/Self-Refine/ToT/GoT）解决的是‘如何进行思考’；第二层能力（Tool Use/Memory）解决的是‘能够执行什么任务’；第三层调度（Router/Supervisor/Multi-Agent）解决的是‘多 Agent 如何协作’；第四层运行机制（Loop Engineering）解决的是‘如何持续稳定运行’。”
第三层（进行升华）： “这四层并非互斥的选择题，生产级 Agent 实际上是由四层叠加组合而成。例如 Claude Code 就是 Plan-and-Execute + Tool Use + Loop Engineering 的组合方案。具体选择哪种模式取决于业务场景，核心原则是避免过度设计。”
60 分回答与 90 分回答的对比：
| 追问问题 | 60 分回答 | 90 分回答 |
|---|---|---|
| “ReAct 和 Plan-and-Execute 有什么区别？” | “一个边做边想，一个先规划后执行” | “ReAct 每步都要调用大模型，开销较大但灵活度高；Plan-and-Execute 先生成完整计划再执行，开销较小但计划出错时需要整体重规划” |
| “Router 和 Supervisor 分别在什么场景下使用？” | “看具体情况” | “Router 适合意图明确、任务互不交叉的场景；Supervisor 适合任务可分解、需要汇总结果的场景；选错 Router 遇到跨领域任务会分类错误” |
| “Loop Engineering 如何防止无限循环？” | “设置一个终止条件” | “设置硬性上限：最大循环次数/最大 Token 消耗/最大执行时间，超限后强制终止并执行降级；终止条件的设计比 Loop 本身更为关键” |
| “生产级 Agent 如何进行组合设计？” | “全部都用上” | “Plan-and-Execute + Tool Use + Memory + Loop，从简单方案起步，根据需求逐步增加层级，过度设计是 Agent 项目最常见的陷阱” |
加分项提示： 如果你能够主动提到“Memory 需要做三层分层（短期记忆/长期记忆/摘要记忆）”，面试官会认为你具备真实的生产环境实战经验。
总结
回到开头那道面试题目。“Agent 有哪些设计模式”——这道题之所以成为大厂 Agent 岗位的高频考题，是因为它能够有效区分“只会背诵名词”和“真正理解架构”这两类不同的候选人。
- 单纯背诵名词等于零分回答：面试官真正想听的是系统性分析能力，而非简单的名词罗列。
- 四层架构体系：推理层（如何进行思考）→ 能力层（能够执行什么任务）→ 调度层（如何协作）→ 运行机制层（如何持续稳定运行）。
- 13 种模式各自归属：推理层 6 种、能力层 2 种、调度层 3 种、运行机制层 1 种，它们并非平级选项。
- 模式之间可以灵活叠加组合：生产级 Agent 是四层叠加的产物，而非单一选择。
- Loop Engineering 是当前最热门的话题：Claude Code/Codex/Cursor 的底层核心都是持续循环机制。
- 面试话术的三层结构：点明本质（四层不是平级）→ 阐述框架 → 进行升华（可叠加组合）。60 分与 90 分之间的差距在于组合实践经验与防坑意识的差异。
这些模式并非互斥的选择题，而是可以灵活叠加的组合方案。先从最简单的模式起步，待核心功能跑通后，再根据实际需求逐步增加层级——这才是工程实践中正确的做法。
