ReAct Agent：让大模型一边思考，一边调用工具完成任务

前言

大语言模型擅长文本生成、知识问答和内容总结，但如果让它完成“查询实时天气”“搜索知识库”“读取数据库”“调用接口”这类任务，仅依靠模型自身的参数知识往往不够。

原因很简单：大模型只能根据已有上下文生成文本，它无法天然访问外部系统，也无法保证自己的知识是最新的。

为了解决这个问题，Agent 技术开始受到广泛关注。Agent 不再只是让大模型回答一个问题，而是让大模型根据目标进行分析、选择工具、执行操作，并根据执行结果继续推理。

在众多 Agent 架构中，ReAct 是最经典、最容易理解，也最适合入门的一种。

需要注意的是，这里的 ReAct 并不是前端框架 React，而是由两个单词组合而成：

  • Reasoning：推理；

  • Acting：行动。

ReAct 的核心思想可以概括为一句话：

让大模型在推理和行动之间不断循环，直到完成任务。

一、为什么普通大模型无法完成复杂任务

假设用户提出下面的问题：

帮我查询北京今天的天气，并根据天气情况推荐适合的出行方式。

如果直接交给普通大模型处理，模型可能会根据历史知识生成一个看似合理的回答。但天气是实时变化的，模型参数中保存的信息显然不能作为当前天气。

为了正确回答这个问题，系统至少需要完成以下步骤：

  1. 理解用户需要查询北京天气；

  2. 调用天气查询工具；

  3. 获取实时天气结果；

  4. 分析温度、降雨和风力；

  5. 给出出行建议。

普通的大模型调用通常只有一次输入和一次输出：

用户问题 -> 大模型 -> 最终回答

而 Agent 的执行流程更加复杂：

用户问题
   ↓
大模型分析任务
   ↓
选择并调用工具
   ↓
获取工具结果
   ↓
继续分析
   ↓
生成最终回答

因此，Agent 的价值并不是让大模型“知道更多”，而是让大模型能够连接外部能力，并根据环境反馈完成任务。

二、什么是 ReAct Agent

ReAct 是一种将推理过程和外部行动结合起来的 Agent 运行模式。

在 ReAct 中，大模型不会一开始就直接给出最终答案，而是按照下面的结构运行：

Thought：思考下一步应该做什么
Action：选择并调用某个工具
Observation：接收工具执行结果
Thought：根据结果继续分析
Action：再次调用工具
Observation：获得新的结果
Final Answer：生成最终答案

其中包含四个核心概念。

1. Thought

Thought 表示大模型当前的思考过程。

例如：

用户询问北京今天是否适合骑车，我需要先获取北京的实时天气。

Thought 不直接修改外部系统，它主要用于决定下一步行动。

2. Action

Action 表示 Agent 选择调用的工具。

例如：

Action: get_weather
Action Input: 北京

工具可以是天气接口、搜索引擎、知识库检索、数据库查询，也可以是开发者自己编写的业务函数。

3. Observation

Observation 表示工具返回的执行结果。

例如：

Observation:
北京当前温度为31℃，有中雨，风力4级。

工具结果会重新放入上下文，交给大模型继续判断。

4. Final Answer

当大模型认为已经获得足够信息时，不再调用工具，而是输出最终答案。

例如：

北京当前有中雨且风力较大，不建议骑行，可以优先选择地铁或公交出行。

ReAct 的关键并不只是“调用工具”，而是大模型可以根据每次工具调用的结果动态调整后续步骤。

三、ReAct Agent 的完整执行流程

一个完整的 ReAct Agent 通常包含以下几个阶段。

1. 接收用户目标

用户向 Agent 提出问题或任务，例如：

查询项目知识库，告诉我系统支持哪些文档格式。

此时，Agent 得到的是一个任务目标，而不是固定的执行步骤。

2. 分析任务

大模型分析问题，判断完成任务需要哪些信息。

例如：

用户询问系统支持的文档格式，这些信息应该存储在项目知识库中，需要调用知识库检索工具。

3. 选择工具

Agent 根据工具描述选择最适合的工具。

假设系统注册了以下工具：

search_knowledge：搜索知识库片段
read_document：读取完整文档
query_database：查询数据库

大模型会根据任务选择 search_knowledge。

4. 调用工具

Agent 将参数传递给工具：

Tool: search_knowledge
Input: 系统支持的文档导入格式

工具可能返回：

系统支持 PDF、Word、Markdown 和 TXT 文件解析，同时支持网页 URL 导入。

5. 判断信息是否充足

获得结果后，大模型需要判断当前内容是否足以回答问题。

如果结果完整，Agent 可以直接生成最终答案。

如果结果只提到了 PDF 和 Word，没有说明是否支持 Markdown，Agent 可能继续调用完整文档读取工具。

6. 结束循环

当模型认为任务已经完成，或者达到最大执行次数时，Agent 结束运行。

整个过程可以表示为：

用户输入
   ↓
构建上下文
   ↓
大模型推理
   ↓
是否调用工具？
  ↙          ↘
是            否
↓              ↓
执行工具       输出最终答案
↓
获得观察结果
↓
写入上下文
↓
再次调用大模型

这就是 ReAct Agent 最核心的循环结构。

四、ReAct Agent 的核心组成

一个可运行的 ReAct Agent 通常由五部分组成。

1. 大语言模型

大语言模型是 Agent 的决策中心，主要负责：

  • 理解用户目标；

  • 分析当前状态；

  • 选择工具；

  • 生成工具参数；

  • 判断任务是否完成；

  • 组织最终回答。

需要注意的是，大模型并不直接执行工具，它只负责生成调用决策。

2. 工具集合

工具是 Agent 与外部世界交互的方式。

常见工具包括：

  • 搜索引擎工具；

  • 知识库检索工具；

  • 完整文档读取工具；

  • 数据库查询工具；

  • 天气查询工具；

  • 计算器工具；

  • 文件读写工具；

  • HTTP 接口调用工具。

每个工具通常需要定义三部分内容：

工具名称
工具描述
输入参数结构

例如：

名称：search_knowledge

描述：
根据关键词或问题搜索知识库，返回相关文档片段。

参数：
query：搜索内容
top_k：返回结果数量

工具描述非常重要。大模型主要依靠工具名称、描述和参数定义来判断什么时候调用该工具。

如果工具描述含糊，模型就可能选错工具，或者生成错误参数。

3. Prompt

Prompt 用于告诉大模型它的角色、目标和执行规则。

一个简单的 ReAct Prompt 可以写成：

你是一个知识库助手。

你可以使用以下工具：
1. search_knowledge：搜索知识库
2. read_document：读取完整文档

请根据用户问题完成任务。

执行时遵循以下规则：
1. 信息不足时调用工具；
2. 不要编造工具执行结果；
3. 每次只选择一个最合适的工具；
4. 获得结果后判断是否需要继续调用工具；
5. 信息足够时输出最终答案。

在实际项目中，Prompt 还可能包含权限限制、回答格式、最大步骤数和异常处理规则。

4. Agent Loop

Agent Loop 负责控制整个循环过程。

其伪代码如下：

messages := []Message{
    SystemMessage(systemPrompt),
    UserMessage(userQuestion),
}

for step := 0; step < maxSteps; step++ {
    response := chatModel.Generate(messages)

    if response.HasToolCall() {
        toolCall := response.ToolCall()

        result := toolManager.Execute(
            toolCall.Name,
            toolCall.Arguments,
        )

        messages = append(messages, response)
        messages = append(messages, ToolMessage(result))

        continue
    }

    return response.Content
}

return "任务执行步骤超过限制"

Agent Loop 本身并不复杂，它主要完成三件事：

  1. 调用大模型；

  2. 执行大模型选择的工具；

  3. 把工具结果重新交给大模型。

真正复杂的是如何设计工具、上下文和终止条件。

5. 上下文

每执行一步，系统都需要将相关信息加入上下文，例如：

  • 用户原始问题；

  • 模型已经进行的分析；

  • 已经调用过的工具；

  • 工具返回结果；

  • 当前任务状态。

上下文让大模型知道自己已经做过什么，从而避免重复执行。

但是上下文并不是越长越好。随着执行步骤增加，Token 消耗也会不断上升，还可能出现无关信息干扰模型判断的问题。

因此，复杂 Agent 系统通常会对历史信息进行裁剪、摘要或压缩。

五、ReAct 与普通 RAG 的区别

ReAct Agent 经常和 RAG 一起出现，但两者并不是同一个概念。

普通 RAG 的执行流程通常是固定的：

用户问题
   ↓
向量化
   ↓
检索知识库
   ↓
获取相关片段
   ↓
大模型生成回答

无论用户问什么，系统基本都会执行一次检索，然后生成答案。

ReAct Agent 的执行流程则由大模型动态决定：

用户问题
   ↓
大模型判断
   ↓
选择工具
   ↓
执行工具
   ↓
继续判断
   ↓
可能再次调用其他工具

两者的主要区别如下。

对比项普通 RAGReAct Agent
执行流程固定动态
工具数量通常只有检索器可以有多个工具
工具选择系统预先决定大模型动态选择
调用次数通常一次可以多次
适合任务知识问答多步骤复杂任务
可控性较高相对较低
成本较低较高

如果用户只是询问知识库中的一个简单问题，普通 RAG 通常已经足够。

如果任务需要先搜索知识库、再读取完整文档、最后对多个文档进行比较，那么 ReAct Agent 更合适。

六、ReAct Agent 的优点

1. 执行过程灵活

ReAct 不需要开发者提前写死所有步骤。

面对不同问题，大模型可以选择不同工具和不同执行顺序。

2. 可以处理多步骤任务

例如：

搜索相关文档
→ 读取文档内容
→ 提取关键信息
→ 对比多个方案
→ 生成总结

这种任务很难通过一次模型调用完成，而 ReAct 可以拆分成多轮操作。

3. 具有一定可解释性

ReAct 会保留工具调用记录，因此开发者可以查看：

  • 模型选择了哪个工具；

  • 向工具传递了什么参数；

  • 工具返回了什么结果；

  • 为什么继续执行下一步。

这对于调试 Agent 非常重要。

4. 扩展性较强

开发者可以不断向 Agent 注册新的工具，而不需要重写整个执行流程。

例如知识库 Agent 最初只有搜索工具，后续可以继续增加：

  • 完整文档读取；

  • 文档摘要；

  • 多文档对比；

  • FAQ 生成；

  • 数据库查询。

七、ReAct Agent 的问题

ReAct 虽然灵活，但也不是所有场景都适合使用。

1. 容易陷入循环

模型可能反复调用同一个工具：

搜索知识库
→ 结果不满意
→ 再次搜索
→ 仍然不满意
→ 继续搜索

因此系统必须设置最大执行次数，例如最多执行 5 次或 10 次。

2. 工具选择可能错误

大模型可能选择不合适的工具，或者生成错误参数。

解决方式包括：

  • 优化工具名称；

  • 明确工具描述；

  • 使用结构化参数；

  • 减少功能重复的工具；

  • 对参数进行后端校验。

3. 执行成本较高

每完成一次 Thought、Action 和 Observation，都可能需要重新调用大模型。

一个任务如果执行 6 个步骤，可能需要调用模型多次，其 Token 消耗和响应时间都明显高于普通问答。

4. 结果具有不确定性

相同的问题在不同时间执行，大模型可能选择不同工具或不同路径。

因此，对于支付、删除数据、修改权限等高风险操作，不能完全依赖模型自由决策。

这类操作通常需要增加人工确认：

Agent 生成操作计划
→ 用户确认
→ 系统执行操作

5. 对工具返回结果过度信任

工具结果也可能为空、超时或者包含错误数据。

Agent 不能默认工具一定成功，系统需要明确返回：

执行状态
错误信息
结果内容

并让模型根据真实状态决定是否重试或终止任务。

八、ReAct Agent 适合哪些场景

ReAct 更适合目标明确、但执行步骤无法完全提前确定的任务。

常见场景包括：

1. 知识库助手

Agent 可以根据问题动态选择：

  • 搜索知识库；

  • 读取完整文档；

  • 查询文档元数据；

  • 对比多个文档；

  • 汇总答案。

2. 智能客服

Agent 可以先查询用户问题，再调用订单、物流、退款和售后工具。

3. 数据分析助手

Agent 可以根据用户需求查询数据库、执行统计计算并生成分析结论。

4. 运维助手

Agent 可以读取日志、查询服务器状态、分析错误原因并给出处理建议。

5. 编程助手

Agent 可以读取项目文件、搜索代码、执行测试并根据错误结果修改代码。

不过，如果业务流程非常固定，例如注册、登录、支付和审批，使用传统工作流通常更加稳定，没有必要强行使用 ReAct。

九、如何设计一个可靠的 ReAct Agent

设计 ReAct Agent 时，可以重点关注以下几点。

第一，工具数量不要过多。工具越多，大模型选择错误的概率越高。

第二，工具职责必须清晰。不要同时设计多个功能高度相似的搜索工具。

第三，参数必须结构化。推荐使用 JSON Schema 定义工具输入，避免模型生成难以解析的自然语言参数。

第四，设置最大循环次数。防止 Agent 无限执行。

第五，记录运行日志。至少记录模型输出、工具名称、工具参数、工具结果、执行时间和错误信息。

第六，高风险工具需要确认。删除、支付、发送消息、修改权限等操作不能直接执行。

第七，为工具设置超时和重试机制。外部接口不可避免地会出现网络异常。

第八，限制工具权限。Agent 只能访问当前用户有权限操作的数据。

十、总结

ReAct Agent 是一种将大模型推理能力和外部工具调用能力结合起来的 Agent 架构。

它通过下面的循环完成任务：

思考
→ 行动
→ 获取观察结果
→ 继续思考
→ 再次行动
→ 输出最终答案

相比普通大模型问答，ReAct 可以访问实时信息、调用业务系统，并完成多步骤任务。

相比固定的 RAG 流程，ReAct 更加灵活，可以根据用户问题动态选择知识库搜索、完整文档读取、数据库查询等工具。

但灵活性也带来了成本增加、工具误选、重复循环和执行不可控等问题。因此，在实际项目中，ReAct Agent 并不是工具越多越好，也不是执行步骤越复杂越好。

一个可靠的 ReAct Agent，应该具备清晰的工具定义、严格的参数校验、合理的循环限制、完整的运行日志和必要的人工确认机制。

对于简单知识问答，可以优先使用普通 RAG；对于需要动态决策和多工具协作的复杂任务，再使用 ReAct Agent。

只有根据业务场景选择合适的架构，才能真正发挥 Agent 的价值。

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

别让你的 Agent 一口吃成胖子：AI Agent 任务拆分的工程实践指南

avatar AI Agent技术社区
cover

AI Agent律师行业智能体的实践步骤

avatar AI Agent技术社区

MCP + 企业IM架构：AI Agent调用OA、ERP、MES时，身份和权限如何传递？

<think>我们只需要根据内容生成摘要，不超过150字。先理解文章核心：MCP+企业IM架构，AI Agent调用OA/ERP/MES时身份和权限传递。要点：IM从消息入口变任务入口；MCP解决连接，但不解决权限；需要五层身份映射；权限分层（可见性、调用、数据范围、确认）；建议组合MCP+API网关。摘要需简洁。 参考生成： "本文探讨MCP与企业IM集成中AI Agent调用业务系统时的身份权

avatar AI Agent技术社区