ReAct框架解析：从工程契约视角构建大模型智能体

1. 项目概述：ReAct，一个被误解的“算法”

如果你最近在准备AI相关的面试，或者对Agent（智能体）开发感兴趣，那么“ReAct”这个词大概率已经在你眼前晃过无数次了。面试官可能会问：“解释一下ReAct框架”，技术文章里会写“基于ReAct的Agent”，开源项目则标榜“支持ReAct推理模式”。很多人，包括不少刚入行的开发者，第一反应是去搜索“ReAct算法原理”，试图找到一个像梯度下降或决策树那样有明确数学定义的算法。但我想告诉你的是，这种思路从一开始就偏了。

ReAct根本就不是一个算法，它是一种工程契约，一种在复杂问题域与可执行动作之间建立可靠映射的方法论。这个认知上的转变至关重要。把它当成算法去死记硬背，你只能应付最浅层的概念题；而把它理解为一套工程契约，你才能从容应对面试中那些步步紧逼的追问，并在实际项目中设计出真正健壮的智能体系统。简单来说，ReAct定义了一种标准化的“思考-行动”循环协议：让AI先根据当前观察进行推理（Reasoning），再根据推理结果执行一个具体的、可观测的动作（Acting），然后基于动作的结果再次观察，进入下一轮循环。这个循环本身不规定你用什么模型（可以是GPT-4，也可以是Claude或开源模型），也不规定具体任务（可以是网页操作、数据分析或代码调试），它规定的是一种交互的“格式”和“承诺”。

为什么这种“契约”视角在面试和工程中如此重要？因为面试官真正想考察的，不是你能否复述论文里的定义，而是你能否理解一个技术方案背后要解决的工程难题：如何让不可控的大模型输出，变得稳定、可追踪、可调试？如何将模糊的人类指令，分解成一系列确定性的环境交互？ReAct提供的正是这样一个框架性的答案。接下来，我们就从问题域出发，彻底拆解ReAct，并映射到那些常见的面试追问上，让你不仅知道它是什么，更知道为什么是它，以及怎么用它。

2. 核心需求解析：为什么我们需要“契约”而非“算法”？

要理解ReAct的价值，我们必须先回到它所要解决的核心问题域。在没有ReAct这类范式之前，我们使用大模型处理复杂任务时，面临的是怎样一种混沌状态？

2.1 传统提示工程的局限性：脆弱的“一步到位”

在ReAct或Chain-of-Thought（思维链）流行之前，典型的做法是设计一个复杂的、包含所有上下文和指令的“超级提示词”（Monolithic Prompt），然后期望模型直接吐出最终答案。比如，“请分析这个网页的内容，总结其主要观点，并判断作者的情感倾向，最后用表格列出关键论据。”

这种做法存在几个致命缺陷：

1. 黑箱与不可调试：模型一次性生成数百个token，如果中间某一步逻辑出错，或者产生了“幻觉”（编造信息），开发者很难定位问题究竟出在哪里。是整个任务理解错了，还是总结环节有偏差，或者是表格格式乱了？你只能看到最终那个可能不尽人意的结果。
2. 缺乏与环境交互的能力：很多任务需要获取外部信息。例如，“查询北京今天的天气，如果下雨就推荐室内活动”。在传统提示下，模型可能会直接编造一个天气情况（幻觉），或者因为训练数据中没有实时信息而失败。模型自身无法执行“查询天气API”这个动作。
3. 难以处理长程任务：对于需要多步骤、且后续步骤依赖前序结果的任务，一次性生成所有步骤的规划极其困难，且容错率极低。一旦某步规划不切实际，整个计划就失败了。

面试追问映射：面试官可能会问：“在Agent出现之前，用纯Prompt工程处理复杂任务有什么痛点？” 这时你不能只回答“效果不好”，而要具体指出黑箱性、无法交互、难以处理长流程这三大工程痛点，并举例说明。这体现了你对问题演进历史的深刻理解。

2.2 思维链（CoT）的进步与遗留问题

Chain-of-Thought的提出是一个重大进步。它通过“让我们一步步思考”这类提示，要求模型将推理过程显式地输出出来。这解决了“黑箱”的一部分问题，使得模型的思考过程变得可见。

但CoT依然局限在“纯推理”的层面。它的输出仍然是一段文本，而不是一个可执行的动作。模型可以推理出“要解决这个问题，我需要先查询天气API”，但它无法自己执行这个查询动作。CoT将任务分解在了思维层面，但未能连接到物理（或数字）世界。它缺乏“行动-观察”这个关键闭环。

2.3 工程上的核心需求：标准化接口与可控执行

因此，从工程化落地角度看，我们需要的是一个能够：

1. 标准化模型输出：让模型的输出不再是自由格式的文本，而是结构化的、可被程序解析的指令。例如，输出必须是{"thought": "...", "action": "Search", "action_input": "..."}这样的JSON格式。
2. 连接感知与动作：为模型配备“手脚”（Tools/API），并定义一套清晰的协议，告诉模型如何调用这些手脚，以及如何理解手脚返回的结果（观察）。
3. 实现循环与状态管理：任务通常不是一步完成的，需要根据上一步的结果决定下一步做什么。系统需要能维护一个任务状态（如已执行步骤、当前观察），并驱动模型进行下一轮“推理-行动”。

ReAct正是为了满足这些工程需求而诞生的“契约”。它规定：每一轮交互，模型必须输出结构化的“思考”和“动作”；系统执行动作后，必须将结果作为“观察”反馈给模型；模型再基于全部历史（思考、动作、观察）进行下一轮输出。这套循环协议，使得大模型驱动的智能体从“天马行空的文本生成器”变成了“可规划、可执行、可追踪的自动工作流引擎”。

实操心得：很多新手在初次搭建Agent时，会纠结于寻找“最厉害的模型”。但实际上，一个遵循ReAct契约、配备合适工具、但使用中等性能模型的Agent，其稳定性和成功率往往远高于一个用了顶级模型但输出不可控、工具调用混乱的系统。工程契约的价值在于降低系统整体不确定性，模型能力只是这个系统中的一环。

3. ReAct契约的三大核心组件拆解

理解了为什么需要契约，我们再深入看看这份“契约”具体规定了什么。一个典型的ReAct循环包含三个核心组件：推理（Reasoning）、行动（Acting）、观察（Observation）。每一轮循环的输出和输入，都必须遵循严格的格式。

3.1 推理（Reasoning）：不仅仅是“想一想”

在ReAct中，推理是一个面向行动的、情境化的思考过程。它不仅仅是模型内部的黑箱计算，更是必须用自然语言显式表达出来的、为下一步动作提供依据的文本。

推理内容必须包含：

• 对当前状况的分析：基于之前的观察，我们现在处于什么状态？目标是什么？
• 对可用工具的评估：我手头有哪些工具？哪个工具最适合当前状况？
• 下一步动作的决策与理由：因此，我决定采取哪个动作？为什么这个动作能推进任务？

错误的推理示例：

思考：我需要找到答案。

正确的推理示例：

思考：用户想了解ReAct。我已经知道ReAct是一种范式。但我需要更权威、更详细的定义。我应该使用“搜索”工具，以“ReAct reasoning acting framework”为关键词进行查询，这样可以获取最新的研究资料。

为什么必须如此详细？这不仅仅是为了让人读懂。在复杂任务中，详细的推理相当于给模型的“工作记忆”做了外部缓存。当任务链很长时，模型可能会遗忘早期的决策依据。而白盒化的推理记录，使得系统在出错时可以进行回溯分析，也使得多智能体协作时，其他智能体能够理解其决策逻辑。

面试追问映射：面试官可能会追问：“ReAct中的Reasoning和Chain-of-Thought中的‘一步步思考’有什么区别？” 关键区别在于目的性。CoT的思考是为了得到最终答案文本；ReAct的思考是为了生成下一个结构化动作。前者是终点，后者是通往下一个动作的桥梁。你可以说：“ReAct的推理是行动导向的、情境化的，并且其输出格式是契约强制规定的结构化内容的一部分。”

3.2 行动（Acting）：从文本到可执行指令

这是ReAct将模型与外部世界连接起来的关键环节。行动必须是具体的、离散的、且被系统支持的操作。

行动的核心要求：

1. 工具化：每一个行动都对应一个预先定义好的工具（Tool）。例如：Search(query),Calculator(expression),BrowseWebsite(url),ExecutePython(code)。
2. 参数化：行动必须携带精确的参数。Search(“什么是机器学习”)是有效的；Search(一些关于AI的东西)则是无效的。
3. 结构化输出：模型不能输出“我要搜索”，而必须输出如{"action": "Search", "action_input": "ReAct paper 2022"}这样的结构化数据，以便系统解析并调用相应函数。

工具（Tools）的设计是工程成败的关键。工具需要满足：

• 功能原子化：一个工具只做一件事，并且做好。避免设计“万能工具”，那样会导致模型难以理解和调用。
• 接口稳定：工具的输入输出格式必须稳定、明确。输入应该是简单的数据类型（字符串、数字、列表），输出也应该是结构化的文本或数据。
• 安全性：工具执行可能具有副作用（写文件、发邮件、操作数据库）。必须在工具层面做好权限控制和输入验证，不能完全信任模型的输出。

3.3 观察（Observation）：环境的确定性反馈

行动执行后，环境（或工具）返回的结果就是观察。观察必须被完整、准确地反馈给模型，作为下一轮推理的输入。

观察的处理原则：

• 原始性：尽量返回工具执行的原始结果，避免过度加工。例如，搜索工具返回的是API的原始摘要列表，而不是人工总结的一段话。这保证了信息的保真度。
• 上下文整合：系统需要将本次的“观察”与之前的“思考”、“行动”历史一起，组合成新的提示上下文，传递给模型。这构成了模型的“工作记忆”。
• 截断与摘要：对于非常长的观察（如爬取了一个长网页），直接全部塞给模型会浪费上下文窗口且干扰重点。此时需要引入“摘要”工具或策略，但摘要本身也应视为一个独立的“行动-观察”步骤。

ReAct循环的标准化数据流可以概括为：

初始状态：用户问题 + 工具描述 循环开始： 1. 模型接收：全部历史（[Thought1, Action1, Obs1, Thought2, Action2, Obs2, ...]） + 当前目标。 2. 模型输出：格式化的 `Thought: ...\nAction: ...\nAction Input: ...`。 3. 系统解析：提取 `Action` 和 `Action Input`。 4. 系统执行：调用对应的工具函数。 5. 系统收集：工具返回结果，作为 `Observation: ...`。 6. 系统组装：将本轮输出的 Thought/Action 和得到的 Observation 追加到历史中。 7. 判断循环是否继续（根据是否输出最终答案或达到步数限制）。

注意事项：在实际工程中，第2步的“模型输出”必须进行严格的格式校验（Schema Validation）。模型有时会“胡言乱语”，输出不符合约定的格式。系统必须能处理这种异常，例如通过一个“格式修复”子流程，或者直接终止任务并报错。对模型输出的不信任，是构建鲁棒Agent系统的第一课。

4. 从契约到实现：构建ReAct智能体的工程实践

理论说完了，我们来看看如何亲手搭建一个遵循ReAct契约的智能体。这里我们以构建一个“研究助手”Agent为例，它能够根据一个复杂问题，自动搜索资料、进行计算、并整理答案。

4.1 工具库的设计与实现

工具是Agent的手脚，设计好坏直接决定Agent的能力边界。

1. 网络搜索工具这是最基础的工具。我们可以利用SerpAPI、Google Search API或者Bing Search API。

import requests import os class SearchTool: name = "search" description = "Useful for when you need to answer questions about current events or factual information. Input should be a clear search query string." def _run(self, query: str) -> str: # 示例：使用SerpAPI（需注册获取API_KEY） params = { 'q': query, 'api_key': os.getenv("SERPAPI_KEY"), 'engine': 'google' } try: response = requests.get('https://serpapi.com/search', params=params) results = response.json().get('organic_results', []) # 提取前3个结果的摘要，作为观察返回 observations = [] for r in results[:3]: observations.append(f"Title: {r.get('title')}\nSnippet: {r.get('snippet')}\nLink: {r.get('link')}") return "\n\n".join(observations) if observations else "No relevant results found." except Exception as e: return f"Search failed with error: {str(e)}"

设计要点：description字段至关重要，它是模型理解工具用途的唯一依据。描述要准确、简洁，并说明输入格式。返回的观察信息结构清晰，便于模型阅读。

2. 计算器工具用于解决数学计算，避免模型自己算错或幻觉。

import ast import operator as op class CalculatorTool: name = "calculator" description = "Useful for performing arithmetic calculations. Input should be a valid mathematical expression, e.g., '(12.5 + 4.3) * 2'." def _run(self, expression: str) -> str: try: # 安全评估数学表达式 node = ast.parse(expression, mode='eval') # 定义允许的操作符 allowed_operators = {ast.Add: op.add, ast.Sub: op.sub, ast.Mult: op.mul, ast.Div: op.truediv, ast.Pow: op.pow, ast.USub: op.neg} def eval_node(node): if isinstance(node, ast.Num): return node.n elif isinstance(node, ast.BinOp): left_val = eval_node(node.left) right_val = eval_node(node.right) return allowed_operators[type(node.op)](left_val, right_val) elif isinstance(node, ast.UnaryOp): operand_val = eval_node(node.operand) return allowed_operators[type(node.op)](operand_val) else: raise TypeError(f"Unsupported operation: {node}") result = eval_node(node.body) return str(result) except Exception as e: return f"Calculation error: {str(e)}. Please provide a valid arithmetic expression."

设计要点：安全！安全！安全！绝不能直接用eval()。这里使用ast模块进行解析，并严格限制允许的操作符，防止模型被诱导执行恶意代码。

3. 维基百科摘要工具获取相对结构化的知识。

import wikipedia class WikipediaTool: name = "wikipedia" description = "Useful for getting summary information about a topic. Input should be a specific topic name." def _run(self, topic: str) -> str: try: # 设置语言和摘要长度 wikipedia.set_lang("en") summary = wikipedia.summary(topic, sentences=3) return summary except wikipedia.exceptions.DisambiguationError as e: return f"Disambiguation needed. Possible options: {', '.join(e.options[:5])}" except wikipedia.exceptions.PageError: return f"Page for '{topic}' not found." except Exception as e: return f"An error occurred: {str(e)}"

4.2 提示词工程：如何教会模型遵守契约

有了工具，下一步是指导模型按照ReAct格式输出。这需要精心设计提示词（Prompt）。

系统提示词（System Prompt）是核心：

你是一个强大的研究助手，通过思考、行动、观察的循环来解决问题。 你必须严格遵守以下格式： 思考：你需要在这里进行深入推理，分析当前情况，回顾之前的观察，并决定下一步做什么。解释你为什么选择这个行动。 行动：你只能从以下工具中选择一个：{search, calculator, wikipedia, finish}。 行动输入：你选择的行动所需的输入，必须是一个字符串。 在你输出“行动：”和“行动输入：”之后，系统会执行该工具并返回观察结果。 当你确信已经收集到足够信息，能够给出最终答案时，请使用“finish”工具。 “finish”工具的输入就是你给用户的最终答案。 开始！ 问题：{用户的问题}

关键技巧：

1. 格式示例（Few-shot）：在系统提示词中，最好包含1-2个完整的ReAct循环示例。这比单纯描述格式有效得多。模型通过示例学习格式和推理风格。
2. 工具描述集成：在实际代码中，{search, calculator, wikipedia, finish}这部分会被动态替换为所有工具的name和description，让模型知道每个工具能干什么。
3. 明确终止条件：必须清晰定义如何结束任务（如使用finish工具）。否则Agent可能陷入无限循环。

4.3 主循环与控制逻辑的实现

这是驱动整个ReAct引擎的代码。

import re from typing import Dict, Any class ReActAgent: def __init__(self, llm_client, tools: Dict[str, Any], max_steps=10): self.llm = llm_client self.tools = tools self.max_steps = max_steps def run(self, query: str): # 初始化对话历史，包含系统提示和用户问题 prompt = self._build_initial_prompt(query) history = [{"role": "user", "content": prompt}] for step in range(self.max_steps): # 1. 调用模型，获取回复 response = self.llm.chat_completion(history) agent_response = response['choices'][0]['message']['content'] print(f"\n--- Step {step+1} ---") print(agent_response) # 2. 解析回复，提取 Thought, Action, Action Input thought, action, action_input = self._parse_response(agent_response) # 3. 检查是否结束 if action.lower() == "finish": print(f"\n任务完成！最终答案：{action_input}") return action_input # 4. 执行动作 if action in self.tools: observation = self.tools[action]._run(action_input) print(f"观察：{observation}") else: observation = f"错误：未知工具 '{action}'. 可用工具：{list(self.tools.keys())}" # 5. 更新历史，将本轮输出和观察加入上下文 history.append({"role": "assistant", "content": agent_response}) # 注意：这里将观察也作为一条“用户”消息追加，模拟环境反馈 history.append({"role": "user", "content": f"观察：{observation}"}) print("\n达到最大步数限制，任务终止。") return "任务未能在限制步数内完成。" def _parse_response(self, text: str): # 使用正则表达式解析格式 thought_match = re.search(r'思考：?(.*?)(?=\n行动：|\n$)', text, re.DOTALL) action_match = re.search(r'行动：?(.*?)(?=\n行动输入：|\n$)', text, re.DOTALL) action_input_match = re.search(r'行动输入：?(.*?)(?=\n思考：|\n$)', text, re.DOTALL) thought = thought_match.group(1).strip() if thought_match else "" action = action_match.group(1).strip() if action_match else "" action_input = action_input_match.group(1).strip() if action_input_match else "" return thought, action, action_input

核心逻辑解析：

• 历史管理：每一轮的输出（Thought/Action）和观察（Observation）都被追加到对话历史中。这模拟了Agent的“工作记忆”，是ReAct循环能持续进行的基础。
• 解析鲁棒性：_parse_response函数需要足够健壮，以应对模型输出格式的微小偏差（如多余的空格、换行符）。更高级的做法是使用LLM本身进行解析，或者要求模型输出严格的JSON。
• 循环终止：设置了最大步数max_steps防止无限循环，同时依赖模型主动调用finish工具来正常结束。

实操心得：在测试初期，你可能会发现模型经常不按格式输出。除了优化提示词，一个实用的技巧是加入一个“格式验证与修复”步骤。如果解析失败，可以将错误信息连同原始回复一起发给模型，要求它“请严格按照指定格式重新输出”。这通常比直接让系统报错更有效。

5. 面试追问的深度映射与回答策略

了解了ReAct的工程实现，我们再来看看面试官会如何层层深入地考察你对它的理解。下面是一个模拟的面试对话树，以及每个问题背后的考察点和回答要点。

面试官：“请简单介绍一下ReAct。”

• 考察点：基础概念理解。看你能不能把它和算法区分开。
• 回答要点：直接点明其“工程契约”或“范式”的本质。“ReAct是一种用于构建大模型智能体（Agent）的范式，它通过标准化‘推理-行动-观察’的循环，将大模型的推理能力与外部工具的执行能力结合起来。它不是一个具体的算法，更像是一份规定智能体如何与环境交互的协议。”

面试官：“它和Chain-of-Thought（CoT）以及Plan-and-Execute有什么区别？”

• 考察点：对相关概念的辨析能力，考察知识体系的结构化程度。
• 回答要点：画一个对比表格在脑中，然后分点阐述。

  特性	Chain-of-Thought (CoT)	ReAct	Plan-and-Execute
  核心	显式推理过程	推理+行动+观察循环	先规划全步骤，再执行
  输出	最终答案文本	结构化动作指令	完整的计划列表
  交互性	无，纯推理	有，每步依赖上步观察	弱，规划后一次性执行
  适用场景	纯逻辑/数学问题	需与环境交互的复杂任务	步骤相对独立、可预知的任务

  • 具体阐述：“CoT是让模型‘想清楚再说’，重点在提升推理质量；ReAct是让模型‘想一步做一步’，重点在实现与世界的交互；Plan-and-Execute则是‘先画蓝图再施工’，适合步骤间耦合度低的任务，但缺乏执行中的灵活性。ReAct在动态环境中的适应性更强。”

面试官：“在实现ReAct Agent时，最大的挑战是什么？”

• 考察点：工程实践经验，是否踩过坑。
• 回答要点：不要泛泛而谈“模型不听话”，要具体。
  1. 格式控制：“确保模型输出严格遵循约定的结构化格式（如JSON）是一大挑战。需要使用提示工程技巧（如Few-shot示例）、输出解析（Parser）甚至后处理来保证。”
  2. 工具设计的粒度：“工具设计太粗，模型难以调用；太细，又会增加模型的认知负担和出错概率。需要找到原子性和实用性的平衡点。”
  3. 错误处理与鲁棒性：“模型可能输出无效动作、工具执行可能失败、网络可能超时。系统必须有完整的错误处理链路，比如动作重试、格式修复、任务回退等，防止单点失败导致整个Agent崩溃。”
  4. 上下文管理：“随着循环进行，历史（Thought, Action, Observation）会越来越长，可能超出模型的上下文窗口。需要设计摘要或选择性记忆的机制。”

面试官：“如何评估一个ReAct Agent的好坏？”

• 考察点：对项目落地和效果衡量的思考。
• 回答要点：从多个维度展开。
  • 任务成功率：最核心的指标，在测试集上完成目标任务的百分比。
  • 平均步数/效率：完成一个任务平均需要多少轮ReAct循环。步数越少，通常效率越高，成本也越低。
  • 工具调用准确率：模型选择的工具是否恰当，输入的参数是否准确。
  • 推理质量：生成的“Thought”是否逻辑清晰、与行动匹配。这可以通过人工评估或使用高级模型（如GPT-4）进行评判。
  • 鲁棒性：在面对模型输出格式错误、工具异常、网络问题时的表现。

面试官：“如果Agent陷入了死循环（比如不停搜索同一个关键词），你会怎么排查和解决？”

• 考察点：调试能力和系统性思维。
• 回答要点：展现你的排查路径。
  1. 检查观察：首先看工具返回的“观察”是否有效。是不是搜索没结果返回了空信息，导致模型没有新信息而重复动作？
  2. 检查推理：看模型的“思考”部分。它的推理逻辑是否出现了偏差？是否错误地认为之前的行动没有提供所需信息？
  3. 引入外部终止与引导：
     • 步数限制：这是最基本的防护。
     • 重复动作检测：在系统层面检测到连续N次相同或相似动作时，强制中断或注入一条警告观察（如“你已重复执行相同操作，请重新评估你的策略”）。
     • 反思机制：在每N步后，强制模型进行一次“元思考”，总结当前进展和剩余目标，这有助于其跳出局部循环。
  4. 优化提示词：在系统提示中明确加入避免循环的指令，或提供更多样化的示例。

6. 进阶思考：ReAct的局限与未来演进

没有任何一个范式是银弹。ReAct虽然强大，但也有其明显的局限性。认识到这些局限，才能更好地应用它，并理解其未来的演进方向。

6.1 ReAct范式的局限性

1. 串行瓶颈：标准的ReAct是单线程、串行执行的。“思考-行动-观察”必须一步一步来。对于可以并行执行的任务（如同时查询多个不相关的数据源），这种模式效率低下。
2. 错误累积：任何一步的推理错误或行动失败，都会影响后续所有步骤。系统缺乏从错误中自动恢复或调整整体计划的高级能力。
3. 长程规划能力弱：ReAct侧重于下一步该做什么，而不是一个长远的全局规划。对于极其复杂、需要上百步的任务，它容易迷失在细节中，忘记最终目标。
4. 对提示词质量极度敏感：模型的行为严重依赖系统提示词和Few-shot示例的设计。设计不当的提示词会导致格式错误、逻辑混乱或无效循环。

6.2 与其他范式的结合：ReAct的“进化形态”

工程实践总是在融合与创新。为了克服上述局限，业界出现了许多ReAct的变体或结合体。

• ReAct + Reflection（反思）：在每执行几步后，不是直接进入下一轮循环，而是插入一个“反思”步骤。让模型回顾历史，评估当前计划是否有效，是否偏离目标，并进行自我纠正。这相当于给Agent加了一个“元认知”层，提升了其纠错和长期规划能力。
• ReAct + Plan-and-Execute：先让一个“规划者”模型（Planner）制定一个高层次计划大纲，然后由“执行者”模型（Executor）按照ReAct模式去执行每个子任务。这结合了宏观规划的优势和微观交互的灵活性。LangChain的“Plan-and-Execute” Agent就是这种思路。
• 多智能体协作（Multi-Agent）：将一个大任务分解，由多个遵循ReAct契约的智能体分工协作。它们之间通过消息传递进行通信。这可以解决串行瓶颈，实现任务并行，也使得系统设计更加模块化。例如，一个Agent负责搜索，一个负责分析数据，一个负责撰写报告。

6.3 面试中的高阶问题准备

基于这些演进，面试官可能会问出更深入的问题：

“除了ReAct，你还了解哪些Agent推理架构？你认为它们各自适合什么场景？”

• 回答思路：可以提到“State Machine”（状态机）架构（任务流程固定，用LLM判断状态转移）、“Router”（路由）架构（LLM作为路由器，将问题分配给最专业的子工具链）、以及上述的“Reflection”和“Multi-Agent”。强调“没有最好，只有最合适”。流程固定的客服场景用状态机可能更稳定；开放域问答用ReAct更灵活；复杂项目开发则可能需要多智能体。

“如果让你设计一个支持‘反思’机制的ReAct Agent，你会怎么设计？”

• 回答思路：这是一个系统设计题。可以分点阐述：
  1. 触发条件：定义何时触发反思（例如，每N步后、工具连续失败后、用户给出否定反馈时）。
  2. 反思提示词：设计专门的提示词，要求模型评估“当前计划是否可行”、“距离目标还有多远”、“最大的障碍是什么”、“是否需要调整策略”。
  3. 行动修正：根据反思的输出，系统可以决定是继续原计划、修改后续步骤、还是回溯到之前的某一步重新开始。
  4. 历史管理：反思的结论需要以某种形式（如作为一条特殊的“元观察”）加入到历史上下文中，指导后续行动。

回到我们最初的观点：ReAct不是算法，是工程契约。这份契约的价值在于，它为大模型这匹“想象力丰富但行为不羁的野马”，套上了可操控的“缰绳”（结构化输出）和可驰骋的“道路”（工具集）。理解这份契约的每一条款——为什么要有思考、行动为何要结构化、观察如何反馈——你就能在面试中游刃有余，更能在实际项目中设计出稳定、高效的智能体系统。真正的挑战不在于理解ReAct本身，而在于如何根据具体的业务场景，去设计那份最合适的“契约”，并准备好应对它可能失效的所有情况。这，才是从入门到精通的必经之路。