LangChain Agent 反复调用工具死循环?结构化返回 + Prompt 规则让它学会跳过
【导航台账】制造业数据与AI践行者老蒋的技术博客全系列文章汇总(持续更新)
📌 文章摘要
多工具协同 Agent 执行任务链时,常因工具返回 “未找到” 而反复调用,最终触发迭代上限中断。本文深入拆解根因:纯文本错误信号无法被 Agent 精准识别,提供「结构化 JSON 返回 + Prompt 容错规则」双层解决方案,让 Agent 学会识别数据缺失并自动跳过,是生产级 Agent 开发的必备容错方案。
文章目录
第二层:Prompt里的“容错规则”管不到Agent的“本能”
问题现象
兄弟们,上一个坑好不容易解决,嵌套JSON的问题搞定了(点击跳转链接),Agent能调用工具了,我以为可以松一口气了。
结果跑起来之后,我傻眼了。
输入:
交互屏组装A线设备报错E401,帮我排查一下
Agent执行了 search_manual 拿到了维修指引,然后开始调用 query_shift:
Action: 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_ascii=False)
当查询成功时,也返回结构化JSON:
# ✅ 成功时也返回结构化JSON
return json.dumps({
"status": "success",
"line": line_name,
"date": date,
"shift": shift
}, ensure_ascii=False)
第二步:在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-4164
Agent成功跳过了“未找到”的排班查询,继续执行了后续步骤,完成了整个任务链。
方案对比
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 纯文本返回 | 简单的单轮对话 | 实现简单 | 无法被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规则组合是最佳实践。
系列导航
本文问题源自:《智联工坊实战:多工具协同Agent》实战过程,完整源码及深度教程见该文:链接
💡 建议收藏:开发多工具协同 Agent 时,90% 的卡死问题都来自信号不明确导致的无效重试。本文的双层容错方案可直接复用到所有工具定义中,遇到 Agent 反复调用、迭代超时时可直接对照排查。
互动与交流
你在多工具协同Agent的开发中,有没有遇到过Agent“卡死”在某个工具上反复尝试的情况?你是怎么让它学会“跳过”的?欢迎评论区交流,咱们互相支支招——说实话,让Agent学会“放弃”这件事,比让它学会“执行”还难。
关于作者
制造业数据与AI践行者老蒋,23年IT老兵。聚焦制造业数据架构与AI融合落地。全流程实战,全源码开源。
标签:#排坑笔记 #LangChain #Agent #多工具协同Agent #Agent容错设计 #工具调用排坑 #迭代上限
更多推荐




所有评论(0)