向初学者讲述ReAct框架，限制大篇幅使用修辞手法

先看一个具体例子：用户问“订单 A123 现在能退货吗？” 普通问答模型如果拿不到订单信息，只能解释一般退货规则。使用 ReAct 的助手则可以这样处理： 第一步：调用订单查询工具，获取订单 A123 的信息。 工具返回：订单已签收 3 天，商品类别为普通服装。 第二步：根据订单信息，调用退货规则查询工具。 工具返回：该类商品支持签收后 7 天内申请退货，但需要满足不影响二次销售等条件。 第三步：结合两次查询结果回答：“目前在退货申请期限内；是否满足退货条件，还需要确认商品状态。” 这里的订单和规则都是教学假设。关键在于：助手不是一次生成所有步骤，而是拿到工具结果后，再决定接下来做什么。 一、ReAct 是什么 ReAct 来自 Reasoning（推理）和 Acting（行动），是一种组织大语言模型完成任务的方法，不是某个必须安装的软件框架，也与前端 React 无关。 它的核心是让推理和行动交替进行：根据已有信息决定下一步，执行行动，读取结果，再更新下一步决策。 原论文常用三个概念描述这个过程： Thought：对当前任务和下一步行动的推理。 Action：执行某个动作，例如查询订单、搜索资料、运行计算。 Observation：动作执行后得到的结果，例如查询返回的数据或错误信息。 这个过程可以重复多轮，直到可以回答，或者达到停止条件。 二、模型和程序分别做什么 以查询订单为例，模型可以生成一个工具调用请求： 工具名：get_order 参数：order_id = "A123" 模型并不因此直接访问了订单数据库。真正执行查询的是你写的程序。 一次典型循环是： 程序把用户问题、可用工具说明发给模型。 模型选择调用哪个工具，并给出参数。 程序检查权限和参数，执行对应函数。 程序把函数返回值作为工具结果传回模型。 模型根据新结果继续调用工具，或者输出最终答案。 所以，最小实现需要模型、工具函数，以及负责执行和反馈的循环程序。不一定需要引入复杂的 Agent 框架。 原论文展示了显式的 Thought 文本；实际工程中，不必要求模型输出完整的内部推理过程。重点是下一步行动能利用前一步反馈，而不是日志里是否出现“Thought”这个词。 三、为什么不提前把步骤写死 假设查询订单时，工具返回“订单不存在”。 固定流程如果没有处理这个分支，可能仍然继续查退货规则。ReAct 可以根据反馈调整行动，例如要求用户检查订单号，而不是沿着原计划继续执行。 这是它的主要价值：适合下一步依赖执行结果、难以提前确定全部路径的任务。 但如果任务始终是“读取表单 → 校验字段 → 写入数据库”，固定工作流通常更简单、可控，没必要为了使用 Agent 而使用 ReAct。 四、它与工具调用、Plan-and-Execute 有什么区别 工具调用是一种能力：让模型通过结构化请求使用外部功能。 ReAct 是一种使用这些能力的方式：行动后读取反馈，再决定下一步。不是所有工具调用都构成 ReAct，例如固定调用一次计算器再返回结果，不一定需要完整的推理与行动循环。 Plan-and-Execute 更强调先制定计划，再执行；ReAct 更强调执行过程中根据反馈不断决策。两者可以组合：先做一个粗略计划，再用 ReAct 完成每个子任务。 五、初学者实现时要注意什么 限制循环次数。比如最多执行 8 轮工具调用，避免反复搜索同一个问题。 检查工具权限。模型提出“执行退款”，不代表程序就应该允许；涉及资金、删除数据等操作，需要额外校验或用户确认。 处理工具失败。查询超时、参数错误、结果为空，都应该明确返回，不能让模型当作成功继续。 根据证据回答。工具只确认了“在申请期限内”，模型就不应该扩大成“保证可以退货”。 不要把 ReAct 当作正确性保证。它能让模型使用外部反馈，但依然可能选错工具、误读结果，也可能增加延迟和调用成本。 一句话总结：ReAct 的核心不是“想好后执行”，而是“执行一步，读取反馈，再决定下一步”。 原论文与示例：https://react-lm.github.io/