【导航台账】制造业数据与AI践行者老蒋的技术博客全系列文章汇总持续更新 文章摘要多工具协同 Agent 执行任务链时常因工具返回 “未找到” 而反复调用最终触发迭代上限中断。本文深入拆解根因纯文本错误信号无法被 Agent 精准识别提供「结构化 JSON 返回 Prompt 容错规则」双层解决方案让 Agent 学会识别数据缺失并自动跳过是生产级 Agent 开发的必备容错方案。文章目录问题现象根因分析第一层纯文本“未找到”对Agent来说太“模糊”了第二层Prompt里的“容错规则”管不到Agent的“本能”第三层语言模型理解“结构”比理解“文本”容易得多解决方案第一步让工具返回结构化JSON工具层第二步在Prompt中明确“识别信号”Prompt层验证结果方案对比经验总结系列导航互动与交流关于作者问题现象兄弟们上一个坑好不容易解决嵌套JSON的问题搞定了点击跳转链接Agent能调用工具了我以为可以松一口气了。结果跑起来之后我傻眼了。输入交互屏组装A线设备报错E401帮我排查一下Agent执行了search_manual拿到了维修指引然后开始调用query_shiftAction: query_shift Action Input: {line_name: 交互屏组装A线} Observation: 未找到 交互屏组装A线 在 2026-08-04 的排班数据 Action: query_shift Action Input: {line_name: 交互屏组装A线, date: 今天} Observation: 未找到 交互屏组装A线 在 2026-08-04 的排班数据 Action: query_shift Action Input: {line_name: 交互屏组装A线, date: 2026-08-03} Observation: 未找到 交互屏组装A线 在 2026-08-03 的排班数据 Action: query_shift Action Input: {line_name: 交互屏组装A线, date: 2026-08-05} Observation: 未找到 交互屏组装A线 在 2026-08-05 的排班数据 ... 重复7次后 ... Finished chain. Agent: Agent stopped due to iteration limit or time limit.我当时的第一反应是这不科学啊……我明明在Prompt里写了“如果某一步返回未找到标记为数据缺失继续执行后续步骤”它怎么还在死磕根因分析说实话这个问题我一开始以为是Prompt写得不够强硬。但加了三次“绝对禁止反复查询”之后Agent依然我行我素。后来我把query_shift的返回值改成了结构化JSON问题才真正解决。第一层纯文本“未找到”对Agent来说太“模糊”了Agent看到未找到 交互屏组装A线 在 2026-08-04 的排班数据这个信息时它真的理解这句话的意思吗它不知道。它只知道这个工具返回了一段中文文本。它无法判断这是一个“明确的失败信号”还是“换个参数重试就能成功的提示”。在Agent的视角里这句话更像是在说“你给的日期不对换个日期试试。”于是它就换了7个日期。第二层Prompt里的“容错规则”管不到Agent的“本能”我在Prompt里写的是4. 容错规则如果某一步工具返回“未找到”或“无数据”不要反复查询标记为“数据缺失”然后继续执行后续步骤。但问题是Agent根本不知道“未找到”是一个“信号”。它看到的只是一段文本。它不知道这个文本是一个“标记”需要被识别并触发“跳过”动作。这就好比你跟一个外国人用中文说“别去那边”他听到的只是几个音节而不是一个指令。第三层语言模型理解“结构”比理解“文本”容易得多大模型虽然能理解自然语言但它真正擅长的是识别模式。当你把返回值从纯文本改成结构化JSON时// ❌ 纯文本模糊 未找到 交互屏组装A线 在 2026-08-04 的排班数据 // ✅ 结构化JSON明确 { status: not_found, message: 未找到交互屏组装A线在2026-08-04的排班数据, suggestion: 系统无此产线排班数据请继续下一步排查 }Agent看到status: not_found时它可以精确识别这个信号而不需要“理解”一句中文。说白了就是Agent理解JSON比理解中文快得多。给它一个结构化的信号比给它一句自然语言描述要靠谱得多。解决方案别慌两步搞定它。第一步让工具返回结构化JSON工具层修改query_shift.py的返回值从纯文本改为结构化JSON# ❌ 旧写法纯文本 if record.empty: return f未找到 {line_name} 在 {date} 的排班数据 # ✅ 新写法结构化JSON if record.empty: return json.dumps({ status: not_found, message: f未找到 {line_name} 在 {date} 的排班数据, suggestion: 系统无此产线排班数据请继续下一步排查 }, ensure_asciiFalse)当查询成功时也返回结构化JSON# ✅ 成功时也返回结构化JSON return json.dumps({ status: success, line: line_name, date: date, shift: shift }, ensure_asciiFalse)第二步在Prompt中明确“识别信号”Prompt层在builder.py的_get_prompt_template中把容错规则写得更加具体4. **容错规则** - 如果某一步工具返回的 JSON 中 status 为 not_found说明该数据在系统中不存在。 - 此时不要反复查询不同参数直接标记为数据缺失然后继续执行后续步骤。 - 例如query_shift 返回 {status: not_found, ...} 时跳过排班查询直接进入备件查询。验证结果修改后重新运行Action: search_manual Observation: 【智联工坊维修手册匹配】交互屏E401错误触摸屏驱动通信超时... Action: query_shift Action Input: {line_name: 交互屏组装A线} Observation: {status: not_found, message: 未找到排班数据, suggestion: 继续下一步排查} Action: query_spare_parts ← ✅ 跳过了直接进入下一步 Action Input: {part_name: 触摸屏驱动} Observation: {status: success, part: 触摸屏, inventory: {...}} Action: generate_work_order Action Input: {line_name: 交互屏组装A线, fault_code: E401, ...} Observation: {order_id: WO-20260804-4164, ...} Final Answer: 已生成工单 WO-20260804-4164Agent成功跳过了“未找到”的排班查询继续执行了后续步骤完成了整个任务链。方案对比方案适用场景优点缺点纯文本返回简单的单轮对话实现简单无法被Agent精确识别为“信号”结构化JSON返回多工具协同、链式调用信号明确便于Agent识别和跳转需要额外解析逻辑结合Prompt容错规则生产级多工具Agent双重保障工具层Prompt层协同需要同时修改两处经验总结怕你忘了我再啰嗦一遍Agent看不懂中文里的“未找到”暗示它需要结构化的信号才能精确识别和执行跳转。落到具体操作上就是三条工具返回值统一使用结构化JSON。包含status字段用success和not_found这样的明确信号而不是让Agent去“理解”一段中文描述。Prompt中的容错规则要对应JSON结构。用“如果status为not_found”这样的表述而不是“如果返回未找到”这种模糊描述。Agent识别字段比理解中文更可靠。工具层 Prompt层 双层保障。单靠Prompt约束Agent可能“不听”单靠结构化返回Agent也可能“不知道这个字段是什么意思”。两者结合才是生产级方案。适用范围本文方案适用于多工具协同Agent中某个工具可能因数据缺失而返回“未找到”的场景。如果所有工具都保证返回有效数据则无需此方案。对于需要跳过、重试、降级的容错场景结构化JSON Prompt规则组合是最佳实践。系列导航本文属于《数据与AI工程排坑笔记》系列上一篇LangChain ReAct Agent 嵌套 JSON 报错args_schemaNone 解决 Field required下一篇Agent 输出带 Markdown 代码块Prompt 约束 解析兜底解决 JSON 解析失败本文问题源自《智联工坊实战多工具协同Agent》实战过程完整源码及深度教程见该文链接 建议收藏开发多工具协同 Agent 时90% 的卡死问题都来自信号不明确导致的无效重试。本文的双层容错方案可直接复用到所有工具定义中遇到 Agent 反复调用、迭代超时时可直接对照排查。互动与交流你在多工具协同Agent的开发中有没有遇到过Agent“卡死”在某个工具上反复尝试的情况你是怎么让它学会“跳过”的欢迎评论区交流咱们互相支支招——说实话让Agent学会“放弃”这件事比让它学会“执行”还难。关于作者制造业数据与AI践行者老蒋23年IT老兵。聚焦制造业数据架构与AI融合落地。全流程实战全源码开源。标签#排坑笔记#LangChain#Agent#多工具协同Agent#Agent容错设计#工具调用排坑#迭代上限