ReAct 框架怎么工作？

30 秒回答

1. ReAct的核心思想是将推理(Reasoning)和行动(Acting)交织进行，而非先想后做或先做后想
2. 能清晰说明Thought-Observation-Action的循环流程
3. 理解ReAct相比纯CoT或纯工具调用的优势（可解释性、容错性、信息补充）
4. 能举例说明在问答、工具调用中的具体应用方式

回答与解析

答案要点

• ReAct的核心思想是将推理(Reasoning)和行动(Acting)交织进行，而非先想后做或先做后想
• 能清晰说明Thought-Observation-Action的循环流程
• 理解ReAct相比纯CoT或纯工具调用的优势（可解释性、容错性、信息补充）
• 能举例说明在问答、工具调用中的具体应用方式

核心思想

ReAct = Reasoning（推理）+ Acting（行动），关键创新是让模型交替进行"思考"和"行动"，而非一次性生成完整计划。

传统方式的问题：

• 纯CoT：只推理不行动，无法获取外部信息
• 纯工具调用：盲目执行，缺乏对结果的反思

工作流程

Thought → Action → Observation → [循环] → Answer

应用场景

多跳问答

Thought: 问题问的是"XX公司的创始人毕业于哪所大学"，我需要先查创始人是谁
Action: search("XX公司创始人")
Observation: 创始人是张三
Thought: 现在查张三的毕业院校
Action: search("张三 毕业院校")
...

工具调用（如计算器、数据库）

• 模型自主判断何时需要工具
• 根据工具返回结果调整后续策略

相比纯方案的优势

• 可解释性：Thought链清晰展示决策过程
• 容错性：Observation失败时可重新推理
• 信息补充：动态获取缺失知识，不依赖静态参数

口语版讲法(约4分钟)

• 一句话定位：ReAct的本质是让模型边想边做
• 边界划分：ReAct适合动态需外部信息的场景，纯CoT或纯工具调用各有局限
• 工作流程：Thought-Action-Observation循环，举例多跳问答
• 真实业务场景：客服退款流程中的工具调用与容错
• 落地风险：前提是工具反馈质量，失败场景是循环死锁，上线关注观测点收敛
• 工程师姿态：更倾向ReAct作为基础框架，结合反思机制提升鲁棒性

这道题问的是ReAct框架，其实核心就是一句话：让模型边推理边行动，而不是先想完再干或者盲目执行。传统做法要么是纯Chain-of-Thought，模型自己在那推理，但拿不到外部信息，遇到知识截止或者需要实时数据就抓瞎；要么是纯工具调用，模型接到指令就去调API，但对返回结果缺乏反思，错了就一路错下去。ReAct把这两者揉在一起，每走一步都先想一下现在是什么状态、下一步该干什么，然后执行动作，拿到反馈再继续想，直到信息够用了才给出最终答案。

具体说一下工作流程，其实就是Thought、Action、Observation三个步骤循环。Thought是分析当前状态，比如用户问『XX公司的创始人毕业于哪所大学』，模型先想：我需要先查创始人是谁。然后Action就是执行搜索，调用搜索引擎或者知识库API。Observation拿到返回结果，比如创始人是张三。接着下一轮Thought：现在知道了张三，那我再查他的毕业院校。再Action，再Observation，直到能把答案拼出来。这个循环看起来简单，但实际落地时，真正的难点不是让模型会调工具，而是让模型在Observation失败或者结果不符合预期时，能调整策略重新推理。

举个例子，在客服退款场景里，用户说『我买的东西降价了，能退差价吗』。模型先Thought：需要查订单信息和当前价格。Action：调订单系统查订单状态和购买价。Observation：订单已发货，购买价100元。然后Thought：再查当前售价。Action：调价格服务。Observation：当前价80元。这时模型需要结合退款策略判断：如果支持保价，就引导用户申请；如果不支持，就解释政策。这个过程中，如果某个API超时或者返回错误，模型不能卡死，得重新思考：是不是换个方式查，或者直接告诉用户暂时查不到。

这里有个坑，ReAct落地的前提是工具反馈的质量足够高且稳定。如果API经常返回空或者错误信息，模型可能会反复重试甚至陷入死循环。我会特别关注Observation的收敛性，给循环设一个最大步数，超时就fallback到人工或者给一个兜底回答。另外，ReAct不是万能的，它特别适合那些需要多步推理和外部信息交互的任务，比如多跳问答、动态数据查询。但如果是纯知识类问题，比如『牛顿的三大定律是什么』，模型参数里就有，直接生成就行，没必要走ReAct，反而增加延迟。所以落地时常常是ReAct和纯生成混着用，让模型自己判断什么时候需要调用工具。

还有一个有意思的延伸，就是ReAct的Thought链天然提供了可解释性，但同时也暴露了模型的推理路径，如果中间某步推理错了，整个答案可能就偏了。我比较关注怎么在ReAct基础上加入自我反思机制，比如让模型在Observation之后多一步校验，确认结果是否合理，不合理就回溯重来。这个方向其实已经有一些工作在做，比如Self-Refine或者Reflexion，通过引入外部反馈来修正推理轨迹。

所以整体上，我会把ReAct看作Agent任务的基础框架，它解决了『想和做脱节』的核心矛盾。但在实际工程里，我更倾向把它和反思、校验机制结合起来，同时严格控制循环次数和工具调用的代价，这样才能在效果和效率之间取得平衡。

关键一句:ReAct的Thought链暴露推理路径，引入自我反思机制（如Self-Refine或Reflexion）可以修正错误轨迹。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做一个智能客服，用户问'帮我查一下上周的订单'，模型先查订单号，但发现需要先确认用户身份，然后调用户信息API，再查订单。这个过程里模型是应该一口气全想好再行动，还是边想边做？你怎么看？

2. 问法 2 · 层层追问

   大模型调用工具的时候，你一般怎么设计流程？……是先生成整个计划再执行，还是每一步都实时决策？……如果中间工具返回的结果和预期不符，模型怎么调整？这个循环具体怎么实现？

3. 问法 3 · 直球架构

   介绍一下ReAct框架的核心思想和典型工作流程，包括Thought、Action、Observation这些环节是怎么循环的。再举一个多跳问答或工具调用的例子，说明它相比纯CoT或纯工具调用的优势。