完整题目
以ReAct（Reasoning + Acting）框架为例，请详细解释其工作流程：什么是Plan？提示词如何设计？Observation指什么？各模块的输入、输出形式及结构是怎样的？并举例说明一次完整的交互过程。
本文目录
答案要点
- 清晰区分Reasoning和Action两个核心模块的协作关系
- 准确描述Plan的本质（动态规划而非静态计划）
- 说明Observation的来源和作用（工具返回结果作为下一轮推理的输入）
- 给出提示词的结构模板（Thought/Action/Observation的格式规范）
- 举例展示完整的循环交互流程（至少包含2轮Reasoning-Action-Observation循环）
ReAct核心思想
ReAct = Reasoning（推理） + Acting（行动），让LLM交替进行"思考"和"执行"，通过工具与环境交互解决复杂问题。
三个关键概念
| 模块 | 含义 | 本质 |
|---|---|---|
| Plan | 动态推理链 | 不是预先生成的静态计划，而是每步根据Observation重新评估的即时策略 |
| Thought | 推理过程 | 模型内部的思考文本，决定下一步行动 |
| Observation | 环境反馈 | 工具执行后返回的外部信息，作为下一轮推理的输入 |
提示词设计结构
[系统指令]
You are an assistant that solves problems by thinking step by step.
You have access to tools: {tool_names}
[格式规范 - 必须严格遵循]
Thought: [你的推理过程，分析当前状态]
Action: [工具名称，如search/calculate]
Action Input: [工具的具体参数]
Observation: [工具返回结果，由系统填充]
...（循环直到得出最终答案）
Final Answer: [最终结论]关键约束：每轮只输出一个Thought+Action，等待Observation后再继续。
各模块的输入输出
| 模块 | 输入 | 输出 |
|---|---|---|
| Reasoning | 用户Query + 历史(Thought, Action, Observation) | Thought文本 |
| Action | Thought中的决策 | 工具调用（名称+参数） |
| Observation | 工具执行结果 | 结构化/文本数据 |
| 下一轮Reasoning | 更新后的完整历史 | 新的Thought或Final Answer |
完整交互示例
场景：查询"2024年诺贝尔物理学奖得主的主要贡献"
【Round 1】
用户输入: 2024年诺贝尔物理学奖得主的主要贡献是什么？
LLM输出:
Thought: 我需要先查询2024年诺贝尔物理学奖得主是谁
Action: search
Action Input: {"query": "2024年诺贝尔物理学奖得主"}
系统执行search →
Observation: 2024年诺贝尔物理学奖授予John J. Hopfield和Geoffrey E. Hinton，以表彰他们在人工神经网络和机器学习方面的基础性贡献
【Round 2】
LLM输出:
Thought: 已获知得主是Hopfield和Hinton，需要分别查询两人的具体贡献
Action: search
Action Input: {"query": "John Hopfield Hopfield network contribution"}
系统执行search →
Observation: Hopfield于1982年提出Hopfield网络，引入能量函数概念，开创了递归神经网络的研究...
【Round 3】
LLM输出:
Thought: 已了解Hopfield的贡献，还需查询Hinton的具体工作
Action: search
Action Input: {"query": "Geoffrey Hinton backpropagation deep learning contribution"}
系统执行search →
Observation: Hinton的主要贡献包括：反向传播算法(1986)、深度信念网络(2006)、AlexNet(2012)等...
【Round 4】
LLM输出:
Thought: 已收集完整信息，可以综合回答
Final Answer: 2024年诺贝尔物理学奖授予Hopfield和Hinton。Hopfield的贡献是... Hinton的贡献是...设计要点总结
- Plan是隐式的：通过Thought的链式累积实现动态规划
- Observation是瓶颈：工具质量直接决定Agent效果
- 格式约束是关键：必须用结构化分隔符（如
Observation:）让模型区分内外信息
换一种问法，检查是否真正理解
场景切入
假设你在做一个智能客服，用户问“帮我查一下上周的订单”，它先要调用查询工具，然后根据返回结果再决定下一步。你能用ReAct框架讲一下这个过程中模型是怎么思考、怎么调用工具、以及怎么利用返回结果继续推理的吗？
层层追问
先说说你理解的ReAct工作流程……那这里的Plan到底是什么？是一个提前写好的步骤，还是每步动态生成的？……提示词里怎么约束模型只产生一个Thought和一个Action？……Observation又是怎么来的？
直球架构
讲一下ReAct框架的完整工作流程，包括Plan、Thought、Action、Observation这几个模块分别是什么，输入输出格式是怎样的，再举个例子展示至少两轮循环的过程。
练习口述回答 · 约4分钟
- 一句话定位：ReAct本质是让模型交替思考和行动，动态调整策略
- Plan不是静态计划，是动态推理链；提示词设计要严格约束格式
- Observation是环境反馈，驱动下一轮推理
- 完整示例：查询诺贝尔奖得主贡献，三到四轮循环
- 落地关注点：工具质量、幻觉控制、格式解析
这道题其实问的是，怎么让大模型不光会想，还能动手。[[ReAct]]这个框架的核心，就是把推理和行动串成一个循环，模型每想一步就调用一次工具，拿到反馈再接着想，直到把问题解决。它不是先生成一个完整的计划再去执行，而是一边干一边调整，有点像人做复杂任务的时候，走一步看一步。
具体说一下几个关键模块。首先是Plan，很多人以为Plan就是一开始定好的步骤，其实不是。ReAct里的Plan是动态的，每一步的Thought都在根据最新的Observation重新评估，说白了就是推理链本身就成了计划。举个例子，你要查一个产品的价格，第一步可能先搜产品名，看到结果发现有两个型号，第二步就得搜具体型号，这个分支就是动态生成的。
然后是提示词设计。这里有个硬约束：必须让模型按固定格式输出。我一般会用类似这样的模板：Thought: 推理过程; Action: 工具名; Action Input: 参数。然后系统拿到这个Action去调用工具，把结果填回Observation字段。模型看到Observation才能继续下一轮。这个格式一旦乱了，整个循环就断了，所以提示词里要反复强调格式。
Observation是什么呢？就是工具返回的结果，可以是文本、结构化数据，甚至API报错。它直接作为下一轮推理的输入。这里有个常见坑：如果工具返回的信息不完整或者有噪声，模型可能被带偏。所以Observation的质量直接决定了[[Agent]]的效果，上线前我会花大量时间打磨工具的输出格式和异常处理。
我拿一个具体的业务场景举例吧，比如客服系统里，用户问“我买的手机订单为什么还没发货”。ReAct的流程大概是：第一轮，模型想“先查订单信息”，调用订单查询工具，输入订单号，拿到订单状态。第二轮，看到状态是“已发货但物流未更新”，又想“查物流详情”，调用物流查询工具，拿到快递单号和最新物流记录。第三轮，看到物流显示“运输中”，但用户催得急，模型可能会再调一个客服备注工具，记录用户诉求。最后综合所有信息给出回答：“您的订单已发货，目前运输中，预计明天到达，我已备注加急。”整个过程就是Thought、Action、Observation循环，直到能给出Final Answer。
不过ReAct有个明显短板：如果模型在Thought里推理错了，比如误解了Observation，后面的步骤就会越走越偏。所以我在实际落地时，会考虑结合[[Self-Refine]]或者[[Reflexion]]机制，让模型自己检查自己的输出，发现错误就回溯重来，而不是一条路走到黑。