当前很多智能体系统都基于 ReAct 思想构建。所谓 ReAct本质上是Reason Act也就是让大模型不断经历思考 → 行动 → 观察 → 再思考 → 再行动 → 最终回答一个典型流程是User Query ↓ LLM 判断下一步 ↓ 调用工具 ↓ 获得 Observation ↓ 将结果放回上下文 ↓ LLM 继续推理 ↓ 输出最终结果从原理上看ReAct 很简单但从工程落地看真正困难的不是“让 Agent 会调用工具”而是当工具失败、参数错误、结果为空、任务跑偏、陷入循环时系统如何兜住。因此工业级 Agent 的核心不是裸 ReAct而是ReAct Loop State Machine Tool Schema Error Policy Verifier Fallback Logging Human Confirmation一句话概括大模型负责判断下一步系统负责控制边界、校验结果、处理失败。一、为什么失败处理机制如此重要很多 Agent Demo 看起来很智能但一到真实业务场景就容易失控。常见问题包括工具选错 工具参数错误 工具调用超时 接口返回为空 权限不足 结果格式异常 重复调用同一个工具 上下文越来越长 任务目标逐渐漂移 模型误读工具返回结果 最终答案缺乏证据支撑如果没有失败处理机制Agent 很容易进入这种状态失败 → 再试 → 继续失败 → 换个错误方式再试 → 输出一个看似合理但实际错误的答案所以失败处理不是补丁而是 Agent Runtime 的核心能力。二、工业级 ReAct Agent 的核心架构一个更稳的 Agent 不应该只是一个简单的 while loop而应该有完整的执行控制层。推荐架构如下User Request ↓ Task Classifier ↓ Planner ↓ Agent Controller ↓ Tool Router ↓ Tool Validator ↓ Tool Executor ↓ Observation Normalizer ↓ State Store ↓ Verifier ↓ Final Response可以简化成五个阶段任务分类 → 规划 → 执行 → 校验 → 兜底其中最关键的是Controller。它负责控制 Agent 能跑几步、能调用什么工具、失败后能不能重试、什么时候必须停止、什么时候需要人工确认。三、失败处理机制一最大步数限制最基础也最重要的机制是Max Steps。不要让 Agent 无限循环。MAX_STEPS8forstepinrange(MAX_STEPS):resultagent.run_step()ifresult.is_final:returnresult.answerreturnfallback_answer(执行步骤过多任务已终止)不同任务可以设置不同步数任务类型max_steps 建议简单问答2 - 3RAG 查询3 - 5表格 / 文档处理5 - 8多工具 Agent8 - 12代码修复类 Agent10 - 20Max Steps 主要防止一直搜索 一直查数据库 一直重试同一个工具 一直陷入“我再试一次”四、失败处理机制二工具调用超时每个工具都必须设置 timeout。尤其是这些工具浏览器自动化 OCR 远程 API 数据库查询 文件解析 大模型二次调用示例defrun_tool_with_timeout(tool,args,timeout10):try:returntool.run(args,timeouttimeout)exceptTimeoutError:return{ok:False,error_type:TIMEOUT,message:工具调用超时,retryable:True}如果没有 timeout一个慢接口就可能拖死整个 Agent。五、失败处理机制三重试策略失败不能盲目重试要区分错误类型。错误类型是否重试处理方式网络超时可以退避重试502 / 503可以等待后重试限流可以延迟重试参数格式错误不建议直接重试让模型修参数权限不足不重试返回权限问题数据不存在不重试换路径或标记为空业务规则拒绝不重试给出拒绝原因推荐策略第一次失败自动重试 第二次失败换策略 第三次失败降级返回示例配置retry_policy{TIMEOUT:2,NETWORK_ERROR:2,RATE_LIMIT:3,PARAM_ERROR:0,PERMISSION_DENIED:0}重试机制的重点不是“多试几次”而是根据错误类型选择不同恢复方式。六、失败处理机制四工具参数校验模型生成的工具参数不一定可靠。例如模型可能生成{date:明天,user_id:null,limit:很多}但工具真正需要的是{date:2026-05-20,user_id:u_123,limit:20}所以每个工具调用前都要经过 schema 校验。frompydanticimportBaseModel,FieldclassSearchArgs(BaseModel):query:strlimit:intField(default10,ge1,le50)defvalidate_args(args):returnSearchArgs(**args)完整链路应该是LLM 生成参数 ↓ Schema 校验 ↓ 参数补全 / 标准化 ↓ 权限检查 ↓ 执行工具 ↓ 返回结构化 Observation尤其是数据库、文件写入、发消息、提交代码这类高风险工具不能让模型直接自由传参。比如不要直接暴露execute_sql(sql:str)更推荐封装成安全接口search_candidates(job_id:str,min_score:int,limit:int)七、失败处理机制五Observation 标准化工具结果不要直接把一大段原始文本塞回模型。应该统一成结构化格式{ok:true,tool_name:search_user_doc,data:[],error_type:null,message:找到 3 条结果,confidence:0.82,next_suggestion:可以继续读取第 1 个文档}失败时也要结构化{ok:false,tool_name:read_doc,error_type:PERMISSION_DENIED,message:没有该文档读取权限,retryable:false,next_suggestion:请用户授权或跳过该文档}这样模型才能明确知道是否成功 为什么失败 能不能重试 下一步建议是什么如果工具只返回一个模糊的error模型很容易继续乱猜。八、失败处理机制六循环检测Agent 很容易出现重复调用。例如search(queryA) → no result search(queryA) → no result search(queryA) → no result需要记录工具调用历史检测重复行为。ifsame_tool_and_args_called_more_than(2):returnfallback(检测到重复工具调用已终止)建议规则调用类型限制同一工具 同一参数最多 1 次同一工具 相似参数最多 3 次全局工具调用次数最多 10 次连续失败次数最多 2 - 3 次循环检测可以显著降低 Agent 的不稳定性和无效 token 消耗。九、失败处理机制七任务目标防漂移Agent 在多轮执行中容易偏离用户原始目标。比如用户要求提取 50 个文档的 part1 原文不要总结但 Agent 跑着跑着可能变成我来总结一下这 50 个文档的主要内容解决办法是把原始目标和约束写入 state每一步都带着执行。{original_goal:提取每个文档中的 part1 原文不做总结,current_step:读取第 7 个文档,forbidden:[不要归纳,不要改写,不要合并个人内容]}这也是为什么工业级 Agent 更适合用State Machine而不是裸 Prompt 循环。十、改进机制一Reflection 自我反思失败处理是兜底改进机制是让 Agent 做得更好。最常见的是 Reflection。流程是Agent 执行 ↓ 生成初稿 ↓ Critic 检查 ↓ 发现问题 ↓ Agent 修正 ↓ 最终输出适合场景复杂文档总结 代码生成 报告生成 多步骤任务 数据分析但 Reflection 不建议无限循环。工程上通常最多1 次反思 1 次修正否则成本高、延迟长甚至可能越改越偏。十一、改进机制二Verifier 独立校验器比让同一个模型自我反思更稳的是增加独立 Verifier。Generator Agent 负责生成 Verifier Agent 负责检查常见校验包括SQL Verifier检查表名、字段、limit、where 条件 Args Verifier检查工具参数是否合法 Evidence Verifier检查最终答案是否有证据支撑 Format Verifier检查输出是否符合 JSON / Markdown / 表格格式 Business Verifier检查是否违反业务规则架构如下User ↓ Agent ↓ Tool Call ↓ Draft Answer ↓ Verifier ↓ Pass → Final ↓ Fail → Repair在工业系统里Verifier 往往比单纯 Reflection 更可靠。十二、改进机制三Plan-and-Execute裸 ReAct 是一步一步贪心决策适合简单任务。复杂任务更推荐先规划再执行例如一个飞书周报汇总 Agent可以先生成计划Step 1读取多维表格获取员工姓名和文档链接 Step 2依次读取每个人的文档 Step 3提取 part1 到 part5 Step 4按 part 维度汇总 Step 5写入目标飞书文档 Step 6输出失败列表和成功列表架构Planner ↓ Executor ↓ Verifier ↓ Final适合多文档处理 招聘流程自动化 数据同步 报表生成 跨系统操作 自动写代码Plan-and-Execute 的优势是全局目标更稳定执行过程更可控。十三、改进机制四工具结果缓存Agent 经常重复查询相同内容比如读取同一个文档 查询同一个员工 搜索同一个关键词 计算同一段文本 OCR 同一张图片可以增加缓存cache_key tool_name normalized_args_hash命中后直接返回{ok:true,from_cache:true,data:...}不同数据类型适合不同缓存策略数据类型缓存策略静态文档长缓存搜索结果短缓存用户权限极短缓存实时价格 / 天气不缓存或极短缓存工具失败结果短缓存防止重复打爆接口缓存的价值不只是降成本也能减少重复失败。十四、改进机制五运行经验记忆这里的 Memory 不是普通聊天记忆而是Agent 运行经验记忆。例如{task_type:read_feishu_doc,failure:文档链接需要先转换为 doc_token,fix:调用 parse_feishu_url 再调用 read_doc,success_rate:0.91}可以沉淀成功工具链 失败参数模式 常见报错原因 用户偏好 业务规则 系统限制比如周报汇总 Agent 可以记住不要总结个人内容 按 part 维度汇总 每个人原文保留 先批量读取文档再做结构化提取长期看这类经验记忆能让 Agent 越跑越稳。十五、改进机制六Human-in-the-loop不是所有操作都应该自动执行。有些高风险操作必须让人确认发邮件 删数据 改数据库 提交代码 发布任务 审批流程 向候选人打招呼 大规模批量操作可以按照风险等级设计操作类型风险等级处理方式查询低自动执行总结低自动执行写草稿中自动执行但不发送修改文档中执行前确认或保留版本发送消息高人工确认删除数据高强制确认金融 / 法律 / 医疗决策极高只辅助不自动决策Human-in-the-loop 不是降低智能化而是提升系统可信度。十六、推荐落地的 10 个关键机制如果要做一个真正可用的 Agent建议优先做下面这些。优先级机制价值P0max_steps防止无限循环P0timeout防止工具卡死P0tool schema validation防止参数乱传P0structured observation让模型正确理解工具结果P0retry policy网络 / API 异常可恢复P1loop detection防止重复调用P1fallback strategy失败时可降级P1verifier防止最终答案胡编P1tool result cache降低成本和延迟P2reflection / memory持续改进效果十七、一个更稳的 Agent 执行伪代码defrun_agent(user_query):stateinit_state(user_query)planplanner.make_plan(user_query)state.planplanforstepinrange(MAX_STEPS):actionagent.decide_next_action(state)ifaction.typefinal_answer:checkedverifier.check(action.answer,state)ifchecked.ok:returnaction.answerelse:state.add_feedback(checked.feedback)continueifaction.typetool_call:validationtool_validator.validate(action.tool_name,action.args)ifnotvalidation.ok:state.add_observation({ok:False,error_type:PARAM_ERROR,message:validation.message,retryable:False})continueifloop_detector.is_repeated(action,state):returnfallback(检测到重复工具调用已终止)resulttool_executor.run(tool_nameaction.tool_name,argsvalidation.args,timeout10,retry2)observationnormalize_observation(result)state.add_observation(observation)ifobservation.okisFalseandobservation.retryableisFalse:state.add_failure(observation)continuereturnfallback(执行步骤超过上限已降级返回)十八、一个具体业务例子飞书周报汇总 Agent假设要做一个飞书周报汇总 Agent任务是读取多维表格中的员工姓名和文档链接 依次读取每个人的文档 提取 part1、part2、part3、part4、part5 最后按 part 汇总 每个人的内容保持原文不要归纳总结。失败处理可以这样设计场景处理机制飞书表格读取失败重试 2 次失败后返回表格读取失败某员工文档无权限跳过该员工记录失败原因文档里找不到 part3标记为空不让模型编造文档过长分块读取按标题定位part 内容提取不完整Verifier 检查标题边界写入汇总文档失败保留本地中间 JSON多人内容混淆按 employee_id 做状态隔离模型总结了原文规则校验失败后重新提取中间状态可以这样存{employee_name:张三,doc_url:...,doc_status:success,parts:{part1:{status:success,content:原文内容...},part2:{status:not_found,content:}},errors:[]}这样最后汇总时不会把不同人的内容混在一起也不会在缺失内容时让模型自由发挥。十九、建议的工程目录结构可以按照下面的结构设计 Agent 项目agent/ ├── runtime/ │ ├── controller.py # 主循环控制 │ ├── state.py # Agent 状态 │ ├── planner.py # 任务规划 │ ├── executor.py # 工具执行 │ ├── verifier.py # 结果校验 │ └── fallback.py # 降级策略 │ ├── tools/ │ ├── base.py # Tool 基类 │ ├── registry.py # 工具注册 │ ├── schemas.py # 参数 schema │ └── business_tools.py # 业务工具 │ ├── memory/ │ ├── short_term.py # 本轮状态 │ ├── long_term.py # 长期经验 │ └── cache.py # 工具缓存 │ ├── guardrails/ │ ├── permission.py # 权限检查 │ ├── pii.py # 敏感信息控制 │ ├── policy.py # 安全策略 │ └── loop_detector.py # 循环检测 │ └── prompts/ ├── planner_prompt.py ├── react_prompt.py ├── verifier_prompt.py └── repair_prompt.py这个结构的核心思想是把模型能力和系统控制能力分开。模型负责理解和决策工程系统负责约束和保障。二十、结语ReAct 只是起点Runtime 才是关键ReAct 提供了智能体的基础范式思考 → 行动 → 观察 → 再思考但它本身并不等于工业级 Agent。真正能落地的 Agent一定需要可控的执行循环 可靠的工具调用 清晰的失败分类 结构化的状态管理 明确的重试和降级策略 独立的结果校验 必要的人类确认机制最终可以总结成一句话ReAct 让 Agent 具备“会做事”的能力而失败处理和改进机制决定 Agent 能不能“稳定做事”。所以做 Agent 不能只关注模型有多强、工具有多少更要关注失败时怎么办 结果怎么验证 状态怎么保存 风险怎么控制 下次怎么改进这才是从 Demo Agent 走向工业级 Agent 的关键。