二、ReAct 的核心流程ReAct 的经典流程可以理解为：这个流程看起来简单，但它解决了 Agent 系统里最关键的问题：模型不是一次性回答，而是可以根据环境反馈不断调整下一步。这也是 ReAct 和普通问答最大的区别。三、普通问答和 ReAct 最大区别是什么？普通问答模式下，大模型的工作方式更像这样：这种方式适合：解释概念总结文章改写文案翻译文本写代码片段回答稳定知识比如你问：HTTP 404 是什么意思？模型可以直接回答，因为这类知识相对稳定，不依赖实时信息。但如果你问：帮我查一下今天凌晨接口自动化为什么失败？这就不是普通问答能解决的问题了。因为模型必须知道：哪个项目失败了？哪些用例失败了？错误日志是什么？是否和环境有关？是否和发布变更有关？是否是脚本问题还是业务缺陷？这些信息不在模型内部，需要它去查测试平台、日志系统、发布系统、接口报告。这就是 ReAct 的价值。四、ReAct 的标准执行过程面试时不要只说“先推理，再行动”。这个回答太粗。更完整的 ReAct 流程，通常包括下面几个步骤：1. Task：理解用户任务模型先理解用户到底想完成什么。比如用户说：帮我分析一下今天凌晨接口自动化失败原因。这里的目标不是“解释什么是接口自动化”，而是要完成一次问题排查。2. Reason：推理当前缺少什么信息模型需要判断：我现在有没有执行报告？有没有失败用例列表？有没有错误日志？有没有最近发布记录？有没有环境状态信息？如果这些信息不够，就不能直接下结论。3. Action：选择工具并执行模型根据当前缺失的信息，选择工具。可能调用：测试报告查询工具日志查询工具数据库查询工具发布记录查询工具接口文档查询工具缺陷系统查询工具4. Observation：读取工具返回结果工具执行完成后，会返回结果。比如：{ "taskName": "凌晨接口自动化回归", "totalCases": 120, "failedCases": 17, "mainFailedApi": "/order/create", "error": "Inventory service timeout"}模型拿到结果后，需要继续判断：这个结果是否足够定位问题？是否还需要继续查库存服务日志？
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
