很多人面试一聊到 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选择工具并执行模型根据当前缺失的信息选择工具。可能调用测试报告查询工具日志查询工具数据库查询工具发布记录查询工具接口文档查询工具缺陷系统查询工具4. 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 解决的是模型如何用结构化参数调用某个函数。对比项ReActFunction 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 流程。它要决定最多执行几轮是否继续调用工具什么时候停止超时怎么处理工具失败是否重试是否需要人工确认没有 ControllerAgent 很容易失控。LLM 推理层判断下一步负责理解任务和做决策。它要判断当前任务是什么现有信息够不够缺少什么信息应该调用哪个工具工具参数是什么工具结果是否足够是否可以输出最终答案3. Tool Router工具路由负责把模型的动作转换成真实工具调用。比如模型决定查询测试报告Tool Router 就需要调用对应接口{“tool”: “query_test_report”,“params”: {“project”: “order-service”,“date”: “2026-06-27”,“taskType”: “api-regression”}}Tool Router 不是简单转发。它还要做工具是否存在校验参数是否合法校验权限是否允许校验调用频率控制异常结果兜底调用日志记录4. 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 5for step in range(max_steps): # 1. 模型基于用户任务和已有上下文判断下一步 decision llm_reason( taskuser_task, contextcontext ) # 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 可能一直推理、一直调用工具、一直无法结束。所以必须设置最大执行轮次最大工具调用次数单次工具超时时间总任务超时时间失败兜底策略2. 可能调用错误工具模型可能选错工具也可能传错参数。所以工具层必须做工具白名单参数类型校验必填字段校验权限校验风险等级校验3. 工具结果可能不可靠工具返回结果不一定都是可信的。可能出现工具超时返回空数据返回脏数据接口报错数据不一致权限不足所以不能“工具返回什么就信什么”。需要做错误码识别结果结构化置信度判断多工具交叉验证异常兜底回答4. 高风险动作不能自动执行尤其是涉及生产环境时不能让 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 消耗最大任务执行时间最大重试次数4. 工具返回要结构化工具最好返回结构化结果而不是一大段自然语言。比如{“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 到底是怎么一步一步把真实任务跑完的。