十三、ReAct 的风险是什么？讲 ReAct 不能只讲优点。面试官更看重你是否知道它的边界。1. 可能无限循环如果没有限制，Agent 可能一直推理、一直调用工具、一直无法结束。所以必须设置：最大执行轮次最大工具调用次数单次工具超时时间总任务超时时间失败兜底策略2. 可能调用错误工具模型可能选错工具，也可能传错参数。所以工具层必须做：工具白名单参数类型校验必填字段校验权限校验风险等级校验3. 工具结果可能不可靠工具返回结果不一定都是可信的。可能出现：工具超时返回空数据返回脏数据接口报错数据不一致权限不足所以不能“工具返回什么就信什么”。需要做：错误码识别结果结构化置信度判断多工具交叉验证异常兜底回答4. 高风险动作不能自动执行尤其是涉及生产环境时，不能让 Agent 想做什么就做什么。比如：删除数据修改配置发布上线触发生产任务批量发送消息修改用户权限这些都不能直接交给 Agent 自动执行。更合理的方式是分级控制：十四、ReAct 是否要把推理过程展示给用户？这也是一个很重要的工程问题。很多教学文章会写成：Thought: 我需要查询天气Action: 调用天气工具Observation: 下午有雨Thought: 用户应该带伞Final Answer: 建议带伞这种格式适合学习，但不一定适合生产环境。真实系统里，不建议把完整推理过程原样展示给用户。更合理的方式是：对用户展示关键依据和最终结论内部记录工具调用日志保留必要的决策摘要隐藏敏感推理细节对高风险操作保留审计记录比如用户看到的是：我查询了上海今天的天气信息，下午 3 点后降水概率较高，建议带伞。而不是看到完整的内部推理链路。面试时可以这样答：ReAct 的思想是推理和行动交替，但生产环境不一定要把完整推理过程暴露给用户。更常见的做法是展示关键依据和结论，同时在系统内部保留工具调用记录、参数、返回结果和必要的决策摘要，方便审计和排查。这个回答会显得更工程化。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
