工业检测软件如何引入AI Agent：从架构到落地全攻略

这两年做工业检测软件开发的朋友应该都有同感：软件功能本身很久没有质变了。定位、测量、缺陷分类这些算子库越来越全，可真正到了产线上，调试一套检测流程依旧靠老师傅一点一点试参数、标缺陷、调阈值。我去年参与了一个模拟项目X，前前后后改了十几版检测脚本，每次换料型都要重新标定。那段时间我一直在琢磨：能不能把这套繁琐的流程交给一个AI Agent去自主完成？

这篇文章就围绕"工业检测软件怎么做AI Agent"展开，聊聊我从想法到落地全过程中的设计思路、架构拆解、模型选型、工具链搭建，以及踩过的坑。内容面向两类人：一是做视觉检测软件架构的工程师，想给现有系统加一层智能决策能力；二是刚接触大模型、想知道它除了对话还能在工业场景干什么的开发者。读完你至少能获得一个可复现的最小闭环方案，以及一套判断Agent是否真正值得上产线的评估框架。

1. 先把问题定义清楚：工业检测Agent到底解决什么

很多团队一上来就说"我们要做个智能检测Agent"，结果做出来是个套了聊天皮的检测软件，根本没人用。根子在于没想清楚：Agent和传统检测系统的边界到底在哪。

1.1 传统检测软件的"三座大山"

传统工业检测软件的痛点，归纳下来就三件事，每一件都是真实产线上耗人精力的大头。

第一是参数调试成本高。一个检测工位往往要处理几十个参数：曝光时间、光源亮度、滤波核大小、二值化阈值、Blob面积范围、特征匹配分数……这些参数不是调一次就完事，换一种物料、换一个批次，可能就要重新适应。某3C电子厂的零件表面检测项目里，工程师光是把划痕检测的阈值从0.75调到0.68，就花了半天时间，还得配合现场打光条件反复验证。

第二是缺陷样本难沉淀。产线上的异常永远是"长尾分布"：划痕、脏污、磕碰、毛刺、压伤、异色、缺料、溢胶……每个品类都有自己的"个性缺陷"。传统做法是人工截图、人工标注、定期训练模型，但样本散落在各个工程师的电脑里，缺少系统化的回流机制，导致算法迭代速度永远赶不上新缺陷出现的速度。

第三是检测逻辑是固化的。传统检测软件的流程写死了：定位、ROI裁剪、算法处理、判定输出。这套链路对"已知的已知"很有效，但对"已知的未知"和"未知的未知"完全无能为力。比如一个从来没见过的新缺陷类型，或者一个因为来料角度偏了导致整个流程崩溃的情况，传统软件要么报错停机，要么直接误判，没有中间态。

这三座大山共同指向一个本质问题：检测系统缺少"理解"和"自适应"的能力。它不知道自己在检什么、为什么这样检、检出来的结果意味着什么，只是机械地执行算子序列。

1.2 Agent能带来哪些质的改变

AI Agent的核心能力，放在工业检测语境里就是一句话：让检测系统具备感知、决策、执行、记忆、反思的完整闭环。

举一个具体场景。产线上突然出现一批表面有细微水渍痕迹的产品，传统检测方案里没有"水渍"这个缺陷类别，于是这批产品被判定为良品流出，或者被当作"脏污"批量误杀。如果有Agent参与，它的行为路径会是这样的：

• 感知：视觉模型提取到一批特征向量，与已知缺陷库比对后发现相似度低，判定为"疑似新缺陷"；
• 决策：调用大模型对该区域进行开放词汇描述，结合产线湿度传感器数据，推理出"可能是水渍"；
• 执行：触发"灰度增强 + 边缘梯度响应"组合算法做二次确认，同时异步通知质检员确认；
• 反思：确认后把这个样本加入缺陷库，并调整后续检测逻辑，在下一次遇到类似水渍时自动识别。

这个过程不是把一个大模型塞进检测软件就完事，而是要在传统检测系统外面加一套"智能操作系统"，让它调度已有的算法工具，并在闭环中持续进化。

这里有个重要认知：Agent不是来替换传统检测算法的，而是来做它们的调度者、编排者和解释者。传统算法是手，Agent是大脑。手还是那双手，但大脑知道什么时候该用哪只手、用完了怎么判断结果、结果是否需要返回去修正手的动作。

2. 架构拆解：检测Agent的关键模块与协作方式

如果把工业检测Agent拆开看，它并不是一个单独的服务，而是一组模块的有机组合。我在模拟项目X里的整体架构分四层，下面逐一拆解。

2.1 感知层：视觉特征提取与缺陷理解的边界

感知层的职责是把"图像"变成"信息"，它的核心不是深度学习模型本身，而是模型的"表达能力"和"组织方式"。

传统检测软件里的视觉输出是单一的：一个面积值、一个灰度均值、一个匹配分数。Agent需要的是更丰富的结构化描述：目标区域在哪、什么形状、表面纹理特征如何、颜色分布怎样、边缘梯度方向如何。因此感知层不只是跑一个分类网络，而是同时跑多个特征提取器，把结果组织成多模态特征向量。

我用的方案是：经典图像处理特征（HOG、LBP、灰度共生矩阵） + 轻量化CNN特征 + 语义分割掩码，三者融合成一条结构化的"视觉观测帧"。为什么要保留经典特征？因为工业现场的图像噪声、光照变化对CNN很不友好，而经典特征在某些场景下反而更稳定。Agent在推理时可以根据置信度决定信任哪种特征来源，这是一种"多模态冗余"设计。

感知层的另一个关键设计是"异常检测前置"。在进入Agent决策之前，先用一个自编码器或者孤立森林模型做无监督异常检测，将图像分为"正常、疑似异常、未知异常"三档。这相当于给Agent加了好感度门槛，大部分产线图像是正常的，不值得消耗大模型算力去推理，只有异常或未知图像才会触发Agent的深度介入。

2.2 决策层：从规则引擎到大模型的推理链路

决策层是Agent的中枢，负责回答三个问题：现在发生了什么？应该怎么处理？处理后怎么确认？

我给决策层的设计是"规则优先 + LLM兜底 + 反射修正"三层结构。规则优先是指所有已知缺陷类型、已知处理逻辑都写成结构化规则，直接走传统流程，不经过大模型。这样保证检测的确定性和低延迟。LLM兜底是指当规则的置信度低于阈值，或者输入数据特征无法匹配任何已知规则时，将任务交给大模型做开放推理。反射修正则是在每一次决策后，把实际结果与预期结果做对比，形成一条"反思记录"，用于后续规则优化。

举个例子。规则库里有一条："胶囊外观检测：如果面积大于50像素且灰度低于80，判定为黑点。"当Agent遇到一个面积30像素但灰度低于40的小颗粒时，规则给出"不够黑点阈值，放行"，但异常检测模块提示"疑似异常"。此时LLM介入，结合小颗粒的位置（恰好位于胶囊头部边缘），推理出"可能是压伤而非黑点"，并建议用边缘检测算法验证。验证结果确认是压伤，反射机制记录下"小面积+低灰度+位于边缘 = 压伤"这条新经验。

这种三层结构有个好处：它不会让大模型成为系统的瓶颈，也不会因为规则死板而漏掉新缺陷。本质上是把"经验知识"和"机器智能"做了分层管理。

2.3 执行层：工具调用与闭环控制

执行层解决的问题是：Agent做出决策之后，命令怎么下达、动作怎么执行、结果怎么回收。

工业检测软件的工具集通常是固定的：图像采集、曝光控制、算法处理、PLC信号输出、数据库写入、告警推送。Agent要做的事情是为这些工具设计统一的功能接口，让大模型可以通过"函数调用"的方式触发它们。

我这里的做法是参考OpenAI Function Calling的思路，给每个工具写一个JSON Schema描述，包含工具名、入参、出参、功能说明、注意事项。大模型根据当前上下文决定调用哪个工具、传什么参数。关键点是这个工具描述必须写得"足够笨人友好"：比如"adjust_threshold"这个工具，Schema里不能只写"调整阈值"，而要写清楚"调整缺陷判定的灰度阈值，范围0-255，值越小越容易判缺陷，默认建议70-90之间，调整后需重新跑一遍检测确认误判率"。

执行层的闭环控制同样重要。一个检测动作执行完，系统必须把结果回传给决策层，决策层结合结果更新内部状态，然后决定下一步动作。这本质上是一个状态机：每步动作之后，Agent的世界模型都在更新。我在实现上用了一个"执行记录表"，每一步动作的时间、参数、结果、置信度都被记录下来，既用于当前流程的控制，也用于后续反思和复盘。

2.4 记忆与反馈：样本沉淀与模型迭代

很多做Agent的人容易忽略记忆层，但在工业场景里，记忆才是Agent长期价值的核心。产线每天都在产生新数据，如果Agent不能把经验存下来，它就是个一次性对话工具，没有任何积累价值。

我的记忆层设计分两部分：短期记忆和长期记忆。短期记忆是指当前检测会话内的上下文，比如"这一批产品的来料批次、当前缺陷率、最近10次检测判定结果"；长期记忆则是一个经验库，存储历史样本、特征向量、判定结论、反思记录，供后续同类场景直接命中。

长期记忆的实现方式就是业界常说的RAG（检索增强生成）。每个缺陷样本被编码成特征向量存入向量数据库，当新样本到来时，Agent先从库中检索相似样本，带着相似样本的表征做推理。这样一来，Agent的判断不是凭空产生的，而是有历史案例支撑的。

模型迭代则是记忆层的上层应用：当经验库里的同类样本累积到一定数量，系统自动触发一次增量训练，更新感知层的检测模型。闭环走完，Agent的能力螺旋式上升。

3. 关键设计：模型选型与工具链搭建

聊完架构，说说落地的关键设计决策。这部分是真正决定项目成败的地方，也是很多团队一开始就走偏的部分。

3.1 大小模型协同的落地思路

工业现场有一个天然约束：GPU算力不充裕，往往只有一台带基础显卡的工控机，甚至有些老产线连GPU都没有。这意味着你不能指望在每台工控机上跑一个大模型。

我的建议是"大小模型协同、分层部署"。轻量模型（YOLO系列、MobileNet、自编码器）跑在边缘工控机上，负责实时检测和异常预筛；中等模型（10B以下的视觉语言模型）跑在产线边缘的GPU服务器上，负责需要一定理解能力的判定；大模型（70B级别以上）放在工厂AI中心或云端，负责复杂度高的推理、知识沉淀和规则生成。三级部署的算力代价递减，但决策能力递增。

这样做还有一个额外收益：边缘端即使与中心断开网络，也能保底完成基本的检测逻辑，Agent的决策质量会降低但不会宕机。这在工业现场是硬需求，产线停产一分钟都是经济损失。

模型选型上我踩过一次坑：一开始贪心选了70B大模型做全量推理，效果确实好，但延迟达到4秒，根本扛不住产线节拍。后来把80%的常见缺陷判定下沉到规则和轻量模型，大模型只处理剩余20%的疑难情况，平均延迟一下降到300毫秒以内，可接受的检测节拍才得以保障。

3.2 工具集设计：从"被动调用"到"主动调度"

工具设计决定了Agent的能力边界。我最初只给Agent暴露了3个工具：检测、调参、报警。结果它的能力非常受限，面对复杂情况要么报错、要么答非所问。后来我把工具集扩充到11个，才真正体现出Agent的调度价值。

核心工具集合分为四类：

• 感知类工具：图像采集、ROI标定、特征提取、异常打标
• 分析类工具：算法运行（滤波/边缘/形态学）、参数评估、批量回放
• 控制类工具：曝光/光源调节、阈值设定、PLC信号输出
• 知识类工具：经验库检索、相似样本匹配、缺陷描述生成

每一类工具必须配合完整的Schema描述，大模型才能"正确地用错"。这里有个细节：工具名和描述要写成"场景导向"而非"接口导向"。同样是阈值调整，Schema描述里写"适用于灰度类缺陷的判定敏感度调整，值越小灵敏度越高"比写"调整integer参数threshold"好用十倍。大模型不理解工业术语，但完全能理解人话描述。

主动调度是指Agent能根据当前检测状态自动编排工具的执行顺序。比如它发现当前批次产品的表面纹理复杂，导致边缘检测误判率偏高，会自动决策：先执行图像滤波增强，再执行边缘检测，并用形态学闭运算去除细小噪点，最后再判定缺陷。传统检测流程的算子顺序是写死的，Agent让这个顺序变成了动态可编排的，这是我见过最明显的体验提升点。

3.3 提示词与工作流编排要点

提示词设计在工业检测场景里和其他领域有些不一样。工业场景的要求是"稳定、可预期、结构化"，而不是"有创意、发散、自然"。所以提示词模板要做严格约束。

我常用的系统提示词结构包括三部分：角色定义（你是谁）、能力边界（你能做什么、不能做什么）、行为规范（怎么思考、怎么调用工具、怎么报告结果）。其中能力边界一定要写清楚"不能做什么"，避免Agent跨权操作。比如"不得修改检测流水线的PLC控制逻辑"、"不得直接删除经验库中的历史样本"、"当置信度低于0.6时必须人工介入"。这些约束能在很大程度上减少危险动作。

工作流编排上，我建议画一条主状态链路：图像接入 → 异常预筛 → 规则判定 → LLM决策 → 工具执行 → 结果确认 → 经验回流。每一步都有明确的出口条件，不满足则触发回退或告警。这套链路要落到代码里，不能靠大模型"自由发挥"，不然产线稳定性会出大问题。

我的经验是：Agent自主性要给，但要有栅栏。给它在一个大的SOP框架内自主编排，而不是让它无约束地全权接管。工业场景容错率极低，任何Agent厂房降本增效宣传背后，都是无数次"擦边球"测试换来的平衡。

4. 实操：从0到1做一个检测Agent的最小闭环

理论讲完，上一套能跑起来的实操方案。这个最小闭环大概需要一周左右的开发时间，就能在一个模拟检测数据集上验证Agent的基本能力。

4.1 环境准备与基础能力接入

我的建议是用Python生态，PyTorch做模型部分，vLLM或Ollama做大模型推理，FAISS做向量检索，FastAPI做服务框架。工控机与中心之间用消息队列通信，这样Agent架构可以随时拆解、重部署。

第一步先把传统检测管线的接口封装好，给每个算子一个明确的输入输出JSON格式。这一步是Agent能不能"握住"检测系统的手的关键，接口封装得越薄越好，让Agent不直接接触底层相机SDK和PLC协议。我会把图像采集封装成一个"take_photo()"，把算法运行封装成"run_algorithm(name, params)"，把结果输出封装成"send_result(verdict, confidence)"。Agent看到的就是这三个函数，至于里面是调用哪家相机、哪家PLC，它不需要知道。

基础能力接入的第二件事是搭一个向量数据库，把项目里历史积累的缺陷样本图、特征向量、判定结论全部灌进去。这一步必须做，否则Agent的检索式推理就是空谈。样本不用太多，几百张有代表性的就够了，关键是每张样本都要有标签和结构化描述。

4.2 构建检测任务的数据Schema与状态机

Agent要理解检测任务，需要先把任务本身的"语法"定义清楚。我用一个数据Schema来描述当前检测任务：

{ "task_id": "batch_20240618_01", "material": "steel_surface_grade_a", "inspection_points": ["scratch", "rust", "pitting", "stain"], "current_image": "path/to/image_0231.jpg", "detection_result": null, "confidence": null, "status": "pending", "history": [] }

每个字段都在告诉Agent：我在检什么、当前看到什么、已经做了什么。Agent每完成一步，就更新这个Schema，并且把操作记录放到history里。

状态机是另一个关键组件。我把一个完整的检测流程划分为5个状态：INIT（初始化）、SCAN（扫描待检）、JUDGE（判定中）、ACT（执行中）、REVIEW（复核中）。状态转移不允许跳过，比如从SCAN直接跳到REVIEW是不合法的，Agent必须经过JUDGE并产生置信度结果才能进入REVIEW。这个设计有效防止了大模型"跳步"带来的混乱。

4.3 让Agent学会"调用检测工具"

接下来是核心一步：让大模型学会通过Function Calling调用我们封装的检测工具。以几个核心工具为例：

{ "name": "run_algorithm", "description": "运行指定的图像处理算法，用于对当前图像进行特征增强或检测。", "parameters": { "type": "object", "properties": { "algorithm_name": { "type": "string", "enum": ["median_blur", "canny_edge", "threshold", "contour_extract", "morphology_close"], "description": "要运行的算法名称" }, "params": { "type": "object", "description": "算法的参数键值对，具体参数取决于算法名称" } }, "required": ["algorithm_name"] } }

这个Schema是给大模型看的，所以描述信息要尽可能细化。比如"algorithm_name"里枚举的每个算法，最好在描述里给出典型使用场景和推荐参数范围。大模型"读"到这个Schema后，才知道什么时候该用Canny、什么情况该做形态学闭运算，而不是乱猜。

做好Schema后，我用一个模拟对话验证Agent的工具调用逻辑：给它一张表面有细微裂纹的图片，问它该怎么做。如果模型正确输出调用median_blur和canny_edge的组合，再配合contour_extract做轮廓提取，说明工具链打通了。

4.4 从单步执行到多步自主排障

工具调用跑通后，要进一步提升Agent的自主性，让它不仅能执行单步动作，还能根据执行结果动态调整策略。这一步我给Agent接入了一个"反思循环"。

结构上我用了一个简单的Agent循环：观测（拿到当前图像和状态）→ 推理（大模型根据观测生成下一步计划）→ 执行（调用工具）→ 反思（比较执行结果与预期，决定是否继续或终止）。

我设计了一个模拟排障场景来测试它：一张钢材表面图像，初始用固定阈值分割缺陷，结果把正常纹理误报成划痕。Agent的反思机制应该让它意识到"阈值分割在这种光照条件下不可靠"，然后自主切换到"边缘特征 + 纹理分析"的检测路径。如果系统设计合理，它会在2到3轮内找到更优的检测配置，而不是死磕一个参数。

多步自主排障的关键点在于"反馈信号"的获取。工业检测里，反馈信号可以是缺陷检测的准确率、检测时间消耗、误报数量等。Agent每尝试一种新配置，都要能拿到这些反馈，才能判断自己做得好不好。我把这个反馈设计成了一个回调函数，每轮循环结束时返回当前配置下的检测质量评分，把评分注入提示词上下文，供大模型参考。

4.5 用一套量化指标判断Agent是否合格

Agent做完不能只靠"看起来聪明"来验收，必须有一组量化指标。我用的指标体系围绕三个维度：

• 检测能力：准确率（Accuracy）、误报率（FPR）、漏报率（FNR），对比传统检测基线
• 决策质量：工具调用成功率、多步决策完成率、反射修正命中率
• 工程性能：单次检测Latency、Agent调用LLM的Token消耗、占用的显存/内存

我认为最关键且最容易被忽视的是"决策质量"里的反射修正命中率。这个指标反映了Agent是否真的在"学习"：它在反思中提出修正方案的次数里，有多少次真的改善了检测结果。我见到的初版Agent这个指标普遍很低，大概20%到30%，说明它大多数反思是无效空转。经过提示词优化和工具描述优化后，能提升到60%以上，这时候Agent才是有实践价值的。

另外一定要做A/B对比测试：同一批测试样本，分别用传统检测流程和Agent强化流程跑，对比误判率和处理时间。不要只看准确率，因为Agent有时会用更多步骤获得同样准确的结果，如果没有效率收益，产线是不愿意为复杂度买单的。

5. 落地踩坑记录与排查速查表

最后聊聊实操中真正踩过的坑，以及对应的排查思路。这些内容比架构设计更值得看，因为都是代码和产线上真实发生的问题。

5.1 典型故障一：Agent幻觉导致误检

Agent用久了，一定会遇到"幻觉"问题，在工业检测里非常危险。我遇到的一个真实案例：某新能源电池模组的表面检测任务里，Agent在处理一张图像时，因为检索到了经验库中一个相似度高达0.87但实际是不同缺陷类型的样本，直接把它当成判定依据，输出了"此缺陷为极耳受损，需停机"的错误结论。其实那个图像只是一个轻微折痕，按产线标准可以放行。

排查思路分两步。第一步，检查相似度阈值是否设置得过高，检索到的样本是否真的足够相似；第二步，在提示词里强调"相似样本仅作参考，必须结合当前图像的独立特征做最终判断"，并在输出格式上要求Agent标明"参考样本ID"和"独立判断依据"，这样即使出错也可追溯。

从根本上解决幻觉，要靠"置信度门槛 + 人工确认"机制。我设定AI每一判断都必须携带置信度，低于0.7的判定结果自动转向人工复核。这个机制会牺牲一部分效率，但产线上的安全价值远远高过效率。

5.2 典型故障二：工控现场算力不足

很多产线的工控机配置很老，我遇到过一台只有8GB内存、无独立显卡的工控机，连轻量级YOLO模型都跑不顺，更别提Agent了。一开始硬往里塞大模型，结果图像采集线程和推理线程互相抢资源，整个检测工位卡死。

解决方案是"分层降级 + 异步化"。图像采集和实时预筛跑在工控机主线程，Agent推理全部放到边缘GPU服务器，通过局域网把预筛后的"疑似异常帧"送过去推理，结果回传。工控机本地再加一级缓存队列，防止断网时数据丢失。

异步化的关键是把"实时链路"和"智能链路"彻底分开。实时链路保证产线节拍不中断，智能链路负责疑难帧的深度分析，两者通过消息队列解耦。只要实时链路正常，Agent哪怕挂了，产线也只是降级到基础检测模式，不会停机。

5.3 典型故障三：数据漂移带来的Agent退化

Agent上线时效果很好，用了两三个月后准确率肉眼可见地下降。排查后发现原因很常见：产线换了新供应商的原材料，表面纹理和原先差异很大，但Agent的经验库没有更新，检索匹配一直命中旧的相似样本，导致误判率上升。

数据漂移是工业AI的老大难，Agent场景下更突出，因为Agent依赖检索和经验库，一旦库里的样本分布跟不上现实分布，决策质量就会出问题。我的对策是设计一个"分布漂移监控器"，定期对近期检测图像的特征分布和建库时的基底分布做距离计算（比如Wasserstein距离），一旦超过阈值，自动触发主动学习流程：把分布外的图像挑出来，发起标注任务，人工确认后回流到经验库。

另一个更简单的对策是"样本保鲜期"：给经验库里的每个样本打上入库时间和最后命中时间，定期清理超过保质期且长期未命中的样本，防止脏数据长期占据检索空间。

5.4 排查速查表

最后说点真实的感受

做完这个项目后，我最大的体会是：AI Agent在工业检测里绝不是"灵丹妙药"，它更像一个极其聪明的学徒——学得快、懂得多、反应灵活，但仍然需要师傅给定框架、划好边界，否则会用自己的"聪明"闯祸。真正让它发挥价值的关键，不是大模型选得多强，而是"感知数据的结构化程度"和"反馈闭环的完整性"。数据结构化做不好，Agent就是无源之水；反馈闭环断了，Agent就只是个会聊天的空壳。

最后分享一个小技巧：给Agent的每一个决策动作加一行日志，记录"当时看到了什么、为什么这样判断、最后结果如何"。这个日志成本极低，但排障时的价值无可估量。产线现场的人不会因为你的模型准确率高就信任你，但会因为你能够在出现问题后30分钟内定位到责任环节而信任你。做工业软件，赢得信任比赢得性能更重要。