点击上方 前端Q，关注公众号

回复加群，加入前端Q技术交流群

前言

上一篇我们用 LangChain.js 从零搭了一个 Tool-Calling Agent。你可能已经注意到了——Agent 能自己决定用不用工具、用哪个工具、用完之后怎么办。

但它到底是「怎么做到」的？内部的"思考过程"长什么样？为什么有时候很聪明，有时候又会卡在死循环里？

今天就来拆解 Agent 背后的核心机制—— 「ReAct 模式」。

为什么需要 ReAct？

先说一个问题。你问普通 LLM："阿根廷现任总统的夫人是哪里人？"

LLM 怎么处理？它直接从训练数据里"回忆"答案，一步到位给你。但训练数据可能过时了，也可能压根没收录这个信息。于是它就「编一个看起来很像的答案」——这就是所谓的"幻觉"。

问题出在哪？「LLM 不会"查资料"，只会"靠记忆"。」

ReAct 的解决思路很直接：别让 LLM 光靠记忆答题，「让它边想边查，查完再想」。

• 左边是普通 LLM：问题进去，答案出来，中间全靠"脑补"

• 右边是 ReAct Agent：问题进去后，它会思考→调工具查数据→看结果→再思考→直到有把握了才回答

ReAct 到底是什么

ReAct = 「Re」asoning + 「Act」ing，推理 + 行动。

它来自 2022 年普林斯顿大学的一篇论文。核心思想就一句话：

「让 LLM 把"想"和"做"交替进行，而不是先想完再做，或者直接做不想。」

具体来说，ReAct Agent 在工作时会反复经历三个阶段：

1. 「Thought（思考）」

   ：分析当前情况，决定下一步做什么

2. 「Action（行动）」

   ：调用某个工具去执行操作

3. 「Observation（观察）」

   ：看看工具返回了什么结果

然后拿着结果继续思考，决定是继续行动还是给出最终回答。

这个循环会一直转，直到 Agent 觉得"信息够了，我可以回答了"才停下来。

用一个真实例子走一遍完整循环

光说概念太抽象，我们用一个具体例子走一遍。

「用户问：北京和东京今天哪个更热？」

Agent 内部的执行过程：

🧠 Thought #1: 用户想比较北京和东京的温度，我需要分别查两个城市的天气。先查北京。

🔧 Action #1: 调用 get_weather({ city: "北京" })

👁 Observation #1: 晴，25°C，湿度 40%



🧠 Thought #2: 拿到北京是 25°C 了，接下来查东京。

🔧 Action #2: 调用 get_weather({ city: "东京" })

👁 Observation #2: 多云，31°C，湿度 70%



🧠 Thought #3: 北京 25°C，东京 31°C，东京比北京热 6 度。信息够了，可以回答。

✅ Final Answer: 东京今天更热！东京 31°C，北京 25°C，东京比北京高 6 度。

注意看，Agent 「不是一开始就知道要调两次工具再做一次计算」。它是一步一步走的——查完北京再决定查东京，查完东京再决定回答。每一步都基于"上一步的结果"来决策。

这就是"想一步做一步"的核心含义。

在 LangChain.js 里怎么用 ReAct Agent

上一篇我们用的 createToolCallingAgent 其实已经内置了 ReAct 模式。如果你想用更"正宗"的 ReAct Agent，LangGraph 提供了一个专门的 createReactAgent：

import { ChatOpenAI } from"@langchain/openai";

import { createReactAgent } from"@langchain/langgraph/prebuilt";

import { tool } from"@langchain/core/tools";

import { z } from"zod";



// 定义工具

const weatherTool = tool(

async ({ city }) => {

constdata: Record<string, string> = {

"北京": "晴，25°C", "东京": "多云，31°C", "伦敦": "阴，18°C",

    };

return data[city] || `暂不支持 ${city}`;

  },

  {

name: "get_weather",

description: "查询城市天气。用户问天气、温度相关问题时使用。",

schema: z.object({ city: z.string().describe("城市名") }),

  }

);



const searchTool = tool(

async ({ query }) => {

return`关于"${query}"的搜索结果：这是一条模拟的搜索结果...`;

  },

  {

name: "web_search",

description: "搜索网络信息。用户问事实性问题且天气工具无法回答时使用。",

schema: z.object({ query: z.string().describe("搜索关键词") }),

  }

);



// 创建 ReAct Agent

const agent = createReactAgent({

llm: newChatOpenAI({ modelName: "gpt-4o", temperature: 0 }),

tools: [weatherTool, searchTool],

});



// 运行

const result = await agent.invoke({

messages: [{ role: "user", content: "北京和东京哪个更热？" }],

});

createReactAgent 和上一篇的 createToolCallingAgent + AgentExecutor 本质上做的是同一件事，但 createReactAgent 基于 LangGraph 构建，更适合后续扩展到复杂的多步工作流和多 Agent 场景。

ReAct 的内部实现原理

如果你好奇 ReAct 在底层到底是怎么实现的，其实核心逻辑非常简单。用伪代码写出来就几行：

asyncfunctionreactLoop(input: string, tools: Tool[], llm: LLM) {

const messages = [

    { role: "system", content: "你是一个有工具可用的助手..." },

    { role: "user", content: input },

  ];



while (true) {

// 1. 让 LLM 思考（可能返回文本回答，也可能返回工具调用请求）

const response = await llm.call(messages);



// 2. 如果 LLM 没有请求调用工具 → 直接返回回答，循环结束

if (!response.toolCalls || response.toolCalls.length === 0) {

return response.content;

    }



// 3. 如果 LLM 请求了工具调用 → 执行工具

for (const toolCall of response.toolCalls) {

const targetTool = tools.find(t => t.name === toolCall.name);

const result = await targetTool.invoke(toolCall.args);



// 4. 把工具结果追加到消息历史（这就是"观察"）

      messages.push({ role: "tool", content: result, toolCallId: toolCall.id });

    }



// 5. 带着工具结果回到第 1 步，让 LLM 继续思考

  }

}

就是一个 「while(true)」 循环：

1. 问 LLM："接下来干什么？"

2. LLM 要么说"我要用工具"，要么说"我能回答了"

3. 如果要用工具 → 执行 → 把结果喂回去 → 回到第 1 步

4. 如果能回答了 → 返回答案 → 循环结束

「就这么简单。」 没有什么复杂的状态机，没有什么神经网络魔法。核心就是"LLM 判断 + 工具执行"的反复交替。

那"聪明"的部分在哪？全在 LLM 本身。LLM 负责判断"现在需不需要用工具、用哪个、传什么参数、结果够不够"。ReAct 只是给了它一个"可以反复思考和行动"的框架。

ReAct 的两个关键机制

看起来简单，但有两个细节让 ReAct 真正能跑起来：

机制一：Stop Sequence（停止生成）

普通的 LLM 调用是"生成到结束"——它会一口气把回答写完。但在 ReAct 里，「LLM 生成到"我要调工具"的时候必须停下来」，等工具执行完再继续。

怎么做到的？现代 LLM 的 Tool Calling API 原生支持这个——当 LLM 决定调工具时，它返回的不是普通文本，而是一个结构化的 tool_call 对象。运行时检测到 tool_call 就知道"该停下来执行工具了"。

机制二：Scratchpad（草稿纸）

上一篇提到的 agent_scratchpad，就是 ReAct 的"工作记忆"。每一轮的 Thought、Action、Observation 都会追加到这个草稿纸里，下一轮思考时 LLM 能看到"之前做了什么、得到了什么"。

没有 Scratchpad，Agent 就像一条金鱼——每转一圈都忘了之前做过什么，只能反复调同一个工具。

ReAct 最容易踩的坑：死循环

ReAct 最常见的问题就是 「Agent 陷入死循环」——反复调同一个工具、得到同样的结果、但就是不停下来。

为什么会这样？常见原因有三个：

「原因一：工具返回的结果 Agent 看不懂」

比如工具返回了一堆 HTML 或者报错的 stack trace，LLM 不知道该怎么理解这个结果，就决定"再试一次"——然后又得到一样的结果——然后又"再试一次"……

「解法」：确保工具返回清晰、简洁的文本，让 LLM 能理解。出错时返回"查询失败，原因是 xxx"，而不是抛一堆错误堆栈。

「原因二：没有替代方案」

Agent 只有一个工具可以完成某类任务，这个工具失败了，Agent 不知道还能干什么，就只能反复重试。

「解法」：给 Agent 提供"退路"。比如在 system prompt 里加一句："如果工具调用失败超过 2 次，直接告诉用户'我暂时无法获取这个信息'。"

「原因三：没设上限」

ReAct 的 while(true) 循环理论上可以无限跑下去。

「解法」：一定要设 maxIterations。一般 5~10 次就够了，超过大概率是出了问题。

// LangChain.js 的两种设法

// 方式一：AgentExecutor

const executor = newAgentExecutor({ agent, tools, maxIterations: 8 });



// 方式二：createReactAgent（通过 recursionLimit）

const agent = createReactAgent({

  llm, tools,

// 每个 tool call 算两步（call + result），所以 recursionLimit 约等于 maxIterations * 2

});

const result = await agent.invoke(input, { recursionLimit: 16 });

三种 Agent 模式怎么选

ReAct 不是唯一的 Agent 模式。了解不同模式的适用场景，才能选对"武器"。

三种 Agent 模式对比

模式	一句话描述	适合什么场景	不适合什么场景
「ReAct」	边想边做，走一步看一步	探索性任务、不确定需要几步才能完成的任务	步骤非常多且固定的流水线任务
「Plan-and-Execute」	先列计划再执行	复杂的多步任务、步骤之间有依赖关系	简单查询、需要快速响应的场景
「Function Calling」	直接调工具，一步到位	单步操作、明确知道该调哪个工具	需要多步推理的复杂任务

实际使用中的建议：

• 「大部分场景用 ReAct 就够了」

  ——它是目前 90% 生产级 Agent 的默认架构

• 如果你的任务步骤固定（比如"搜索→总结→翻译→发送"），可以考虑 Plan-and-Execute

• 如果只是单步工具调用（"帮我查个天气"），Function Calling 最简单直接

让 ReAct 更靠谱的 5 个实践

1. system prompt 里明确"什么时候该停"

不要让 Agent 自由发挥。明确告诉它什么情况下应该直接回答，什么情况下才需要用工具：

你是一个助手，遵循以下规则：

- 如果是闲聊或你已经知道答案的问题，直接回答，不要调工具

- 只在需要实时数据（天气、新闻、股价）或精确计算时才使用工具

- 如果工具调用失败 2 次，告诉用户你暂时无法获取该信息

- 每次回答都要基于工具返回的真实数据，不要编造

2. 给工具返回值加"格式规范"

工具返回的内容越结构化，LLM 理解起来越轻松：

// ❌ 返回一大坨原始数据

returnJSON.stringify(apiResponse);



// ✅ 返回精简、结构化的信息

return`城市：${city}｜天气：${weather}｜温度：${temp}°C｜湿度：${humidity}%`;

3. 打开 verbose 观察思考过程

调试阶段一定要看 Agent 的完整 Trace。很多"回答不对"的问题，你一看 Trace 就知道哪一步跑偏了——是选错了工具？传错了参数？还是理解错了工具返回的结果？

// AgentExecutor 方式

const executor = newAgentExecutor({ agent, tools, verbose: true });



// 或者用 LangSmith 做更完整的追踪（推荐生产环境用）

4. 限制工具数量，控制复杂度

前面说过，5~8 个工具是舒适区。如果超过了，考虑做"工具分组"：

用户问题 → 路由 Agent（判断属于哪个分类）

                ├── 天气类 → 天气子 Agent（2-3 个天气相关工具）

                ├── 数据类 → 数据子 Agent（2-3 个数据库相关工具）

                └── 搜索类 → 搜索子 Agent（2-3 个搜索相关工具）

这就是从"单 Agent + 多工具"到"多 Agent 协作"的演进方向，后面的文章会专门讲。

5. 生产环境加上兜底和监控

// 超时兜底

const timeout = setTimeout(() => { /* 强制返回兜底回答 */ }, 30000);



// 成本监控：记录每次请求用了多少 token、调了几次工具

// 异常告警：如果某个 Agent 频繁触发 maxIterations，说明有问题需要排查

一个稍微复杂的例子：研究助手

最后来一个比"查天气"稍微复杂一点的例子，让你感受 ReAct 在多步推理中的威力：

import { ChatOpenAI } from"@langchain/openai";

import { createReactAgent } from"@langchain/langgraph/prebuilt";

import { tool } from"@langchain/core/tools";

import { z } from"zod";



const searchTool = tool(

async ({ query }) => {

// 模拟搜索结果

if (query.includes("React 19")) {

return"React 19 于 2024 年 12 月正式发布，主要新特性包括：React Compiler、Server Components 正式版、Actions、use() Hook 等。";

    }

if (query.includes("Vue 3.5")) {

return"Vue 3.5 于 2024 年 9 月发布，主要改进：响应式系统性能提升、SSR 改进、新增 useTemplateRef 等。";

    }

return`关于"${query}"的搜索结果较少，建议换个关键词。`;

  },

  {

name: "search",

description: "搜索技术资讯。当需要查找框架版本、技术动态等信息时使用。",

schema: z.object({ query: z.string().describe("搜索关键词") }),

  }

);



const compareTool = tool(

async ({ items, dimension }) => {

return`从"${dimension}"角度对比 ${items.join(" vs ")}：两者各有优势，需要结合具体场景选择。`;

  },

  {

name: "compare",

description: "对比分析两个或多个技术方案。当用户要求对比时使用。",

schema: z.object({

items: z.array(z.string()).describe("要对比的项目列表"),

dimension: z.string().describe("对比维度，如'性能'、'生态'、'学习成本'"),

    }),

  }

);



const agent = createReactAgent({

llm: newChatOpenAI({ modelName: "gpt-4o", temperature: 0 }),

tools: [searchTool, compareTool],

});



const result = await agent.invoke({

messages: [{

role: "user",

content: "帮我对比一下 React 19 和 Vue 3.5 的主要更新，哪个更值得关注？"

  }],

});

Agent 的执行过程大概是这样：

🧠Thought:用户想对比React19和Vue3.5，我需要先查两者的信息

🔧Action:search({query:"React 19 新特性"})

👁Observation:React19主要新特性包括ReactCompiler、ServerComponents...



🧠Thought:拿到React19信息了，再查Vue3.5

🔧Action:search({query:"Vue 3.5 新特性"})

👁Observation:Vue3.5主要改进：响应式系统性能提升...



🧠Thought:两个都查到了，现在用对比工具来分析

🔧Action:compare({items: ["React 19", "Vue 3.5"],dimension:"新特性和值得关注程度"})

👁Observation:两者各有优势...



🧠Thought:信息够了，综合搜索结果和对比分析来回答

✅Final Answer: [综合对比分析...]

三步搜索 + 一步对比，Agent 自己规划了整个研究流程。你只需要问一个问题，它自己想办法搞定。

总结

ReAct 的核心非常简单：「让 LLM 边想边做，做完再想，直到搞定为止。」

它之所以成为 90% 生产级 Agent 的默认架构，就是因为这个"想→做→看"的循环足够通用——不管你的任务是查天气、做研究、写代码还是排查 bug，都可以用这个模式来处理。

记住三个关键点：

1. 「ReAct = Reasoning + Acting 的交替循环」

   ，不是一步到位，而是走一步看一步

2. 「底层实现就是一个 while 循环」

   ——LLM 判断 + 工具执行的反复交替，没有魔法

3. 「最大的坑是死循环」

   ——设好 maxIterations、给好兜底策略、让工具返回清晰的结果

推荐资源：

• 「ReAct 原始论文」

  ：https://arxiv.org/abs/2210.03629

• 「LangGraph.js ReAct Agent」

  ：https://langchain-ai.github.io/langgraphjs/how-tos/create-react-agent/

• 「Agent 架构概念」

  ：https://langchain-ai.github.io/langgraphjs/concepts/agentic_concepts/

往期推荐

从零开始：用 LangChain.js 构建你的第一个 Tool-Calling Agent

前端 AI SDK 怎么选？三大方案实战对比

Browser-Use 源码解析：AI 是怎么"看懂"并操控网页的

最后

• 欢迎加我微信，拉你进技术群，长期交流学习...
  

• 欢迎关注「前端Q」,认真学前端，做个专业的技术人...
  

点个在看
支持我吧