★ FEATURED ARTICLE 做工业质量系统这些年我越来越觉得SPC统计过程控制这类经典工具正处在一个尴尬的位置控制图每天都在生成报警邮件每天也在发但现场真正能在报警之后追根因、定对策的少之又少。很多质量工程师的日常是打开WebSPC看板、截个异常图、发到工作群然后就没有然后了。原因不是大家不重视质量而是传统SPC系统的能力边界太清晰网页化只解决了看图和报表的问题判异之后的根因分析依然要靠人工去翻设备参数、查工单批次、核对物料信息一个异常点查上半天时间一久自然变成报警疲劳。这套AI-SPC系统的出发点就是把这个缺口补上基于LangGraph编排完整的SPC智能分析流程基于MCP让大模型安全地触达测量数据、工艺参数、工单系统把控制图判异、根因归因、对策建议、审核闭环串成一个可追踪、可回放、可人工介入的Agent工作流。这篇是工程复盘笔记适合两类人看一是有MES、SCADA数据基础、正准备做AI质检智能体的后端或算法工程师二是质量信息化负责人想搞清楚AI-SPC到底能落地到什么粒度。1. 为什么传统WebSPC不够用先想清楚AI要补哪个环节1.1 SPC的闭环里最缺的是分析那一环SPC的核心思想其实很朴素用统计量判断生产过程是否处于受控状态。传统做法是先按时间顺序采集样本按子组计算均值、极差或标准差画成X-bar-R图或X-bar-s图再套用几条判异准则超界、连串、趋势都会被标记出来。这套方法论本身没有问题问题出在工程落地上。我见过不少企业的WebSPC系统功能停留在三个阶段中的前两个第一阶段是单机Excel表格时代第二阶段是C/S客户端时代第三阶段才勉强做到B/S网页化让质量工程师能在浏览器里看到实时控制图和报警列表。但SPC真正的完整闭环是四件事过程监控、异常判异、根因分析、对策执行。传统WebSPC很努力地做了前两件后两件几乎全靠人工。判异规则说连续6点递增异常可为什么递增是环境温湿度漂移、设备老化、来料批次波动、还是参数设定错误系统不会告诉你工程师得自己开一堆系统去查。1.2 AI-SPC的定位接管从报警到归因的中间地带我对AI-SPC的理解不是让大模型去画控制图也不是让它替代质量工程师做最终决策而是让AI接管报警之后到拿出候选根因之前这段最消耗人力的地带。具体来说系统要能做三件事第一判异规则命中后自动锁定异常点所在的时间窗口第二通过工具调用去查同窗口内的设备参数、工单批次、工艺设定和历史检测数据形成多维证据第三由大模型基于这些证据生成带引用来源的根因假设和处置建议推送给质量工程师审核。举个例子某产线的回流焊温度特征值在X-bar图上连续7点上升AI不会只说存在趋势异常它会去调MCP工具查这段时间的风速设定、链速、加热区温度曲线、当日锡膏批次然后给出类似链速从1.02降到0.98、加热区3实测温度偏高6℃与同批次锡膏活性变化叠加可能是温区内热电偶漂移这样的分析。1.3 为什么会选LangGraph和MCP这个技术选型是在对比过三条路线之后定的。第一条路线是传统硬编码用Python写死判异规则、写死归因查询逻辑再配一个规则引擎。缺点是每个新场景都要改代码归因逻辑越加越复杂完全谈不上智能。第二条路线是一个Agent自由发挥把数据查询工具全部丢给大模型让它自己决定调用顺序。问题很明显大模型在关键统计环节可能出现幻觉也缺乏对流程的可控性在质量场景里这是不可接受的。第三条路线就是我们最终采用的LangGraph加MCP用LangGraph把分析流程定义成有向图节点是确定性的计算步骤或LLM推理步骤边决定流程走向支持条件分支和人机协同用MCP把所有外部数据能力封装成标准工具大模型只能通过这些工具拿数拿不到的部分就明确说无证据。这套组合最大的好处是流程可控、过程可回放、权限有边界。2. WebSPC系统架构总览数据、服务、Agent三层怎么协作2.1 从控制图到Agent工作台的完整数据流整个WebSPC系统可以拆成四层我们内部习惯叫前端工作台、接入网关、Agent编排层、MCP工具层。前端工作台负责控制图渲染、异常列表和AI报告展示技术上是常见的Web应用图表部分用的开源图表库控制图这类图形本身不复杂真正复杂的是让用户能在一张图上同时看到原始测量点、控制限、判异标注和AI归因结论。接入网关是一层FastAPI服务承担任务创建、身份认证、审计日志和SSE推送。用户在页面上选择工序、时间范围和子组大小点开始分析后网关创建一条分析任务之后所有进度都通过服务端推送实时更新到页面上。Agent编排层是LangGraph实例负责跑完整个SPC分析流程。MCP工具层则是大模型和外部系统的唯一通道封装了测量数据服务、工艺参数服务、工单服务、报警通知服务。数据流是这样的操作员选择工序和时段 → 网关创建SPC分析任务 → Agent先拉测量数据 → 计算控制图统计量 → 判异规则引擎输出异常点 → 若无异常只生成日常摘要 → 若有异常进入归因节点 → Agent通过MCP并行查询工艺参数、工单批次、设备信息 → 生成带证据的根因假设 → 推送到前端等待质量工程师审核 → 审核通过后自动创建改进措施任务。2.2 三层架构的边界划分这个系统最核心的设计决策是把确定性计算和智能推理严格分开。统计量计算和控制限计算属于确定性逻辑不允许大模型参与。X-bar-R图的均值、极差、标准差、控制限每一个数值都必须能追溯回原始数据接受任何精度审查。这部分我放在独立的判异规则引擎里输入是一段时间的测量数据输出是结构化判异结果比如哪个点触发了哪条规则、超了多少倍标准差。智能推理部分则交给LangGraph里的Agent节点让它负责语义层面的归因分析。这里有个很容易犯的错误就是一开始我们试图用大模型直接判断这个点是否异常效果非常不稳定。同样的数据多问几次会得到不同的结论这不是模型笨而是数值判异本来就不该交给语言模型。2.3 为什么在这个架构里同时需要LangGraph和MCPLangGraph解决的是流程怎么走MCP解决的是能力怎么接两者不冲突也不重叠。没有LangGraphMCP工具给了大模型之后调用顺序和分支逻辑是失控的。没有MCPLangGraph的节点想查数据只能写死数据库连接那权限、审计和跨系统调用又会变成一笔糊涂账。我把二者分工讲得直白一点LangGraph是项目经理它决定先做统计、再判异、再归因、再审核MCP是后勤接口它规定项目经理只能通过指定的单据去领料不能自己闯进仓库乱翻。这样即使哪天LLM换了一个更强的版本甚至换成开源模型整个流程骨架都不会塌。3. LangGraph编排AI-SPC分析流程状态驱动的智能体实现3.1 先定义状态一次SPC分析会话的工作记忆LangGraph的编程模型和普通函数调用最大的区别在于整个工作流共享一个状态对象像一张不断被填写的工作台每个节点只负责更新自己关心的字段读自己需要的字段。状态用类型字典定义下面是我们SPC分析任务的状态结构from typing import TypedDict, Optional class SPCState(TypedDict): task_id: str process_id: str time_range: tuple[str, str] subgroup_size: int measurements: list[dict] statistics: dict rule_hits: list[dict] anomaly_points: list[dict] evidence: dict[str, list[dict]] hypotheses: list[dict] countermeasures: list[dict] review_status: str report_id: Optional[str]这个状态设计有几个隐性的好处。一是可持久化分析过程中途挂掉可以从checkpoint恢复二是可追踪每个节点执行前后把状态快照落库出了错能回放整个分析路径三是天然支持多轮交互质量工程师在审核节点补充了信息后状态里的hypotheses可以被修正并进入下一轮分析。3.2 节点与条件分支异常才进入归因正常只出摘要我们把一次分析定义成下面这些节点节点名和函数一一对应load_measurements、compute_statistics、run_rules、summarize_only、investigate_anomalies、generate_hypotheses、propose_actions、human_review。关键在于条件分支的写法。run_rules执行完判异规则后根据rule_hits是否为空决定走哪条路没有异常就走summarize_only节点生成一段该时段过程受控的简短摘要直接结束不浪费LLM调用有异常才进入investigate_anomalies。对应LangGraph的图构建逻辑大致是这样from langgraph.graph import StateGraph, END workflow StateGraph(SPCState) workflow.add_node(load, load_measurements) workflow.add_node(stat, compute_statistics) workflow.add_node(rules, run_rules) workflow.add_node(summarize, summarize_only) workflow.add_node(investigate, investigate_anomalies) workflow.add_node(hypothesis, generate_hypotheses) workflow.add_node(action, propose_actions) workflow.add_node(review, human_review) workflow.set_entry_point(load) workflow.add_edge(load, stat) workflow.add_edge(stat, rules) workflow.add_conditional_edges( rules, route_by_anomaly, {normal: summarize, anomaly: investigate} ) workflow.add_edge(investigate, hypothesis) workflow.add_edge(hypothesis, action) workflow.add_edge(action, review) workflow.add_edge(summarize, END) workflow.add_edge(review, END)route_by_anomaly是根据rule_hits是否为空返回分支名的纯函数。这种显式的条件边比直接在节点内写if-else要清晰得多因为每个分支都是一等公民可以被单独测试也可以在图上直观呈现。3.3 人机协同节点让质量工程师插队介入SPC场景的特殊性在于AI不能拍板。根因假设可以大胆生成但最后的处置决策必须交给有经验的质量工程师确认。我们用的是LangGraph的human-in-the-loop机制propose_actions生成对策草案后流程在human_review节点暂停状态落到数据库前端工作台收到事件后展示待审核卡片。质量工程师可以点通过也可以填一段修正意见比如链速变化不是主因优先查热电偶。修正意见会写回状态触发流程从generate_hypotheses重新再跑一轮。这个设计决定了系统能否真正上线。没有人工确认节点的AI-SPC在质量管理体系里是站不住的。你在前端看到的不是AI自动完成分析而是AI提出假设人做判断系统记录整个决策链。3.4 可追踪设计每个分析步骤都能回放排查所有节点的输入、输出、调用的MCP工具、耗时都会写入审计表。每一条记录对应一次完整分析会话关联task_id。上线之后我们排查问题基本都是靠这个回放机制。有一次典型排查某个工序的判异规则明明命中了但生成的报告里没有归因结论。回放发现是MCP查询工艺参数时超时导致evidence为空generate_hypotheses节点在没有证据的情况下选择直接退出。后来我们在节点里加了降级策略部分证据缺失时明确标注证据不完整假设置信度下调而不是静默失败。4. MCP接入层实战让大模型安全地触达生产数据4.1 把SPC周边能力封装成MCP工具MCP层的设计原则只有一个大模型能调用的能力必须全部经过显式定义数据库连接字符串绝对不能出现在Agent进程里。我们封装了四组MCP工具。测量数据服务提供get_measurements_by_range用于查询指定工序在指定时间窗口内的原始测量值工艺参数服务提供get_process_parameter_history用于查设备参数、温湿度环境参数的历史曲线工单服务提供get_work_order_by_batch和get_material_batch_info用于把异常时间窗口的物料批次信息捞出来报警通知服务提供notify_quality_alert用于审核通过后自动通知相关人员。每个工具都有独立的服务进程MCP Server和Agent进程通过标准协议通信。这样做的好处是任何一个工具服务挂了Agent能明确感知到哪个数据源不可用而不是整个分析流程崩溃。4.2 一个工具定义的完整示例与调用时序以测量数据服务为例MCP工具定义如下{ name: get_measurements_by_range, description: 查询指定工序在指定时间段内的测量值序列返回按采集时间排序的数据点。, inputSchema: { type: object, properties: { process_id: {type: string}, start_time: {type: string, format: date-time}, end_time: {type: string, format: date-time}, limit: {type: integer, default: 5000} }, required: [process_id, start_time, end_time] } }LangGraph的归因节点在调用这个工具时会先拿到一批候选数据再进行下一步分析。真正的调用时序是首先判异节点输出异常点在10:12到10:35之间归因节点把时间窗传给get_process_parameter_history查温度、湿度、风速等参数再调get_work_order_by_batch确认这段时间生产的批次号两个查询结果都进入状态里的evidence字段。LLM只负责阅读evidence字段并推理不能自己去构造数据。4.3 权限边界、审计日志和幻觉控制MCP工具虽然好用但权限问题必须前置设计。我们的做法是按工具粒度做白名单某个Agent只能调用分配给它的工具质量工程师角色能看到全部工具调用记录但普通操作员只能看到结果摘要。每次工具调用的入参、返回数据条数和耗时都记审计日志。幻觉控制是这个环节的重中之重。大模型在归因时最大的风险不是答错而是答得有理有据但数据是编的。我们做了两条硬约束一是所有假设必须引用MCP返回数据中的字段报告里证据区域只能渲染真实返回的数据条目二是结构化输出校验LLM必须返回指定JSON格式其中evidence_ids必须对应证据列表里的真实索引校验不通过就重新生成。实测下来加了这些约束之后归因假设的采纳率有明显提升而且即使假设错误质量工程师也能从证据链里快速定位是哪条依据不成立。5. 核心实现细节控制图计算、判异规则与自动报告5.1 计算X-bar/R图控制限这部分必须可靠控制图是整个系统的数据地基统计量算错后面全错。我们常用的子组大小n5X-bar-R图的控制限公式如下子组均值X̄和子组极差R由样本数据直接计算总体估计量为X̄的平均值和R的平均值。X-bar图的控制限为UCL X̄ A2 × R̄LCL X̄ - A2 × R̄R图的控制限为UCL D4 × R̄LCL D3 × R̄。查表可知n5时A2≈0.577D3≈0D4≈2.114。对应的Python实现import numpy as np def xbar_r_limits(subgroups: list[np.ndarray]) - dict: x_bar float(np.mean([np.mean(g) for g in subgroups])) r_bar float(np.mean([np.max(g) - np.min(g) for g in subgroups])) A2, D3, D4 0.577, 0.0, 2.114 # 子组大小为5时查表 return { x_bar: x_bar, r_bar: r_bar, x_ucl: x_bar A2 * r_bar, x_lcl: x_bar - A2 * r_bar, r_ucl: D4 * r_bar, r_lcl: D3 * r_bar }这段代码看起来简单但有几个前置细节。子组划分规则必须和生产节拍对齐不能简单按固定条数硬分测量数据要先做异常点清洗但不允许随意剔除看起来不对的点剔除必须留痕控制限用历史数据滚动计算还是固定学习期计算要跟工艺工程师确认清楚。5.2 常用判异规则的工程化实现我们把常用判异规则做成了可配置的规则集每条规则都是独立函数输出规则编号、命中的点、严重程度。下面是我们启用的主要规则规则编号判异描述典型含义规则1单个点超出3σ控制限过程突然失控或测量异常规则2连续9点落在中心线同一侧过程均值发生偏移规则3连续6点单调递增或递减存在持续趋势性变化规则4连续14点相邻点交替上下数据存在混合分布或过度调整规则5连续3点中有2点距中心线超过2σ同一侧均值漂移早期信号规则6连续5点中有4点距中心线超过1σ同一侧过程变异增大规则7连续15点落在中心线1σ范围内数据分层或可能是假数据规则8连续8点距中心线均大于1σ同一侧长期偏移累积有一个工程经验值得展开说多条判异规则联动时误报率会叠加如果严格按命中任意一条就报警很多稳定工序会被频繁打扰。我们的做法是给每条规则配置权重比如规则1权重是3规则5是1只有当命中规则的加权分达到阈值时才升级为人工关注。这个阈值可以先保守设高跑两周再看报警收敛情况。5.3 自动生成带证据引用的根因分析报告归因节点产出的不是一段自由文本而是结构化的分析报告包含异常概述、统计依据、证据条目、根因假设列表、对策建议、待确认事项六部分。生成逻辑分成两步。第一步是提取差异特征把异常时间窗口的工艺参数和历史基线窗口做对比比如设定温度240℃、实际均值246.3℃、偏差超过基线1.8倍标准差这一步是确定性计算避免LLM凭空比较数值。第二步才是LLM的语义归纳让它基于差异特征和工单信息生成假设每个假设都要标明支持证据和置信度。报告整体推送到前端时质量工程师可以逐条查看证据来源点开某条证据就能看到原始数据时间序列。这个可追溯特性是系统能获得信任的关键如果只给结论不给证据这套AI-SPC大概率会被当成玩具。6. 从Demo到产线试点实测结果和高频坑6.1 试点场景和关键效果我们在某电子制造企业的SMT车间做了两条产线的试点范围是回流焊温度特征值的X-bar-R图监控。试点周期四周从只读模式切到AI建议人工确认模式。有两个数字印象很深。第一个是日均报警次数从原来的37次降到12次主要功劳是规则权重分级把大量低严重度规则命中降级为日志记录而不是工作群打扰。第二个是从报警到拿到首版候选根因的时间从平均三四个小时压缩到系统自动分析的三四分钟之内质量工程师审核后再决定是否继续深入。当然归因建议不是每条都对。四周试点的AI候选根因被审核采纳的占比大约是六成另外四成里有一半是证据不足被驳回剩下一半是质量工程师补充了业务背景后修正了结论。这个结果比预期好但离全自动还有距离也正因为有这四成的不靠谱我们已经把人工确认列成了架构里的强制节点。6.2 高频问题排查表把试点过程中踩过的坑整理成一张表排在前面的几个最值得记住现象根因解决方案控制图在换班节点出现规律性跳变采集服务时区不统一数据落库用了本地时间统一按UTC存储前端按展示时区转换LLM生成了数据中不存在的峰值描述未强制引用MCP返回字段证据白名单结构化输出校验MCP查询在大数据量下超时工具服务未做分页和超时降级默认limit分页超时降级为证据不完整提示同一条规则报警密集轰炸权重未分级规则联动误报规则加权计分低权重命中只记录不打扰LangGraph重放历史任务时状态错乱检查点未关联外部task_id状态快照按task_id持久化恢复时重放节点日志时区问题是我们第一天就被坑到的产线采集系统用的是本地时间数据库是另一个时区凌晨班次的数据画出来全是锯齿。后来统一成UTC存储才算根治。这个问题在文档里很难提前预料但一旦出现排查成本很高还是靠审计表中的时间戳比对发现端倪。6.3 一点复盘这套架构到底改了什么回头看LangGraph和MCP的引入并没有推翻SPC本身相反它们是让SPC重新被用起来的基础设施。LangGraph解决的是流程编排复杂度。当分析链路里存在确定性计算、LLM推理、人工审核三种节点并且有回退、重试、条件分支时图的表达能力比链式调用强太多。MCP解决的是系统间集成复杂度。它把测量数据、工艺参数、工单系统、报警通知统一成标准接口Agent侧不需要知道这些数据存在哪、怎么连只需按工具契约调用权限和审计也天然有了边界。我个人最大的体会是不要一上来就追求全自动闭环。AI-SPC最有价值的落地形态是AI负责把脏活累活干完把最可能的答案和证据一起摆到人面前人负责最后拍板。这个分工越早想清楚架构越稳现场越愿意用。最后再分享一个小建议别拿美化过的演示数据跑AI-SPC直接拉一个月的真实历史报警数据离线回放一遍你会发现光是align班次、时区、批次信息就够忙一阵子的。但这步做完后面上线时的麻烦会少掉一大半。我们就是这样在正式部署前用历史数据把判异规则的误报率反复压下来的。
阅读完成 · 觉得有帮助？
