ReAct推理模式：让大模型边想边做

可视化演示

展示ReAct推理模式中思考→行动→观察的循环过程，通过推理步骤和工具调用结合，减少幻觉提高准确性。

什么是ReAct — 从“背诵型厨师”到“查证型厨师”

餐厅里有两类厨师。一类是“背诵型厨师”，只靠背过的菜谱做菜，从不检查食材。客人问“今天有河鱼吗”，他扫一眼菜单没有，就瞎编一句“有，三文鱼不错”。另一类是“查证型厨师”，会先在心里盘算需要什么，再掀开冰箱看一眼，才给出靠谱的回答。不幸的是，大模型天生就像第一类厨师——训练时见过海量文本，回答时却无法“掀开世界看一眼”。

ReAct 正是把大模型从“背诵型厨师”改造成“查证型厨师”的提示词方法。它的名字来自两个英文单词的组合：Reason（推理）和 Act（行动），由研究者 Yao 等人在 2022 年提出。核心思想极其朴素：让模型在作答之前，先输出一段“内心独白”，再调用外部工具（搜索引擎、计算器、数据库）获取真实信息，把结果带回来继续思考，而不是一步登天直接给答案。

为什么普通提示词不够？因为“一步到位的生成”意味着模型只凭参数里储存的“记忆”作答。你问“2023 年全球人口最多的城市”，如果训练数据里没有，模型就现场编一个。ReAct 通过把推理和行动交替写进生成文本，强迫模型走“先想后做、边做边想”的流程。这里还要区分一个容易混淆的概念——思维链（CoT，Chain of Thought）。CoT 只是让模型“多想一想”，把推理过程写在回答里；ReAct 更进一步，让模型真的“动手做”，通过与外部环境交互来获取证据。

就像老师傅做菜前必须先看一眼冰箱，ReAct 让大模型在开口前先“看一眼世界”。这一看，就是 AI 从“嘴硬”到“靠谱”的分水岭。

核心循环机制 — 推理、行动、观察的“厨房三步曲”

厨房里的节奏是这样的：老师傅接到订单，先想“这道菜还缺什么”→ 动手翻冰箱 → 看到食材的实际状态 → 再想“要不要焯水去涩” → 动手烧水 → 观察水滚了没有 → … 直到菜出锅。每一个“想—动—看”都是一次迭代，这就是 ReAct 的循环节拍。

ReAct 的完整生成过程可以用一条“轨迹”（trajectory）来描述，它是三类文本块交替出现的序列。每次循环包含三个环节：Thought（推理）用自然语言写明当前的理由和计划，Action（行动）调用一个环境接口（工具），Observation（观察）记录工具返回的信息。三者首尾相接，构成闭环——上一轮的观察，就是下一轮推理的起点。

用数学记号表达，一条 ReAct 轨迹长这样：

这个循环和老师傅做饭的节拍一模一样：心里盘算，动手验证，瞪眼观察，再盘算……唯一的不同是，大模型的“厨房”在文本世界里——推理是文字，行动是工具调用，观察也是文字。

提示词设计 — 写一份“边想边做”的厨房工作手册

要让一位新来的大厨按“边想边做”的方式工作，光口头叮嘱没用，得把规矩白纸黑字写进手册。提示词就是给大模型的“厨房工作手册”。你写得多清楚，模型就执行得多规范。

ReAct 提示词的核心是“格式约定”。最常见的做法是在系统提示里明确要求：你必须交替使用 Thought:、Action:、Observation: 三种标签，并在答案收敛后以 Answer: 结尾。同时给出 1-2 个完整的示范例子（这就是 few-shot，即“给几个示例让模型模仿”）。例如：

写 ReAct 提示词有四个要点。第一，工具调用语法必须唯一且机器可解析，比如统一写成 Action: 工具名("参数")，否则程序不知道该执行什么。第二，要求模型“每步先说明理由再行动”，这能逼出真正的推理而不是瞎猜。第三，告诉模型“只有观察结果足以支撑结论时才能输出最终答案”，防止它在证据不足时提前刹车。第四，用一个完整示例展示循环如何结束——很多模型需要“看到”终止条件才会正确停止。另外，开头加上“让我们一步一步思考”这类短语，虽然简单粗放，但能帮助模型进入推理模式。

手册写得越清楚，大厨越少自由发挥；提示词写得越规范，模型越少胡编乱造。

Question: 北京和上海哪个城市更大？Thought: 我需要两座城市的人口数据来对比。Action: search("北京人口")Observation: 北京约2186万Thought: 还需要上海的数据。Action: search("上海人口")Observation: 上海约2475万Thought: 2475万 > 2186万，证据充分。Answer: 上海更大。

行动工具 — 给大模型一双“能伸向世界的手”

光会把想法说出来还不够。老师傅的手要能伸到冰箱、调料架、灶台上，大模型的“手”就是外部工具。没有手，再好的推理也只是“纸上谈兵”。

ReAct 依赖一组预先定义好的工具，常见的有四类：搜索引擎（查事实）、计算器（做精确运算）、代码解释器（跑程序处理数据）、数据库查询（检索结构化记录）。模型的行动环节输出一条特殊指令，程序在外部解析并执行该指令，再把工具返回的文本当作“观察”重新喂回模型。整个过程对模型而言，只是在“生成文本”——但文本被外部世界赋予了真实的语义。

工具调用格式是连接模型与环境的“接口协议”。以搜索为例，模型的输出中出现了 Action: search("北京人口2024")，程序就解析出工具名 search 和参数 "北京人口2024"，执行后把结果 Observation: 约2186万 追加到对话中。这一步看似简单，却是整个循环的关键——它保证模型的每一个结论都能回溯到某个外部证据。另一个值得注意的点是：工具本身不需要理解模型，它只负责“返回文本”，至于文本怎么解读，那是下一轮推理的事。

工具是厨师的手，但手怎么伸、伸向哪，由脑子里的推理决定。工具列表再丰富，不会“想”也白搭。

减少幻觉 — 让每道菜都有“试吃依据”

老师傅为什么从不吹牛说“这道菜绝对正宗”？因为他自己尝过。大模型有了工具，就等于有了“味觉”。幻觉的根源是“只靠记忆生成”——模型把训练数据里的碎片拼接成看似合理的答案，却没有任何验证。ReAct 恰恰在这一点上动了手术。

ReAct 从两个层面压制幻觉。第一，推理环节让模型暴露知识缺口。当模型被迫写下“我需要知道 X 才能回答”时，它自己就会发现“我其实不知道 X”，于是转入行动去查证。第二，行动环节用外部证据替代记忆猜测。观察结果成为回答的“锚点”，模型引用观察而不是引用想象——就像厨师说“这茄子是新鲜的”是因为他刚摸过，而不是因为菜谱上这么写。

ReAct 还有一个普通提示词不具备的能力：即时纠错。如果第一次搜索没有返回有用信息，模型会通过观察发现“我查的方向不对”，然后修改关键词再次行动。比如先搜“最大城市”没结果，改为搜“2024 城市常住人口排名”，再对比数据。这种“发现问题—调整策略—重新行动”的自愈能力，正是建立在循环结构之上的。但也要清醒：ReAct 显著降低幻觉，却不能根除。如果工具本身返回了错误信息，模型依然可能把“垃圾”当“证据”。

就像老师傅发现茄子发蔫后立刻改做“凉拌茄条”——看到实际情况马上调整方案，而不是硬着头皮按原菜谱炒。这种“以观察为准、随时修正”的精神，就是 ReAct 减少幻觉的全部秘密。

应用场景 — 从“话痨”到“实干家”

一个只会“谈思路”的顾问和一个“动手验证”的工程师，你更信任谁？ReAct 的意义就是把大模型从前者变成后者。凡是需要“多步求证”的复杂任务，都是 ReAct 的用武之地。

第一个典型场景是复杂问答。用户问“去年大模型推理成本下降了多少？”，普通模型会编一个百分比；ReAct 模型先搜索两份行业报告，再用计算器计算差值比例，最后引用数据来源作答。第二个场景是智能体（Agent）应用。客服机器人收到“订单 12345 显示已签收但我没收到货”，不再回答“请您联系快递”，而是推理“需要查物流轨迹和签收人”，调用订单系统工具，观察“由前台代收”后，给出“请先询问物业前台”的精准建议。第三个场景是决策支持。在数据分析平台上，用户问“哪个地区的增长潜力最大”，Agent 先推理需要哪些指标，再调用数据库查询和代码解释器完成统计，最后拿着真实计算结果给建议。

这些场景的共同特点是：答案必须建立在事实之上，且过程可以被追溯。传统的“一问一答”式提示词无法胜任，因为模型根本没有机会去“查”。ReAct 的循环结构恰好补上了这一环。

从“话痨”到“实干家”，差的不是模型更聪明，而是模型学会了“先查再答”。

调试与局限 — 透明背后的时间账

老师傅边做菜边报菜名，客人随时知道他在干什么，非常放心。但代价是：每多说一句、每多翻一次冰箱，都要花时间。ReAct 的优缺点，恰恰长在同一根藤上。

先看优点：可调试性。Thought 轨迹相当于“思维过程日志”，用户和开发者可以清楚地看到模型在哪一步跑偏——是推理错了，还是工具选错了，还是观察解读错了。这种透明度在金融、医疗、客服等对可解释性要求高的场景里极其宝贵。出了问题，你不再是面对一个“黑盒”，而是面对一份可以逐行审查的记录。

再看代价：成本和延迟。模型每多一轮循环，就多消耗一批 token（token 是模型处理文本的最小单位，可以近似理解为“字词碎片”）。一个需要 5 步工具调用的任务，调用成本可能是一个普通回答的 5-10 倍。另一个更隐蔽的风险是错误累积：如果第 2 步的观察结果有误，第 3、4 步的推理会建立在错误地基上，越走越偏——就像厨师尝了一口发酸的酱油没察觉，之后的整道菜都带着怪味。

边想边做是优点，但想太多、做太多，也可能“过度烹饪”。工程上的智慧不在于无脑增加循环轮数，而在于设计好“什么时候该停”——这恰恰是 ReAct 落地时最考验 Prompt 工程师的地方。

AI 应用场景

Python 演示

def search(query):    """模拟搜索工具：从本地知识库查找信息"""    knowledge = {        "北京人口": "约2186万",        "上海人口": "约2475万",    }    return knowledge.get(query, "未找到相关信息")  def react_agent(question):    """ReAct 推理循环：推理 -> 行动 -> 观察 -> 再推理"""    print(f"[问题] {question}")    print("[推理] 需要人口数据支撑回答，先查北京。")    print("[行动] search(北京人口)")    obs1 = search("北京人口")    print(f"[观察] {obs1}")    print("[推理] 还需上海人口才能对比。")    print("[行动] search(上海人口)")    obs2 = search("上海人口")    print(f"[观察] {obs2}")    print("[推理] 上海2475万 > 北京2186万，证据充分。")    print(f"[回答] 上海人口更多（约2475万），北京约2186万。")    return obs1, obs2  if __name__ == "__main__":    react_agent("北京和上海哪个城市人口更多？")

1. def search(query):定义一个“工具”函数，相当于厨师可以随时查看的“食材档案”。
2. return knowledge.get(query, "未找到相关信息")工具以纯文本形式返回结果，这正是 ReAct 中“观察”的形态。
3. print("[推理] 需要人口数据支撑回答，先查北京。")Thought 环节：模型先说清楚“我为什么这么做”。
4. print("[行动] search(北京人口)")Action 环节：模型输出固定格式的工具调用指令。
5. obs1 = search("北京人口")程序解析并执行工具调用，把结果拿来给模型“观察”。
6. print(f"[观察] {obs1}")Observation 环节：工具返回的文本被写回上下文，供下一轮推理使用。
7. if __name__ == "__main__":可执行入口，保证脚本能被直接运行。

常见误区

面试题