前言
前段时间有个粉丝去面蚂蚁,岗位跟大模型应用相关。面试官聊了几轮项目后随口问了一句:
👔 你了解哪些 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 是执行完之后自己回头检查------看看代码有没有 bug、逻辑有没有漏洞。是一次"复盘",不是重新生成。
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)→判断是否继续,循环往复。
python
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 成本低(只多调一次模型),适合代码 Review 这类"对错明确"的场景;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 分 vs 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 分的差距在组合经验和防坑意识。
这些模式不是互斥的选择题,而是可以叠加的组合。 先从最简单的模式起步,跑通后按需加层------这才是工程上正确的做法。
你的 Agent 项目用了哪些模式的组合?踩过"过度设计"的坑吗?欢迎评论区交流。