ReAct vs 纯提示：为何更优？

这道题其实是在问，当模型光靠内部知识不够用的时候，我们怎么让它像人一样，一边思考一边借助外部工具。[[ReAct]] 的核心，说白了就是把推理和行动揉成一个循环，而不是先想完再去做。它的流程就是 Thought 到 Action 到 Observation，再回到 Thought，这样一圈一圈走，直到任务完成。

具体说，模型先想一下当前需要什么信息，然后去调用搜索、计算或者 API，拿到结果后再结合这个新信息继续推理。这个机制让它能动态获取外部实时信息，而不是只靠训练时记住的那些知识。

那和纯 Prompting 的边界在哪里呢？纯 Prompting 适合那些知识相对静态、答案比较确定的场景，比如问一个常识问题。但一旦任务涉及时效性信息、多步验证或者需要精确计算，纯 Prompting 就容易[[幻觉]]或者出错。ReAct 的优势恰好就在这些场景，它能根据 Observation 及时调整策略，而且每一步的推理轨迹都是显式的，可解释性也好很多。

举个例子，客服处理退款申请。用户说订单超时了要退款，但实际政策是只有未发货的才能全额退，已发货要扣运费。纯 Prompting 的模型可能直接说可以退，或者编一个不存在的政策。用 ReAct 的话，模型会先想，我需要查这个订单的状态和退款政策，然后调内部 API 或者知识库，拿到订单已发货、政策规定扣运费，然后计算实际退款金额，再生成回复。整个过程每一步都有据可查。

但这里有个坑，ReAct 不是银弹。它的前提是外部工具要稳定可靠，而且模型要能正确解析工具返回的结果。如果搜索 API 不稳定或者返回了错误信息，ReAct 反而会放大错误。另外，推理链太长的话，模型容易在中间步骤迷失，忘记最初的目标，导致循环不下去。上线的时候我会特别关注工具调用的超时和重试机制，以及给推理链设一个最大步数，超出就回退到安全回复。

还有一个点值得细想，就是 ReAct 和 [[Agent]] 的关系。很多人把 ReAct 直接等同于 Agent，但我觉得 Agent 的范畴更大，ReAct 只是其中一种实现范式。在复杂任务里，我们往往需要 ReAct 配合其他机制，比如记忆管理或者多工具调度，才能真正稳定。

所以说，我会把 ReAct 看作一个高级脚手架，它让模型从闭卷考试变成了开卷加边查边想。但真正落地的时候，得清楚它适合什么场景，也要知道它的脆弱点在哪里。我更倾向于在需要多步验证和动态信息的任务里用 ReAct，而在简单问答里直接用纯 Prompting 就够了，没必要杀鸡用牛刀。