ReAct模式：Agent的思考-行动循环

ReAct的核心是把「思考」和「行动」交替进行。在它之前，LLM的推理和外部交互是割裂的——要么纯靠链式思考（CoT）在脑子里推演，要么直接调工具但缺少中间推理过程。 打个比方，就像你查一个复杂bug的过程：先根据报错猜一个原因（Thought），去打个日志或者跑个命令验证（Action），看到输出结果（Observation），再调整判断继续查。ReAct就是让Agent也能这么干。

整个循环是这样的： 用户请求进来后，LLM先生成一段Thought——这是它的内部推理，比如「用户问的是天气，我需要调用天气API，参数是城市名」。然后它输出一个Action，指定要调用的工具和参数。系统执行这个工具调用，把结果作为Observation反馈给LLM。LLM看到Observation后，再决定是继续下一轮Thought-Action，还是认为信息够了直接生成最终Answer。 关键点在于，这个循环不是固定次数的，LLM自己判断什么时候该停。

用过。之前做一个内部的数据分析Agent，用户用自然语言提问，Agent去查数据库、做计算、生成报告。 踩的坑主要有两个： 第一个是循环失控。有时候LLM会在几轮之后进入一种「强迫症」状态，反复去查已经查过的数据。解决方案是加了一个最大轮次限制，同时在每轮的Thought里注入当前已有的信息摘要，告诉它「你已经知道这些了，不需要重复」。 第二个是Action格式不稳定。LLM有时候输出的工具调用格式会漂移，尤其是参数比较复杂的时候。后来我们用了structured output配合严格的JSON Schema约束，把这个问题基本解决了。

不是直接报错，那样体验太差了。我们设计了一个降级策略： 到了上限后，把当前已收集的所有Observation汇总，强制让LLM基于已有信息生成一个「尽力而为」的回答，同时标注哪些部分是完整验证过的，哪些是基于部分信息的推断。用户看到之后可以选择接受或者让Agent继续查。 说白了就是「有限信息下的best effort」，比卡死或报错好得多。

看任务复杂度和确定性。 ReAct适合探索性任务——你不太确定需要几步、每步结果会影响下一步决策的场景。因为它是逐步决策的，灵活性高。 Plan-and-Execute适合目标明确、步骤可预判的任务——比如「帮我把这份报告翻译成英文并发邮件」，步骤清晰，先规划再批量执行效率更高。 实际项目中我倾向于混合使用：外层用Plan-and-Execute做大的任务拆解，每个子任务内部如果需要探索就用ReAct循环。类似于你做项目时先列task list，但每个task执行时可能需要灵活调试。