【导航台账】制造业数据与AI践行者老蒋的技术博客全系列文章汇总(持续更新)

📌 文章摘要

多工具协同 Agent 执行任务链时,常因工具返回 “未找到” 而反复调用,最终触发迭代上限中断。本文深入拆解根因:纯文本错误信号无法被 Agent 精准识别,提供「结构化 JSON 返回 + Prompt 容错规则」双层解决方案,让 Agent 学会识别数据缺失并自动跳过,是生产级 Agent 开发的必备容错方案。

文章目录

问题现象

根因分析

第一层:纯文本“未找到”对Agent来说太“模糊”了

第二层:Prompt里的“容错规则”管不到Agent的“本能”

第三层:语言模型理解“结构”比理解“文本”容易得多

解决方案

第一步:让工具返回结构化JSON(工具层)

第二步:在Prompt中明确“识别信号”(Prompt层)

验证结果

方案对比

经验总结

系列导航

互动与交流

关于作者


问题现象

        兄弟们,上一个坑好不容易解决,嵌套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看不懂中文里的“未找到”暗示,它需要结构化的信号才能精确识别和执行跳转。

落到具体操作上就是三条:

  1. 工具返回值统一使用结构化JSON。包含 status 字段,用 "success" 和 "not_found" 这样的明确信号,而不是让Agent去“理解”一段中文描述。

  2. Prompt中的容错规则要对应JSON结构。用“如果 status 为 not_found”这样的表述,而不是“如果返回未找到”这种模糊描述。Agent识别字段比理解中文更可靠。

  3. 工具层 + Prompt层 = 双层保障。单靠Prompt约束,Agent可能“不听”;单靠结构化返回,Agent也可能“不知道这个字段是什么意思”。两者结合才是生产级方案。

适用范围

本文方案适用于多工具协同Agent中,某个工具可能因数据缺失而返回“未找到”的场景。如果所有工具都保证返回有效数据,则无需此方案。对于需要跳过、重试、降级的容错场景,结构化JSON + Prompt规则组合是最佳实践。

系列导航

本文问题源自《智联工坊实战:多工具协同Agent》实战过程,完整源码及深度教程见该文:链接

💡 建议收藏:开发多工具协同 Agent 时,90% 的卡死问题都来自信号不明确导致的无效重试。本文的双层容错方案可直接复用到所有工具定义中,遇到 Agent 反复调用、迭代超时时可直接对照排查。

互动与交流

        你在多工具协同Agent的开发中,有没有遇到过Agent“卡死”在某个工具上反复尝试的情况?你是怎么让它学会“跳过”的?欢迎评论区交流,咱们互相支支招——说实话,让Agent学会“放弃”这件事,比让它学会“执行”还难。

关于作者

制造业数据与AI践行者老蒋,23年IT老兵。聚焦制造业数据架构与AI融合落地。全流程实战,全源码开源。

标签:#排坑笔记 #LangChain #Agent #多工具协同Agent #Agent容错设计 #工具调用排坑 #迭代上限

Logo

Agent 垂直技术社区,欢迎活跃、内容共建。

更多推荐