完整题目
请详细解释ReAct（Reasoning + Acting）范式的核心思想、工作流程以及在构建AI Agent系统中的优势和应用场景。
本文目录
答案要点
- 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，建议防晒出行")核心优势
| 对比维度 | 纯CoT（只推理） | 纯Act（只行动） | ReAct |
|---|---|---|---|
| 信息获取 | 依赖内部知识，易幻觉 | 能获取外部信息 | ✅ 结合两者 |
| 可解释性 | 黑盒推理 | 行动轨迹清晰 | ✅ 思维过程透明 |
| 纠错能力 | 无法验证 | 失败即终止 | ✅ 观察反馈驱动调整 |
| 复杂任务 | 难以分解 | 缺乏规划 | ✅ 逐步规划执行 |
典型应用场景
- 知识问答：需要实时检索+推理整合（如"某公司最新财报的同比增长率"）
- 工具编排：多步骤API调用（订票→查天气→规划路线）
- 交互式探索：数据库查询、代码调试等需要试错迭代的任务
工程实践要点
- Prompt设计：严格约束输出格式（Thought/Action/Observation标签）
- 工具描述：清晰定义Action的输入schema和返回格式
- 终止条件：设置最大循环次数，识别
finish等特殊Action
ReAct是现代Agent框架（如LangChain、AutoGPT）的理论基础，与Function Calling结合可实现生产级系统。
换一种问法，检查是否真正理解
场景切入
假设我们在做一个智能客服系统，用户问‘帮我查一下上个月的订单’，然后又说‘再帮我退掉其中那件红色的’。这时候模型需要先查订单，再根据结果执行退款。你怎么让模型在思考的同时还能调用工具，并且根据结果调整下一步动作？
层层追问
你了解大模型Agent的常见范式吗？……比如CoT和直接调用工具各有什么问题？……那有没有一种方式能把推理和行动结合起来，让模型边想边做？……具体是怎么循环的？
直球架构
讲一下ReAct范式的完整工作流程，包括Thought、Action、Observation怎么循环，以及它对比纯推理或纯行动的优势。另外，在实际Agent系统中，ReAct怎么解决工具调用中的错误修正和可解释性问题？
练习口述回答 · 约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 来执行，这样既灵活又稳定。