【导航台账】制造业数据与AI践行者老蒋的技术博客全系列文章汇总(持续更新)
📌 文章摘要
单工具Agent只能“回答”,多工具协同Agent才能“解决”。本文以智联工坊设备故障闭环处理为场景,从零搭建一个能完成“查手册→查排班→查备件→生成工单”完整任务链的多工具协同Agent。深入拆解任务分解、链式编排、中间结果传递三大核心能力,并记录调试过程中遇到的“嵌套JSON”与“Markdown代码块”两大实战坑点。全源码将开源,请关注更新情况。
开篇:痛点和场景
兄弟们,Case01和Case02我们搞定了一个制造Agent的“手脚”和“记忆”。它能算OEE、能查手册、能问排班,还能记住你之前说过什么。
但班组长小刘试用了一段时间后,给我提了一个新需求。
他说:“老蒋,你这个Agent确实能干活了。但每次我都要自己判断‘该用哪个工具’。能不能这样——我跟它说‘设备报错了’,它自己就知道该查手册、该问排班、该查备件,最后给我一张工单?”
我当时的第一反应是:这不科学啊…… 我这Agent虽然能干活,但要让它自己做决策、自己编排工具顺序、自己传递中间结果——这可不是加一行代码能搞定的。
但小刘说得对。单工具Agent只能“回答”,多工具协同Agent才能“解决”。
本文要解决的痛点:让Agent能自主完成一个完整的任务链——用户只需要说“设备报错了”,Agent自动执行“查手册→查排班→查备件→生成工单”的全流程。
适合谁读:已经跑通单工具Agent(如Case01),希望将Agent能力从“回答问题”升级为“解决问题”的开发者。
脱敏声明:本文基于虚拟工厂“智联工坊”场景,所有数据均已脱敏处理。
正文:方案设计
场景定义:设备故障闭环处理
我们以一个真实的制造场景为例:
用户输入:“交互屏组装A线设备报错E401,帮我排查一下”
Agent需要自动完成:
查维修手册 → 获取E401的维修指引
查产线排班 → 确认今天有没有人
查备件库存 → 确认需要更换的备件够不够
生成维修工单 → 汇总信息,生成标准工单
这个场景的难度在于:Agent不能只调用一个工具,它需要自己做决策——先查什么、再查什么、查到的结果怎么传给下一个工具。
工程目录结构
javy21_manufacturing_ai_practice/
├── common/ # 共享基建层(复用Case01/Case02)
│ ├── base_agent_builder.py
│ ├── chroma_client.py
│ └── llm_client.py
│
└── cases/
└── case03_multi_tools_agent/ # Case03:多工具协同Agent
├── config.py
├── tools/
│ ├── __init__.py
│ ├── search_manual.py # ① 手册检索(复用Case01)
│ ├── query_shift.py # ② 排班查询(复用Case01)
│ ├── query_spare_parts.py # ③ 备件库存(新增)
│ └── generate_work_order.py# ④ 生成工单(新增)
├── agent/
│ └── builder.py # 注册4个工具,定制Prompt
├── scripts/
│ └── 01_test_cli.py # 交互式CLI测试
└── web/ # 可选Web界面
和Case01的区别:工具从3个扩展到4个(新增备件库存和工单生成),更重要的是Agent的Prompt中加入了“链式推理”的引导。
核心实现:让Agent学会“先做什么,再做什么”
Step 1:工具定义——新增2个核心工具
③ 备件库存查询工具(query_spare_parts.py)
这个工具模拟了真实工厂的备件库存系统:
class SparePartsInput(BaseModel):
part_name: str = Field(description="备件名称或型号关键词")
class QuerySparePartsTool(BaseTool):
name: str = "query_spare_parts"
description: str = "查询制造产线的备件库存信息..."
args_schema: Type[BaseModel] = SparePartsInput
def _run(self, part_name: str) -> str:
# 模拟库存数据库查询
# 返回:库存状态、库位、数量、采购周期
④ 生成维修工单工具(generate_work_order.py)
这个工具将多个信息源汇总成标准化工单:
class GenerateWorkOrderTool(BaseTool):
name: str = "generate_work_order"
description: str = "生成智联工坊标准维修工单..."
args_schema: Optional[Type[BaseModel]] = None # 关键:手动解析参数
def _run(self, *args, **kwargs) -> str:
# 手动解析Agent传入的所有参数
# 生成结构化工单
这里要留个心眼:为什么
args_schema=None?因为LangChain的ReAct Agent会把所有参数打包成一个JSON字符串塞进第一个字段,导致Pydantic校验失败。绕过校验、在_run内部手动解析是更健壮的做法。
Step 2:Agent组装——注册4个工具
builder.py 的核心代码只有这几行:
class MultiToolsAgentBuilder(BaseAgentBuilder):
def __init__(self, **kwargs):
kwargs.setdefault("temperature", 0.0)
kwargs.setdefault("max_iterations", 8) # 复杂任务链需要更多迭代
kwargs.setdefault("memory_type", None)
super().__init__(**kwargs)
def _register_tools(self) -> List[BaseTool]:
return [
SearchManualTool(), # ① 手册检索
QueryShiftTool(), # ② 排班查询
QuerySparePartsTool(), # ③ 备件库存
GenerateWorkOrderTool(), # ④ 生成工单
]
Step 3:Prompt引导——告诉Agent“先做什么,再做什么”
这是多工具协同Agent最关键的部分。Prompt中必须明确告诉Agent:
-
任务的执行顺序(先查手册→再查排班→再查备件→最后生成工单)
-
中间结果的传递方式(上一步的结果要作为下一步的输入)
-
容错规则(如果某一步查不到数据,不要死磕,继续往下走)
def _get_prompt_template(self) -> str:
return """
你是一个资深的智联工坊制造运维专家。你有权使用以下工具:
{tools}
**核心工作流程**:
1. 如果用户没有提供产线名称或故障码,直接询问用户。
2. 处理故障时,请严格按以下顺序分步执行:
- 第一步:search_manual → 获取维修指引
- 第二步:query_shift → 查询产线排班
- 第三步:query_spare_parts → 查询备件库存
- 第四步:generate_work_order → 生成维修工单
3. 上一步的结果,必须作为下一步的输入。
4. 如果某一步返回"未找到",标记为"数据缺失",继续执行后续步骤。
...
"""
运行验证:完整的多工具协同流程
运行 01_test_cli.py,输入:
交互屏组装A线设备报错E401,帮我排查一下
Agent的思考链如下:
Action: search_manual
Action Input: {"fault_code": "E401"}
Observation: 【智联工坊维修手册匹配】
交互屏E401错误:触摸屏驱动通信超时,请重启工控机并检查USB连接线。
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": {"status": "充足", "quantity": 15, "location": "A-3-12"}}
Action: generate_work_order
Action Input: {"line_name": "交互屏组装A线", "fault_code": "E401", "solution": "重启工控机并检查USB连接线", "spare_parts_status": "充足", "assigned_shift": "白班"}
Final Answer: 已生成工单 WO-20260804-4164 ...
关键验证点:
-
顺序执行:Agent严格按照 search_manual → query_shift → query_spare_parts → generate_work_order 的顺序执行
-
中间结果传递:search_manual 返回的“触摸屏驱动”被 query_spare_parts 作为输入使用
-
容错处理:query_shift 返回“未找到”,Agent没有死磕,直接跳到下一步
-
结构化输出:generate_work_order 输出了包含工单编号、故障码、备件状态、执行步骤的完整工单
总结:价值提炼
本文解决了什么:将一个单步的“问答Agent”升级为多步的“任务解决Agent”。用户只需要说“设备报错了”,Agent自主完成从查手册到出工单的完整闭环。
三个关键认知:
-
任务分解是核心:多工具协同的关键不是工具多,而是Agent能理解“先做什么、再做什么”。Prompt中的顺序引导是成败的关键。
-
容错比完美更重要:真实场景中,数据缺失是常态。Agent需要学会“跳过”而不是“死磕”。在Prompt中明确容错规则,比在代码中处理异常更有效。
-
手动解析参数比Pydantic校验更健壮:ReAct Agent习惯把参数打包成嵌套JSON,
args_schema=None+ 手动解析是绕过这个坑的有效方式。
智能工厂对标:本方案对应GB/T 39116-2020中“生产作业”能力域(主域)——实现设备故障的自动化闭环处理;以及“数据资源”能力域(辅域)——实现维修知识、备件库存、排班数据的跨系统协同。可直接用于国家智能制造能力成熟度三级(集成级)申报材料中的技术佐证。
系列导航
-
下一篇:《数据质量智能巡检Agent》(Case04,即将发布)
互动与交流
你在将Agent从“单工具”升级到“多工具协同”时,有没有遇到过Agent“不知道该先调用哪个工具”的问题?或者工具之间的参数传递卡住了?欢迎评论区吐槽,咱们一起聊聊——说实话,让Agent学会“分步执行”这件事,我前前后后折腾了好几天。
关于作者
制造业数据与AI践行者老蒋,23年IT老兵。聚焦制造业数据架构与AI融合落地。全流程实战,全源码开源。
📌 排坑笔记预告(主文完成后产出)
| 编号 | 标题 | 预计发布 |
|---|---|---|
| 坑T1 | 《“嵌套JSON”噩梦的终结:args_schema=None让工具重获自由》 | 主文发布后次日 |
| 坑T2 | 《不要让你的Agent“吊死”在一棵树上:工具返回“未找到”时的容错设计》 | 主文发布后第3天 |
| 坑T3 | 《Markdown代码块 vs 纯净JSON:LangChain工具调用的格式战争》 | 主文发布后第5天 |


被折叠的 条评论
为什么被折叠?



