很多人面试一聊到 ReAct，第一句话就是：
ReAct = Reason + Act，也就是推理加行动。
这句话不能说错，但只答到这里，基本就停留在“背概念”的层面。
因为面试官真正想听的，不是你会不会把 ReAct 拆成两个英文单词，而是你能不能讲清楚：
ReAct 为什么能让大模型从“会回答”变成“会办事”？
它和普通问答、Function Calling、Workflow 到底有什么区别？
它为什么适合复杂任务，而不是简单闲聊？
它在真实系统里怎么调用工具、读取反馈、继续决策？
如果放到测试开发、后端系统、AI 应用里，应该怎么落地？
很多候选人讲 Agent 时容易飘。
一会儿自主规划，一会儿长期记忆，一会儿多智能体协作，听起来很高级，但真正问到：
这个 Agent 到底怎么一步一步把任务跑完？
就开始答不清楚了。
而 ReAct 正好就是理解 Agent 工作方式的一个核心入口。
它最关键的地方不是“模型会推理”，而是让模型学会一件事：
当前信息不够时，不要硬编答案，而是先判断缺什么，再调用工具补齐信息，然后根据反馈继续决定下一步。
这才是 ReAct 真正重要的地方。
一、ReAct 到底是什么？
ReAct 是 Reasoning 和 Acting 的结合。
也就是让大模型在完成任务时，交替进行：
Reason：推理
Act：行动
Observation：观察工具返回结果
再继续推理
直到形成最终答案
一句话讲清楚：
ReAct 是一种让大模型通过“推理—行动—观察—再推理”的循环，逐步完成复杂任务的 Agent 思路。
它不是让模型一次性把答案说出来，而是让模型边想边做。
比如用户问：
今天上海会不会下雨？我要不要带伞？
普通问答模式下，模型可能直接生成一段建议。
但问题是：模型本身并不知道今天上海的实时天气。
如果它直接回答，很可能只是生成一个“看起来像答案”的内容。
而 ReAct 模式下，模型会先判断：
这是一个实时问题，内部知识不够，需要调用天气工具。
然后它会执行：
调用天气 API
获取降水概率、降雨时段、温度变化
判断是否需要带伞
基于实时结果给出建议
这时模型不是在“凭感觉回答”，而是在基于工具反馈完成任务。
二、ReAct 的核心流程
ReAct 的经典流程可以理解为：
这个流程看起来简单，但它解决了 Agent 系统里最关键的问题：
模型不是一次性回答，而是可以根据环境反馈不断调整下一步。
这也是 ReAct 和普通问答最大的区别。
三、普通问答和 ReAct 最大区别是什么？
普通问答模式下，大模型的工作方式更像这样：
这种方式适合：
解释概念
总结文章
改写文案
翻译文本
写代码片段
回答稳定知识
比如你问：
HTTP 404 是什么意思？
模型可以直接回答，因为这类知识相对稳定，不依赖实时信息。
但如果你问：
帮我查一下今天凌晨接口自动化为什么失败？
这就不是普通问答能解决的问题了。
因为模型必须知道：
哪个项目失败了？
哪些用例失败了？
错误日志是什么？
是否和环境有关？
是否和发布变更有关？
是否是脚本问题还是业务缺陷？
这些信息不在模型内部，需要它去查测试平台、日志系统、发布系统、接口报告。
这就是 ReAct 的价值。
对比项
普通问答
ReAct Agent
核心方式
直接生成答案
推理和行动交替进行
信息来源
模型内部知识
模型知识 + 外部工具
是否能查实时信息
通常不行
可以通过工具获取
是否能执行动作
通常不行
可以调用 API、数据库、脚本、搜索工具
适合任务
概念解释、总结、改写
查询、排查、分析、多步骤任务
最大风险
容易编造
工具调用失控、循环、越权
一句话总结：
普通问答解决“我知道什么”，ReAct 解决“我该怎么一步一步把事情办完”。
四、ReAct 的标准执行过程
面试时不要只说“先推理，再行动”。
这个回答太粗。
更完整的 ReAct 流程，通常包括下面几个步骤：
- Task：理解用户任务
模型先理解用户到底想完成什么。
比如用户说：
帮我分析一下今天凌晨接口自动化失败原因。
这里的目标不是“解释什么是接口自动化”，而是要完成一次问题排查。
- Reason：推理当前缺少什么信息
模型需要判断：
我现在有没有执行报告？
有没有失败用例列表？
有没有错误日志？
有没有最近发布记录？
有没有环境状态信息？
如果这些信息不够，就不能直接下结论。
- Action：选择工具并执行
模型根据当前缺失的信息，选择工具。
可能调用：
测试报告查询工具
日志查询工具
数据库查询工具
发布记录查询工具
接口文档查询工具
缺陷系统查询工具
- Observation：读取工具返回结果
工具执行完成后，会返回结果。
比如：
{
"taskName": "凌晨接口自动化回归",
"totalCases": 120,
"failedCases": 17,
"mainFailedApi": "/order/create",
"error": "Inventory service timeout"
}
模型拿到结果后，需要继续判断：
这个结果是否足够定位问题？是否还需要继续查库存服务日志？
- Final Answer：输出最终答案
当信息足够时，模型才给出结论。
比如：
今天凌晨接口自动化失败主要集中在订单创建接口，直接原因是库存服务调用超时。失败时间与库存服务凌晨发布窗口高度重合，初步判断不是自动化脚本问题，而是依赖服务发布后稳定性异常。建议先回看库存服务发布变更和连接池配置。
这就比一句“可能是环境问题”有价值多了。
五、用一个测试开发场景讲清楚 ReAct
如果你是测试开发方向，面试时最好不要只举“查天气”的例子。
查天气虽然容易理解，但太生活化。
更建议你举一个工作场景。
比如：
用户问：帮我分析一下今天凌晨接口自动化任务为什么失败。
普通问答会怎么做？
普通问答可能会说：
接口自动化失败可能由环境问题、接口变更、测试数据异常、依赖服务不可用、脚本断言错误等原因导致。
这句话没有错，但没用。
因为它只是泛泛而谈，没有真正排查。
ReAct Agent 会怎么做？
它会按步骤推进。
整个过程中，ReAct Agent 做了几件事：
没有直接猜答案
先判断缺少执行报告
查询报告后发现失败集中点
再查日志定位直接原因
再查发布记录验证关联性
最后给出结论和建议
这就是 ReAct 的价值。
它不是更会聊天，而是更会沿着任务往下查。
六、ReAct 为什么这么重要？
因为真实业务里的任务，很少是一步到位的。
用户不会总是问：
什么是 Redis？
更多时候问的是：
为什么今天 Redis 连接突然变慢？
用户不会总是问：
什么是接口自动化？
更多时候问的是：
为什么这次接口自动化通过率突然从 98% 掉到 83%？
用户不会总是问：
什么是测试用例？
更多时候问的是：
根据这份需求，帮我生成测试用例，并检查有没有漏掉异常场景。
这些任务都需要：
查外部信息
调用工具
分析反馈
再决定下一步
最后形成结论
这正是 ReAct 适合的场景。
可以这么理解：
大模型本身擅长语言理解和推理，但不擅长直接访问外部世界。ReAct 通过工具调用，把模型的推理能力和外部系统连接起来。
所以 ReAct 是很多 Agent 系统的基础模式。
它让模型不只是“生成内容”，而是可以“推进任务”。
七、ReAct 和 Function Calling 有什么区别？
这个问题面试很常见。
很多人会把 ReAct 和 Function Calling 混在一起。
其实它们不是一回事。
一句话区分：
ReAct 是一种 Agent 决策模式，Function Calling 是一种工具调用实现方式。
更简单地说：
ReAct 解决的是：模型什么时候该调用工具，调用哪个工具，拿到结果后下一步怎么做。
Function Calling 解决的是：模型如何用结构化参数调用某个函数。
对比项
ReAct
Function Calling
本质
Agent 推理与行动模式
工具调用机制
关注点
如何一步步完成任务
如何规范调用函数
核心问题
什么时候调用工具、调用后怎么继续
函数名是什么、参数是什么
是否必须绑定
不必须
可以作为 ReAct 的实现方式
举例
判断需要查天气，再调用天气工具
调用 get_weather(city="上海")
可以这样回答面试官：
Function Calling 更像是工具接口层，ReAct 更像是工具使用策略。ReAct 的 Act 阶段可以通过 Function Calling 来实现，但 ReAct 不等于 Function Calling。
这个边界一定要讲清楚。
否则很容易被认为只是懂 API，不懂 Agent。
八、ReAct 和 Workflow 有什么区别？
现在很多 AI 应用平台都有 Workflow，比如 Dify、Coze、n8n、LangGraph 等。
面试官可能会继续问：
那 ReAct 和工作流有什么区别？
可以这样回答：
Workflow 更适合流程明确、步骤固定的任务；ReAct 更适合路径不确定、需要根据反馈动态调整的任务。
对比项
Workflow 工作流
ReAct
流程特点
预先编排
动态决策
执行路径
相对固定
根据反馈变化
可控性
更强
需要额外治理
灵活性
相对有限
更强
适合场景
固定审批、定时报表、标准流程
排障分析、复杂问答、多工具协作
风险点
流程僵硬
工具乱调、循环失控、越权操作
举个例子。
如果任务是：
每天上午 9 点拉取数据，清洗后生成报表，发送到群里。
这更适合 Workflow。
因为步骤很固定。
但如果任务是：
帮我分析为什么今天转化率突然下降。
这更适合 ReAct。
因为排查路径不确定，可能要查：
投放数据
页面变更
用户行为
接口错误率
支付失败率
客服反馈
发布记录
下一步怎么查，要根据前一步结果决定。
所以：
稳定流程用 Workflow，不确定任务用 ReAct。实际工程里，两者经常结合使用。
九、ReAct 在工程里怎么落地？
一个简单的 ReAct Agent 系统，通常不是只有一个大模型。
它至少包括下面几层：
- Agent Controller：控制循环
负责控制整个 ReAct 流程。
它要决定：
最多执行几轮
是否继续调用工具
什么时候停止
超时怎么处理
工具失败是否重试
是否需要人工确认
没有 Controller，Agent 很容易失控。
- LLM 推理层：判断下一步
负责理解任务和做决策。
它要判断：
当前任务是什么？
现有信息够不够？
缺少什么信息？
应该调用哪个工具？
工具参数是什么？
工具结果是否足够？
是否可以输出最终答案？
- Tool Router：工具路由
负责把模型的动作转换成真实工具调用。
比如模型决定查询测试报告，Tool Router 就需要调用对应接口：
{
"tool": "query_test_report",
"params": {
"project": "order-service",
"date": "2026-06-27",
"taskType": "api-regression"
}
}
Tool Router 不是简单转发。
它还要做：
工具是否存在校验
参数是否合法校验
权限是否允许校验
调用频率控制
异常结果兜底
调用日志记录
- Observation Parser：结果解析
工具返回结果后，最好不要直接把一大段原始文本丢给模型。
更好的方式是做结构化处理：
{
"status": "success",
"summary": "订单创建接口失败率升高",
"data": {
"totalCases": 120,
"failedCases": 17,
"mainError": "Inventory service timeout",
"affectedApi": "/order/create"
},
"confidence": "high"
}
结构化反馈更利于模型继续判断。
十、ReAct 的伪代码怎么写？
面试时如果你能写出一个简单伪代码，会比只讲概念更有说服力。
def react_agent(user_task):
context = []
max_steps = 5
for step in range(max_steps):
# 1. 模型基于用户任务和已有上下文判断下一步
decision = llm_reason(
task=user_task,
context=context
)
# 2. 如果模型认为信息足够，就生成最终答案
if decision["type"] == "final_answer":
return decision["answer"]
# 3. 如果需要调用工具，先获取工具名和参数
if decision["type"] == "tool_call":
tool_name = decision["tool"]
params = decision["params"]
# 4. 工具权限和参数校验
validate_tool(tool_name, params)
# 5. 执行工具
observation = call_tool(tool_name, params)
# 6. 将工具返回结果加入上下文，进入下一轮
context.append({
"tool": tool_name,
"params": params,
"observation": observation
})
return"当前任务未能在限定步骤内完成，建议补充信息或转人工处理。"
这段代码说明了几个关键点：
ReAct 是循环结构
每一轮都要判断是否需要工具
工具调用前要做校验
工具返回结果要进入上下文
必须有最大轮次限制
这比单纯背“Reason + Act”要强很多。
十一、ReAct 在测试开发里的典型应用
如果你是测试开发从业者，面试时可以从这些场景展开。
- 需求生成测试用例
用户输入一份需求文档后，ReAct Agent 可以：
阅读需求文档
判断是否缺少接口说明
查询接口文档
查询历史用例
生成测试点
补充边界场景和异常场景
输出结构化测试用例
这比单纯让模型“根据需求写用例”更可靠。
因为它会主动补齐上下文。
- 自动化失败归因
自动化失败后，ReAct Agent 可以：
查询失败报告
聚合失败用例
查看错误日志
查询服务健康状态
查询发布记录
判断失败类型
给出处理建议
最终可以区分：
脚本问题
环境问题
测试数据问题
接口变更问题
依赖服务异常
真实业务缺陷
这就是测试平台智能化的典型方向。
- 缺陷报告辅助生成
用户输入一段问题描述后，Agent 可以：
判断描述是否完整
提醒补充复现步骤
查询历史相似缺陷
判断是否重复提交
补充影响范围
生成规范缺陷报告
比如原始描述是：
支付失败了。
Agent 可以继续追问或调用工具补充：
哪个用户？
哪个订单？
哪个支付渠道？
错误码是什么？
是否所有用户都失败？
是否和近期发布有关？
这就比简单润色缺陷标题更有价值。
- 测试数据准备
比如用户说：
我要测新用户首单优惠。
ReAct Agent 可以判断需要准备：
新用户账号
手机号绑定
优惠券配置
商品库存
订单创建
支付链路
优惠金额校验
然后调用不同工具准备数据。
这类任务不是普通问答，而是典型的多步骤执行任务。
十二、ReAct 的优势是什么？
- 能处理多步骤任务
很多真实任务不能一步完成。
ReAct 可以通过多轮推理和工具调用逐步推进。
比如：
查报告 → 查日志 → 查发布 → 归因 → 生成建议。
- 能连接外部系统
大模型本身不能直接访问数据库、日志平台、测试平台、业务系统。
但 ReAct 可以通过工具调用把这些系统接进来。
这让模型从“知识问答”变成“任务执行”。
- 能根据反馈调整路径
ReAct 不是死流程。
如果工具返回结果不完整，它可以继续补查。
如果发现方向错了，它可以换一个工具。
如果信息已经足够，它可以停止并输出答案。
- 更接近真实工作方式
人类排查问题时，本来也是这样：
先看现象
判断可能原因
查一个证据
根据证据调整判断
继续查
最后形成结论
ReAct 只是把这套过程放到了 Agent 系统里。
十三、ReAct 的风险是什么？
讲 ReAct 不能只讲优点。
面试官更看重你是否知道它的边界。
- 可能无限循环
如果没有限制，Agent 可能一直推理、一直调用工具、一直无法结束。
所以必须设置：
最大执行轮次
最大工具调用次数
单次工具超时时间
总任务超时时间
失败兜底策略
- 可能调用错误工具
模型可能选错工具，也可能传错参数。
所以工具层必须做：
工具白名单
参数类型校验
必填字段校验
权限校验
风险等级校验
- 工具结果可能不可靠
工具返回结果不一定都是可信的。
可能出现：
工具超时
返回空数据
返回脏数据
接口报错
数据不一致
权限不足
所以不能“工具返回什么就信什么”。
需要做：
错误码识别
结果结构化
置信度判断
多工具交叉验证
异常兜底回答
- 高风险动作不能自动执行
尤其是涉及生产环境时，不能让 Agent 想做什么就做什么。
比如：
删除数据
修改配置
发布上线
触发生产任务
批量发送消息
修改用户权限
这些都不能直接交给 Agent 自动执行。
更合理的方式是分级控制：
工具类型
示例
建议策略
查询类
查日志、查报告、查知识库
可以自动执行
分析类
总结原因、生成建议
可以自动执行
低风险写入
创建草稿、生成待审核用例
可自动执行，但要记录
中风险操作
提交缺陷、触发测试任务
建议人工确认
高风险操作
删除数据、发布上线、修改生产配置
禁止自动执行或必须审批
十四、ReAct 是否要把推理过程展示给用户？
这也是一个很重要的工程问题。
很多教学文章会写成：
Thought: 我需要查询天气
Action: 调用天气工具
Observation: 下午有雨
Thought: 用户应该带伞
Final Answer: 建议带伞
这种格式适合学习，但不一定适合生产环境。
真实系统里，不建议把完整推理过程原样展示给用户。
更合理的方式是：
对用户展示关键依据和最终结论
内部记录工具调用日志
保留必要的决策摘要
隐藏敏感推理细节
对高风险操作保留审计记录
比如用户看到的是：
我查询了上海今天的天气信息，下午 3 点后降水概率较高，建议带伞。
而不是看到完整的内部推理链路。
面试时可以这样答：
ReAct 的思想是推理和行动交替，但生产环境不一定要把完整推理过程暴露给用户。更常见的做法是展示关键依据和结论，同时在系统内部保留工具调用记录、参数、返回结果和必要的决策摘要，方便审计和排查。
这个回答会显得更工程化。
十五、一个高质量 ReAct Agent 应该怎么设计？
如果面试官继续追问：
如果让你实现一个 ReAct Agent，你会重点关注什么？
可以从下面几个方面回答。
- 工具定义要清晰
工具描述越清楚，模型越容易选对。
不要给模型一个“万能工具”。
比如：
{
"name": "query_test_report",
"description": "查询指定项目在指定时间范围内的自动化测试报告",
"params": {
"project": "string",
"start_time": "string",
"end_time": "string"
}
}
这个工具的边界很清楚：
只能查测试报告，不能查日志，也不能修改数据。
- 工具权限要分级
不同工具的风险等级不一样。
查询日志和删除数据，绝对不能放在同一个权限级别。
可以这样设计：
- 执行轮次要限制
ReAct 不是越多轮越好。
轮次越多，成本越高，延迟越高，失控风险也越大。
所以要限制：
最大推理轮次
最大工具调用次数
最大 Token 消耗
最大任务执行时间
最大重试次数
- 工具返回要结构化
工具最好返回结构化结果，而不是一大段自然语言。
比如：
{
"result": "failed",
"reason": "database connection timeout",
"affected_cases": 23,
"suggestion": "check database connection pool and recent deployment"
}
结构化结果更容易被模型继续使用。
- 过程必须可观测
Agent 系统一旦上线，必须能追踪过程。
否则出问题时根本不知道它为什么这么做。
至少要记录：
用户原始输入
每一轮模型决策
调用了哪个工具
工具参数是什么
工具返回结果是什么
是否重试
是否触发人工确认
最终答案依据是什么
没有可观测性，Agent 很难进生产环境。
十六、面试标准答案：ReAct 工作原理是什么？
如果面试官直接问：
ReAct 的工作原理是什么？
可以这样回答：
ReAct 是 Reasoning 和 Acting 的结合，它让大模型在完成任务时，不是直接生成答案，而是交替进行推理和行动。
模型会先理解用户任务和当前上下文，判断已有信息是否足够。如果信息不足，它会推理缺少什么信息，并选择合适的工具去执行，比如搜索、查数据库、调 API、查日志、查测试报告等。工具返回结果后，模型会把这个结果作为新的观察信息，再继续判断下一步，直到可以形成最终答案。
所以 ReAct 的核心是“推理—行动—观察—再推理”的闭环。它比普通问答更适合实时查询、多步骤任务、复杂排查和外部系统协作。
这段回答基本可以覆盖大部分面试场景。
十七、面试官继续追问，可以这样答
- ReAct 和普通问答有什么区别？
普通问答是模型基于已有知识直接生成答案，适合解释概念、总结文本、写作改写等任务。
ReAct 会先判断信息是否足够，如果信息不足，会主动调用工具获取外部信息，并根据工具反馈继续推理。它更适合实时查询、多步骤操作和复杂业务任务。
- ReAct 和 Function Calling 有什么区别？
Function Calling 是工具调用机制，解决的是怎么用结构化参数调用函数。
ReAct 是 Agent 决策模式，解决的是模型什么时候该调用工具、调用哪个工具、拿到工具结果后下一步怎么做。
Function Calling 可以作为 ReAct 的 Act 阶段实现方式，但 ReAct 不等于 Function Calling。
- ReAct 和 Workflow 有什么区别？
Workflow 是预先编排好的固定流程，适合路径明确、步骤稳定的任务。
ReAct 是动态决策模式，会根据每一步反馈决定下一步，适合排查类、分析类、多路径不确定的任务。
实际系统里两者可以结合：稳定流程用 Workflow，不确定节点交给 ReAct Agent。
- ReAct 有什么风险？
主要风险包括工具调用错误、循环次数失控、工具结果不可靠、执行高风险动作等。
工程上需要通过工具白名单、参数校验、权限分级、最大轮次限制、超时控制、人工确认和审计日志来降低风险。
- ReAct 适合哪些场景？
ReAct 适合需要多步推理和外部工具协作的场景，比如智能客服、知识库问答、日志分析、自动化测试失败归因、测试用例生成、运维排障、数据查询等。
如果任务只是简单文本生成，或者流程完全固定，不一定需要 ReAct。
十八、最后总结
ReAct 不是一个复杂到听不懂的概念。
它最核心的逻辑就是：
当模型发现当前信息不够时，不要硬答，而是先推理缺什么，再调用工具补齐信息，然后根据反馈继续判断下一步。
这件事看起来简单，但它是 Agent 从“会聊天”走向“会做事”的关键一步。
普通问答解决的是：
我知道什么。
ReAct 解决的是：
我现在不知道完整答案，但我知道下一步该查什么、该调用什么、该怎么根据结果继续推进。
所以，面试官问 ReAct，表面是在问一个 Agent 概念。
实际上是在看你有没有理解：
大模型为什么需要工具
Agent 为什么需要反馈闭环
ReAct 和普通问答有什么本质区别
ReAct 和 Function Calling、Workflow 的边界在哪里
一个 Agent 系统怎么才能真正落到工程里
真正理解 ReAct，不是会背 Reason + Act。
而是能讲清楚：
一个 Agent 到底是怎么一步一步把真实任务跑完的。
