目录
一、ReAct 是什么
三个核心阶段
一个具体例子
ReAct 为什么比"直接回答"强
生产环境必做的安全措施
二、LangChain 中的 ReAct 模式
模式一：LangChain ReAct + 原生 ToolCall（新版主流）
模式二：LangChain ReAct 纯 Prompt 解析（经典版）
三、两种模式的核心对比
四、什么情况下纯 Prompt ReAct 反而更好
五、一句话总结
下面我用文字完整拆解 ReAct 模式本身，以及 LangChain 中的两种 ReAct 实现。
一、ReAct 是什么
ReAct =Reason +Act，2022 年由 Princeton 和 Google 论文提出。核心思想极其简单但极其有效：让大模型交替执行"推理"和"行动"，而不是一次性给出答案。
三个核心阶段
阶段 | 英文 | 模型在做什么 |
Thought | 推理 | 分析当前状态，判断缺什么信息，规划下一步 |
Action | 行动 | 执行具体动作——调用工具、检索知识、查询接口 |
Observation | 观察 | 接收外部返回结果，加入上下文 |
这三步循环往复，直到模型判断"信息够了"，输出Final Answer。
一个具体例子
用户问："茅台和五粮液 2024 年净利润谁更高？"
Thought: 我需要查询茅台和五粮液2024年的净利润数据。 Action: query_financial_report(stock="茅台", year=2024, metric="net_profit") Observation: 862亿 Thought: 茅台拿到了，现在查五粮液。 Action: query_financial_report(stock="五粮液", year=2024, metric="net_profit") Observation: 318亿 Thought: 862 > 318，茅台更高。信息完整，可以回答了。 Final Answer: 茅台2024年净利润862亿，五粮液318亿，茅台更高，差额约544亿。ReAct 为什么比"直接回答"强
普通 LLM 遇到上面的问题会怎样？它要么直接编一个数字（幻觉），要么说"我无法获取实时数据"。而 ReAct 的关键是：它不会在信息不足时硬答，而是先去获取信息，再基于真实数据回答。
这就是 ReAct 的本质——用"行动"弥补模型知识的不足，用"推理"保证行动方向的正确性。
生产环境必做的安全措施
必须设置最大迭代步数（max_iterations），通常 5~10 步。ReAct 的循环结构天然有死循环风险——模型可能在 Thought → Action → Observation 之间反复绕圈。超限后强制终止并返回当前最优结果。这不是可选项，是强制安全措施。
二、LangChain 中的 ReAct 模式
ReAct 是一种思想/范式，LangChain 是它的工程实现之一。但关键认知是：LangChain 实现了两种不同的 ReAct 模式，区别在于"工具调用意图从哪里来"。
模式一：LangChain ReAct + 原生 ToolCall（新版主流）
from langgraph.prebuilt import create_react_agent # 底层调用 llm.bind_tools(tools) # 模型通过原生 ToolCall 协议返回结构化 tool_calls agent = create_react_agent(llm, tools) result = agent.invoke({"messages": [{"role": "user", "content": "茅台PE是多少？"}]})工作原理：
- LangGraph 把工具描述通过
tools参数传给模型 API - 模型推理后返回
tool_callsJSON（原生协议能力） - LangGraph 自动解析、执行工具、把结果塞回 messages
- 再次请求模型，模型基于工具返回结果继续推理或输出最终答案
特点：结构化输出可靠、框架自动处理循环、但依赖模型的 ToolCall 质量。
模式二：LangChain ReAct 纯 Prompt 解析（经典版）
from langchain.agents import AgentExecutor, create_react_agent from langchain import hub # 不传 tools 参数给 API # 工具描述全部渲染进 System Prompt prompt = hub.pull("hwchase17/react") agent = create_react_agent(llm, tools, prompt) executor = AgentExecutor(agent=agent, tools=tools) result = executor.invoke({"input": "茅台PE是多少？"})工作原理：
- LangChain 把所有工具描述拼进 System Prompt，告诉模型："你有这些工具可用"
- 模型输出纯文本，遵循固定格式：
Thought: 我需要查询茅台的PE。 Action: query_stock_price Action Input: {"stock_code": "600519"}- LangChain 用正则表达式从文本中提取
Action和Action Input - 执行对应工具，把结果拼成
Observation: xxx塞回 Prompt - 再次请求模型，模型基于 Observation 继续 Thought → Action → ...
特点：完全不依赖模型的 ToolCall 协议，纯靠 Prompt 工程 + 文本解析。适合不支持 ToolCall 的模型。
三、两种模式的核心对比
维度 | 原生 ToolCall 模式 | 纯 Prompt 解析模式 |
工具意图来源 | 模型 API 返回 | 模型输出纯文本，框架正则提取 |
是否传 tools 参数 | ✅ 传给 API | ❌ 不传，工具描述塞进 Prompt |
输出格式 | 结构化 JSON | 固定格式的纯文本 |
解析方式 | JSON parse | 正则表达式 / 字符串匹配 |
解析可靠性 | 高（结构化输出） | 中（模型可能格式不稳定） |
模型要求 | 模型必须支持 ToolCall | 任何能遵循指令的模型都行 |
Token 开销 | 较低（工具描述不占 Prompt） | 较高（工具描述全部在 Prompt 里） |
调试难度 | 中（有结构化日志） | 高（纯文本，出错不好定位） |
适用场景 | GPT-4o / Claude / M2.5 等主流模型 | 开源小模型、不支持 ToolCall 的模型 |
四、什么情况下纯 Prompt ReAct 反而更好
虽然原生 ToolCall 是主流，但以下场景纯 Prompt ReAct 有优势：
- 模型不支持 ToolCall：很多开源小模型没有做过工具调用对齐训练，
tools参数对它们无效，只能走 Prompt 方案。 - 复杂推理链：ReAct 的 Thought 过程是显式的推理链，某些场景下"先想清楚再行动"比直接输出 tool_calls 效果更好。特别是参数需要多步推理才能确定的场景。
- 需要完全自定义流程：纯 Prompt 模式下你可以完全控制 Prompt 模板、解析逻辑、错误处理，不受框架 ToolCall 封装的约束。
- 跨模型兼容：同一套 Prompt ReAct 模板可以跑在不同模型上，而 ToolCall 的格式和行为在不同厂商 API 之间有细微差异。
五、一句话总结
ReAct 是"推理 + 行动交替循环"的思想范式；LangChain 是它的工程实现。LangChain 的 ReAct 有两条路：一条走模型原生 ToolCall 协议（结构化、主流），一条走纯 Prompt 文本解析（灵活、兼容性强）。选哪条取决于你的模型能力和业务需求——先用 ToolCall，不行再切 Prompt 解析。
Boss，如果你还想深入某个具体环节（比如 ReAct Prompt 模板怎么写、LangGraph 的状态机怎么设计、或者怎么在 MiniMax-M2.5 上跑 ReAct），随时说。
