面试题 · Prompt
请介绍ReAct（Reasoning + Acting）框架的基本思想、工作流程及其在大模型代理（Agent）任务中的应用，例如问答、工具调用等场景。
ReAct = Reasoning（推理）+ Acting（行动），关键创新是让模型交替进行"思考"和"行动"，而非一次性生成完整计划。
传统方式的问题：
Thought → Action → Observation → [循环] → Answer学习内容与项目面试，在同一条路上。
| 步骤 | 作用 | 示例 |
|---|
| Thought | 分析当前状态，决定下一步 | "我需要查天气API获取北京今天温度" |
| Action | 执行具体动作（工具调用/搜索） | search_weather(location="北京") |
| Observation | 接收环境反馈 | "北京今天晴，25°C" |
| 循环/终止 | 信息足够则回答，否则继续推理 | 温度已知，可以回答用户问题 |
多跳问答
Thought: 问题问的是"XX公司的创始人毕业于哪所大学"，我需要先查创始人是谁
Action: search("XX公司创始人")
Observation: 创始人是张三
Thought: 现在查张三的毕业院校
Action: search("张三 毕业院校")
...工具调用（如计算器、数据库）
场景切入
假设你在做一个智能客服，用户问'帮我查一下上周的订单'，模型先查订单号，但发现需要先确认用户身份，然后调用户信息API，再查订单。这个过程里模型是应该一口气全想好再行动，还是边想边做？你怎么看？
层层追问
大模型调用工具的时候，你一般怎么设计流程？……是先生成整个计划再执行，还是每一步都实时决策？……如果中间工具返回的结果和预期不符，模型怎么调整？这个循环具体怎么实现？
直球架构
介绍一下ReAct框架的核心思想和典型工作流程，包括Thought、Action、Observation这些环节是怎么循环的。再举一个多跳问答或工具调用的例子，说明它相比纯CoT或纯工具调用的优势。
这道题问的是[[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]]任务的基础框架，它解决了『想和做脱节』的核心矛盾。但在实际工程里，我更倾向把它和反思、校验机制结合起来，同时严格控制循环次数和工具调用的代价，这样才能在效果和效率之间取得平衡。