考察点
「你了解 ReAct 吗？除了 ReAct 还有哪些？」是 Agent 面试的固定连招。面试官想看你对各模式的优缺点有真实的权衡经验，特别是 Reflection 能不能治幻觉、什么时候该上 Multi-Agent 这两个经典追问。
参考答案
总览：四种主流模式
| 模式 | 核心思想 | 优点 | 缺点 |
|---|---|---|---|
| ReAct | 边推理边行动，观察回填 | 简单通用、轨迹可审计 | 局部贪心、token 随步数膨胀 |
| Plan-and-Execute | 先全局规划再执行，可 Replan | 长程目标稳、执行阶段省 token | 计划质量依赖模型、对环境变化反应滞后 |
| Reflection | 产出后自我批判再修订 | 输出质量高、能抓自身错误 | 延迟和成本翻倍、可能越改越差 |
| Multi-Agent | 多个专职 Agent 分工协作 | 上下文隔离、可并行、专精化 | 复杂度爆炸、token 消耗数倍、调试难 |
ReAct：默认起点
原理和落地我在另一篇里展开过，这里只强调定位：它是所有模式的基线。任何新模式要先回答「比 ReAct 好在哪、贵在哪」。工程上我默认先用 ReAct 把闭环跑通，确认瓶颈（是漂移？质量？还是延迟？）之后再针对性升级。
Plan-and-Execute：治长程漂移
ReAct 每步只看眼前，跑十几步容易忘了最初目标。Plan-and-Execute 开局生成完整计划，执行时锚定计划走，环境变了就 Replan。适合能提前分解的流程型任务，比如「对比三个竞品的价格和功能出一份报告」。代价是 Planner 本身要强模型，且每步 Replan 检查会再加一次调用。
Reflection：治质量，不治事实
Reflection 让模型产出结果后，再用一个批评者角色（可以是同一个模型换 prompt）审视输出，挑出毛病后重写。写代码场景最经典：生成代码 → 跑单测/静态检查 → 把报错喂回去让模型修，这就是带外部反馈的 Reflection（Reflexion 论文的路线）。
要特别说清楚一个面试加分点：Reflection 对「形式错误」有效，对「事实幻觉」基本无效。代码跑不过、格式不对、漏了约束条件，模型自己能发现；但如果它一本正经地编了个不存在的 API，批评者和生成者是同一个模型，大概率批评者也认为这个 API 存在。治事实幻觉靠的是工具验证（检索、执行），不是自我批评。我在项目里的教训是 Reflection 最多跑 2 轮，第 3 轮开始经常出现「改了 A 毛病引入 B 毛病」的震荡，收益急剧递减。
Multi-Agent：最后才考虑的选项
当单个 Agent 的上下文塞不下（比如一个任务要同时消化 50 页文档 + 操作 10 个工具）、或者子任务天然并行（同时调研 5 个竞品），才轮到 Multi-Agent。Anthropic 明确提醒不要过早引入：多 Agent 的 token 消耗是单 Agent 的数倍（他们的研究系统里约 4 倍聊天用量），调试时要在多个 Agent 的轨迹里对时间线，复杂度非线性增长。先把单 Agent + 好工具做到极限。
选型口诀
步骤未知用 ReAct，长程分解用 Plan，质量敏感加 Reflection（限两轮、配外部验证），上下文爆炸或天然并行才上 Multi-Agent。四个模式不互斥，真实系统常是「Plan 定骨架、ReAct 跑节点、关键产出过 Reflection」的组合。
可能的追问
- 「Reflection 能用于自我校正幻觉吗？」 不能单独用。自我批评抓得住形式错误抓不住事实错误，必须接外部验证（检索核对、代码执行、schema 校验）形成「生成→验证→修正」的环。
- 「Reflexion 和普通 Reflection 有什么区别？」 Reflexion 把失败经验以文本形式存进「情景记忆」，跨轮次甚至跨任务复用，不只是当轮修订。
- 「什么时候该引入 Multi-Agent？」 三个信号：单 Agent 上下文窗口装不下任务所需信息；子任务并行收益大于协调成本；不同子任务需要完全不同的 prompt/工具集，混在一起互相污染。