完整题目
ReAct（Reasoning + Acting）框架是一种提升大模型在复杂任务中表现的方法。请阐述其核心思想，并解释相比单纯的提示工程（prompting），ReAct为何能在推理与工具使用任务中取得更优效果。
本文目录
核心思想
ReAct = Reasoning（推理）+ Acting（行动），核心是让模型交替进行思考和执行，形成闭环：
思考(Thought) → 行动(Action) → 观察(Observation) → 思考(Thought) → ...不是一次性生成答案，而是逐步展开——先想"我需要查什么"，再调用工具，根据结果再决定下一步。
为什么比单纯Prompting更优
| 对比维度 | 纯Prompting/CoT | ReAct |
|---|---|---|
| 信息获取 | 依赖参数记忆，易幻觉 | 实时调用工具，获取外部信息 |
| 错误处理 | 一步错全盘错 | 观察反馈后可修正推理路径 |
| 可解释性 | 黑盒推理 | 每一步思考显性化，可追溯 |
关键优势：
- 解耦推理与信息：CoT只在"脑子里想"，ReAct让模型意识到"我不知道，要去查"
- 环境反馈闭环：工具返回的错误/意外结果，能触发重新规划（如搜索无结果→换关键词）
- 自我纠错能力：某步工具调用失败，后续Thought可调整策略，而非继续错误推导
本质区别
纯Prompting是开卷考试闭着眼答，ReAct是允许查资料且边查边想。
高德场景举例：路径规划时，ReAct会先思考"用户要避开拥堵"，再调用实时路况API，发现某路段封路后，重新规划替代路线——纯Prompting做不到这种动态适应。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
我看你做过客服系统，假设用户问“帮我查一下上周的订单”，你的模型直接回答“订单号是123”，但其实是幻觉。怎么设计才能让模型先调用订单查询API，再根据结果回答？
层层追问
你觉得纯Prompting在复杂任务里有什么局限？……那如果任务需要调用外部工具呢？……模型拿到工具返回结果后，怎么决定下一步？有个叫ReAct的框架，你了解吗？
直球架构
ReAct框架的核心思想是什么？请解释它为什么比简单的提示工程更擅长处理推理加工具调用的任务，重点说清楚推理与行动如何交替进行，以及这种设计带来的优势。
练习口述回答 · 约4分钟
- 本质是让模型边想边查，形成思考-行动-观察闭环
- 和纯提示的边界：CoT适合封闭推理，ReAct适合需要外部信息或工具的场景
- 业务例子：客服退款场景，模型查规则、调接口、动态调整
- 落地风险：工具质量、模型推理能力、成本是前提，常见失败是模型不按格式输出
- 工程师取舍：我会把ReAct看成系统设计的一部分，和提示工程搭配用
这道题其实是在问：当模型遇到一个单靠内部知识搞不定的任务时，怎么让它像人一样，边思考边查资料，而不是硬猜答案。[[ReAct]]的核心理念很简单，就是把Reasoning和Acting交替进行，形成一个思考、行动、观察的闭环。模型先想‘我需要知道什么’，然后调用一个工具，比如查API或者数据库，拿到结果后结合观察再想下一步，直到最终给出答案。
那它和单纯的提示工程，比如[[CoT]]，有什么本质区别呢？我觉得边界很清楚：CoT适合那种推理链条封闭、所有信息都在模型参数里的任务，比如数学题。但一旦任务需要实时信息，比如天气、库存、用户上下文，或者要操作外部系统，CoT就抓瞎了，因为它只能‘在脑子里想’，得不到外部反馈。ReAct的优势就在于它能主动获取信息，而且能根据反馈自我纠错。举个例子，如果模型搜索没结果，它不会硬走原来的推理路径，而是换个关键词再搜。
具体到业务场景，最典型的就是客服退款。假设用户说‘我买的东西降价了，要退差价’，系统需要先理解退款规则，然后查订单状态、调价格接口，发现商品已经发货了，那就要走退货退款流程。纯提示工程做不到这种动态适应，因为它没法实时查规则和接口数据。而ReAct可以让模型先思考‘我需要查订单号和当前价格’，然后调用查单API，拿到结果后再思考‘已经发货了，应该走退货流程’，再调用退货接口。每一步都是基于上一步的观察来决策。
但落地ReAct是有前提和风险的。首先，工具本身的质量要够好，API返回的数据要准确、及时，不然模型越推越错。其次，模型的推理能力要跟得上，如果模型连‘搜索无结果该换关键词’这种常识都推理不出来，那ReAct就变成了死循环。最常见的失败场景是模型不按格式输出，比如该调工具时它直接编了个答案，或者工具调用格式错了，系统解析不了。所以上线时我会特别关注模型的输出格式约束，用[[系统提示]]和few-shot样例来引导，同时做好超时和重试机制。
另外，这里有个有意思的点：ReAct的思考轨迹本质上是一种Chain-of-Thought的变体，但它的推理路径不是线性的，而是树状的，因为工具返回的结果可能让模型分支到不同的方向。所以我在想，如果要进一步提升鲁棒性，能不能结合[[Tree-of-Thoughts]]的思路，让模型同时探索多条行动路径，然后选最优的那条？不过这样成本会高很多，需要权衡。
所以，我不会把ReAct看成提示工程的替代品，而是把它看作系统设计中的一个决策点。更倾向的做法是：简单任务用CoT直接推，复杂、需要外部交互的任务用ReAct，甚至可以把两者混合，比如先用CoT做初步推理，再用ReAct去验证和补充信息。最终怎么选，取决于任务对实时性和准确性的要求，以及工具链的成熟度。