面试的时候我问过很多人："你觉得 ReAct 的核心是什么？“十有八九的回答是"推理+行动"或者"思考然后做事”。我一般会接着问："那具体怎么实现的？"场面就安静了。ReAct 不是"让 LLM 边想边做"这么简单。它是个非常具体的循环：Thought → Action → Observation。每一轮，Agent 先想（Thought），再做（Action），再看结果（Observation），然后根据结果再想下一步。我第一次用 ReAct 的惨痛经历前年做一个自动化运维 Agent，用户的问题是"帮我查一下服务器 CPU 高，然后重启服务"。我自信满满地用了 ReAct，心想这还能翻车？第一轮：Thought → “用户说 CPU 高，要先查 CPU 使用率” → Action → 调监控 API 查 CPUObservation → CPU 确实高，92%第二轮：Thought → “CPU 高可能是什么原因？是不是某个进程？” → Action → 调进程列表 APIObservation → 有个 Java 进程占了 80%第三轮：Thought → “要重启 Java 服务” → Action → 调重启 APIObservation → 重启成功看起来没问题对吧？但真实情况是：这个 Agent 在第三轮直接重启了服务，没通知用户，也没备份数据。用户的服务是电商核心交易系统，重启导致了 5 分钟的交易中断。我后来复盘发现，ReAct 的 Thought 环节缺了一个关键问题：“这个操作有没
