工业检测软件如何接入AI Agent：架构设计与落地实践

1. 工业检测软件接入 AI Agent 的整体设计思路

工业检测这个行当，过去十几年基本是"规则驱动"的天下：阈值判定、模板匹配、特征比对，工程师把判定逻辑一条条写死，产线上的相机拍完图，算法跑一遍，OK 或 NG 直接给结果。这套东西稳定、可解释、好维护，但它的天花板也很明显——换个产品型号、换一批来料、光照稍微变一点，规则就得重调，调到最后往往变成"参数工程师"的体力活。

这两年大模型和 Agent 概念火起来之后，很多做工业检测的团队都在琢磨：能不能让检测软件自己"长脑子"，遇到新缺陷能自己判断、自己调参、自己写报告？这就是"工业检测软件怎么做 AI Agent"这个问题的由来。我先把这个概念说清楚：工业检测里的 AI Agent，不是把检测算法换成大模型，而是在原有检测流水线之上，加一层能感知、能决策、能调用工具、能记忆的智能调度层。检测本身还是靠视觉算法（传统 CV 或深度学习模型），Agent 负责的是"什么时候用什么模型、结果异常了怎么办、缺陷怎么归类、报告怎么写、参数要不要调"这些上层决策。

为什么这么设计？因为工业场景对实时性和确定性的要求极高。一条产线每分钟过几十上百个工件，你不可能让大模型去逐帧推理，延迟和成本都扛不住。所以合理的架构是"快慢分离"：快路径用轻量模型和规则做实时判定，慢路径用 Agent 做异步的分析、归因、优化。这个思路和很多互联网系统的"在线服务 + 离线分析"是一个道理。

适合谁来参考这套方案？我把它分成三类：一是已经在做工业检测软件、想加智能能力的视觉算法工程师；二是负责产线数字化、想把检测数据用起来的自动化/工艺工程师；三是对 Agent 架构感兴趣、想找落地场景的AI 应用开发者。不管你是哪一类，下面这套拆解都能让你看清"从哪下手、坑在哪、怎么落地"。

我先把整体架构的骨架摆出来，后面每一块再展开讲。一个可落地的工业检测 AI Agent，通常包含五层：

这张表是整篇文章的"地图"，接下来我会一层层拆开，重点讲决策层和工具层怎么接、记忆层怎么建、以及实际跑起来会遇到哪些坑。

2. 核心细节解析：Agent 到底"智能"在哪

2.1 为什么不能直接让大模型看图片做判定

很多人第一反应是：现在多模态大模型这么强，直接让它看图判断有没有缺陷不就行了？我实测过，这条路在工业场景基本走不通，原因有三个。

第一是精度和稳定性。工业缺陷检测动辄要求 99.9% 以上的召回率，漏检一个不良品可能意味着整批退货。多模态大模型在通用图像理解上很强，但对"这个划痕是 0.1mm 还是 0.2mm""这个焊点算不算虚焊"这种细粒度、强专业性的判断，表现远不如专门训练的检测模型。它可能会把正常的纹理当成缺陷，也可能漏掉真正的微小瑕疵。

第二是延迟和成本。产线节拍可能是几百毫秒一个工件，大模型推理一次少则几百毫秒多则几秒，还要按 token 计费，一天几十万张图跑下来成本惊人。而一个轻量 CNN 模型在边缘设备上几毫秒就能出结果。

第三是可解释性和可追溯。工业客户要的是"为什么判 NG"，检测模型能给出热力图、置信度、特征响应，大模型给的是一段自然语言描述，出了问题没法定位。

所以正确的定位是：检测模型负责"看"，Agent 负责"想"。Agent 不替代检测，而是站在检测之上做决策和协调。这个边界一定要划清楚，否则项目一开始就会跑偏。

2.2 Agent 的四大核心能力拆解

一个真正有用的工业检测 Agent，我总结下来要具备四种能力，缺一不可。

感知能力：Agent 要能"知道现在发生了什么"。这包括读取检测结果（OK/NG、缺陷类型、置信度、位置）、读取设备状态（相机是否正常、光源亮度、产线速度）、读取上下文（当前生产的是哪个型号、哪批来料）。这些信息通过工具层暴露给 Agent，它才能做判断。

决策能力：这是 Agent 的核心。比如检测到一批 NG 突然增多，Agent 要能判断是"偶发不良"还是"系统性异常"，进而决定是"继续观察""触发告警"还是"建议停机检查"。这个决策过程靠的是 LLM 的推理能力加上预设的规则约束。

工具调用能力：Agent 不能只会说，还要会做。它要能调用"重新检测""调整阈值""查询历史数据""生成报告""发送告警"这些工具。这就是 Function Calling 的用武之地——把每个可执行动作封装成一个函数，Agent 根据情况决定调哪个。

记忆能力：Agent 要能记住"上次遇到类似缺陷是怎么处理的""这个型号的历史良率是多少""上个月调过哪些参数"。没有记忆的 Agent 每次都是从零开始，谈不上智能。记忆分短期（当前会话上下文）和长期（向量库里的历史经验）。

这四种能力对应到代码结构上，就是四个模块：数据采集模块、推理决策模块、工具注册模块、记忆存储模块。下面我会分别讲怎么实现。

2.3 工具层的设计原则：把能力"函数化"

工具层是 Agent 和实际系统之间的桥梁，设计得好不好直接决定 Agent 能不能干活。我的经验是遵循三个原则。

原则一：原子化。每个工具只做一件事，粒度要细。比如不要设计一个"处理异常"的大函数，而是拆成"查询历史同类缺陷""获取当前参数配置""修改阈值""触发复检""发送告警"这些小函数。Agent 可以自由组合，灵活性高。

原则二：幂等和安全。工业系统里，一个误操作可能造成停机或批量误判。所以工具设计要考虑幂等性（重复调用不出问题）和权限控制（哪些操作 Agent 能自主执行，哪些必须人工确认）。比如"修改检测阈值"这种敏感操作，我一般设计成"Agent 只能建议，人工确认后才执行"。

原则三：返回结构化数据。工具返回给 Agent 的结果最好是 JSON 这种结构化格式，包含状态码、数据、错误信息。这样 Agent 解析起来准确，不容易产生幻觉。

举个具体的工具定义例子，用 Python 的字典描述：

tools = [ { "name": "query_defect_history", "description": "查询指定缺陷类型在最近N小时内的出现次数和分布", "parameters": { "type": "object", "properties": { "defect_type": {"type": "string", "description": "缺陷类型，如 scratch, dent, stain"}, "hours": {"type": "integer", "description": "查询时间范围，单位小时"} }, "required": ["defect_type", "hours"] } }, { "name": "get_current_params", "description": "获取当前检测工位的参数配置", "parameters": {"type": "object", "properties": {}} }, { "name": "suggest_param_change", "description": "生成参数调整建议，需人工确认后生效", "parameters": { "type": "object", "properties": { "param_name": {"type": "string"}, "suggested_value": {"type": "number"}, "reason": {"type": "string"} }, "required": ["param_name", "suggested_value", "reason"] } } ]

这套定义直接喂给支持 Function Calling 的模型，Agent 就能根据对话上下文决定调哪个工具。注意suggest_param_change这个设计——它只生成建议不直接改，这就是安全原则的体现。

3. 实操过程：从零搭一个检测 Agent 原型

3.1 环境准备与依赖选型

先说环境。工业现场一般跑在工控机或边缘盒子上，配置不会太高，所以我的建议是检测模型本地跑，Agent 的 LLM 调用走内网服务或云端 API。如果对数据安全要求极高，可以在内网部署开源模型，但要注意推理性能。

基础依赖大致是这些：

# 视觉检测部分 pip install opencv-python torch torchvision # Agent 编排部分 pip install langchain openai # 或对应厂商的 SDK # 记忆存储 pip install chromadb # 轻量向量库，适合边缘部署 # 数据处理 pip install pandas numpy

选型上我踩过的坑：一开始想用重量级向量库，结果在工控机上装都装不上，依赖冲突一堆。后来换成 ChromaDB 这种轻量的，本地持久化，几十万条记录也够用。LLM 这块，如果只是做归因分析和报告生成，用中等规模的模型就够，没必要上最大的，成本和延迟都更友好。

3.2 检测结果的标准化封装

Agent 要处理检测结果，前提是结果格式统一。不同检测算法输出的格式五花八门，有的给坐标，有的给掩码，有的只给个标签。我一般会写一个适配层，把所有结果统一成这样的结构：

def normalize_result(raw_result): return { "image_id": raw_result["id"], "timestamp": raw_result["ts"], "verdict": "NG" if raw_result["defects"] else "OK", "defects": [ { "type": d["label"], "confidence": round(d["score"], 4), "bbox": d["box"], # [x1, y1, x2, y2] "area_ratio": compute_area_ratio(d["box"], raw_result["size"]) } for d in raw_result["defects"] ], "station": raw_result["station_id"], "product_model": raw_result["model"] }

这个标准化结构是后面所有 Agent 逻辑的基础。area_ratio这个字段是我特意加的——缺陷面积占比是判断严重程度的重要依据，Agent 拿到这个数才能做更细的决策。

3.3 决策逻辑的实现：规则兜底 + LLM 增强

决策层我强烈建议用"规则兜底 + LLM 增强"的混合模式，而不是纯靠 LLM。原因很简单：LLM 会幻觉，工业场景容错率低。

具体做法是：先跑一层硬规则，处理明确的场景。比如"连续 10 个工件 NG"直接触发停机告警，这个不需要 LLM 判断。规则处理不了的模糊场景，再交给 LLM 分析。

def decide(normalized_results, context): # 第一层：硬规则 ng_count = sum(1 for r in normalized_results if r["verdict"] == "NG") if ng_count >= 10: return {"action": "stop_line", "reason": "连续NG超阈值", "source": "rule"} # 第二层：LLM 分析 summary = build_summary(normalized_results, context) llm_decision = call_llm_agent(summary) return llm_decision

build_summary这个函数很关键，它把原始检测数据压缩成 LLM 能理解的文本摘要。不要直接把几百条 JSON 塞给模型，token 爆炸还容易让它抓不住重点。我的做法是统计聚合：缺陷类型分布、时间趋势、与历史基线的对比。

3.4 记忆层的搭建：让 Agent 越用越聪明

记忆层是很多团队忽略的部分，但它恰恰是 Agent 从"能用"到"好用"的关键。我把它分成两块。

结构化记忆用普通数据库存，记录每次异常事件的处理过程：什么时间、什么缺陷、Agent 给了什么建议、人工最终怎么处理、结果如何。这些数据可以用来做后续的规则优化。

向量记忆用向量库存，把历史缺陷的描述、处理经验转成向量。当新缺陷出现时，Agent 先检索相似的历史案例，作为决策参考。这就是 RAG（检索增强生成）在工业场景的应用。

def store_experience(defect_desc, resolution): embedding = embed_model.encode(defect_desc) collection.add( embeddings=[embedding], documents=[defect_desc], metadatas=[{"resolution": resolution, "ts": time.time()}] ) def recall_similar(defect_desc, top_k=3): embedding = embed_model.encode(defect_desc) results = collection.query(query_embeddings=[embedding], n_results=top_k) return results["metadatas"][0]

实测下来，有了记忆层之后，Agent 对重复性问题的处理准确率明显提升，因为它能"想起"上次类似情况是怎么解决的。

3.5 交互层：报告生成与告警推送

Agent 的产出最终要落到人能看到的地方。我做了两个出口：一个是自动生成的班次报告，一个是实时告警。

报告生成用 LLM 把统计数据转成自然语言，比如"本班次共检测 12000 件，NG 率 0.8%，较上一班次上升 0.3 个百分点，主要缺陷类型为划痕（占比 62%），集中在 3 号工位，建议检查该工位的传送带是否有异物"。这种报告比纯数字表格直观得多，工艺工程师一看就懂。

告警推送则要克制。我见过有的系统一有 NG 就推送，结果大家直接屏蔽了。合理的做法是分级：普通波动不推，趋势性异常推给工艺工程师，紧急异常推给产线负责人。这个分级逻辑也可以交给 Agent 判断。

4. 常见问题与排查技巧实录

4.1 Agent 决策不稳定怎么办

这是最常见的问题。同样的输入，Agent 两次给的决策不一样。排查思路是这样的：

先看温度参数。LLM 的 temperature 如果设得太高（比如 0.7 以上），输出就会发散。工业场景建议设到 0.1 甚至 0，追求确定性。

再看提示词。提示词里如果有模糊表述，模型就会自由发挥。要把判定标准写死，比如"NG 率超过 5% 判定为异常"，而不是"NG 率较高时判定为异常"。

最后看上下文长度。如果塞给模型的上下文太长，它可能抓不住重点。这时候要做信息压缩，只给关键数据。

4.2 工具调用失败怎么排查

Agent 调工具失败，通常是三个原因：参数格式不对、工具本身报错、模型理解错了工具用途。

我的排查顺序是：先看工具返回的错误信息（所以工具一定要返回详细错误），再看模型生成的调用参数（打印出来对比 schema），最后看工具描述是否清晰。工具描述写得含糊，模型就会乱调。比如"查询数据"这种描述太宽泛，要写成"查询指定缺陷类型在指定时间范围内的出现次数"。

4.3 常见问题速查表

4.4 几个我踩过的坑

坑一：过度依赖 LLM 做实时判定。我一开始想让 Agent 参与每个工件的判定，结果延迟直接爆掉。后来改成只让 Agent 处理异常事件，正常工件走快路径，问题就解决了。

坑二：忽略数据质量。Agent 再聪明，喂给它的数据是错的也白搭。有次检测模型本身有 bug，把正常纹理判成缺陷，Agent 基于错误数据给了一堆错误建议。所以上线前一定要保证底层检测的可靠性。

坑三：没有人工确认环节。早期版本让 Agent 直接改参数，结果有一次它把阈值调得太松，漏检了一批不良品。后来所有敏感操作都加了人工确认，Agent 只给建议。

坑四：记忆库不清理。历史经验越积越多，检索出来的都是过时案例。要定期清理和更新记忆库，把失效的经验标记掉。

5. 落地建议与扩展方向

5.1 分阶段落地的节奏

别想着一步到位做个全能 Agent，我建议分三步走。

第一步，只做数据聚合和报告生成。这个最简单，风险最低，先让团队看到价值。Agent 把检测数据汇总成日报周报，工艺工程师省了做表的时间，接受度自然高。

第二步，加入异常归因和告警。让 Agent 分析异常原因，给出处理建议，但决策权还在人手里。这个阶段重点是积累数据和验证 Agent 的判断准确率。

第三步，开放有限的自主决策。对于低风险、高频次的操作（比如复检触发），可以让 Agent 自主执行。高风险操作仍然人工确认。

这个节奏的好处是每一步都有明确的价值产出，也给了团队和系统磨合的时间。

5.2 效果评估的指标

怎么判断 Agent 做得好不好？我一般看这几个指标：决策准确率（Agent 建议被采纳的比例）、异常响应时间（从发现异常到给出建议的耗时）、人工干预率（需要人工纠正的比例）、报告生成效率（相比人工节省的时间）。这些指标要持续跟踪，作为迭代依据。

5.3 后续可以扩展的方向

这套架构搭起来之后，扩展空间很大。比如接入更多数据源（设备振动、温度、来料批次），让 Agent 做更全面的归因；比如把 Agent 和 MES、ERP 打通，实现从检测到生产的闭环；再比如用 Agent 辅助检测模型的迭代，自动分析误检漏检案例，生成优化建议。

我个人在实际操作中的体会是，工业检测 Agent 的价值不在于它多"聪明"，而在于它能把散落的数据、经验、决策逻辑串起来，让整个检测系统从"被动判定"变成"主动优化"。这个转变带来的效率提升，往往比单纯提升检测精度更可观。最后分享一个小技巧：Agent 的提示词不要一次写死，留个配置文件，方便现场根据实际情况调整，毕竟每个产线的工况都不一样，能快速迭代才是王道。