面试必备:AI Agent核心框架ReAct万字深度剖析
近来,不少求职者在应聘AI应用工程师、Agent应用工程师或AI产品经理等岗位时,常常遇到一个高频面试问题:
ReAct究竟是什么?它主要用来解决什么问题?
坦白说,这个问题涵盖的范围相当广泛,作为常规岗位的面试题可能不太适宜。
但请注意,这绝不意味着ReAct不重要。恰恰相反,ReAct本身极为关键,只是要透彻理解它,几乎需要梳理清楚整个Agent的架构体系,因此大多数应聘者很难给出令人满意的答案。
另一方面,对于多数从业者而言,这个词显得较为**“低频”**。这是因为许多(中小型)公司的负责人引入Agent概念更多是为了融资或宣传,并非真心打算将其应用于实际生产环境,导致许多同学缺乏相关的实践机会。最终结果是:
大多数人仅仅通过文章有所耳闻,整体认知非常模糊。 那么,ReAct到底是什么?
ReAct = Reason(推理) + Act(行动),这是由Google和普林斯顿大学的研究人员在2022年提出的一种范式:
- 推理(Reasoning): 驱使大语言模型思考“为何”以及“如何”执行某项行动。
- 行动(Acting): 驱使大语言模型执行具体行动,并与外部环境进行交互。
- 循环反馈: 通过观察行动结果来驱动下一步的推理过程。
简单翻译就是:先思考,再行动。但这似乎仍未彻底解答其必要性、本质内涵及实现方法,因此我们需要追根溯源。
为何需要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架构的实现。

ReAct架构核心解析
首先,ReAct架构本质上是一套循环执行的工作流:
... → 推理(Thought) → 行动(Action) → 观察(Observation) → ...
这一范式的精髓在于,在 “思考-行动-观察” 的持续循环中逐步推进并完成任务。换言之,智能体(Agent)一边盘算如何解决问题,一边调用工具获取必要信息,随后依据观察到的结果调整后续计划,直至得出最终答案。
下面通过一个具体案例演示该过程。问题:“2018年世界杯冠军国家的总统是谁?” 其完整的推理与行动链条可能如下:
- 推理(Thought): 用户的问题是“2018年世界杯冠军国家的总统”。这是一个复合型问题,需要拆解为两个步骤:首先查明2018年世界杯的冠军国家,然后查询该国的现任总统信息。
- 行动(Action): 调用搜索引擎工具,查询关键词“2018年世界杯 冠军”。
- 观察(Observation): 工具返回结果:“2018年世界杯冠军是法国队。”
- 推理(Thought): 智能体获知冠军国家是法国。下一步需要查明法国总统是谁。
- 行动(Action): 再次调用搜索引擎工具,查询关键词“法国现任总统”。
- 观察(Observation): 搜索结果显示:“法国现任总统是埃马纽埃尔·马克龙(Emmanuel Macron)。”
- 最终回答: 综合全部收集到的信息,智能体向用户回答:“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架构实现到后期,难点往往都集中在上下文设计上。当前常用的技巧是利用一个“中央记事本”来记录复杂任务过程中的所有关键信息,包括:
- 用户的原始提问是什么;
- 目前已经掌握了哪些信息;
- 尝试过哪些方法或工具;
- 哪些信息已被交叉验证为真实可靠;
- …
在AI工程实践中,要妥善实现上述状态管理本身就颇具挑战。这里采用的分层设计允许系统在不同粒度上管理状态,既避免了单一状态对象变得过于臃肿,也有效控制了项目的整体复杂度。
具体实现细节在此不展开,大家可参考相关开源项目。这里给出状态管理的伪代码示例:
状态对象 = {
任务ID: "查询_001",
原始问题: "2018世界杯冠军国家的总统是谁",
已验证事实: {
"冠军国家": "法国",
"法国总统": "马克龙"
},
思考记录: ["这是一个复合问题,需要分两步解决..."],
行动记录: [
{工具: "搜索", 查询: "2018世界杯冠军"},
{工具: "搜索", 查询: "法国现任总统"}
],
当前步骤: 3
}
二、决策引擎流程
设计好基础状态(亦可称为上下文工程)是第一步,第二步则是将AI的思考过程清晰地展示出来,类似于人类的解题步骤:
- 分析当前所处的情况与已知信息。
- 确定还需要获取哪些关键信息。
- 选择获取信息的最佳方法(即选择合适的工具)。
- 评估工具执行的结果,并据此决定下一步行动。
具体代码实现略过,其核心流程如下图所示:
开始
↓
分析当前状态
├── 已有足够信息? → 生成最终答案
├── 需要外部信息? → 选择合适工具并执行
└── 需要更多分析? → 进入深入思考环节
↓
执行决策(调用工具或生成答案)
↓
更新全局状态与上下文
↓
检查任务是否完成
├── 是 → 流程结束
└── 否 → 返回“分析当前状态”步骤,开始新一轮循环
三、工具调用机制
如上所述,除了模型自身的知识储备,AI解决问题的核心途径就是工具调用。这包括案例中使用的搜索引擎,以及更常见的知识库查询工具等。只要模型需要与外部世界交互,都离不开工具调用。在ReAct模式中,工具调用的流程相对固定:
- 需求匹配: 确定当前步骤需要什么工具。
- 工具选择: 从可用工具池中挑选最合适的一个。
- 参数准备: 根据工具定义,准备所需的输入参数。
- 执行调用: 运行工具并获取返回结果。
- 结果验证: 检查工具返回的结果是否可靠、可用。
四、案例流程代码化演示
我们依旧以“2018世界杯冠军国家的总统是谁?”为例。第一步是初始化任务状态:
{
任务: "2018世界杯冠军国家的总统是谁?",
已知信息: {},
待查信息: ["2018冠军国家", "该国总统"]
}
接着是首次决策与行动循环:
AI思考: “这是一个复合问题,首先需要找到冠军国家。”
AI行动: 使用搜索工具,查询“2018世界杯冠军”。
工具结果: “2018年世界杯冠军是法国队。”
更新状态: 在已知信息中添加“冠军国家=法国”。
然后是第二次决策与行动循环:
AI思考: “已知冠军国家是法国,现在需要查询法国总统信息。”
AI行动: 使用搜索工具,查询“法国现任总统”。
工具结果: “法国现任总统是埃马纽埃尔·马克龙。”
更新状态: 在已知信息中添加“法国总统=马克龙”。
最终,在信息完备的基础上生成答案:
AI思考: “已收集到全部必要信息,可以合成最终答案。”
AI回答: “2018年世界杯冠军是法国,法国总统是埃马纽埃尔·马克龙。”
上述流程在事后复盘时看似简单,但要让模型在实际交互中精准地一步步执行,尤其在复杂的业务场景下,其实是颇具挑战的。需要考虑诸多问题,例如:
- 如何准确判断当前信息是否已足够回答问题?
- 如何制定最有效的搜索关键词?
- 如何处理工具返回的不确定或模糊信息?
- …
上述任何一步出现决策失误,都可能导致任务失败。因此,生产级项目通常会内置大量纠错与重试机制,代价则是更长的响应时间和更多的Token消耗。
下面分享一些实践中的优化技巧。
五、实践优化技巧
首先,思考(Thought)的组织与生成尤为关键。其输入是当前状态信息和预设工具列表,输出是下一步的行动计划。一个清晰有效的提示词模板能极大提升稳定性:
基于当前已知信息 {已知信息},
我们还需要 {缺失信息} 来回答问题。
下一步应该 {行动计划描述},建议使用 {工具名称} 工具。
其次,当可用工具数量众多时,为防止模型随意调用,通常需要建立工具评分与选择机制。例如:
需求:查询实时天气信息。
候选工具:
1. 专用天气API(实时性强、准确性高) → 匹配度评分 90
2. 通用网页搜索(信息可能过时) → 匹配度评分 60
3. 历史天气数据库(非实时数据) → 匹配度评分 30
当然,即使建立了评分模型,最终的选择权仍在AI手中,依然存在判断不准的可能性,这目前难以完全避免。
再者,持续且高效的状态管理是维持Agent稳定运行的基础。其核心原则是“AI可以自由思考,但全局状态必须清晰可控”:
- 分层存储: 区分短期工作记忆与长期知识记忆。
- 智能压缩: 保留关键决策信息,自动清理冗余中间内容。
- 版本控制: 支持关键状态点的回滚,便于错误恢复。
- 依赖跟踪: 显式记录不同信息片段之间的关联关系。
最后,所有AI驱动的产品都需要建立系统的评估体系,即一套衡量其表现好坏的标准。常见的评估维度包括:
- 任务完成率: 用户问题被正确解决的比例。
- 平均响应时间: 从提问到获得最终答案的平均耗时。
- 平均对话轮次: 解决一个问题平均需要多少次交互。
- 用户满意度评分: 用户对答案质量的主观评价。
- 思考过程质量: AI推理步骤的相关性、逻辑性。
- 工具调用准确率: 工具被正确调用并返回有效结果的比例。
- 循环效率: 解决平均每个问题所需的“思考-行动”循环次数。
- 资源消耗: 平均每次对话的API调用次数、Token使用量。
- …
这部分涉及较广,在此不再深入展开。
结语:ReAct的局限与展望
没有完美的解决方案,ReAct范式天生也存在一些局限性,需要客观认识:
一、响应延迟与资源消耗 由于当前大语言模型的输出并非绝对可靠,为了保障最终结果的稳定性,生产流程中往往会引入多次校验环节。这直接导致Agent的整体响应时间偏长,且Token消耗速度较快。例如,曾有案例显示,用户仅请求生成一份PPT就消耗了一个月额度的Token,且任务尚未完成,引发了投诉。
二、过度思考问题 过度思考部分源于模型本身的特性,更换模型可能有所改善。但根本问题在于,AI自身难以判断问题的复杂程度。出于保险起见,它可能在简单场景下也进行不必要的复杂验证。解决方案思路包括:
- 添加前置的问题复杂度分类器。
- 为简单问题设计快捷处理通道。
- 设置“思考预算”,例如Token数或循环次数限制。
三、工具集成与管控挑战 尽管主流模型已原生支持工具调用协议,但许多公司在生产环境中仍倾向于自建一层代理或网关。原因很现实:几乎没有生产级AI应用会毫无保留地直接使用第三方服务进行核心操作。
四、状态管理的复杂性 严格来说,这不完全是ReAct的问题。任何涉及复杂意图识别和多轮交互的AI项目,其上下文工程都会非常复杂。如何设计清晰、高效、可扩展的状态管理层,是AI工程化面临的核心挑战之一。
尽管存在上述挑战,ReAct目前已成为构建可推理、可行动AI Agent的事实标准框架。最后,回到最初的面试问题:ReAct究竟是什么?
ReAct是一套用于构建智能体(Agent)的核心交互范式。其核心作用是赋予大语言模型连接与操作外部世界的能力,并通过结构化、可追溯的推理过程,尽可能降低模型“幻觉”。特别重要的是,ReAct范式产生的完整思考与行动日志是可调试、可观测的,这从工程层面显著增强了AI应用的可控性与透明度。
希望以上的解析能对大家有所帮助。