Agent 三种常见范式：ReAct / Plan-and-Execute / Reflection
面试方向：AI Agent 算法岗 ｜精简版 15 题｜ReAct 重点，另外两种了解即可。
术语说明：这里的 ReAct = Reason + Act，不是前端 React；“三大框架”是面试复习中的常见归类，严格说它们是Agent 设计范式，不是业界唯一公认的三种软件框架，且可以组合使用。
使用方法：先独立回答题目，再看下方标准答案。★ 为必背；项目题只提供可自洽的表述，具体落地细节须以真实实现为准。
一、面试题清单（15 题）
P0：ReAct 核心（9 题，必背）
- ★ 什么是 ReAct？核心思想和完整循环是什么？
- ★ ReAct 的 Thought、Action、Observation 各代表什么？
- ★ ReAct 与 CoT（Chain-of-Thought）有什么区别？
- ★ ReAct 与普通 Function Calling 有什么关系和区别？
- ★ ReAct 如何决定调用什么工具？工具结果如何参与下一步决策？
- ★ ReAct 什么时候停止？怎样避免死循环、重复工具调用和成本失控？
- ★ 如果工具调用失败、超时或返回错误数据，ReAct 应如何处理？
- ★ ReAct 的优缺点是什么？哪些业务适合/不适合？
- ★ ReAct 如何降低幻觉？为什么不能说它能消除幻觉？
P1：其他两种范式（3 题，了解）
- 什么是 Plan-and-Execute？与 ReAct 有什么区别？
- 什么是 Reflection（反思/自检）？它与 ReAct 如何配合？
- ReAct、Plan-and-Execute、Reflection 如何选型？能否组合？
P0：结合你的项目（3 题，重点）
- ★ 你的文档处理项目为什么在局部节点使用 ReAct，而不是纯规则工具路由？
- ★ 既然用了 ReAct，为什么整个系统还要用 Workflow，而不全交给自主 Agent？
- ★ 如果 ReAct 选错了解析工具或产生错误输出，你如何定位、兜底并评测？
二、标准答案（面试口述版 + 追问）
1. 什么是 ReAct？核心思想和完整循环是什么？
面试口述版： ReAct 是 Reasoning + Acting 的缩写，是将模型的决策推理与外部工具行动交替组织的 Agent 范式。模型根据用户目标和已有观察选择下一步动作，执行工具后把 Observation 回填上下文，再继续判断，直到能回答或满足停止条件。它的价值是让模型不只凭内部知识生成，而能通过外部工具获取证据并动态调整行为。
核心流程： 用户目标 → 判断下一步（Thought/决策）→ 工具调用（Action）→ 工具结果（Observation）→ 下一轮决策 → Final Answer。
追问： Thought 是概念性决策步骤；实际系统不一定暴露模型的完整内部推理文本，也可以通过结构化工具调用与状态字段实现。
2. Thought、Action、Observation 分别是什么？
面试口述版： Thought 是选择下一步操作的判断，Action 是具体操作（如调用文件解析工具），Observation 是工具或环境返回的实际结果。后续决策应基于 Observation，而不是假设工具已成功。
例子： 识别 PDF → 调用 PDF 解析器 → 返回文本及页码/错误 → 判断是否继续、切换解析器或报错。
3. ReAct 与 CoT 有什么区别？
面试口述版： CoT 主要通过分步骤推理解决问题，不要求与外部环境交互；ReAct 在推理/决策中穿插工具行动和真实反馈，能不断修正后续步骤。简单说 CoT 偏“想”，ReAct 是“判断—行动—观察”的循环。它们并不互斥，ReAct 可以包含分步推理。
追问： ReAct 不保证外部信息就正确；证据质量、工具可靠性仍重要。
4. ReAct 与 Function Calling 有什么区别？
面试口述版： Function Calling 是模型以结构化参数请求调用工具的机制；ReAct 是围绕目标进行多轮决策与行动的执行范式。Function Calling 可以成为 ReAct 的 Action 实现方式，但单次 Function Calling 不等于完整的 ReAct 循环。
易错点： 不要说“用 Function Calling 就一定是 ReAct”。
5. ReAct 如何决定调用什么工具？
面试口述版： 需要给模型明确工具的名称、描述、输入 schema 和调用边界。模型结合任务目标、已有上下文和上轮 Observation 选择工具与参数；运行时先校验参数和权限，再执行工具，并将结果转化为可用的 Observation。若结果不足，可以继续调用其他工具或终止并说明限制。
追问： 工具选择质量取决于描述是否区分清楚、schema 是否严格、是否存在无效/重叠工具及异常反馈是否清晰。
6. ReAct 怎样停止、避免死循环？
面试口述版： 通常设置任务完成条件以及工程停止条件，包括最大步骤数、最大 Token/费用预算、工具调用超时、重复调用检测和无进展判定。达到目标则返回最终结果；出现无法解决的异常则安全退出，不能无限重试。
追问： 相同参数重复调用多次但 Observation 不变，应检测为无进展而非持续探索。
7. 工具失败时怎么办？
面试口述版： 首先区分参数错误、超时、服务暂时不可用和业务语义错误。参数错误先修正 schema；临时失败可有限次数重试并退避；有备用工具则切换；无法修复则记录错误、停止对应节点并进入降级或人工复核。对于有副作用的工具，重试前须考虑幂等性。
追问： 工具返回的文本不可信，不能直接把其中的指令当作系统指令执行。
8. ReAct 的优缺点及场景？
面试口述版： 优点是工具使用灵活、能根据反馈调整、过程较易观察与排错。缺点是多轮推理与工具调用带来延迟和费用，路径不确定，可能出现错误工具选择、重复动作及错误传播。适合步骤不完全固定、需要动态调用工具的任务；对强确定性、低延迟、高审计要求的固定流程，应优先采用规则或 Workflow，并在局部使用 ReAct。
9. ReAct 为什么有助于降低幻觉？
面试口述版： ReAct 可以通过工具检索、查询或执行获得外部 Observation，避免完全依赖模型参数记忆；但如果检索内容本身错误、模型误读 Observation，或模型编造工具没有返回的信息，依然会幻觉。因此需要工具结果验证、引用/证据对齐和必要的兜底机制。
10. 什么是 Plan-and-Execute？与 ReAct 区别？
面试口述版： Plan-and-Execute 通常先由 Planner 把目标拆成子任务，再由 Executor 执行，必要时 Replan。ReAct 更强调每一步根据最新 Observation 动态决策；Plan-and-Execute 更强调全局规划和任务依赖。长任务拆解清晰时 Plan-and-Execute 有优势，但计划可能过时；也可以用 ReAct 作为单个子任务的执行器。
11. 什么是 Reflection？
面试口述版： Reflection 是在生成或执行后对结果进行自检、评价和修正的范式，通常构成“生成—检查—修改”的迭代。它可以配合 ReAct 在工具调用后检查结果质量，也可以放在最终输出前。需注意模型自评并不一定可靠，最好结合规则验证器、测试或外部证据，并设置修订次数上限。
12. 三者如何选型？
面试口述版： 短且不确定、频繁与工具交互，优先考虑 ReAct；任务可分解且依赖复杂，考虑 Plan-and-Execute；结果需要多轮质量校验，则叠加 Reflection。它们不互斥，选型要根据任务确定性、可靠性、成本和可观测性，而不是追求结构复杂。
记忆表： ReAct = 边做边决定；Plan-and-Execute = 先规划再执行；Reflection = 做完检查修正。
13. 【项目题】为什么在文档处理节点中使用 ReAct？
面试口述版： 我的系统整体是文档处理 Workflow，但文档类型与解析方式存在一定不确定性。我希望在固定节点内部让模型基于文件特征和解析反馈选择合适的处理工具，因此采用 ReAct 式的“判断—调用—观察”方式，而不是让所有格式都走同一个解析器。这样既保留格式适配的灵活性，也不改变下游流程的固定依赖。
严谨边界： 如果你的真实实现只是“一次分类 → 一次工具调用”，面试时更准确称为LLM 工具路由/Function Calling；只有在根据 Observation 持续决定下一步时，才更接近完整 ReAct。不要为了说 ReAct 而虚构多轮循环。
14. 【项目题】既然用了 ReAct，为什么整个系统还是 Workflow？
面试口述版： 因为我的核心业务依赖是确定的：文档识别与解析 → 分块 → 知识图谱构建 → 结果复查。阶段顺序必须可控，且每一阶段都应能单独定位和重试。Workflow 能提供固定的拓扑、明确的数据接口和错误边界；ReAct 只在需要动态决策的局部节点使用。两者不是二选一，而是“Workflow 管全局，ReAct 管局部不确定性”。
面试官追问“为什么不用 Plan-and-Execute？”： 任务的全局阶段本来已经确定，不需要每次再由模型生成一份计划；引入 Planner 可能增加调用成本与不确定性。只有未来任务类型明显扩展、步骤依赖动态变化时，才更值得引入动态规划。
15. 【项目题】解析工具选错或输出错误怎么办？如何评测？
面试口述版： 我会在接口上保存每阶段的输入、输出、工具名、错误码和关联 ID，先判断是路由选择错误、解析内容缺失、分块导致语义断裂，还是知识图谱构建与最终回答的问题。可通过文件类型校验、输出结构验证、原文对齐、有限重试和人工复核降低错误传播。评测分别看工具路由准确率、解析完整率、分块质量、图谱事实正确率，以及端到端任务成功率、延迟和成本。
注意： 以上为推荐的排错与评测设计；只描述你确实实现过或能明确区分为后续优化的措施，不要声称已上线或已有特定指标。
三、考前速记（只背这一段也能应对基础追问）
- ReAct： 目标驱动的“决策 → 工具行动 → 观察反馈 → 再决策”循环。
- CoT vs ReAct： 前者以推理为主；后者将推理/决策与外部行动交替结合。
- Function Calling vs ReAct： 前者是结构化工具调用机制；后者是组织多轮工具交互的范式。
- Plan-and-Execute： 先拆计划再执行，必要时重规划。
- Reflection： 对结果进行自评/验证并修订。
- 项目选型： Workflow 管固定全局流程，ReAct 处理局部动态工具选择；不是二选一。
- 可靠性： Schema 校验、终止条件、有限重试、观察日志、质量验证。
四、参考来源
- ReAct 原始论文：https://arxiv.org/abs/2210.03629
- Google Research ReAct 介绍：https://research.google/blog/react-synergizing-reasoning-and-acting-in-language-models/
- LangChain 关于 Planning Agents：https://www.langchain.com/blog/planning-agents
- 牛客 Agent 常见范式讨论：https://www.nowcoder.com/discuss/888907676686516224
- 美团 Agent 面试案例（第三方转载整理）：https://mj.mianlingai.com/interview/meituan-ai-application-developer-first-round-931898194231820288/
本文件为基于公开知识与面试题型的总结，不是原样转载面试记录。
