面试必备：AI Agent核心框架ReAct万字深度剖析

近来，不少求职者在应聘AI应用工程师、Agent应用工程师或AI产品经理等岗位时，常常遇到一个高频面试问题：

ReAct究竟是什么？它主要用来解决什么问题？

坦白说，这个问题涵盖的范围相当广泛，作为常规岗位的面试题可能不太适宜。

但请注意，这绝不意味着ReAct不重要。恰恰相反，ReAct本身极为关键，只是要透彻理解它，几乎需要梳理清楚整个Agent的架构体系，因此大多数应聘者很难给出令人满意的答案。

另一方面，对于多数从业者而言，这个词显得较为**“低频”**。这是因为许多（中小型）公司的负责人引入Agent概念更多是为了融资或宣传，并非真心打算将其应用于实际生产环境，导致许多同学缺乏相关的实践机会。最终结果是：

大多数人仅仅通过文章有所耳闻，整体认知非常模糊。 那么，ReAct到底是什么？

ReAct = Reason（推理） + Act（行动），这是由Google和普林斯顿大学的研究人员在2022年提出的一种范式：

  1. 推理（Reasoning）： 驱使大语言模型思考“为何”以及“如何”执行某项行动。
  2. 行动（Acting）： 驱使大语言模型执行具体行动，并与外部环境进行交互。
  3. 循环反馈： 通过观察行动结果来驱动下一步的推理过程。

简单翻译就是：先思考，再行动。但这似乎仍未彻底解答其必要性、本质内涵及实现方法，因此我们需要追根溯源。

为何需要ReAct框架？

从模型能力的演进历程来看，我们旨在解决大语言模型**“只能思考与言说，无法实际操作”** 的固有局限。

在此背景下，Function Calling（函数调用）或Model Context Protocol（MCP）等概念应运而生。其基本模式是预先定义一系列工具并将其挂载到模型（请求）上，每次由模型根据用户问题与工具参数（如描述、名称等）来判断是否需要调用特定工具。

以经典问题**“成都最近两天天气怎么样？”** 为例，若期望模型自动调用工具，通常需要如下配置：

# 将“工具”挂载到模型上：此处是一个 get_weather 函数
{
"type": "function",
"function": {
    "name": "get_weather",
    "description": "查询未来几天某个城市的天气预报",
    "parameters": {
      "type": "object",
      "properties": {
          "city": {
            "type": "string",
            "description": "城市名，例如：成都"
          },
          "days": {
            "type": "integer",
            "description": "查询多少天的预报（1-7天）"
          }
      }
      "required": ["city", "days"]
    }
  }
}

在基本交互模型确立之后，问题接踵而至：真实应用场景中工具数量庞大、用户提问模糊不清、用户意图复杂多样…

总而言之，所有难题叠加在一起，可以归结为一句话：模型在工具调用方面的表现不尽如人意。

于是，思维链CoT（Chain-of-Thought） 技术登场了。它要求模型对用户问题进行深入分析，将复杂问题分解为一系列小步骤（对应小工具调用），然后观察这些工具依次执行，成功完成一步再进行下一步，期望借此提升整体AI产品的用户体验。

最后总结一下，ReAct旨在解决的核心问题是：将“懂得思考”与“能够操作外部世界”这两种能力紧密结合，形成一个可观察、可迭代的闭环任务流程。

接下来，我们通过一个简单实例来详细解析ReAct架构的实现。

Image

ReAct架构核心解析

首先，ReAct架构本质上是一套循环执行的工作流：

... → 推理（Thought） → 行动（Action） → 观察（Observation） → ...

这一范式的精髓在于，在 “思考-行动-观察” 的持续循环中逐步推进并完成任务。换言之，智能体（Agent）一边盘算如何解决问题，一边调用工具获取必要信息，随后依据观察到的结果调整后续计划，直至得出最终答案。

下面通过一个具体案例演示该过程。问题：“2018年世界杯冠军国家的总统是谁？” 其完整的推理与行动链条可能如下：

  1. 推理（Thought）： 用户的问题是“2018年世界杯冠军国家的总统”。这是一个复合型问题，需要拆解为两个步骤：首先查明2018年世界杯的冠军国家，然后查询该国的现任总统信息。
  2. 行动（Action）： 调用搜索引擎工具，查询关键词“2018年世界杯 冠军”。
  3. 观察（Observation）： 工具返回结果：“2018年世界杯冠军是法国队。”
  4. 推理（Thought）： 智能体获知冠军国家是法国。下一步需要查明法国总统是谁。
  5. 行动（Action）： 再次调用搜索引擎工具，查询关键词“法国现任总统”。
  6. 观察（Observation）： 搜索结果显示：“法国现任总统是埃马纽埃尔·马克龙（Emmanuel Macron）。”
  7. 最终回答： 综合全部收集到的信息，智能体向用户回答：“2018年世界杯冠军法国的总统是埃马纽埃尔·马克龙。”

在整个解题过程中，智能体经历了两轮完整的 “思考→行动→观察” 循环，逐步拆解并解决了这个复杂问题。

当前业界普遍认同且有数据支撑的观点是：CoT技术能够有效降低模型的“幻觉”现象，这也是ReAct框架的重要意义之一。接下来，我们探讨其简易实现方案。

一、状态管理设计

├── 全局状态
│   ├── task_id: "query_？？？"
│   ├── original_query: "2018世界杯冠军国家的总统是谁"
│   ├── task_graph: 任务依赖关系图
│   └── verified_facts: {"france_won_2018": true}
│
├── 会话状态
│   ├── current_plan: 当前执行计划
│   ├── available_tools: [search, calculator, ...]
│   └── context_window: 最近10轮思考与行动历史
│
└── 执行状态
    ├── step_id: "step_001"
    ├── current_action: {"tool": "search", "params": {...}}
    └── partial_results: {}

Agent架构实现到后期，难点往往都集中在上下文设计上。当前常用的技巧是利用一个“中央记事本”来记录复杂任务过程中的所有关键信息，包括：

  1. 用户的原始提问是什么；
  2. 目前已经掌握了哪些信息；
  3. 尝试过哪些方法或工具；
  4. 哪些信息已被交叉验证为真实可靠；
  5. …

在AI工程实践中，要妥善实现上述状态管理本身就颇具挑战。这里采用的分层设计允许系统在不同粒度上管理状态，既避免了单一状态对象变得过于臃肿，也有效控制了项目的整体复杂度。

具体实现细节在此不展开，大家可参考相关开源项目。这里给出状态管理的伪代码示例：

状态对象 = {
  任务ID: "查询_001",
  原始问题: "2018世界杯冠军国家的总统是谁",
  已验证事实: {
    "冠军国家": "法国",
    "法国总统": "马克龙"
  },
  思考记录: ["这是一个复合问题，需要分两步解决..."],
  行动记录: [
    {工具: "搜索", 查询: "2018世界杯冠军"},
    {工具: "搜索", 查询: "法国现任总统"}
  ],
  当前步骤: 3
}

二、决策引擎流程

设计好基础状态（亦可称为上下文工程）是第一步，第二步则是将AI的思考过程清晰地展示出来，类似于人类的解题步骤：

  1. 分析当前所处的情况与已知信息。
  2. 确定还需要获取哪些关键信息。
  3. 选择获取信息的最佳方法（即选择合适的工具）。
  4. 评估工具执行的结果，并据此决定下一步行动。

具体代码实现略过，其核心流程如下图所示：

开始
  ↓
分析当前状态
  ├── 已有足够信息？ → 生成最终答案
  ├── 需要外部信息？ → 选择合适工具并执行
  └── 需要更多分析？ → 进入深入思考环节
  ↓
执行决策（调用工具或生成答案）
  ↓
更新全局状态与上下文
  ↓
检查任务是否完成
  ├── 是 → 流程结束
  └── 否 → 返回“分析当前状态”步骤，开始新一轮循环

三、工具调用机制

如上所述，除了模型自身的知识储备，AI解决问题的核心途径就是工具调用。这包括案例中使用的搜索引擎，以及更常见的知识库查询工具等。只要模型需要与外部世界交互，都离不开工具调用。在ReAct模式中，工具调用的流程相对固定：

  1. 需求匹配： 确定当前步骤需要什么工具。
  2. 工具选择： 从可用工具池中挑选最合适的一个。
  3. 参数准备： 根据工具定义，准备所需的输入参数。
  4. 执行调用： 运行工具并获取返回结果。
  5. 结果验证： 检查工具返回的结果是否可靠、可用。

四、案例流程代码化演示

我们依旧以“2018世界杯冠军国家的总统是谁？”为例。第一步是初始化任务状态：

{
  任务: "2018世界杯冠军国家的总统是谁？",
  已知信息: {},
  待查信息: ["2018冠军国家", "该国总统"]
}

接着是首次决策与行动循环：

AI思考: “这是一个复合问题，首先需要找到冠军国家。”
AI行动: 使用搜索工具，查询“2018世界杯冠军”。
工具结果: “2018年世界杯冠军是法国队。”
更新状态: 在已知信息中添加“冠军国家=法国”。

然后是第二次决策与行动循环：

AI思考: “已知冠军国家是法国，现在需要查询法国总统信息。”
AI行动: 使用搜索工具，查询“法国现任总统”。
工具结果: “法国现任总统是埃马纽埃尔·马克龙。”
更新状态: 在已知信息中添加“法国总统=马克龙”。

最终，在信息完备的基础上生成答案：

AI思考: “已收集到全部必要信息，可以合成最终答案。”
AI回答: “2018年世界杯冠军是法国，法国总统是埃马纽埃尔·马克龙。”

上述流程在事后复盘时看似简单，但要让模型在实际交互中精准地一步步执行，尤其在复杂的业务场景下，其实是颇具挑战的。需要考虑诸多问题，例如：

  1. 如何准确判断当前信息是否已足够回答问题？
  2. 如何制定最有效的搜索关键词？
  3. 如何处理工具返回的不确定或模糊信息？
  4. …

上述任何一步出现决策失误，都可能导致任务失败。因此，生产级项目通常会内置大量纠错与重试机制，代价则是更长的响应时间和更多的Token消耗。

下面分享一些实践中的优化技巧。

五、实践优化技巧

首先，思考（Thought）的组织与生成尤为关键。其输入是当前状态信息和预设工具列表，输出是下一步的行动计划。一个清晰有效的提示词模板能极大提升稳定性：

基于当前已知信息 {已知信息}，
我们还需要 {缺失信息} 来回答问题。
下一步应该 {行动计划描述}，建议使用 {工具名称} 工具。

其次，当可用工具数量众多时，为防止模型随意调用，通常需要建立工具评分与选择机制。例如：

需求：查询实时天气信息。
候选工具：
1. 专用天气API（实时性强、准确性高） → 匹配度评分 90
2. 通用网页搜索（信息可能过时） → 匹配度评分 60
3. 历史天气数据库（非实时数据） → 匹配度评分 30

当然，即使建立了评分模型，最终的选择权仍在AI手中，依然存在判断不准的可能性，这目前难以完全避免。

再者，持续且高效的状态管理是维持Agent稳定运行的基础。其核心原则是“AI可以自由思考，但全局状态必须清晰可控”：

  1. 分层存储： 区分短期工作记忆与长期知识记忆。
  2. 智能压缩： 保留关键决策信息，自动清理冗余中间内容。
  3. 版本控制： 支持关键状态点的回滚，便于错误恢复。
  4. 依赖跟踪： 显式记录不同信息片段之间的关联关系。

最后，所有AI驱动的产品都需要建立系统的评估体系，即一套衡量其表现好坏的标准。常见的评估维度包括：

  1. 任务完成率： 用户问题被正确解决的比例。
  2. 平均响应时间： 从提问到获得最终答案的平均耗时。
  3. 平均对话轮次： 解决一个问题平均需要多少次交互。
  4. 用户满意度评分： 用户对答案质量的主观评价。
  5. 思考过程质量： AI推理步骤的相关性、逻辑性。
  6. 工具调用准确率： 工具被正确调用并返回有效结果的比例。
  7. 循环效率： 解决平均每个问题所需的“思考-行动”循环次数。
  8. 资源消耗： 平均每次对话的API调用次数、Token使用量。
  9. …

这部分涉及较广，在此不再深入展开。

结语：ReAct的局限与展望

没有完美的解决方案，ReAct范式天生也存在一些局限性，需要客观认识：

一、响应延迟与资源消耗 由于当前大语言模型的输出并非绝对可靠，为了保障最终结果的稳定性，生产流程中往往会引入多次校验环节。这直接导致Agent的整体响应时间偏长，且Token消耗速度较快。例如，曾有案例显示，用户仅请求生成一份PPT就消耗了一个月额度的Token，且任务尚未完成，引发了投诉。

二、过度思考问题 过度思考部分源于模型本身的特性，更换模型可能有所改善。但根本问题在于，AI自身难以判断问题的复杂程度。出于保险起见，它可能在简单场景下也进行不必要的复杂验证。解决方案思路包括：

  • 添加前置的问题复杂度分类器。
  • 为简单问题设计快捷处理通道。
  • 设置“思考预算”，例如Token数或循环次数限制。

三、工具集成与管控挑战 尽管主流模型已原生支持工具调用协议，但许多公司在生产环境中仍倾向于自建一层代理或网关。原因很现实：几乎没有生产级AI应用会毫无保留地直接使用第三方服务进行核心操作。

四、状态管理的复杂性 严格来说，这不完全是ReAct的问题。任何涉及复杂意图识别和多轮交互的AI项目，其上下文工程都会非常复杂。如何设计清晰、高效、可扩展的状态管理层，是AI工程化面临的核心挑战之一。

尽管存在上述挑战，ReAct目前已成为构建可推理、可行动AI Agent的事实标准框架。最后，回到最初的面试问题：ReAct究竟是什么？

ReAct是一套用于构建智能体（Agent）的核心交互范式。其核心作用是赋予大语言模型连接与操作外部世界的能力，并通过结构化、可追溯的推理过程，尽可能降低模型“幻觉”。特别重要的是，ReAct范式产生的完整思考与行动日志是可调试、可观测的，这从工程层面显著增强了AI应用的可控性与透明度。

希望以上的解析能对大家有所帮助。