如果你用过那些”能自己查资料、自己调工具”的 AI 助手，可能会好奇：它到底是怎么决定下一步该做什么的？答案往往和一个叫 ReAct 的范式有关。ReAct 的思路朴素但有效——让模型别一口气往下编，而是像人一样，想一步、做一步、看结果、再想下一步。
ReAct 是什么
ReAct 是 “Reasoning + Acting” 的缩写，中文可以理解为”推理与行动协同”。它来自 2022 年的一篇论文《ReAct: Synergizing Reasoning and Acting in Language Models》（作者 Shunyu Yao 等人，普林斯顿大学与 Google Research，发表于 ICLR 2023）。论文的核心主张是：让大语言模型交替生成两类内容——推理轨迹（reasoning traces）和任务相关的行动（actions），两者相互配合，而不是各干各的。
具体来说，模型在处理一个任务时，会先输出一段”思考”（比如”我需要先查一下这家公司的营收，然后再计算增长率”），接着调用一个外部工具（比如搜索、计算器、数据库查询），拿到观察结果（observation），再基于这个结果继续推理和行动。这样一个”思考 → 行动 → 观察 → 思考……”的循环，就是 ReAct 的核心。
它要解决什么问题
在 ReAct 之前，让大模型”动脑”和让大模型”动手”是两条相对独立的路线。
一条是推理路线，代表是思维链（Chain-of-Thought，CoT）。CoT 让模型在给出答案前先展开一步步推理过程，显著提升了数学、逻辑、常识推理这类任务的准确率。但 CoT 有个明显短板：它完全靠模型自己的”内化知识”来推理，没法访问外部信息。一旦模型的知识过时、或者题目里的信息它没见过，推理链条就会建立在错误的前提上，最终”一本正经地胡说八道”。
另一条是行动路线，让模型调用外部工具、和真实环境交互。这条路线能拿到实时、准确的信息，但缺乏推理的引导，动作往往零散、没有计划性。
ReAct 的洞察在于：这两件事应该结合起来。推理帮助模型制定计划、理解哪些信息还缺；行动则负责去真实世界把缺的信息找回来，或者执行某个操作。推理让行动有方向，行动让推理有事实依据。两者协同，比单打独斗都要好。
一个直观的例子
假设你问模型：”Apple 公司的 CEO 和微软的 CEO，谁的年纪更大？”一个纯 CoT 的模型可能基于记忆直接推理，但如果它记错了某位 CEO 的出生年份，答案就错了。而 ReAct 模型的处理方式是：
- 思考：我需要知道 Apple CEO 和微软 CEO 分别是谁、出生年份是多少。
- 行动：调用搜索工具，搜”Apple CEO”。
- 观察：搜索返回 Tim Cook。
- 思考：再查 Tim Cook 的出生年份，以及微软 CEO。
- 行动：搜索”Tim Cook 出生年份”、”微软 CEO 出生年份”。
- 观察：得到两个年份。
- 思考：对比两个年份，得出谁年纪更大。
- 回答：给出结论。
这个过程里，每一步行动都建立在前面推理的基础上，每一步推理都得到了真实观察的修正。这就是”推理与行动协同”的直观体现。
ReAct 和 CoT、纯行动范式有什么不同
理解 ReAct，最好的方式是对比它和另外两种范式的差异。
纯 CoT（只推理）：模型只输出推理过程，不碰外部世界。优点是简单、不需要工具，适合封闭域内的数学和逻辑题；缺点是无法获取外部事实，容易”幻觉”，且推理过程无法被外部信息纠正。
纯 Act（只行动）：模型只输出动作，不做显式推理。优点是能直接和环境交互；缺点是缺乏规划，面对需要多步决策的任务容易”瞎试”，效率低。
ReAct（推理 + 行动）：两者交替。优点是既能规划又能获取事实，推理和行动相互修正，在需要外部知识、多步决策的任务上表现更好；缺点是提示词设计更复杂，调用工具的链路更长，成本也更高。
论文里的实验也印证了这一点：在 HotpotQA（多跳问答）和 FEVER（事实验证）这类需要外部知识或事实验证的任务上，ReAct 明显优于纯推理或纯行动。而在纯数学推理这类不需要外部信息的任务上，纯 CoT 反而可能更简洁高效。这提醒我们：没有放之四海而皆准的范式，选哪种取决于任务需不需要”和外部世界交互”。
怎么在提示词里实现 ReAct
实现 ReAct 的关键，是让模型学会交替输出”思考”和”行动”。最直接的方式是 few-shot（少样本）提示——在提示词里给出几个完整的”思考 → 行动 → 观察”范例，让模型照着这个格式来。
一个典型的 ReAct 提示词会先定义清楚：哪些行动可用（比如 search、lookup、calculate、finish），每个行动的参数格式，以及输出的结构。模型看到范例后，就会在需要的时候输出类似这样的内容：
Thought: 需要先搜索目标信息。 Action: search[目标问题] Observation: （工具返回的结果） Thought: 基于结果继续判断……
为了让模型”停止行动、给出最终答案”，通常会约定一个特殊的结束动作（如 finish[答案]）。此外，还需要一个执行层——当模型输出一个 Action 时，程序去真正调用对应的工具，把结果作为 Observation 喂回给模型，形成闭环。这也是为什么 ReAct 后来成为 AI Agent 的核心范式之一：它天然就是一个”模型 + 工具”的循环。
ReAct 与今天的大模型
ReAct 提出的 2022 年，让模型自己规划并调用工具还是一件需要精心设计提示词的事。到了今天，情况已经发生了很大变化。
一方面，主流大模型普遍内置了工具调用（function calling / tool use）能力——模型不再需要靠提示词来”扮演”行动输出，而是能通过结构化的接口直接声明要调用哪个函数、传什么参数。很多现代 Agent 框架（如 LangChain 的 create_agent、LangGraph 的 create_react_agent）底层仍然是 ReAct 这套”推理 → 行动 → 观察”的循环，只是把”行动”从文本格式升级成了结构化的函数调用。
另一方面，”推理”这一环也被做得更强。像 o1、DeepSeek-R1 这类推理模型，会在内部进行长时间的隐性思考，再结合工具调用，形成更强大的”思考 + 行动”组合。可以说，ReAct 的核心思想——推理和行动要协同——不但没有过时，反而被后来的 Agent、推理模型发扬光大了。
论文里的实验：ReAct 到底好在哪里
ReAct 论文在几个基准上做了系统的消融和对比，结果很能说明问题。
在 HotpotQA（多跳问答）和 FEVER（事实验证）这两个任务上，ReAct 的表现明显优于纯推理（CoT）和纯行动（Act-only）的基线。原因不难理解：这两个任务都需要”查证外部事实”，纯推理只能靠模型内化知识（容易错），纯行动则缺乏规划（效率低）。ReAct 把两者结合，既能有计划地检索，又能用检索到的事实修正推理，自然表现更好。
有意思的是，在 ALFWorld（一个需要多步决策的文本环境任务）上，ReAct 同样显著领先——它比纯 Act-only 的成功率高出不少。这说明”边想边做”在需要长期规划、多步行动的场景里，优势尤其突出。
但论文也诚实指出了 ReAct 的边界：在纯数学推理这类不需要外部信息的任务上，纯 CoT 反而可能更简洁、更高效。因为此时引入工具调用徒增开销，却带不来信息增益。这个结论提醒我们，ReAct 不是万能药，它的价值在”需要和外部世界交互”的任务上才真正兑现。
一个完整的 ReAct 提示词范例
为了更直观，这里给一个简化版的 ReAct few-shot 提示词结构（省略具体工具实现）：
你是一个能用工具回答问题助手。可用的行动有： - search[关键词]：搜索相关信息 - lookup[字符串]：在上一段文字里查找 - finish[答案]：给出最终答案 示例： 问题：某某公司是哪一年成立的？ Thought: 我需要查一下这家公司的成立年份。 Action: search[某某公司 成立年份] Observation: 该公司成立于 1998 年。 Thought: 我已经得到了成立年份。 Action: finish[1998 年] （下面是真正的任务） 问题：（用户的实际问题）
模型看到这个范例后，就会学着”思考一步、行动一步、观察反馈、再思考”地往下走。实际工程里，这个循环由程序驱动：模型输出 Action 时，程序去调用真正的搜索、数据库或 API，把结果作为 Observation 拼回对话，再让模型继续。这个”模型负责想、程序负责做”的分工，正是后来所有 Agent 框架的雏形。
ReAct 的局限与挑战
ReAct 不是没有代价，实际使用时有几个明显的问题需要正视。
- 错误可能被放大：如果模型在某一步检索到了错误信息，或者工具返回了无关结果，后续推理可能沿着错误方向越走越远。ReAct 的”观察”环节并没有内置纠错能力，错误一旦进入链条，就可能被当成事实继续用。
- 成本与延迟更高：每一步”思考 + 行动 + 观察”都是一次模型调用，多步任务会显著增加 token 消耗和响应延迟。对延迟敏感的场景，这是个不小的负担。
- 容易陷入无效循环：模型可能反复调用工具却得不到有用信息，陷入”查了又查”的死循环。工程上通常需要加”最大步数限制”来兜底。
- 依赖工具质量：ReAct 的效果上限，受限于它能调用的工具好不好用。工具返回质量差，再好的推理也救不回来。
这些局限，也解释了为什么后来的 Agent 系统在 ReAct 的基础上，加上了记忆、反思、规划、纠错等更复杂的机制——它们本质上都是在修补 ReAct 这个基础循环的短板。
从 ReAct 到思维树：推理范式的演进
ReAct 是”推理 + 行动”的代表，而推理范式本身还有其他的演进方向，值得一提。
思维树（Tree of Thoughts，ToT）：把推理从”一条链”扩展成”一棵树”——在每一步都探索多个可能的思路分支，评估后选择最有希望的继续，必要时回溯。它比 CoT 更擅长需要搜索和回溯的难题，但计算成本也高得多。
自我一致性（Self-Consistency）：让模型对同一问题采样多个推理路径，然后投票取多数，能显著提升推理题的稳定性。
反思（Reflexion）：让 Agent 在失败后回顾自己的行为，总结教训，改进下一次尝试，形成”试错-反思-改进”的循环。
这些范式各有侧重：CoT 强调”想清楚”，ReAct 强调”边想边做”，ToT 强调”多想几条路”，Reflexion 强调”从错误里学”。今天的强 Agent 系统，往往是这些思想的融合。
ReAct 在真实产品里长什么样
ReAct 不是停留在论文里的概念，它实实在在地驱动着今天很多 AI 产品的行为。
你问一个 AI 助手”帮我查一下明天北京的天气，然后推荐适合的穿搭”，它内部的执行过程很可能就是一次 ReAct 循环：先推理”我需要先查天气”，调用天气工具，拿到温度和降水概率，再推理”根据 12 度的天气，建议穿外套”，最后给出答案。整个过程对用户是透明的，用户只看到最终结果，但背后是”想一步、做一步”的循环。
再比如”帮我对比一下这两款手机的价格，做成表格”。助手会先调用搜索或比价工具获取数据，可能还会调用计算工具做差价对比，再调用结构化输出能力生成表格。每一步都建立在前面观察的基础上。这种”边查边做、多步协同”的体验，正是 ReAct 范式的功劳。
理解这一点，你在设计 AI 应用时就会更有意识：当任务需要”多步、依赖外部信息、有中间结果”时，本质上就是在设计一个 ReAct 式的 Agent 循环，而不是简单的一次性生成。
ReAct 与「推理模型」的关系
2024 年之后，o1、DeepSeek-R1 这类”推理模型”大火，它们会在给出答案前进行长时间的隐性思考。这引出一个自然的问题：推理模型和 ReAct 是什么关系？
答案是：它们是两个维度上的能力，可以叠加。
ReAct 解决的是”要不要调用外部工具、怎么调用”，关注的是行动的编排；推理模型解决的是”怎么想得更深、更对”，关注的是推理的质量。一个理想的强 Agent，往往是”推理模型 + ReAct 循环”的组合——推理模型让每一步”思考”更靠谱，ReAct 循环让”行动”更有条理。
所以，ReAct 非但没有被推理模型取代，反而因为推理模型更强了而变得更重要：有了更会”想”的模型，ReAct 循环里的每一步决策质量都随之提升，”想一步、做一步”的循环就能走得更远、更稳。可以说，ReAct 是 Agent 的骨架，推理模型是 Agent 的大脑，两者结合，才是今天 Agent 能力的完整图景。
什么时候该用 ReAct，什么时候不必
- 适合用 ReAct 的场景：任务需要实时信息（搜索、查数据库）、需要多步决策（先查 A，再根据 A 查 B）、需要调用外部工具（计算、代码执行、API 调用）、需要可解释的中间过程（让用户看到模型每一步在干什么）。
- 不必用 ReAct 的场景：纯封闭域推理题（数学、逻辑），直接让模型推理或生成即可；简单的单轮问答；对延迟和成本极其敏感、且不依赖外部信息的场景。
一个实用的判断标准：如果答案的正确性依赖于模型”知道某个它可能不知道的事实”，或者任务本身需要”边查边做”，那就值得引入 ReAct 或工具调用。
设计 ReAct 提示词的几个实用细节
ReAct 的思路简单，但真要在工程里跑得稳，提示词和流程设计上有不少讲究。
- 工具描述要具体：每个工具叫什么、干什么、参数是什么、返回什么，都要写清楚。模型是”看着描述选工具”的，描述含糊，模型就容易选错工具或传错参数。
- 观察结果要截断和清洗：搜索结果、网页内容往往又长又脏，直接全量塞回给模型，既费 token 又容易引入噪音。通常要截取最相关的片段，或者做个摘要再喂回。
- 限制最大步数：必须设置一个步数上限，防止模型陷入无效循环。超过上限就强制收尾，或返回一个”无法完成”的兜底答案。
- 区分”可执行动作”和”废话”：模型偶尔会输出一段没有对应动作的”伪行动”。执行层要能识别合法动作格式，不合法的要么纠正、要么提示模型重新输出。
- 把工具结果当成新的事实：Observation 进入上下文后，模型会倾向于相信它。所以工具返回的内容要可信、可控，必要时标注来源，避免被错误信息带偏。
这些细节看起来琐碎，却是 ReAct 从”论文里的 demo”变成”生产里能用的 Agent”的关键。很多 Agent 框架，本质上就是把这些细节标准化、封装成了开箱即用的组件。
ReAct 为什么会被写入大模型的能力标准
理解了 ReAct，就能理解为什么”工具调用”会被纳入大模型的能力评测标准，以及为什么各家都在卷 function calling 的准确率和稳定性。
因为 ReAct 揭示了一个事实：一个只会”说话”的模型，和一个”能边想边做”的模型，解决现实问题的能力有本质差距。现实世界的问题往往不是一次生成就能解决的，而是需要”查证 → 判断 → 操作 → 再判断”的多步闭环。谁能把这个闭环跑得又快又稳，谁就能在 Agent 这一轮的竞争中占据优势。
这也是为什么你会看到，评测里除了”会不会答”，还出现了大量针对工具调用、多步规划、环境交互的基准。它们测的，正是 ReAct 所代表的”推理与行动协同”这个能力维度。理解了这一层，你对当下大模型和 Agent 产品竞争的很多现象，就能看得更透。
小结
ReAct 的价值，在于它用一个简单的循环——思考、行动、观察——把大模型”会推理”和”能动手”这两个能力接在了一起。理解了 ReAct，也就理解了今天大多数 AI Agent 的工作原理：它们本质上都是在跑一个”想一步、做一步、看反馈”的循环。这也是为什么”让模型能调用工具”会成为大模型能力演进里如此关键的一步。
