ReAct推理-行动模式：让AI从“想”到“做”的思维引擎

CH-11-05-004·约 30 分钟·AI应用开发·更新 2026-08-11

想象你是一位刚入职的实习生，老板给你布置了一项任务：“帮我安排下周的客户会议。”你不会坐在那里空想“会议应该怎么安排”，而是会先思考需要什么信息（会议室状态、客户时间、老板日程），然后打开日历系统查看，发现周三下午会议室被占了，于是改成周四上午，再发邮件确认，收到回复后记录结果——思考、行动、观察、再思考，如此循环，直到任务完成。这正是大名鼎鼎的 ReAct 推理-行动模式的本质。ReAct 是 “Reasoning + Acting“ 的缩写，它让大语言模型不再只是”想“（生成思维链）或只是”做“（直接输出答案），而是像这位实习生一样，在思考和行动之间来回切换，每一步行动都基于上一步的观察结果。这个模式是 AI Agent（智能体）的核心引擎，也是从”能聊天的AI“迈向”能干活的AI”的关键一跃。本教程将以这位实习生的成长故事为线索，带你彻底吃透ReAct的原理、设计与工程实践。

岗位关联

ReAct 模式是搭建 AI Agent 的基石。掌握它，你就能让大模型从“纸上谈兵”进化为“真刀真枪”解决问题——无论是写代码、查资料还是操作软件，这是 AI 工程化能力的分水岭。

可视化演示
概念本质
循环机制
提示设计
工具调用
对比分析
应用实践
性能评估
优化策略
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示ReAct推理-行动模式核心机制：Thought-Action-Observation循环演示模型交替推理与行动的过程；工具选择展示ReAct根据推理结果选择调用外部工具；多步推理链展示完整的推理决策路径。

本节配有交互动效（进入视口后自动加载，约 3KB）。

ReAct推理循环 Thought→Action→Observation Loop 模型交替推理与行动的循环过程

概念本质

我们的实习生小林第一天报到，主管递给他一本《工作手册》，上面写着三条铁律：先想清楚再动手、动手后要观察结果、根据结果调整下一步。小林发现，这三条铁律正好对应了 ReAct 模式的核心——推理（Reasoning）与行动（Acting）的协同。传统的大模型像一位“纸上谈兵的参谋”，你问它“明天天气适合爬山吗？”，它只能凭训练时的记忆回答，不会去查实时气象。而 ReAct 模式下的模型像小林一样，既会思考，又会动手查证。从技术上看，ReAct 将大模型的推理轨迹（Thought）与动作执行（Action）交替编织。模型不再一次性生成完整答案，而是生成一段“内心独白”（推理），然后决定调用某个工具或执行某个动作（行动），再从外部环境拿到反馈（观察），继续下一轮推理。这种交替执行范式让模型能够在复杂任务中动态调整策略，而不是一条道走到黑。ReAct 最精妙的地方在于“环境感知反馈”。小林安排会议时，查完日历发现周三满了，这个“观察”结果会直接影响他下一步的决策——改到周四。模型也是如此：每一次行动都会产生新的观察，这些观察是模型下一轮推理的重要输入。这打破了传统“一次性生成”的局限，让模型真正与环境产生交互。小林很快发现，这本工作手册就是他日后成为优秀员工的核心方法论。而大模型通过 ReAct，也走上了同样的成长路径——不再是那个只会空谈的参谋，而是一个能落地干活的执行者。

\text{ReAct} = \underbrace{\text{Thought}}_{\text{推理/思考}} + \underbrace{\text{Action}}_{\text{行动/工具调用}} + \underbrace{\text{Observation}}_{\text{观察/环境反馈}}

核心公式解读：ReAct 不是一次性的“提问→回答”，而是一个逐步展开的循环。每一步的思考都建立在前面所有思考、行动、观察的基础上，就像小林每做一个决定前，都会回顾之前查到的所有信息。这个公式告诉我们：历史轨迹就是模型的“工作记忆”，串联起整个任务链条。

Thought（推理）这是模型生成的“内心独白”，用于分析当前状态、规划下一步。就像小林接到任务后先盘算“我需要知道客户什么时候有空”。
$T_t = \text{LLM}(P, O_1, T_1, A_1, \ldots, O_{t-1})$
Action（行动）模型根据推理结论选择一个动作执行，比如调用搜索工具或执行代码。这对应小林打开日历系统查空档。
$A_t = \text{LLM}(P, O_1, T_1, A_1, \ldots, T_t)$
Observation（观察）执行动作后从环境获得反馈，作为下一轮思考的依据。这就是小林看到“周三会议室被占”这条信息。
$O_t = \text{Env}(A_t)$

循环机制

小林接到的第一个任务：协调一场三方会议。他先思考：“我需要查看三位参会者明天的空闲时间。”（思考）然后打开日程系统查询。（行动）系统返回：“张三 10:00-11:00 忙，李四全天有空，王五下午有空。”（观察）小林继续思考：“交集是明天下午 2 点到 4 点。”（思考）再次查证会议室资源……（行动）这个思考→行动→观察的循环，就是 ReAct 最核心的机制。

在技术实现上，这个循环由大模型自身驱动。模型每轮生成一个“思考片段”和“动作指令”，外部系统执行动作后返回观察结果，拼接到对话历史中，再送进模型进行下一轮推理。环境交互闭环意味着模型的每一步都建立在上一步真实反馈之上，而不是凭空想象。因为有了反馈，当行动失败或结果不符合预期时，模型有机会修正自己的思路。

循环需要终止条件。小林不会无限查日历，当他确认了一个所有人都有空的时间段并发出邀请后，任务就结束了。ReAct 同样如此：当模型判断任务已完成（比如生成“最终答案：会议安排在周四 14:00”），或者达到预设的最大迭代次数时，循环终止。终止条件的设计直接影响任务效率——条件太宽松会浪费计算资源，太严格则任务可能完不成。

循环机制让模型具备了“纠错能力”。小林在查日程时发现记错了参会人姓名，他会立即修正查询条件。传统模型一旦生成答案就无法回头，而 ReAct 模型在观察反馈的驱动下，能够及时发现错误并调整策略，这是它解决复杂长链路问题的根本保障。

\text{Loop: } T_t \rightarrow A_t \rightarrow O_t \rightarrow T_{t+1}, \quad \text{until } \exists t: A_t = \text{Finish}(\text{answer})

通俗说明：这个循环本质上就是一个“带反馈的工作流”。模型每走一步都看看周围环境，直到确信自己完成了任务。就像你第一次去陌生城市找一家餐厅：看地图（思考）、往前走（行动）、看到路标（观察）、再调整方向……直到看见餐厅招牌为止。

循环推进每一轮循环依次经历思考、行动、观察三个阶段，观察结果成为下一轮思考的输入。就像小林查完日程后，下一轮的思考一定基于刚查到的日程信息。
$T_t \rightarrow A_t \rightarrow O_t \rightarrow T_{t+1}$
终止判断模型在某一轮选择输出“Finish“动作并附上最终答案，循环随即停止。就像小林在确认各方时间后，发出会议邀请并报告主管”任务完成”。
$\exists t: A_t = \text{Finish}(\text{answer})$

提示设计

小林的工作手册里不仅有铁律，还有前辈留下的“优秀示范案例”：一个完整的任务记录，展示了思考、行动、观察每一步是怎么写的。ReAct 的提示设计（Prompt Design）也遵循同样的思路——少样本示范（Few-shot Examples）是引导模型进入“思考-行动”节奏的关键。就像你用案例教新人“报告应该这么写”，你在提示中给模型展示 2-3 个完整的 ReAct 轨迹示例，模型就会照着这个格式生成。

少样本示例的质量，直接影响模型能否正确进入循环节奏。一个标准的 ReAct 示例长这样：

格式约束是提示设计的第二根支柱。为了让模型输出可被程序解析，通常要求严格的字段格式：思考、行动、观察分别对应特定标识符。这就像工作手册里规定了表格填写的固定列——姓名、日期、事项——不能随便乱写。常见格式包括 JSON 块、XML 标签或 Markdown 标题风格。思维引导则是通过对示例中“思考”内容的设计，教会模型如何拆解问题、如何利用观察结果。比如在示例中展示“观察发现数据缺失，所以需要换个搜索关键词”这类元认知示范，模型就能学会类似的反思策略。

小林发现，前辈的示范案例并不是随手找的——每个示例都精心挑选了不同难度和类型的任务。ReAct 的少样本选择同样讲究：示例太少，模型学不会循环节奏；示例太多，浪费 token 且可能引入噪声。实践中的通用做法是选取覆盖任务多样性的 2-6 个示例，并在示例中自然展示错误修正过程，让模型模仿这种“从错误中学习”的行为。

\text{Prompt} = \underbrace{\text{Instruction}}_{\text{任务说明}} + \underbrace{\text{Examples}}_{\text{少样本轨迹}} + \underbrace{\text{Format Spec}}_{\text{输出格式约束}}

通俗说明：提示设计就像给新人一套“答题模板”。模板里既有精心挑选的例题（少样本），又有严格的版式要求（格式约束），还有解题思路示范（思维引导）。模型不需要被重新训练，只需要在模板的指引下“照葫芦画瓢”。

任务说明（Instruction）用一句话告知模型“你要通过'思考-行动-观察'循环来解决问题”。就像主管对小林说：“按工作手册的格式完成任务。”
$\text{Instruction: "You must interleave Thinking, Acting, and Observing."}$
少样本轨迹（Examples）展示 2-3 条完整的 ReAct 任务记录，让模型模仿其结构与节奏。这既教会了模型“怎么想”，也教会了“怎么写”。
$\text{Examples} = \{(q_1, T_1, A_1, O_1, \ldots, f_1), \ldots\}$
格式规格（Format Spec）明确规定每一步输出的结构（如文本模板或 JSON 结构），保证程序能稳定解析并执行行动字段。
$\text{Format Spec: } A_t \in \{\text{Search}(\cdot), \text{Lookup}(\cdot), \text{Finish}(\cdot)\}$

text6 行

问题：巴黎和伦敦之间距离多远？思考：我需要查询这两座城市之间的距离。行动：搜索("巴黎 伦敦 距离")观察：约 344 公里。思考：我可以直接回答。行动：Finish("约344公里")

工具调用

小林工作第三周，主管给他装了一套“数字化工具包”：日历系统、邮件客户端、公司知识库搜索栏。这些工具大幅提升了他的工作效率。ReAct 模型的工具调用（Tool Use）正是对应机制——模型不仅是“想”，还能呼唤外部工具来获取信息或执行操作。这些工具包括搜索引擎、计算器、数据库查询接口、代码解释器等，它们是模型与真实世界互动的“手脚”。

在实现层面，外部 API 接入是工具调用的基础。开发者将工具封装成函数，注册到模型的可用工具列表中。模型在生成“行动”字段时，会输出一个结构化的工具调用指令，比如 搜索(关键词) 或 计算(表达式)。系统解析这个指令后执行相应的 API 请求，将返回结果作为“观察”回传给模型。这就像小林在日历系统里输入查询条件，系统把结果显示给他。

计算器与搜索是 ReAct 最常见的两个工具，它们各有分工：搜索提供外部事实信息，弥补模型训练数据时效性的不足；计算器提供精确的数值运算，避免模型在数学计算上出错。结构化参数则保证工具调用的准确性——模型不仅需要决定“调用哪个工具”，还必须提供规范的参数，如搜索关键词、查询范围等。就像小林用日历系统时必须填对日期格式，否则系统会报错。

小林的数字化工具包里还有一份“工具使用说明书”，上面标注了每个工具的功能和适用场景。ReAct 的提示中同样需要向模型描述每个工具的功能、参数格式和使用示例，否则模型可能不知道“什么时候该用搜索，什么时候该用计算器”。工具描述写得越清晰，模型做出正确调用的概率越高，这也是 Agent 工程化中的重要调优环节。

\text{Tool} = (name, \text{params}, \text{output}), \quad A_t = \text{name}(\text{params}_t)

通俗说明：工具调用把模型从“闭卷考试”变成了“开卷考试”——模型不需要把所有知识都背在脑子里，遇到不确定的信息就翻书（搜索）、拿计算器按一按（计算）。这大大扩展了模型的能力边界。

动作格式模型输出的行动字段必须遵循结构化的工具调用语法，包含工具名和参数列表。这就像填写统一的工具申请单：工具名称、参数、预期产出。
$A_t = \text{ToolName}(arg_1, arg_2, \ldots)$
工具返回工具执行后的结果作为观察值回到循环中，格式通常为文本或结构化数据。就像日历系统返回“周三 14:00 会议室空闲”这样的查询结果。
$O_t = \text{Tool}(A_t).\text{output}$

对比分析

小林参加了部门组织的“工作方法分享会”，发现其他同事有不同的工作风格。有位同事老张习惯“先全盘规划再集中执行”——把任务拆成详细步骤清单，然后一步步照做，这就是 Plan-and-Execute 模式；还有位同事老李“只顾埋头推演”——从不查证资料，全靠脑内模拟，这就是纯 CoT（思维链）。小林对比之后发现，自己的工作方法既有规划又有实时调整，正是 ReAct 的独特优势。

CoT 纯推理的局限在于“闭门造车”：老李推算会议安排时，不知道会议室已经被占了，他的推理再缜密也是空中楼阁。纯 CoT 模型无法获取外部信息，面对需要实时数据或工具操作的任务（如查天气、订机票）时无能为力。规划执行分离的 Plan-and-Execute 虽好，但它是“一次性规划”——如果规划基于的前提在过程中发生变化（比如客户临时取消会议），整个计划就会失效，必须从头重新规划。

ReAct 的思路是“走一步看一步”：不提前制定严格的全盘计划，而是在每一轮根据最新观察动态决策。这样既保留了推理的条理性（每一步都经过思考），又获得了行动反馈的纠偏能力。动态调整优势让模型在环境发生意外变化时能灵活应对——就像小林发现周三会议室被占后，立刻调整预案，改查周四的空档。

分享会结束后，小林意识到 ReAct 并非在所有场景都最优。如果任务非常直接（比如简单问答），直接回答比反复循环更高效；如果需要严格的全局优化（比如物流路线规划），Plan-and-Execute 可能更合适。ReAct 的最大价值在于面对需要交互和反馈的复杂任务时，它提供了一种灵活而稳健的解决方案。

\text{CoT: } P(y \mid x) = \text{LLM}(x, T_1, T_2, \ldots) \quad \text{（无外部反馈）}

\text{ReAct: } P(y \mid x) = \text{LLM}(x, T_1, A_1, O_1, T_2, \ldots) \quad \text{（带外部反馈）}

通俗说明：把 CoT 理解成“闭卷写论文”——全凭记忆和逻辑推演；ReAct 则是“开卷做课题”——随时可以查文献、做实验，实验结果反过来修正你的论证。ReAct 的条件概率公式里多出的“观察”项，就是这个“查文献做实验”的信息通道。

CoT 的条件概率CoT 生成答案时只依赖输入和内部推理链，推理链每个节点都是模型“想”出来的，没有来自外部世界的验证。
$P_{\text{CoT}}(y \mid x) = \prod_t P(T_t \mid x, T_{<t})$
ReAct 的条件概率每一步推理的条件不仅包括之前的思考，还包括行动后的观察结果。观察把外部世界的信息注入模型的条件分布。
$P_{\text{ReAct}}(y \mid x) = \prod_t P(T_t, A_t \mid x, T_{<t}, A_{<t}, O_{<t})$

应用实践

三个月后，小林因为高效的工作表现被调入了“智能客服项目组”。这个项目的目标，是让 AI 客服不再只会背诵 FAQ，而是能像真人一样主动查订单、退换货、给出个性化建议。这正是 ReAct 模式的经典应用舞台。

第一个核心应用是智能 Agent（智能体）。在这个场景中，AI 客服收到用户消息“我的快递怎么还没到？”，它先思考：“用户需要查询物流状态，我需要订单号和物流公司的查询接口。”然后行动：调用订单查询工具，拿到物流信息，观察发现“包裹已到本地配送站”，再推理“可以告知用户预计明天送达”。整个过程中，AI 不是一次性给出回答，而是像小林一样一步步查证，确保信息的准确性。大模型在这里是“大脑”，工具是“手脚”，ReAct 则是连接两者的“神经回路”。

第二个应用场景是代码生成与调试。开发者用 ReAct 模式驱动 AI 编写代码：模型先生成一段代码（行动），运行它（工具调用），观察报错信息（观察），再推理修复方案（思考），生成修正后的代码（行动）……如此循环直到代码通过测试。这种“生成-运行-调试”的循环极大提升了编程助手处理复杂编码任务的能力，因为它不依赖模型一次写对，而是让它像程序员一样在错误反馈中迭代改进。

第三个典型应用是信息检索问答。当用户询问“今年诺贝尔物理学奖得主是谁？”这种依赖实时信息的问题时，ReAct 模型先搜索最新新闻，读取相关页面内容，提取答案，再回答用户。相比纯参数记忆的模型，它给出的事实更准确，还能附上信息来源，做到有据可查。这就像小林接到主管问“客户公司最近的动态”，他不会凭模糊记忆回答，而是先去查客户官网和新闻。

小林发现，在实际部署中，ReAct Agent 还面临着许多工程挑战：工具调用的延迟、错误处理的健壮性、成本控制、安全边界……这些都需要在系统设计时仔细权衡。但正是 ReAct 提供的这种“可交互、可验证、可迭代”的框架，让这些工程问题有了统一的解决方案，推动了 AI 从“对话玩具”向“生产力工具”的演进。

\text{Agent} = \underbrace{\text{LLM}}_{\text{决策大脑}} + \underbrace{\text{Tool Set}}_{\text{外部工具}} + \underbrace{\text{ReAct Loop}}_{\text{循环机制}}

通俗说明：这个公式把 AI Agent 的架构拆成了三个积木块：大脑（LLM）负责想，手脚（工具）负责做，而 ReAct 循环是让“想”和“做”无缝衔接的传动轴。没有这个轴，大脑再聪明也不知道如何动手操作真实世界。

决策大脑大语言模型扮演 Agent 的推理核心，负责理解用户意图、决定下一步动作。就像小林是客服项目的“负责人”，所有关键决策都由他的判断力完成。
$\text{LLM}: \text{state} \rightarrow \text{action}$
外部工具一组预定义的 API 或函数，供模型调用以获取信息或执行操作。这些工具是 Agent 与外部世界交互的接口。
$\text{Tools} = \{f_1, f_2, \ldots, f_n\}, \quad f_i: \text{params} \rightarrow \text{result}$
循环机制ReAct 循环将行动产生的观察结果反馈回模型，驱动下一轮决策，直到任务完成。这是 Agent 能够持续工作直到成功的关键引擎。
$\text{Loop}: S_t \xrightarrow{\text{LLM}} A_t \xrightarrow{\text{Tool}} O_t \rightarrow S_{t+1}$

性能评估

半年后的项目复盘会上，小林需要向管理层汇报“新客服系统比老系统好在哪里”。他准备了三个维度的数据：响应准确率、可解释性、多任务适应性。巧合的是，学术评估 ReAct 模型同样从这几个维度入手。

推理可解释性是 ReAct 最突出的优势。传统模型给出一个答案，你不知道它怎么得出的；ReAct 把完整的思考轨迹、行动记录、观察结果都摊开在面前。就像小林每次安排会议后都会留存完整的处理日志：查了什么、发现什么、为什么改期，一目了然。这种透明的决策过程让 AI 系统更容易被信任和调试——当回答出错时，审查思考轨迹即可定位问题出在哪个环节。

事实一致性方面，ReAct 因为引入了外部工具的验证，明显优于纯参数的模型。它不需要“背”答案，而是调用实时数据来支撑回答，因此大幅减少了幻觉（Hallucination）现象。但评估也发现，ReAct 的事实一致性高度依赖工具返回的信息质量和模型对观察结果的理解能力——如果工具返回了误导性信息，模型同样可能出错，就像小林如果依赖过时的日程系统，也会做出错误的安排。

多任务泛化是 ReAct 的另一张王牌。同一个 ReAct 框架只需更换工具集和少样本示例，就能适应问答、检索、决策、代码生成等多种任务。这种通用性让 ReAct 成为构建通用 Agent 的基础范式。然而，它的泛化能力并非无限——对于训练数据中极少出现的长尾任务，模型的推理轨迹可能不稳定，需要针对性地加入领域示例。

小林在报告中写道，ReAct 模型像一个“认真负责但需要好工具和好流程”的员工。它的表现不仅取决于模型本身的智力，还取决于工具质量、示例设计、错误处理机制等系统因素。性能评估因此需要从“模型能力”和“系统设计”两个层面综合考量，这也引出了下文的优化策略。

\text{Acc}_{\text{ReAct}} = \underbrace{\text{Acc}_{\text{Reasoning}}}_{\text{推理质量}} + \underbrace{\Delta_{\text{Tool}}}_{\text{工具增益}} - \underbrace{C_{\text{Error}}}_{\text{错误传播成本}}

通俗说明：这个公式像是在计算“带导航出行”的到达率——你的驾驶技术带来基础成功率（推理质量），实时路况导航进一步提升成功率（工具增益），但如果你把导航看错了（错误传播），反而可能绕远路。ReAct 的性能不是白来的，它需要你正确使用反馈信息。

推理质量ReAct 的准确率基础来自模型本身的推理能力，即“想得对不对”。这与 CoT 的推理能力同源。
$\text{Acc}_{\text{Reasoning}} = P(\text{correct final} \mid \text{correct thoughts})$
工具增益外部工具提供的信息和验证为准确率带来的提升。这是相对纯推理模型的增量价值。
$\Delta_{\text{Tool}} = P(\text{correct} \mid \text{tool output}) - P(\text{correct} \mid \text{no tool})$
错误传播成本推理或行动环节引入的错误会沿循环传播，导致后续步骤全部偏离方向。
$C_{\text{Error}} = P(\text{wrong action} \mid \text{wrong observation}) \times \frac{1}{1 - \gamma}$

优化策略

复盘会上，管理层问小林的最后一个问题是：“新系统还有哪些可以改进的地方？”小林打开笔记本，列出了三条：优化示例、加入容错机制、强化格式约束。这三条也是 ReAct 工程优化的关键路径。

少样本调优是投入产出比最高的策略。ReAct 的表现高度依赖示例轨迹的质量——示例不仅要展示完成任务的全过程，还应覆盖常见的错误场景和修正策略。小林的做法是收集真实客服对话中表现好的案例，人工清洗后作为少样本示例。在技术上，这相当于为模型提供“高质量的行为标杆”，让它学会模仿优秀的思考与行动模式。调优时还要注意示例的多样性：如果所有示例都是“查订单”的流程，模型面对“退换货”请求时就会手足无措。

错误恢复机制解决的是“出了岔子怎么办”的问题。ReAct 循环的常见故障包括：模型输出了非法格式的行动、工具调用超时、观察结果为空等。小林在客服系统中设计了“重试、切换、上报”三级容错：非法格式就重新生成一次；工具超时就改调备用接口；连续失败则转人工客服。技术上的错误恢复包括解析器纠错、异常捕获、自动重试、降级策略等手段，目标是把错误的影响限制在最小范围，防止错误沿循环无限传播。

格式强化是提高系统鲁棒性的基础工作。为了让模型输出更稳定的结构化动作，工程师常采用三种手段：一是设计严格的输出模板（如 JSON Schema）；二是使用语法约束解码（如结构化生成工具）；三是在提示中明确标注“不要输出任何多余文字”。这就像工作手册中规定“所有申请必须用标准表格填写，不接受手写便签”——把流程标准化，才能让自动化系统可靠地运转。

小林最终把这些优化策略落到了实处，客服系统的解决率提升了 23%。他的经验说明：ReAct 模式并不是“开箱即用”的银弹，而是需要精心调校的系统工程。从示例的选择、容错的设计到格式的约束，每一环都直接影响最终效果。掌握这些优化策略，是 AI 工程师从“能跑通 Demo”进阶到“能上线产品”的必修课。

---

\text{Optimization} = \underbrace{\text{Better Examples}}_{\text{更优示范}} + \underbrace{\text{Fault Tolerance}}_{\text{容错机制}} + \underbrace{\text{Strict Format}}_{\text{严格格式}}

通俗说明：优化策略就像给员工系统性地配置“能力提升方案”——换更好的培训材料（示例调优）、建立应急预案（错误恢复）、制定标准化流程（格式强化）。三者缺一不可：没有好示例，员工不知道怎么做；没有应急预案，一出错就停摆；没有标准化，协作效率必然低下。

更优示范通过人工筛选或算法搜索，选择信息更丰富、步骤更合理的少样本轨迹，提升模型的模仿质量。
$\text{Examples}^* = \arg\max_{\text{Examples}} \text{Validity}(\text{Examples})$
容错机制设计异常处理路径。当某一轮行动失败时，系统能自动恢复或给出合理降级。
$\text{Policy}_{\text{fault}} = \begin{cases} \text{retry}, & \text{transient error} \\ \text{switch tool}, & \text{persistent error} \\ \text{escalate}, & \text{max retries exceeded} \end{cases}$
严格格式用约束解码或模板校验保证模型输出的行动指令合法可执行。
$\text{Action}_t \in \mathcal{V}_{\text{valid}} = \text{Schema}(\text{Tools})$

AI 应用场景

智能客服助手

阶段：应用实践（Agent 构建与工具调用）

解决的问题：传统客服机器人只能基于预设问答库回复，遇到“我的订单什么时候到”这类需要查询实时数据的问题就无能为力，用户体验差且转人工率高。基于 ReAct 的客服助手能够自主完成“理解问题→调用订单查询接口→分析物流状态→生成个性化回答”的完整链路，大幅提升问题解决率和用户满意度。

具体案例：某电商平台部署了基于 ReAct 的智能客服。用户询问“我买的内存条兼容我的笔记本电脑吗？”客服 Agent 先调用订单接口获取商品型号，再调用知识库检索该笔记本的主板规格，将两者数据对比后给出结论：“型号匹配，可以兼容。需要确认你的笔记本具体型号后再查一次吗？”整个推理过程有轨迹可循，用户可随时要求人工介入。

AI 编程助手

阶段：应用实践（代码生成与调试）

解决的问题：大模型单独生成代码时经常产生语法错误或逻辑不匹配，开发者需要反复手动调试。ReAct 模式让 AI 编程助手具备“写代码→运行→看报错→改代码”的自主迭代能力，把 AI 从“代码生成器”升级为“自动驾驶的结对程序员”。

具体案例：GitHub Copilot 等工具在高级模式中采用了类似 ReAct 的思路。开发者下达“写一个 Python 函数解析这个 CSV 文件”的指令后，助手生成代码并自动在沙箱环境执行，如果遇到 KeyError 异常，它会读取错误信息，推理出“CSV 的列名可能包含空格”，然后自动加上预处理逻辑，重新运行直到通过测试用例，最后向开发者展示完整的解决过程。

企业知识库问答

阶段：工具调用（外部 API + 搜索）

解决的问题：企业内部知识库文档分散、格式多样，员工很难快速找到所需信息。传统问答模型要么无法访问内部系统，要么检索结果不准确。ReAct 模式通过工具调用将 LLM 与内部知识库 API 对接，把“提问→检索→阅读→整合→回答”做成一个完整循环，保证答案既有据可查又能自然表达。

具体案例：某咨询公司部署了基于 ReAct 的内部知识问答系统。员工询问“去年 Q3 汽车行业报告的核心结论是什么？”Agent 先调用文件搜索工具定位相关报告，再调用文档解析工具抽取关键段落，观察到报告提到“新能源渗透率突破 40%”，结合问题意图组织成简洁回答，并附上报告出处。员工还能追问细节，Agent 会再次检索细化回答。

Python 演示

python83 行

import re  def get_current_time():    return "2024-01-15 14:30:00"  def calculate(expression):    expr = expression.strip()    expr = expr.replace("^", "**")    try:        return str(eval(expr))    except Exception as e:        return f"Error: {e}"  TOOLS = {    "时间查询": {"desc": "获取当前时间", "func": get_current_time, "params": []},    "计算器": {"desc": "计算数学表达式，例如 2+3*4", "func": calculate, "params": ["expression"]},}  def parse_action(text):    match = re.search(r"行动:\s*(\w+)\s*(?:\((.*?)\))?", text)    if not match:        return None    tool_name = match.group(1)    arg = match.group(2) or ""    if tool_name not in TOOLS:        print(f"  [系统] 未知工具: {tool_name}")        return None    param = arg.strip()    if TOOLS[tool_name]["params"] == []:        result = TOOLS[tool_name]["func"]()    else:        result = TOOLS[tool_name]["func"](param)    return f"观察: {result}"  def react_agent(question, max_steps=5):    print("=" * 50)    print(f"问题: {question}")    print("=" * 50)    thought_templates = [        f"思考: 我需要解决这个问题: {question}。让我先分析可用工具。",        "思考: 根据观察结果，我知道可以使用计算器来帮助我。",    ]    action_templates = [        "行动: 时间查询()",        "行动: 计算器(3.14159 * 2)",    ]    history = ""    for step in range(max_steps):        print(f"\n--- 第 {step + 1} 轮 ---")        if step < len(thought_templates):            thought = thought_templates[step]        else:            thought = "思考: 任务似乎已接近完成。"        print(thought)        history += thought + "\n"        if step == 0:            action = "行动: 时间查询()"        elif step == 1:            action = "行动: 计算器(3.14159 * 2)"        else:            action = f"行动: 完成({question})"        print(action)        history += action + "\n"        observation = parse_action(action)        if observation is None:            print("  [系统] 无法解析行动，终止。")            break        print(observation)        history += observation + "\n"        if "完成" in action:            print("\n任务完成！")            break    return history  if __name__ == "__main__":    q = "当前时间是什么？再帮我计算圆周率乘以2的结果。"    react_agent(q)

目的：演示 ReAct 模式的完整循环骨架——模型（此处用模板模拟）交替输出推理和行动，系统解析行动指令并调用工具，观察结果反馈回循环。

TOOLS = {...}定义工具清单，每个工具包含描述、执行函数和参数规格。这就像小林的“数字化工具包”，模型只能调用注册过的工具。
parse_action(text)从模型输出中提取“行动”字段，识别工具名和参数。这是格式约束的落地实现，对应正文中强调的“结构化参数”。
thought_templates模拟模型的思考轨迹。实际使用时这里是大模型的生成结果，本例用模板代替以便独立运行演示。
observation = parse_action(action)执行工具后获得观察结果，打印并加入历史记录。这一步完成了“行动→观察”的闭环。
history += thought + "\n"维护完整的推理轨迹历史。真实系统中这个历史会作为下一轮模型输入的上下文，对应公式中的 $T_{<t}, A_{<t}, O_{<t}$。

常见误区

误区我理解了，ReAct 就是让模型多回答几轮嘛，本质上和我们平时和 ChatGPT 来回对话是一样的，没有本质区别。

正解这是最常见的误解之一。多轮对话只是用户和模型之间的自然语言交互，每一步由用户主动发起，模型是被动响应。而 ReAct 的循环是模型内部自主驱动的一轮轮“思考→行动→观察”过程，模型的每一步行动都是自己决策的，不需要用户干预。就像小林安排会议时，他不会每查一次日历就回头问主管“接下来怎么办”，而是自己根据查到的信息决定下一步行动。ReAct 强调自主性和工具交互，多轮对话则缺少这种“自我驱动闭环”。

为何常见：因为 ReAct 的输出结构和多轮对话在形式上有点相似（都是序列生成），初学者容易从形式类比，忽略了内部的自主决策机制差异。

误区ReAct 模式让模型自己思考行动，那我不需要精心设计提示了，只要把问题丢给模型，它自己会循环处理。

正解恰恰相反，ReAct 的性能高度依赖提示质量。少样本示例的选取、格式约束的设置、工具描述的清晰度，都直接影响模型能否进入正确的循环节奏。如果提示里只是简单写“请通过思考行动观察来回答问题”，模型很可能完全不知道如何调用工具、输出什么格式。就像你给小林一本只有三条原则、没有任何示例的行为手册，他能安排会议，但流程可能很混乱。实践证明，精心设计的 ReAct 提示可以显著提升任务成功率，而不加设计的 ReAct 常常退化成了 CoT。

为何常见：ReAct 的“自主性”让人误以为模型已学会一切，低估了提示工程在这个范式中起到的关键引导作用。

误区ReAct 就是让大模型调用外部 API 嘛，核心价值在于工具接入，推理部分没那么重要。

正解工具调用只是 ReAct 的一个环节，推理（Thought）才是驱动循环的灵魂。模型需要推理来决定“该调用哪个工具、参数是什么、如何解读观察结果、下一步怎么办”——没有高质量的推理，工具调用就是盲目的乱点。就像给小林装了一整套高端工具，但如果没有思考能力，他不知道什么时候该用哪个工具、查到的信息意味着什么。学术实验也表明，移除 ReAct 中的推理轨迹后，其成功率大幅下降，证明推理和行动是相辅相成、缺一不可的。

为何常见：工程实践中工具调用的代码实现比较显式（看得见摸得着），而推理轨迹是隐形的文本生成，容易被低估。

误区ReAct 是最先进的智能体方案，所有 Agent 都应该用 ReAct，其他模式都是过时的。

正解ReAct 并不是万能的。在需要全局优化的场景（如物流路径规划），Plan-and-Execute 的一次性规划能力更合适；在简单直接的任务上，ReAct 的循环反而增加延迟和 token 成本；在涉及严格安全性的操作中，完全自主的 ReAct 循环可能带来风险。工程师需要根据任务特性选择范式，甚至将 ReAct 与其他机制结合——先规划后执行，执行中穿插 ReAct 式反馈修正。就像小林既会按周计划工作（规划），也会在执行中灵活调整（ReAct），两种方式各有用武之地。

为何常见：业界对 ReAct 的广泛宣传容易让人产生“一招鲜吃遍天”的错觉，忽略了算法选型必须贴合具体场景的基本工程原则。

面试题

Q1. ReAct 中的“R“和”A”分别代表什么？

单选题 · easy

A.检索与聚合（Retrieval and Aggregation）
B.推理与行动（Reasoning and Acting）← 正确答案
C.递归与自动（Recursion and Automatic）
D.规则与算法（Rule and Algorithm）

答案：B。ReAct 是 Reasoning（推理）+ Acting（行动）的缩写，核心思想是让模型交替进行推理与工具操作。选项 A 的“检索与聚合”是 RAG 中的概念，选项 C 和 D 属于干扰项，与 ReAct 无关。

Q2. 在 ReAct 循环中，“观察”（Observation）指的是什么？

单选题 · easy

A.模型重新阅读用户的原始问题
B.模型内部生成的反思文本
C.执行行动后从外部环境获得的反馈← 正确答案
D.用户对模型输出的评价

答案：C。观察是 ReAct 循环中至关重要的一环，指模型执行行动（如调用工具）后，从外部环境拿到的结果信息。这就像小林查了日历后看到的“周三会议室已满”。选项 A 和 D 中的“用户输入”不属于环境反馈，选项 B 的“反思文本”属于思考而非观察。

Q3. 以下哪个是 ReAct 中“思考”（Thought）的核心作用？

单选题 · mid

A.直接输出最终答案
B.决定下一步行动并推断观察结果的含义← 正确答案
C.存储训练数据中的知识
D.将用户的输入翻译成工具参数

答案：B。思考是模型生成的推理轨迹，它分析当前状态、规划下一步行动，并解读观察结果的含义。比如小林看到“周三被占”后思考“应该改到周四”。选项 A 是最终动作而非思考，选项 C 是模型参数的功能，选项 D 只是工具调用中的一部分能力，都不够全面。

Q4. 相比纯 CoT（思维链）模式，ReAct 的主要优势有哪些？

多选题 · mid

A.能够获取外部实时信息← 正确答案
B.决策过程可验证、可解释← 正确答案
C.完全消除模型的幻觉问题
D.可以通过工具验证来修正错误← 正确答案

答案：ABD。ReAct 的行动（如搜索）让模型能获取 CoT 无法获得的实时信息，选项 A 正确；思考轨迹+观察结果的记录让决策可追溯、可解释，选项 B 正确；工具验证确实能降低幻觉率，但“完全消除”是绝对化表述，选项 C 错误；观察反馈能帮助模型发现并修正推理中的错误，选项 D 正确。

Q5. 在 ReAct 提示设计中，少样本示例的主要作用是什么？

单选题 · mid

A.增加模型参数量
B.教会模型思考-行动-观察的循环节奏和输出格式← 正确答案
C.减少模型的推理延迟
D.替代外部工具的功能

答案：B。少样本示例为模型提供了模仿的“行为标杆”，展示了一个完整的 ReAct 轨迹该怎么写——思考怎么表达、行动用什么格式、观察如何被利用。选项 A 与提示无关，选项 C 延迟主要受模型自身影响，选项 D 示例无法替代工具的真实功能。

Q6. 当 ReAct 模型连续多轮循环仍未完成任务时，最合理的处理方式是什么？

单选题 · mid

A.让模型无限循环直到完成
B.设置最大迭代步数并触发终止或降级← 正确答案
C.直接返回模型最后一次的思考内容
D.清空历史记录重新开始

答案：B。工程实践中必须设置最大迭代步数（如 10 步），防止模型陷入死循环消耗资源和时间。达到上限后应给出合理回复、转人工或降级处理。选项 A 会造成资源浪费，选项 C 缺少最终答案，选项 D 丢失了已有进度，都不是合理策略。

Q7. ReAct 的错误恢复机制通常包括哪些手段？

多选题 · hard

A.对非法格式的模型输出进行重试← 正确答案
B.工具超时后切换到备用接口← 正确答案
C.连续失败后上报或转人工← 正确答案
D.禁止模型再次调用工具

答案：ABC。错误恢复是 ReAct 工程落地的关键。重试机制处理格式非法或瞬时错误，选项 A 正确；切换备用接口应对工具不可用，选项 B 正确；逐级升级（escalation）防止问题无限积压，选项 C 正确；选项 D“禁止调用工具”等于废除了 ReAct 的行动能力，是不可取的。

Q8. ReAct 在解决哪类问题时最有可能优于 Plan-and-Execute？

单选题 · hard

A.需要严格全局最优解的线性规划问题
B.环境信息动态变化、需要实时反馈调整的任务← 正确答案
C.单个即可完成的事实性问答
D.不需要任何外部工具的纯语法分析

答案：B。ReAct 的“走一步看一步”特性使其在动态环境中优势明显，当下一步行动需依赖上一步产生的新信息时，ReAct 的观察反馈循环比一次性规划更稳健。选项 A 更适合 Plan-and-Execute 的全局规划；选项 C 和 D 的简单任务用 ReAct 反而增加不必要的循环开销。

Q9. 为了让 ReAct 模型稳定输出可执行的工具调用，提示工程中可以采用哪些手段？

多选题 · hard

A.提供结构化的工具描述和调用示例← 正确答案
B.定义严格的输出格式模板（如 JSON）← 正确答案
C.使用语法约束解码确保输出合法← 正确答案
D.提示模型“想清楚再说”但不限制格式

答案：ABC。工具描述与示例让模型知道工具的存在和用途，选项 A 正确；格式模板定义了标准输出结构，方便程序解析，选项 B 正确；约束解码在生成时直接过滤非法动作，选项 C 正确。选项 D 不加格式约束会导致模型自由发挥，实际工程中难以可靠解析。

Q10. 在 ReAct 框架中，"Finish"动作的作用是什么？

单选题 · easy

A.结束循环并输出最终答案← 正确答案
B.暂停模型并等待用户指示
C.清空工具的缓存数据
D.重新开始一轮新的循环

答案：A。Finish 是 ReAct 循环的终止动作，模型完成推理和验证后输出该动作并附带最终答案。就像小林查完全部信息后向主管报告“会议已安排在周四”。选项 B“等待用户”破坏了自主性，选项 C 与循环无关，选项 D 重启循环会让任务永远无法结束。