ReAct模式深入解析：大模型智能体如何实现思考与行动循环

先说一个最容易踩的坑：这篇写的是 ReAct 模式，但它和前端圈天天说的 React 完全不是一回事。如果你是因为搜“react 生命周期函数”、“react 图表”、“react native 启动白屏”来到这里的，建议直接划走；但凡你是做 AI 应用、在思考怎么让大模型不只会聊天、还能自己调用工具解决问题，那么留在这一篇，我们聊的是智能体领域里的ReAct（Reasoning + Acting）模式，一个让大模型“边思考、边行动、看结果再调整”的经典范式。

最近越来越多朋友开始做 AI 智能体，很多人一上来就问“用哪个框架”“要不要上 Reinforcement Learning”，其实大部分场景根本用不着那么复杂。只要把 ReAct 吃透，你已经可以徒手搭出一个能思考、能行动、能自我纠错的 agent 骨架。这篇文章我会按自己的理解，把 ReAct 模式的原理、循环机制、最小实现、落地形态以及真实项目里的坑全部拆开来讲，适合准备入门的同学，也适合想系统梳理一遍的工程师。

在智能体实践中，ReAct 的地位有点像操作系统里的进程调度——它不复杂，但几乎所有上层框架都在直接或间接复用它。花 20 分钟看完整篇，你会发现自己再去看那些开源 agent 框架，至少能看懂七成。

1. 先把 ReAct 和 React 说清楚：同一个读音，两个世界

1.1 三个易混淆概念的一次性区分

ReAct 这个词和 React.js 写出来就差一个字母的大小写，但这两者在各自的圈子里都太有名了，导致搜索时经常互相串门。为了避免后面讨论跑偏，我在开头就把它们彻底分开。

所以，网上经常有人问“ReAct 和 Chain-of-Thought 是什么关系”，这个 ReAct 指的绝对不是前端虚拟 DOM 那套东西，而是大模型推理与工具调用相结合的一种设计模式。React 的“生命周期”概念是组件从挂载到销毁的过程；而 ReAct 智能体最关心的是“一次任务从开始到终止的循环控制”。一个是 UI 层面的生命周期，一个是任务执行层面的控制流，完全是两个维度。

1.2 ReAct 模式的定义：思考与行动交替进行的循环控制

ReAct 的核心思想，用一句大白话说就是：让模型在一轮任务里，持续输出“我现在在想什么、我下一步要做什么、我看到了什么结果”，直到得出最终答案为止。

它在 2022 年底到 2023 年初由相关研究工作提出，论文标题里就有 Reasoning and Acting。当时大模型最主流的使用方式是“直接回答问题”和“像写作文一样把思考过程补全”，但这两者都缺一个关键能力——模型无法与真实世界交互。它只能依靠自己头脑里的知识，一旦知识不足或记忆模糊，就会胡编。

ReAct 的思路非常直接：既然模型擅长生成文本，那就让它把“思考”写成文本；既然模型不擅长精确计算和事实查询，那就给它笔和纸——也就是外部工具。模型每做一步推理，就决定调用哪个工具，拿到工具返回的观察结果后，再继续推理。这个循环反复进行，直到模型认为答案足够可靠、可以端出去给你。

延迟来说，ReAct 并不是什么高深算法，它更像一种“工作章程”，告诉模型应该如何组织和表达自己的决策过程，也告诉程序应该如何解析、执行和反馈。这个章程一旦跑顺，你会发现原本一个只会吐字的模型，突然具备了“动手能力”。

2. 为什么“谋定而后动”比“上来就答”更可靠

2.1 直接回答模式下幻觉从哪来

现实中见到过太多类似场景：用户问“帮我查一下今年某品牌旗舰机的发布时间和起售价”，模型因为训练数据截止或获取不到实时信息，凭印象输出一个答案，看起来头头是道，实际日期差了半年。这就是典型的幻觉。

幻觉的本质是：大模型本质上在做“下一词预测”，它没有搜索引擎，也没有数据库，更没有真实世界的传感器。它只能依赖参数里存储的统计规律，去生成一个“听起来合理”的答案。面对训练数据覆盖不到的新问题、长尾问题、需要精确计算的问题时，它的“合理猜测”就会变成“一本正经的胡说八道”。

有人试图用“你回答得再仔细一点”来缓解，也就是让模型把推理过程写出来（Chain-of-Thought，思维链）。这个方法确实有点用，但它只是在封闭世界里增强推理，仍然无法获取新信息。如果一个问题的答案根本不存储在模型参数里，那么再怎么激发“思考”，也思考不出真值。就好比你让一个没出过海的人闭眼想象海洋生态系统的细节，他只能靠已有知识去拼凑，想象得再细致也代替不了实地采样。

2.2 ReAct 与其他方案的分工：思考链负责想，工具负责验证

ReAct 最大的贡献，是把“内部推理”和“外部验证”缝合在了一起：

• 思考（Thought）：让模型用语言描述当前对问题的理解、下一步计划。
• 行动（Action）：让模型明确调用某个工具，把不确定性交给外部系统去解决。
• 观察（Observation）：把工具返回的结果反馈给模型，作为下一次推理的依据。

这三个动作不断循环，模型就获得了一个“带反馈的闭环”。它在执行过程中产生的每一个判断，都有外部工具结果去校正。比如刚才那个找旗舰手机发布时间的问题，ReAct 智能体会先去搜索相关信息，再根据搜索到的内容组织答案；如果搜索结果不完整，它会换关键词再搜一次，或者在多个信息源之间交叉验证。对比“凭记忆直接答”，这种方式的可靠性自然高出一个量级。

我也要在这里给一个冷静的判断：ReAct 并不是银弹。它解决的是“模型缺乏外部信息校验”的问题，但如果你给它一个垃圾工具，或者工具本身返回的错误结果，那么“观察”环节会把错误继续喂给推理，形成错误累积。后面我会专门讲怎么防这个问题。

3. 拆开 ReAct 循环：Thought / Action / Observation 三步走

3.1 一次完整循环的直观案例

为了让大家一眼看懂，我拿一个最简单的任务举例：用户问“北京现在适合穿什么衣服？”

假设我们给智能体准备了两个工具：一个是天气查询工具get_weather，入参是城市名；一个是建议生成工具recommand_clothes，入参是天气描述。ReAct 智能体执行过程大概长这样：

Thought: 用户想知道北京当前的穿衣建议，我需要先获取北京的实时天气，再根据天气给出建议。 Action: get_weather Action Input: {"city": "北京"} Observation: 晴，气温 21℃，微风，湿度 40% Thought: 天气晴朗，21℃属于较舒适温度，早晚可能稍凉，建议穿薄长袖或加一件外套。 Action: recommand_clothes Action Input: {"weather": "晴，21℃，微风"} Observation: 建议穿长袖T恤外加薄外套，早晚注意保暖。 Thought: 我已经拿到了基于天气生成的穿衣建议，可以直接回答用户了。 Final Answer: 北京今天晴天，21℃，建议穿长袖T恤和薄外套，早晚偏凉记得加衣。

注意观察每个环节的作用：Thought不是装饰品，它让模型把“下一步动作的理由”显式地表达出来，相当于给自己写注释；Action是真正把问题抛给外部工具的动作；Observation则把工具结果带回推理链路。整个过程像一个人查资料、消化、再查资料、再消化，最终给出结论，而不是闭卷考试。

3.2 智能体主循环的控制骨架

把上面的例子抽象成主循环，核心结构如下：

1. 把任务和已执行轨迹（历史思考、行动、观察）一起拼进提示词，发给大模型。
2. 模型返回一段文本，包含新的 Thought、Action 和 Action Input。
3. 程序解析这段文本，拿到要调用的工具名和参数。
4. 在本地安全地执行工具，拿到 Observation。
5. 把观察结果追加进轨迹，回到第 1 步。
6. 直到模型输出Final Answer，或者达到最大步数，结束循环。

用伪代码表示就是这样：

def run_react_agent(task, llm, tools, max_steps=6): messages = [ {"role": "system", "content": BUILTIN_REACT_PROMPT}, {"role": "user", "content": task}, ] for step in range(max_steps): response = llm.chat(messages) thought, action, action_input = parse_react(response) if action == "finish" or response.lower().find("final answer") != -1: return extract_final_answer(response) observation = execute_tool(tools, action, action_input) messages.append({"role": "assistant", "content": response}) messages.append({"role": "user", "content": f"Observation: {observation}"}) raise Exception("达到最大步数，任务失败")

这里有个设计细节值得多说一句：每轮循环都要把“之前所有的思考、行动、观察”完整地喂回模型。这相当于给模型一张不断加长的草稿纸，它不记得自己说过什么，但你可以帮它把说过的话都记下来。这也是 ReAct 最简单也最可靠的记忆方式——不需要额外接向量数据库，靠对话历史本身就能维持上下文一致。

3.3 终止条件与最大步数：循环必须有刹车

没有终止条件的 agent 就是脱缰的野马。实际项目中，我一般设置两层刹车：

• 显式终止：模型输出Final Answer或调用finish工具。
• 隐式终止：循环步数超过阈值（常见 3~8 步），直接掐断，返回“我尽力了”或让用户补充信息。

为什么必须设最大步数？因为大模型也是概率模型，它完全可能在某个错误的思路上反复打转，每次生成几乎一样的 Action，拿到几乎一样的 Observation，然后继续自言自语。如果不限步数，轻则浪费 token 烧钱，重则让用户等到天荒地老。我给不同场景的建议阈值通常是：

另外，终止条件还有一个容易被忽略的点：不要等到max_steps才返回异常，而是要在每步都检查模型是否已经在有效推进。比如连续两步调用同一个工具和参数，基本可以判定模型陷入了死循环，可以直接中断并给它反馈“请更换思路”。

4. 手把手实现一个最小可运行的 ReAct 智能体

4.1 选型：模型通道、工具注册、历史管理

如果你打算自己写代码而不是依赖重型框架，建议按以下三个模块来组织：

• 模型通道：封装好chat(messages)接口，无论是云端大模型还是本地模型，只要兼容相同调用方式都可以。代码里我建议用一套抽象层，方便随时切换模型。
• 工具注册表：每个工具包含名字、描述、入参结构、执行函数。相当于给智能体一个“工具菜单”。
• 历史轨迹：用一个 list 保存所有 assistant 输出和 observation，不额外引入外部存储。

这里我要强调一下工具描述的重要性。ReAct 能不能选对工具，很大程度上取决于工具描述写得好不好。比如同样是搜索工具，如果你只写“search”，模型可能不知道它适合查什么；如果你写“搜索实时新闻、百科、商品信息，入参为查询关键词”，模型的选择准确率会明显上升。工具名和描述本质上就是模型的“说明书”，写得越清楚，它越少瞎猜。

4.2 ReAct 系统提示词的标准写法

系统提示词是 ReAct 智能体的灵魂。我常用的模板大致如下：

你是一个可以调用工具的智能体。请严格遵守以下格式回答： Thought: 分析当前情况，说明你打算怎么做 Action: 工具名称，必须是 available_tools 中列出的工具 Action Input: 传给工具的参数，使用 JSON 格式 Observation: 程序会返回工具执行结果，你不需要生成 当你有足够信息回答任务时，请输出： Final Answer: 最终结论 可用工具： - get_weather: 查询城市实时天气，入参 city(string) 注意： 1. 一次只输出一个 Action，不要连续输出多个。 2. 工具调用结果会放在 Observation 中，请依据 Observation 继续思考。 3. 如果工具结果有误，可以尝试换一个关键词或换一种思路。

三个关键细节：

• 解析标记：用Thought:、Action:、Action Input:这样的显式标签，比让模型输出自由 JSON 更稳定。这是工程经验，不是论文理论。
• “一次只输出一个 Action”：很多模型在长文本生成时喜欢一口气列出一串工具调用，这会给解析带来很大麻烦。明确限制一次一个，解析逻辑会简单得多。
• “你可以试错”：让模型知道 Observation 可能不符合预期，允许它调整策略，这个心理暗示能显著减少模型死磕同一个错误方案的情况。

4.3 核心循环代码与解析逻辑

这里给出一个简化但可运行的 Python 原型。假设你的llm已经封装好了chat(messages) -> str接口：

import json import re class Tool: def __init__(self, name, description, func): self.name = name self.description = description self.func = func class ReActAgent: def __init__(self, llm, tools, max_steps=6): self.llm = llm self.tools = {t.name: t for t in tools} self.max_steps = max_steps def build_prompt(self, task): tool_desc = "\n".join( f"- {t.name}: {t.description}" for t in self.tools.values() ) return ( "你是一个通过调用工具解决问题的智能体。\n" "可用工具：\n" + tool_desc + "\n你必须按照 Thought: / Action: / Action Input: / Observation: 的格式执行，" "最终以 Final Answer: 结束。\n" "任务：" + task ) def parse(self, text): thought = re.search(r"Thought:\s*(.*)", text) action = re.search(r"Action:\s*(\w+)", text) action_input = re.search(r'Action Input:\s*(\{.*?\}|.*)', text) if not action: return None try: args = json.loads(action_input.group(1)) if action_input else {} except Exception: args = {} return { "thought": thought.group(1) if thought else "", "action": action.group(1), "action_input": args, } def run(self, task): history = [] for step in range(self.max_steps): prompt = self.build_prompt(task) if history: prompt += "\n\n已有的执行轨迹：\n" + "\n".join(history) response = self.llm(prompt) if "final answer" in response.lower(): return response.split("Final Answer:")[-1].strip() parsed = self.parse(response) if not parsed: history.append(response) history.append("Observation: 无法解析你的格式，请严格使用 Thought:/Action:/Action Input: 格式") continue tool = self.tools.get(parsed["action"]) if not tool: history.append(response) history.append("Observation: 工具不存在，请从可用工具中选择") continue try: result = tool.func(**parsed["action_input"]) except Exception as e: result = f"工具执行出错: {e}" history.append(response) history.append(f"Observation: {result}") return "达到最大步数，未能得到最终答案。"

这段代码故意写得朴素，但已经是 ReAct 的完整骨架。你会发现代码里几乎没有任何和具体业务绑定的东西，工具换成什么，它就能解决什么类型的问题。

4.4 输出解析与重试机制：最常见的翻车点

解析是 ReAct 工程实现里最容易翻车的部分，没有之一。模型经常给你来点“小惊喜”：

• 在Action Input里写成 Python 字典风格{city: "北京"}，而不是合法 JSON。
• 把Final Answer漏了，直接结束在Observation之后。
• 一口气输出两个 Action，比如Action: get_weather、Action: get_news连着写。

我的处理策略是先容错再反馈：

1. 优先用正则抓Action:后面的字符串，对Action Input尝试json.loads。
2. 解析失败时，不直接放弃，而是把“解析失败”作为一条 Observation 反馈给模型，让模型自己改正格式。
3. 对模型修正次数做上限，比如同一个格式错误出现两次以上就中断，避免无限死循环。

实测下来，很多主流大模型的格式修复能力很强，只要你在 Observation 里明确告诉它“你的 Action Input 不是合法 JSON”，它下一轮大概率就能改对。这个“错误即反馈”的思路，其实也是 ReAct 循环的自我修正机制——不仅是工具执行结果可以反馈，解析器的错误信息同样可以反馈。

5. 在可视化编排与智能体框架中落地 ReAct

5.1 把 ReAct 画到画布上：流程图节点怎么连

现在很多小伙伴喜欢用“画布”式工具来编排智能体，把 LLM 节点、工具节点、条件分支节点拖到一块画布上，连成一条流程。如果你把 ReAct 循环画到这类画布上，结构会非常清晰：

• 开始节点：接收用户问题。
• LLM 生成节点：把任务和历史轨迹输入模型，生成 Thought、Action。
• 解析判断节点：判断模型输出的是 Final Answer 还是 Action。
• 如果是 Final Answer，走结束节点。
• 如果是 Action，进入工具执行节点，拿到结果后进入 Observation 注入节点。
• Observation 注入节点把结果拼进历史，再回到 LLM 生成节点。

整个画布会形成一个闭合回路。这也是为什么你会看到很多智能体框架图里总有一个“loop”标志——那个 loop 本质上就是 ReAct 循环在可视化上的体现。理解了 ReAct，再去看各种 agent 框架图，你会一眼认出哪个节点承担了 Thought 的作用、哪个节点承担了 Observation 的注入。

5.2 ReAct 与原生 Function Calling 的关系：不是替代，而是互补

现在不少大模型提供原生工具调用（Function Calling）能力，模型能直接输出结构化的工具调用请求，程序解析起来比解析文本更稳定。那么问题来了：有了 Function Calling，还需要 ReAct 吗？

我的答案是：需要，但角色不同。Function Calling 解决的是“模型如何规范地表达调用工具的意图”，它给了你一个干净的 JSON 结构；而 ReAct 解决的是“模型如何安排多步推理、如何根据观察结果调整计划”。你把 ReAct 当外层控制循环，把 Function Calling 当内层动作表达，两者可以无缝衔接。

实际项目里有几种做法：

• 简单任务：直接用 Function Calling，模型输出工具调用，执行完一次就结束。
• 多步任务：在 Function Calling 之上叠加 ReAct 式循环，每轮让模型决定调用哪个函数，再观察结果。
• 复杂推理任务：把 ReAct 思维模板和 Function Calling 都写进系统提示词，让模型在思考的同时以结构化方式调用工具。

我自己的经验是，不要因为有了原生 Function Calling 就完全放弃 ReAct 的文本轨迹。ReAct 里显式的 Thought 对复杂任务非常有用，它能让你看到模型当前的策略是否合理，也方便人类介入纠偏。它相当于汽车的仪表盘，而 Function Calling 只是发动机的点火系统。

5.3 框架化时需要考虑的状态与记忆

当 ReAct 从一个几十行的原型变成工程模块，你会开始面对状态管理和记忆的问题。比较常见的优化方向有三个：

• 短期记忆管理：随着循环轮数增加，历史轨迹越来越长，最终可能超过模型上下文窗口。常用办法是只保留最近 N 轮轨迹，或者对早期 Observation 做摘要压缩。
• 工具执行日志：每个工具调用的入参、出参、耗时都记录下来，方便复现和排查。这一步在原型阶段可以偷懒，上生产必须做。
• 幂等保护：如果一个工具调用会触发副作用（比如发消息、写文件），要防止模型在重试时重复执行。简单做法是把工具调用 ID 和结果关联，同一个调用只执行一次。

这些听起来不那么“性感”，但真实项目里决定一个 agent 能不能被信任的，往往就是这些工程细节。

6. 真实项目中反复出现的坑及避开方法

6.1 解析失败导致的死循环

这是一种特别常见的失败模式：模型输出了一段语义正确但格式不合规的文字，解析器没抓到 Action，于是把“解析失败”反馈回去，模型又来一次，还是格式不对，如此反复直到撞上最大步数。

我踩过这个坑后的调整思路是：不要只依赖一个解析器。正则不行就试 JSON，JSON 不行就试子串匹配，甚至可以把模型输出里所有看起来像工具名的词提取出来，和可用工具列表做模糊匹配。解析器容错率越高，循环越不容易卡死。另外，把系统提示词里的格式示例写得更具体，比如给出一个完整的Thought/Action/Action Input/Observation示例，能显著减少格式错误。

6.2 模型无视 Observation，坚持原有错误判断

还有一个很有意思的问题：工具明明返回了正确结果，模型却视而不见，继续按自己之前的错误推理执行。这在大模型里不算罕见，尤其是当工具结果和模型先验知识冲突时，模型可能更相信自己记忆中的答案。

这种场景下，我会在提示词里加重语气：“Observation 是真实执行结果，必须作为后续推理的依据，如果与你的既有认知冲突，请以 Observation 为准。”同时，把 Observation 放在紧接着的 user 消息里，而不是塞在系统提示词里，模型对这种最近交互信息的遵循度通常更高。

6.3 多步错误累积与幻觉校正

ReAct 每一轮的 Observation 都可能携带错误信息，一旦中间某一步判断错了，后面的步骤都会基于错误前提继续推理，而且模型很擅长把错误“圆”得逻辑自洽。

我的对策是在关键步骤后增加验证节点。比如数据最终结论出来前，先用另一个无关工具或重新组织一次独立查询来交叉验证。如果两个来源的结果不一致，要求模型说明差异并重新推理。虽然这会增加 token 成本，但在涉及金额、时间、健康等容错率低的场景中，这个成本值得花。

6.4 安全边界：工具不是无限权限

这是我认为所有做 ReAct 的人都必须重视的一点。智能体有了行动能力，就意味着它可以触发一些有实际影响的动作。在项目里至少要守住几条底线：

• 工具白名单：只开放完成任务所必需的最小工具集，不要给智能体塞一堆用不上的高级权限工具。
• 敏感命令拦截：对删除、改写、付费、发送消息等高风险操作，执行前必须二次确认，或直接禁止自动执行。
• 权限分级：智能体运行进程采用最低权限账号，不能让它用管理员权限去执行任意命令。

安全边界不是技术炫技，而是 agent 能不能从玩具变成生产工具的分水岭。宁可少放一个工具，也不要让模型拿到一个它能“自由发挥”的危险操作入口。

7. ReAct 面试考点速查：别人问这些，你能接住吗

因为不少人是带着面试准备的目的搜到这类标题，我把高频考点整理成了一份清单，方便临时抱佛脚。

7.1 面试高频问题与回答要点

问题 1：请解释什么是 ReAct？

回答框架：ReAct 是 Reasoning + Acting 的组合，让大模型在生成推理轨迹的同时决定是否调用外部工具，并将工具结果作为下一轮推理依据。它把内部知识推理和外部信息获取结合起来，弥补单靠模型记忆带来的幻觉和知识过时问题。

问题 2：ReAct 和 Chain-of-Thought 有什么区别？

回答框架：CoT 只做内部推理，模型不会与外部世界交互；ReAct 在思考之外还能执行动作，通过 Observation 接收真实反馈。两者不是对立关系，ReAct 可以包含 CoT 的推理步骤，但多了一个“行动-观察”闭环。

问题 3：为什么 ReAct 需要设置最大步数？

回答框架：因为模型可能陷入重复循环，如果不限制步数，会出现无限调用、token 成本失控和延迟拉长的问题。最大步数是一种工程上的保险机制，显式终止条件和隐式终止条件共同保证系统可控。

问题 4：解析模型输出时遇到非法 JSON 怎么办？

回答框架：先做容错解析，正则提取关键字段；解析失败后把错误信息作为 Observation 反馈给模型，让它自行修正；设定重试次数上限，避免死循环。

问题 5：ReAct 有什么缺点？

回答框架：多轮调用带来 token 成本和延迟增加；中间步骤错误会累积；工具质量决定结果质量；复杂任务中模型也可能长时间绕圈。因此它并不是所有任务的最优解，简单问题用直接回答或单次检索更划算。

7.2 一组自测判断标准

如果你正在设计一个 ReAct 智能体，可以通过这几个问题快速判断设计是否合格：

• 系统提示词里是否明确规定了输出格式和终止条件？
• 工具描述是否足够清晰，能否让模型判断“什么时候该用这个工具”？
• 历史轨迹是否会无限增长，有没有截断或压缩策略？
• 工具执行失败了，系统能不能把错误反馈给模型并让它换方案？
• 高风险工具是否设置了权限拦截或二次确认？

如果上面五个问题里有三个以上答不上来，建议先把前面几章再过一遍。因为这些问题不是考场刁难，而是生产环境里每天都在发生的真实挑战。

最后聊一点我个人的体会。做了一堆智能体项目后，我最大的感受是：ReAct 这种模式之所以经典，不是因为它用了什么高深算法，而是因为它把“用语言思考”和“用工具验证”这两个大模型最擅长的事情自然地结合了起来。它让模型不再是一个只会闭卷答题的考生，而是一个可以随时翻资料、做实验、查数据的助理。

如果你正在写自己的第一个 agent，别急着堆框架，先用 ReAct 手写一个十几行的循环跑通一个真实任务。你会比想象中更快理解智能体的本质——也更快发现，真正难的不是循环本身，而是怎么让这个循环变得可控、可靠、可解释。