ReAct 范式核心思想与工作流程

30 秒回答

1. ReAct的核心思想是推理与行动的交错循环，而非分离执行
2. 明确说明Thought → Action → Observation的循环流程
3. 对比纯推理或纯行动的缺陷，说明ReAct的优势
4. 举例说明典型应用场景

回答与解析

答案要点

• ReAct的核心思想是推理与行动的交错循环，而非分离执行
• 明确说明Thought → Action → Observation的循环流程
• 对比纯推理或纯行动的缺陷，说明ReAct的优势
• 举例说明典型应用场景
• 提及与Function Calling、CoT的关系

核心思想

ReAct = Reasoning + Acting，将**推理（内部思维）与行动（外部交互）**紧密结合、交错执行，而非先想后做或边做边想分离。

关键洞察：人类解决问题时，思考和行动是循环交织的——观察环境变化→推理下一步→执行动作→再观察。

工作流程

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Thought   │ ──→ │   Action    │ ──→ │ Observation │
│  (推理/规划) │     │  (工具调用)  │     │  (环境反馈)  │
└─────────────┘     └─────────────┘     └──────┬──────┘
        ↑────────────────────────────────────────┘
                    (循环直到任务完成)

典型执行轨迹示例：

Thought: 需要查询北京明天天气
Action: search_weather(location="北京", date="明天")
Observation: {"temp": "25°C", "condition": "晴"}
Thought: 天气晴朗适合户外活动，建议用户带防晒
Action: finish(answer="北京明天晴天25°C，建议防晒出行")

核心优势

典型应用场景

• 知识问答：需要实时检索+推理整合（如"某公司最新财报的同比增长率"）
• 工具编排：多步骤API调用（订票→查天气→规划路线）
• 交互式探索：数据库查询、代码调试等需要试错迭代的任务

工程实践要点

• Prompt设计：严格约束输出格式（Thought/Action/Observation标签）
• 工具描述：清晰定义Action的输入schema和返回格式
• 终止条件：设置最大循环次数，识别finish等特殊Action

ReAct是现代Agent框架（如LangChain、AutoGPT）的理论基础，与Function Calling结合可实现生产级系统。

口语版讲法(约4分钟)

• 一句话定位：ReAct解决的是Agent怎么做决策的问题
• 核心思想：推理与行动交错循环，不是先想后做
• 工作流程：Thought→Action→Observation循环，举例说明
• 优势与边界：对比纯CoT和纯Act，适合工具编排、知识问答
• 落地风险：Prompt格式、工具描述、终止条件，可延伸点：与Function Calling的区别

这道题其实是在问，当我们想让大模型像人一样去调用工具、完成任务的时候，怎么让它既能推理规划，又能实时获取外部信息，还能根据反馈调整。ReAct就是目前最主流的方案，它的核心思想很简单：推理和行动是交错循环的，而不是先想完再做或者边做边想。

具体来说，它的工作流程就是 Thought → Action → Observation 这样一个循环。Thought 是模型在内部推理，规划下一步；Action 是调用外部工具，比如查天气、搜数据库；Observation 是拿到工具返回的结果。然后模型根据 Observation 再产生新的 Thought，再 Action，直到任务完成。举个例子，用户问北京明天天气怎么样，模型先 Thought：需要查天气，然后 Action：调用 search weather('北京', '明天')，拿到 Observation 说晴天25度，再 Thought：天气不错，可以建议防晒，最后 Action：finish 输出答案。整个流程就像人一样，边想边做，边做边看。

它的优势很明显。纯 Chain-of-Thought 只靠内部知识，容易产生 Hallucination，比如模型可能编造一个不存在的天气；纯 Action 没有推理，碰到复杂任务就容易乱，比如连续调用多个 API 时没有规划。ReAct 把两者结合起来，既能获取外部信息，又能逐步规划，而且每一步的 Thought 都是可解释的，出了问题也能根据 Observation 反馈来纠错。

不过落地的时候有几个坑必须注意。先说 Prompt 设计，必须严格约束输出格式，让模型老老实实输出 Thought、Action、Observation 这些标签，否则解析不了。接着说工具描述要清晰，每个 Action 的输入参数和返回格式得写明白，不然模型会传错参数。再补充终止条件，要设最大循环次数，比如10次，防止模型死循环，同时要识别 finish 这种特殊 Action 来正常结束。

应用场景上，ReAct 特别适合需要多步骤工具调用的任务，比如订机票的时候还要查天气、规划路线。还有知识问答，比如问某公司最新财报的同比增长率，需要先搜财报、再算同比增长。但如果是纯文本生成或者简单问答，直接用 In-Context Learning 或者 Few-shot 就够了，没必要上 ReAct，因为循环调用会增加延迟和成本。

说到这，其实有个有意思的点：ReAct 和 Function Calling 经常被一起用，但它们的角色不一样。ReAct 是决策框架，决定什么时候调用什么工具；Function Calling 是工具调用的具体实现，把自然语言请求转成结构化的 API 调用。所以真正落地的时候，我倾向于用 ReAct 做顶层规划，底层用 Function Calling 来执行，这样既灵活又稳定。

总结一下，ReAct 不是银弹，它适合需要外部信息和多步推理的 Agent 场景，但前提是 Prompt 和工具描述要设计好，否则模型很容易跑偏。我更愿意把它看作 Agent 的决策骨架，配上好的工具和终止策略，才能做出靠谱的系统。

关键一句:ReAct和Function Calling的角色分工：ReAct是决策框架，Function Calling是执行层。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们在做一个智能客服系统，用户问‘帮我查一下上个月的订单’，然后又说‘再帮我退掉其中那件红色的’。这时候模型需要先查订单，再根据结果执行退款。你怎么让模型在思考的同时还能调用工具，并且根据结果调整下一步动作？

2. 问法 2 · 层层追问

   你了解大模型Agent的常见范式吗？……比如CoT和直接调用工具各有什么问题？……那有没有一种方式能把推理和行动结合起来，让模型边想边做？……具体是怎么循环的？

3. 问法 3 · 直球架构

   讲一下ReAct范式的完整工作流程，包括Thought、Action、Observation怎么循环，以及它对比纯推理或纯行动的优势。另外，在实际Agent系统中，ReAct怎么解决工具调用中的错误修正和可解释性问题？