1. 工业检测软件为什么需要AI Agent而不是再加一个算法模块工业检测软件这个领域过去十年的主流做法是“加算法”缺陷检测加一个分割模型尺寸测量加一个边缘提取字符识别加一个OCR。每来一个新需求就塞一个新模型进去界面上的按钮越堆越多参数面板越来越长。操作员要记住哪个产品用哪套参数换型的时候手动切换配方出了问题再回头翻日志。这套模式在产线稳定、品类单一的时候还能撑住一旦遇到多品种小批量、换型频繁、缺陷形态变化快的场景就开始力不从心。AI Agent要解决的恰恰不是“再识别一种缺陷”而是把检测软件从“被动执行工具”变成“能自己判断下一步该干什么的协作方”。举个具体的例子一条混线生产的装配线上午跑A型号下午切B型号。传统软件需要工程师提前把两套配方都调好操作员换型时手动加载。而一个具备Agent能力的检测软件可以在相机取到第一帧图像后自己判断当前是哪个型号自动匹配对应的检测逻辑甚至在检测到连续多帧置信度偏低时主动提示“当前光照可能偏移建议重新标定”而不是傻傻地一直输出NG。这里的关键区别在于算法模块负责“看”Agent负责“决定怎么看、看完之后怎么办”。工业检测里真正耗人的从来不是单次推理而是围绕推理的一整套决策链——用哪个模型、阈值定多少、结果怎么复核、异常怎么上报、数据怎么回流。这些环节目前大量依赖人工经验而Agent的价值就是把这部分经验结构化、可执行化。我见过不少团队一上来就想做“全自主检测”让Agent自己决定一切。这个方向在现阶段风险极高因为工业场景对误判的容忍度极低一次漏检可能意味着批量客诉。更务实的路径是从“辅助决策”切入Agent不直接控制产线动作而是负责参数推荐、异常归因、报告生成、复检调度这些“软环节”。等这些环节跑稳了再逐步把权限往执行层放。这个边界感是工业Agent和通用Agent最大的不同。还有一个容易被忽略的点工业检测软件里的Agent天然是多模态的。它要看的不仅是图像还有PLC的时序信号、设备的温度振动、历史工单的文本记录。一个缺陷的产生可能是来料问题也可能是设备漂移还可能是工艺参数越界。单看图像永远只能给出“是什么”给不出“为什么”。Agent要做的是把这些异构信息串起来形成一条可追溯的证据链。这也是为什么工业Agent的架构不能照搬聊天机器人的那一套它需要一套面向时序和工控数据的感知层。2. 拆解工业检测Agent的四层能力骨架2.1 感知层把图像、时序和工单文本统一成Agent能吃的输入感知层是整个Agent的地基但很多团队在这里偷懒只把图像丢给模型其他信号一概不管。结果就是Agent只能回答“这张图有没有缺陷”回答不了“为什么这一批缺陷集中出现在第三工位”。我的做法是感知层至少要接三类数据源。第一类是视觉数据包括原始图像、预处理后的ROI、以及模型输出的热力图和置信度分布。注意Agent需要的不是单一的分类标签而是带空间信息的中间结果。比如一个划痕缺陷Agent要知道它的位置、走向、长度才能判断是刀具磨损还是搬运磕碰。第二类是设备时序数据通过OPC UA或Modbus从PLC、传感器采集。采样率不用太高1Hz到10Hz就够关键是时间戳要和图像帧对齐。对齐这件事说起来简单做起来坑很多——相机触发和PLC扫描周期往往不同步需要在采集端做一次时间归一化。我通常会在采集服务里维护一个统一的时间基准所有数据落库时都带上这个基准时间戳后续Agent推理时才能做真正的跨模态关联。第三类是业务文本数据包括工单信息、换型记录、维修日志、历史判废原因。这些数据通常散落在MES或纸质记录里需要做一次结构化抽取。不用追求大而全先把最近三个月的换型记录和维修记录整理成结构化表格Agent就能用上。# 感知层数据对齐的简化示意 class PerceptionHub: def __init__(self): self.time_base None def align(self, image_frame, plc_sample, work_order): # 以图像帧时间为基准找最近的PLC采样点 nearest_plc min(plc_sample, keylambda x: abs(x.ts - image_frame.ts)) # 工单信息按时间段匹配不要求精确到帧 matched_order self.match_order(work_order, image_frame.ts) return { vision: image_frame, plc: nearest_plc, order: matched_order, aligned_ts: image_frame.ts }注意时间对齐的误差要控制在半个PLC扫描周期以内否则振动信号和图像缺陷的因果关系会失真。我一般要求对齐误差小于50ms。2.2 推理层不是一个大模型而是一组可调度的专家很多人的第一反应是“接一个大模型进去”。但在工业检测里通用大模型直接看图判缺陷的准确率往往还不如一个训练了三天的小型分割网络。所以推理层的正确姿势是专家调度底层是一组专用小模型上层是一个负责编排的决策模块。具体来说我会把推理层分成三个角色。检测专家负责像素级任务比如缺陷分割、尺寸测量、字符识别这些用轻量CNN或传统视觉算法就够了追求的是稳定和速度。归因专家负责把检测结果和设备时序、历史记录关联起来输出可能的原因排序这部分可以用规则引擎加轻量分类器实现。策略专家负责决定下一步动作比如是否触发复检、是否调整阈值、是否通知工程师这部分才是真正需要语言模型能力的地方因为它要理解自然语言描述的工艺规则和操作员指令。这三个角色的调度逻辑我倾向于用状态机加优先级队列来实现而不是让大模型自由发挥。原因很直接工业场景要求可解释、可回滚。状态机保证了每一步决策都有明确的触发条件和退出条件出了问题能定位到具体是哪条规则被触发。大模型只在策略专家这一层做“翻译”和“建议”最终执行权还在状态机手里。角色典型任务推荐技术响应时间要求检测专家缺陷分割、尺寸测量轻量CNN/传统CV100ms归因专家原因排序、关联分析规则引擎分类器500ms策略专家动作建议、报告生成语言模型状态机2s2.3 记忆层让Agent记住这个产线特有的“脾气”通用Agent可以没有记忆每次对话从零开始。工业Agent不行它必须记住这条产线、这个工位、这个型号的历史表现。记忆层要存三类东西短期记忆是当前批次的检测结果序列用来判断趋势长期记忆是历史批次的统计特征用来做基线对比规则记忆是工程师沉淀下来的工艺知识和处置经验。短期记忆用环形缓冲区就够了保留最近500帧的结果。长期记忆我建议用轻量时序数据库按工位和型号建索引存每批次的缺陷率、置信度均值、参数漂移量这些聚合指标。规则记忆最容易被忽视但它恰恰是Agent“越用越聪明”的关键。我的做法是提供一个简单的规则录入界面让工程师用自然语言写处置经验比如“当A型号的划痕缺陷连续三帧置信度低于0.7时优先检查光源亮度”后台把这句话解析成可执行的触发条件。这里有个实操心得规则记忆不要追求自动学习先做好人工沉淀。我见过团队试图用强化学习让Agent自己摸索处置策略结果在真实产线上试错成本太高根本跑不起来。反而是老老实实把老师傅的经验一条条录进去Agent的表现提升最快。等规则库积累到几百条再考虑用模型做规则推荐和冲突检测。2.4 执行层Agent的输出必须能落到工控动作上执行层是工业Agent和通用Agent分道扬镳的地方。通用Agent输出一段文字就结束了工业Agent的输出必须能转化成具体的工控动作调整相机曝光、触发复检工位、标记NG品、推送工单。这些动作通过PLC或工控机接口下发要求确定性和可回滚。我的做法是执行层维护一个动作白名单Agent只能从白名单里选动作不能自由生成。白名单里的每个动作都有明确的参数范围和回滚策略。比如“调整曝光”这个动作参数范围限定在正负20%以内且调整后如果连续10帧置信度没有提升自动回滚到原值。这样既给了Agent一定的自主权又保证了产线安全。# 动作白名单的简化定义 ACTION_WHITELIST { adjust_exposure: { param_range: (-0.2, 0.2), rollback_after: 10, rollback_condition: confidence_not_improved }, trigger_recheck: { max_per_hour: 20, notify: [operator] }, mark_ng: { require_confirm: False } }提示执行层的动作日志必须完整记录包括触发时间、触发原因、执行结果、是否回滚。这份日志既是排查依据也是后续优化Agent策略的数据来源。3. 从零搭建一个可用的检测Agent我的落地步骤3.1 先别碰模型把数据管道跑通我接手过几个“Agent项目”最后发现卡壳的地方都不是模型效果而是数据管道。图像存得到处都是PLC数据在另一台机器上工单信息还在Excel里。所以第一步永远是统一数据入口。具体操作搭一个采集服务把相机、PLC、MES的数据都汇聚到一个消息队列里按统一时间戳落库。这一步不需要任何AI就是纯工程。但这一步做扎实了后面所有事情都会顺。我通常要求采集服务能稳定跑一周不出错数据丢失率低于0.1%才开始做Agent逻辑。数据管道跑通后先做一个离线回放工具。把历史数据按时间轴回放模拟实时输入用来调试Agent的决策逻辑。这个工具能省掉大量上产线调试的时间因为产线停机的成本太高了。3.2 用规则引擎搭出Agent的“骨架决策”在模型还没调好的时候先用规则引擎把决策骨架搭起来。比如如果连续5帧NG且置信度大于0.9直接标记NG如果置信度在0.5到0.9之间触发复检如果连续3帧置信度低于0.5提示检查光源。这些规则用Drools或简单的Python规则引擎就能实现。这一步的目的是让Agent先跑起来哪怕它只会做最简单的判断。跑起来之后你会很快发现哪些规则太松、哪些太紧、哪些场景根本没覆盖到。这些发现比坐在那里空想架构有价值得多。我自己的经验是规则引擎搭出来的骨架能覆盖80%的常规场景。剩下的20%长尾场景才是模型和语言模型发挥作用的地方。如果一上来就追求全模型驱动反而会把简单问题复杂化。3.3 把语言模型接在“策略建议”这一环语言模型在工业Agent里最合适的切入点是把非结构化的工艺知识转化成结构化的决策建议。比如工程师在聊天框里输入“最近B型号的划痕变多了帮我看看怎么回事”语言模型负责把这句话拆解成查询条件型号B、缺陷类型划痕、时间范围最近一周然后调用归因专家去查数据最后把结果组织成一段人话回复。这里的关键是不要让语言模型直接看图或直接控制设备。它只做“翻译”和“组织”中间的数据查询和动作执行都由确定性模块完成。这样既利用了语言模型的语义理解能力又避免了它的不确定性带来的风险。我实测下来语言模型在策略建议这一环的准确率取决于提示词里给了多少上下文。把当前工位的历史缺陷率、最近换型记录、设备状态摘要都塞进提示词模型给出的建议会靠谱很多。但即便如此最终建议还是要经过规则引擎的校验才能执行。3.4 上线前的灰度验证影子模式跑两周Agent上线前必须经过影子模式验证。所谓影子模式就是Agent在后台运行输出决策建议但不实际执行只记录“如果执行了会怎样”。同时人工操作照常进行最后对比Agent建议和人工操作的差异。这个阶段通常跑两周覆盖至少三次换型和一次设备维护。重点看三个指标Agent建议和人工操作的一致率、Agent建议中明显不合理的比例、以及Agent发现而人工遗漏的异常数量。一致率低于70%说明规则太激进不合理比例高于5%说明规则太松遗漏异常数量为零说明Agent没起到补充作用。影子模式跑完把发现的问题修一轮再切到半自动模式Agent的建议需要操作员确认才执行。这个阶段再跑一周确认无误后才放开全自动执行。整个过程急不得工业场景的信任是一点点建立的。4. 踩过的坑工业Agent落地时最容易翻车的五个地方4.1 时间戳不对齐归因结论全是错的这是我踩过最狠的一个坑。当时Agent报告说“振动异常导致划痕缺陷”我差点就去换轴承了。后来一查振动数据的时间戳比图像晚了200ms所谓的“关联”完全是错位的。工业数据的时间对齐精度要求比互联网数据高一个数量级。我的教训是所有数据源在采集端就统一时间基准不要指望在Agent层做对齐。采集端对齐的误差可以控制在毫秒级Agent层再做一次对齐只会引入更多误差。4.2 把置信度当成万能阈值置信度是模型输出的概率不是物理世界的确定性。我见过团队把置信度0.8设为NG阈值结果在换型后模型没适应置信度整体偏低导致大量误判。正确的做法是动态阈值根据当前批次的置信度分布动态调整判定线。比如取最近100帧置信度的中位数作为基准上下浮动一定比例作为阈值。这样换型后模型短暂不适应时不会立刻产生大量误判。4.3 规则库膨胀到无法维护规则引擎用起来很爽但规则会越加越多。我见过一个项目半年积累了800多条规则互相冲突没人敢删。避免这个坑的办法是给规则加生命周期每条规则必须有创建人、创建原因、有效期。到期自动失效需要续期必须重新确认。同时定期做规则冲突检测把互相矛盾的规则标出来人工处理。4.4 语言模型产生“幻觉建议”语言模型在策略建议环节偶尔会给出听起来合理但实际不可行的建议。比如建议“把曝光调到最大”但实际硬件不支持。解决办法是在提示词里明确列出可用动作清单和参数范围并要求模型只能从清单里选。同时在输出后加一道校验参数越界直接拦截。我还会在提示词里加一句“如果不确定输出‘需要人工确认’”给模型一个安全的退路。4.5 忽视操作员的接受度技术再先进操作员不用就是零。我见过Agent建议复检操作员嫌麻烦直接忽略结果漏检。后来我们改了交互Agent的建议直接显示在操作员必经的界面上并且一键就能执行不需要跳转。同时把Agent的准确率数据定期展示给操作员看建立信任。工业Agent的落地一半是技术一半是和人打交道。5. 一个简化版检测Agent的代码骨架下面这个骨架展示了Agent的核心循环感知、推理、决策、执行。实际项目会复杂得多但结构是相通的。class InspectionAgent: def __init__(self, perception, experts, memory, executor): self.perception perception self.experts experts self.memory memory self.executor executor self.state idle def step(self): # 1. 感知获取对齐后的多模态数据 data self.perception.get_aligned_frame() if data is None: return # 2. 推理调度专家 detection self.experts[detection].infer(data[vision]) attribution self.experts[attribution].infer( detection, data[plc], self.memory.short_term ) # 3. 记忆更新短期和长期记忆 self.memory.update(detection, attribution) # 4. 决策策略专家给出建议 suggestion self.experts[strategy].suggest( detection, attribution, self.memory.rules ) # 5. 校验规则引擎校验建议 action self.validate(suggestion) if action is None: return # 6. 执行下发动作 result self.executor.execute(action) self.memory.log_action(action, result) def validate(self, suggestion): # 检查动作是否在白名单内参数是否越界 if suggestion[action] not in ACTION_WHITELIST: return None spec ACTION_WHITELIST[suggestion[action]] if param_range in spec: lo, hi spec[param_range] if not (lo suggestion[param] hi): return None return suggestion这个骨架里experts是一个字典每个专家可以是模型、规则引擎或语言模型的封装。memory负责短期和长期记忆的读写。executor负责和PLC或工控机通信。整个循环以固定频率运行比如每200ms一次保证实时性。注意validate这一步绝对不能省。Agent可以建议但执行前必须过校验。这是工业场景的安全底线。6. 关于效果评估和持续迭代的一点个人体会工业Agent的效果评估不能只看检测准确率。我通常看四个指标决策一致率Agent建议和人工操作的一致程度、异常发现率Agent发现而人工遗漏的异常占比、误报率Agent建议中不合理建议的比例、操作员采纳率操作员实际执行Agent建议的比例。这四个指标要一起看单看任何一个都会误导。持续迭代的关键是建立反馈闭环。操作员每次拒绝Agent的建议都要记录原因每次Agent发现异常都要记录后续处置结果。这些反馈数据定期回流用来调整规则和提示词。我自己的项目里前三个月每周迭代一次规则库之后降到每月一次。迭代频率太高说明规则不稳定太低说明Agent没在进步。最后说一个容易被忽视的点Agent的日志要给人看不是给机器看。我见过日志里全是JSON和ID工程师根本看不懂。后来我们改成每条决策都生成一句人话描述比如“因连续5帧置信度低于0.6触发复检建议”工程师一眼就能明白Agent在想什么。这个改动看似小但对建立信任帮助极大。工业场景里可解释性和准确性同样重要。