ReAct 循环的一点思考和感触

我最近在读 LangChain 1.x 关于 Agent 的章节，越读越觉得 ReAct 这个循环本身，没我一开始想的神。

我甚至不太确定，读完这些之后，我自己是不是"祛魅"了。

什么是 ReAct，以及它为什么让我觉得没那么玄

ReAct 就是 Reasoning 加 Acting，推理加行动。

我一开始对这个概念没什么感觉，直到我意识到，它的循环结构真的就是这几个字。

Thought，Action，Observation。

我需要什么信息，调用什么工具，拿到什么结果，再想下一步。

就这么个东西。

我后来发现，Agent 的"神秘感"，大部分来自它的外壳，而不是循环本身。

你看到的 create_agent、invoke、一堆 middleware，那都是包装。

拆掉包装之后，核心就是：

while True:
    thought = llm(messages)
    if thought.tool_call:
        result = run_tool(thought.tool_call)
        messages.append(result)
    else:
        return thought.answer

一个 while 循环。

把推理写进上下文，让模型自己决定下一步，执行，拿到结果，继续。

它没有魔法。

拆掉循环之后，ReAct 在 Agent 里到底扮演什么角色

我一开始以为 ReAct 是一个"架构"。

后来发现，它更像一个 prompt 的写法。

ReAct 的贡献，就是让模型在每一步都把"我想做什么"说出来，再把"我刚才做了什么"喂回去。

这样模型就能根据上一步的结果，调整下一步的动作。

这个思想很朴素，但很管用。

后来原生 tool calling 出来之后，"让模型输出 Action: xxx 然后我去正则解析"这种做法，基本被替代了。

模型现在直接输出结构化的工具调用，框架直接去执行，不需要正则了。

但 ReAct 的思想没死。

它变成了各家 Agent 循环的默认范式。

你看 OpenAI、Anthropic、LangChain，它们的 Agent loop，底层都是"推理加行动，交替进行"。

ReAct 没被取代，只是换了个形式。

ReAct 的边界，什么时候别用 Agent

读到这里你可能会想，ReAct 这么好，那我所有任务都用 Agent 不就行了？

我一开始也这么想，后来发现不太行。

ReAct 有个特点，走一步看一步。

每一步都是根据上一步的结果，再决定下一步。

这个特点，对于"我不知道要调几个工具"的任务很合适。

但对于"我知道固定流程"的任务，就很浪费了。

比如 RAG，流程是固定的，检索，改写，生成。

你不需要让模型每一步都决定"我下一步做什么"。

固定流程的工作流，比 Agent 稳定得多。

成本也低得多。

所以我的结论是，不是所有任务都适合 Agent。

适合 Agent 的，是那种"我不知道要调几个工具，或者我不知道哪条路走得通"的任务。

不适合的，是那种"流程固定，我甚至能写死 if-else"的任务。

这个边界，是 ReAct 本身没解决的问题。

是你在设计 Agent 系统时，需要自己画的一条线。

拆解完之后，为什么还是需要做 Agent 开发

到这里你可能会问，那如果 ReAct 就这么简单，为什么还需要 Agent 开发？

我一开始也有这个疑问。

后来我发现，我拆的那个 while 循环，是"能跑"的版本。

而"能稳定跑在生产里"的版本，是另一回事。

"能跑"的意思是，我给了它一个任务，它调几个工具，给我个答案。

"能稳定跑"的意思是，它不会死循环烧 token，不会调错工具，不会泄露敏感信息，成本可控，出错了能追溯。

这两个之间的距离，比想象中大得多。

我写那个 while 循环的时候，没考虑过工具失败了怎么办。

没考虑过模型调了同一个工具五次还在等结果怎么办。

没考虑过上下文越来越长，最后爆掉怎么办。

这些"考虑过"的部分，就是 Agent 开发真正要干的事。

最后一点感触

我写这篇文章的时候，一开始是想"祛魅"。

想告诉你，ReAct 没那么神。

写到最后我发现，祛魅这件事，拆完之后，剩下的那些具体的活，一个也没少。

甚至更多了。

ReAct 循环本身，30 行代码。

但让它稳定跑在生产里，要几十倍的工程量。

这两件事，不矛盾。

拆解它，是为了知道它没那么神。

然后继续做那些具体的活。

因为"没那么神"不代表"不需要做"。

它只是让你知道，该在哪里下力气。