尧图网页设计 
工业 AI 受控落地系列 · 场景篇开错一只法兰之前把“正向设备识别”做成一条生产级受控 Agent 证据链从 PEMEX Deer Park 事故出发拆解数据接入、对象消歧、Rule Center、Java/Python 双栈、异常降级、双 Gate 与风险账本核心判断开管作业前的“AI识别”不是一个视觉识别项目而是一个对象身份、证据一致性与许可责任链问题。真正成熟的系统不是给出一个很高的置信度而是在对象无法唯一证明、证据过期、工具失败或规则冲突时稳定地停下来。先把结论说清楚2026年2月美国化学安全与危害调查委员会CSB发布 PEMEX Deer Park 炼厂硫化氢释放事故最终报告。事故发生于2024年10月10日承包商原本要打开一段已排空管线却误开了约5英尺之外、外观相同且仍带压的管段约27,000磅硫化氢释放造成2人死亡、13人送医。CSB 将“Positive Equipment Identification正向设备识别”列为核心安全问题之一。这个事实把问题讲得非常清楚高风险作业真正需要回答的不是“AI看照片能不能认出法兰”法兰管道连接件——两截管道之间可拆卸的盘状接合口并排的两个法兰外观几乎一样肉眼极难区分这正是“开错一只法兰”的由来而是“工单、PID、盲板清单、现场标签、隔离状态和检测记录能不能共同证明眼前这个物理对象就是许可里指定的那个对象”。一句人话我们需要的不是一个“会认东西的AI”而是一个没有证据就不往下走、出了冲突能告诉人为什么的证据编排器。读者先看什么你会得到什么工艺/设备/EHS事故链、Canonical Work Point、双 Gate、KPI如何把“对象确认”固化成可复核的作业前证据链Java/企业应用研发双栈架构、Outbox、幂等、状态机、规则中心怎样不推倒原系统把 Agent 以智能旁路方式接进去AI/Agent 工程师Claim/Evidence、Skill Registry、HITL、异常降级怎样把“模型能力”变成受控、可审计的生产工作流管理者/数智化负责人风险账本、False Pass、PoC路线为什么这不是OCR项目以及该如何判断是否值得投先看一张全景图从工单发起到 Trace 归档四个角色、八个阶段全部挂在同一个 task_id 上——上图即整套系统的运行骨架后文 15 节内容都是在展开这张图的某一块。1. 这不是“识别准确率”问题而是“错误对象放行”问题现场作业里最危险的一类错误往往不是“完全没信息”而是“信息很多而且每一份看起来都合理”。工单上有管线号PID上有图盲板清单有序号现场也有类似标签如果系统不能证明这些信息指向同一个物理对象就存在一个非常现实的缝隙错误对象可能在所有人都“觉得差不多”的情况下被放行。计算机里经常会把这类问题拆成识别、检索、OCR、图谱、工作流。但对现场来说只有一个问题能不能唯一确认。于是系统设计的北极星也应该随之改变——不是追求“视觉模型Top-1准确率更高”而是尽量降低 Gate False Pass本来应该被拦住的错误对象系统有没有放过去。术语翻译Gate False Pass人话本来应该被拦住的问题却被系统放过去了。对高后果作业来说这比“AI平均准确率95%”更值得盯。2. 第一公里不是 Agent而是把“证据供应链”做干净很多 Agent 方案第一张图就是 LLM、RAG、工作流。可真到化工现场第一公里往往是数据工程Excel字段漂移、PID版本混杂、设备位号别名、老DCS没有REST API、现场照片标签被遮挡、气体检测记录还有有效时间窗。源头不干净后面的 Evidence Pack 再漂亮也只是把 Garbage 包装成 JSON。数据源最常见的脏问题生产级处理进入 Evidence 的最低条件工单/审批数据库业务状态与现场任务不同步Java侧主数据状态快照task_id、作业类型、许可版本可追溯PID / 线表 / 盲板清单PDF扫描件、版本多、编号别名结构化解析 文档版本绑定 人工校对来源页/行可定位版本有效DCS/GDS/仪表无API、协议老、网络域隔离边缘网关只读采集OPC DA/UA、Modbus或文件落盘适配时间戳、新鲜度、采集健康状态可见现场标签/照片遮挡、反光、OCR误识别视觉/OCR只做交叉证据不能作为唯一身份依据检测/隔离记录记录过期、数据延迟有效时间窗状态校验未过期来源和责任人明确对多源Excel、CSV和仪表导出文件Polars适合做列级清洗、类型转换和批处理DuckDB适合直接查询一批CSV/Parquet/Excel并做临时分析。它们的价值不是“炫性能”而是让大量一次性Python脚本变成可测试、可复用的数据准备流水线。数据工程示例先把台账变成可验证输入而不是直接丢给大模型# 示例把多个设备/盲板台账先统一到 canonical schema import duckdb sql r SELECT trim(line_no) AS line_no, upper(trim(flange_id)) AS flange_id, cast(pid_revision AS varchar) AS pid_revision, try_cast(valid_from AS timestamp) AS valid_from, filename FROM read_csv(blind_lists/*.csv, union_by_nametrue, filenametrue) WHERE line_no IS NOT NULL rows duckdb.sql(sql).df()关键边界“解析成功”不等于“证据可信”。只有同时具备 source_ref、对象ID、版本、时间戳、schema校验结果以及必要的人工确认数据才有资格进入高风险 Evidence。3. 先给“要开的那个点”一个唯一身份Canonical Work PointEntity Resolution 听起来像算法名实际解决的是一个很朴素的问题工单里的“F-2041-17”、PID上的某个法兰符号、盲板表第17行、现场二维码和操作人员口中的“第二层东侧那个口”到底是不是同一个东西。术语翻译Entity Resolution人话解决“第二版”和“V2.0”是不是同一个版本、“这个现场标签”和“工单对象”是不是同一个物理点的问题。类比Canonical Work Point 相当于给每个作业点发一张唯一的“数字身份证”——不管它在工单、图纸、盲板清单还是现场叫什么别名系统最终只认这张证。我会先定义一个 canonical work_point把工单、图纸、清单、现场证据全部挂到这个统一对象上。Agent可以参与候选匹配但不能在高风险冲突下直接裁决“就是它”。Canonical Work Point把“一个现场点”变成跨系统共享对象work_point_id: WP-ARU-0417unit: ARUline_no: 6-H2S-2041-Apid_doc: PID-ARU-021pid_revision: R07flange_id: F-2041-17blind_list_id: BL-2026-091upstream_equipment: V-204downstream_equipment: E-217field_tag_required: true层级系统先看什么允许自动到哪一步L0 唯一编码line_no、flange_id、设备位号全一致且有效时可确认L1 主数据映射旧编码/别名 → canonical_id可自动映射但必须留审计L2 拓扑关系上下游设备、阀门、支路、PID拓扑只生成候选冲突即停L3 位置/上下文装置区、层高、方位、相邻设备补强候选不单独放行L4 视觉/OCR二维码、挂牌、照片、字符只做交叉验证L5 人工确认候选接近、标签缺失、高风险对象授权人员确认并写回映射真正成熟的回答不是“我有92%的把握这是F-2041-17”而是“存在两个候选对象拓扑证据无法唯一消歧现场标签不可见系统不进入下一步请由授权人员重新定位并确认。”4. 用户问“这个点能不能开”系统内部要拆成一组 ClaimClaim 可以理解成“必须被逐条证明的工程命题”。这样 Agent 的目标就不再是生成一段像专家的结论而是把每一个前置条件变成可验证对象。Claim人话Evidence / Tool失败动作C01 对象唯一工单必须只指向一个 work_pointcanonical_id 工单版本不唯一 → BLOCKC02 图纸当前有效不能拿旧版PID做当前作业发布状态 revision过期 → BLOCKC03 清单映射一致盲板/法兰清单与工单是同一对象映射Trace冲突 → BLOCKC04 现场身份可确认标签/位置/拓扑能把对象唯一找出来现场证据 人工确认不确定 → WAIT_HUMANC05 隔离状态完整上游/下游隔离条件已满足隔离记录/只读状态缺失 → BLOCKC06 前置检测有效检测记录仍在有效时间窗检测时间戳/记录过期 → BLOCKC07 人工许可完成高风险许可责任人已经会签Java审批流未完成 → WAIT_HUMAN5. Rule / Skill / Knowledge 分开是受控 Agent 的第一条红线这里最容易犯的错误是把SOP、企业制度、工具说明和知识库全部塞进Prompt然后告诉模型“请严格遵守”。在生产流程里硬约束必须从语言模型里拿出来。层人话例子为什么独立Knowledge系统知道什么PID符号、SOP、设备说明、历史Near Miss可检索但不能替代规则与当前状态SkillAgent允许做什么query_pid_graph、verify_isolation、build_evidence形成工具白名单与权限边界Rule哪些事绝不能被解释过去对象不唯一→BLOCK过期图纸→BLOCK高风险→人工可测试、版本化、灰度、回滚、审计生产里我更倾向做一个独立 Rule Center而不是把规则散落在代码和Prompt里。每条规则至少包含 rule_id、version、effective_from、severity、condition、action、source、test_cases。这样企业标准更新时可以做新旧版本回放和灰度而不是重新发一版Agent代码。规则中心示例硬约束是配置资产不是 Prompt 文案rule_id:LINE_OPENING_004version:3.2effective_from:2026-08-01severity:HIGHwhen:any:-work_point.unique false-pid.current_release false-isolation.evidence_complete falsethen:gate:BLOCKEDrequire_manual_review:truesource:enterprise_line_opening_standard生产环境里Rule Center 最怕两件事规则互相打架以及灰度失控。所以光有 YAML 还不够至少要再补两道工序规则冲突检测LINE_OPENING_004要发 v3.3发布前规则中心必须自动对新旧规则集做两层检查——静态层面扫描条件重叠与结论矛盾例如新规则放宽了隔离证据要求而另一条隔离标准仍要求证据完整两条规则在同一证据状态下会给出相反裁决运行时层面用历史 Evidence Pack 批量回放比对。检出冲突就禁止发布而不是指望运行时“谁先命中算谁的”。规则沙箱与回放Shadow Mode新规则上线前必须用过去 6 个月的真实 Evidence Pack 完整跑一遍输出新旧版本的 BLOCK / WAIT_HUMAN / PASS 差异表。差异只有两种可接受结局新规则拦下了旧规则漏掉的更好或差异逐条有人工签字说明理由。任何“新规则放行了旧规则拦下的案例”都必须单独评审后才能灰度灰度期间新旧规则并行打分Shadow 数据达标才正式切换。# Rule Center 发布卡点示意publish_check:conflict_scan:required# 与现有规则集做条件重叠/结论矛盾扫描shadow_replay:corpus:last_6mo_evidence_packs# 过去6个月真实证据包回放report:block_diff_summary# 新旧规则 BLOCK/WAIT_HUMAN 差异表approval:relaxed_cases:manual_sign_off# 新规则放行了旧规则拦下的案例 → 逐条签字这样 Rule Center 才不是“配置文件仓库”而是一条带发布门禁的规则资产线。6. 生产级架构让 Agent 夹在业务系统和专业工具之间而不是凌驾其上这套架构最重要的不是“用了几个Agent”而是边界清晰现场OT系统只读接入Java业务系统掌握身份、权限、工单、审批、签名和最终业务状态Python Agent负责理解、检索、Skill编排、Evidence Pack和受控推理规则和专业工具各自拥有独立版本。架构原则AI 是增强路径不是安全流程的单点故障。Agent不可用、模型不可用、外部工具超时都应该降级到原有人工流程任何降级都不能绕过对象确认和作业许可。7. 老 DCS / GDS 没 API 怎么办先做“只读适配层”企业现场最大的工程现实之一是很多系统根本没有现代REST API。DCS、GDS、PLC、仪表和老SCADA可能通过OPC DA、OPC UA、Modbus甚至定时导出文件提供数据。这里不需要强行把现场系统“云原生化”更不应该让Agent直接连控制网络做写操作。更稳妥的做法是在OT与IT之间增加边缘数据接入层协议适配、只读缓存、时间戳、数据质量标记和健康检查在边缘完成向上只暴露统一的只读接口。OPC UA本身就是面向工业系统互操作的信息交换标准可以覆盖传感器、控制系统、MES到企业系统。现场条件接入方式Agent能看到什么失败时怎么处理支持 OPC UA边缘UA Client订阅当前值、时间戳、质量码连接异常→Evidence stale→WAIT_HUMAN仅 OPC DAWindows网关/DA-UA桥接经转换后的只读点位桥接失败→不缓存“上次成功值”冒充当前值Modbus设备协议网关轮询离散/寄存器只读快照超时→标记UNAVAILABLE不自动重试到“碰巧成功”无在线接口受控文件落盘/人工上传带批次/时间戳的文件快照超过新鲜度阈值→BLOCK或人工确认为什么强调“只读”这类 Agent 的目标是证据收敛和风险拦截不是替代DCS/PLC控制回路。把写控制值的权限与Agent隔离既降低安全风险也更容易通过企业OT安全评审。8. 夜间外部工具超时怎么办失败不能被“重试成成功”对生产系统来说工具失败本身不可怕最危险的是失败被静默吞掉或者系统拿上一次缓存结果继续往下走。每个Skill都应该有明确的工具契约status、source_ref、observed_at、freshness、confidence、error_code、retryable。故障系统动作最终状态PID图谱服务超时短超时 有界重试 Circuit BreakerTOOL_UNAVAILABLE → WAIT_HUMAN气检数据超过有效时间窗不使用旧值替代EVIDENCE_STALE → BLOCKEDDCS/边缘网关离线标记数据源不可用并告警DEGRADED_TO_HUMAN规则服务不可用禁止绕过规则中心RULE_ENGINE_UNAVAILABLE → BLOCKEDLLM/RAG不可用关闭智能解释保留确定性检查人工流程继续AI增强能力降级Spring生态可以用 Circuit Breaker、TimeLimiter、Retry 等机制做外部依赖保护。关键不是采用哪一个库而是把“失败怎么进入业务状态”写清楚不能把异常当PASS也不能让无限重试把夜间作业卡成一个不可解释的半死状态。9. Java Python不推倒重构也不让两个世界互相污染很多传统企业的核心业务系统已经在Spring Boot里跑得很稳SSO、组织、RBAC、流程审批、电子签名、数据库事务、审计。这些东西没有必要因为上Agent就搬到Python。更可复制的路线是“Java稳业务Python做智能旁路”。Java / Spring Boot 保留Python Agent 新增身份认证、组织、RBACLLM意图理解、受限Planner工单/作业许可/审批/签名RAG、Entity Resolution辅助业务主状态、数据库事务Skill Router、Evidence Pack规则发布入口/版本元数据工具编排、Explain、Trace审计主表、归档、最终许可不得越权修改核心业务状态术语翻译Transactional Outbox人话避免“Java里任务已经保存了但发给Python Agent的消息恰好失败”这种半成功。业务数据和待发事件在一个本地事务里一起落库再由CDC/MQ可靠发布。类比相当于银行转账的“回执单机制”——账记了回执就一定发得出去要么都成要么都不成不存在“钱扣了、对方却没收到”的半成功。Python侧仍然要做幂等同一个 event_id task_id 重复投递十次也只能产生一次有效业务动作。Java收到Agent回执后也不能盲目覆盖状态而要校验当前 state_version避免旧事件把新状态“回滚”。双栈一致性允许消息重复不允许业务动作重复-- Java 本地事务示意BEGIN;INSERTINTOwork_task(task_id,state,state_version)VALUES(T-42,AGENT_PENDING,1);INSERTINTOoutbox_event(event_id,task_id,event_type,payload)VALUES(E-1001,T-42,REVIEW_REQUESTED,{...});COMMIT;-- Python 消费端idempotency_keyE-1001:T-42ifalready_processed(idempotency_key): ack_and_skip()还有一个容易被忽略的极端场景人工已经在 Java 侧取消了工单Python Agent 却恰好在此时返回了 READY_FOR_MANUAL_REVIEW。如果 Java 只校验 state_version这条迟到回执仍可能把已取消的工单“复活”进复核队列。所以 Java 收到 Agent 回执时要做双重校验先校验 state_version 防乱序回滚再校验工单的业务终态——工单已是 CANCELLED 或 COMPLETED 时回执不触发任何状态机流转直接落审计日志归档-- Java 侧回执校验示意UPDATEwork_taskSETagent_receipt:payload,receipt_statusDISCARDED_TERMINALWHEREtask_id:task_idANDstate_version:expected_version-- 防乱序回滚ANDstateNOTIN(CANCELLED,COMPLETED);-- 终态直接丢弃-- 0 rows affected → 写审计日志工单已终态Agent 回执不入状态机原则是Agent 的回执永远只是“输入”不是“指令”。业务状态机的钥匙始终握在 Java 手里。10. Agent 的真正产物不是“结论”而是一张可展开的 Evidence Pack现场人员不需要看一段AI总结更需要看到一张“身份卡”对象是谁、证据有哪些、哪里一致、哪里没确认、哪条规则命中、为什么必须等人工。Evidence Pack让“为什么不能继续”可以被人复核{task_id:T-42,work_point_id:WP-ARU-0417,identity:{line_no:6-H2S-2041-A,flange_id:F-2041-17,pid_revision:R07},evidence:[{type:PID,ref:PID-ARU-021#R07,verified:true},{type:blind_list,ref:BL-2026-091#row17,verified:true},{type:field_tag,ref:photo://T-42/img3,verified:false,reason:tag_occluded}],rule_hits:[FIELD_TAG_NOT_VISIBLE],gate:WAIT_HUMAN,reason:现场身份无法唯一确认}如果使用LangGraph这类状态编排框架可以把人工复核点设计成可持久化 interrupt流程在需要授权人员确认时暂停保存状态等待人工输入后从同一个thread恢复。但这里的关键仍然不是框架名字而是人工中断必须进入业务状态、可重放、可审计。11. 一个最小可运行 Demo不发许可只演示“证据不足就停”下面的Demo故意不控制DCS、不计算安全设定值也不自动签发作业许可。它只演示三件事对象是否唯一、证据是否有效、规则是否允许继续。FastAPI Demo输出理由和证据引用而不是一个黑盒 PASSEDfromdatetimeimportdatetime,timezonefromfastapiimportFastAPIfrompydanticimportBaseModel appFastAPI()classEvidence(BaseModel):kind:strref:strverified:boolobserved_at:datetime|NoneNoneclassRequest(BaseModel):task_id:strcandidate_ids:list[str]pid_current:boolisolation_ok:boolgas_test_fresh:boolevidence:list[Evidence]defgate(req:Request):reasons[]iflen(set(req.candidate_ids))!1:reasons.append(WORK_POINT_NOT_UNIQUE)ifnotreq.pid_current:reasons.append(STALE_PID)ifnotreq.isolation_ok:reasons.append(ISOLATION_EVIDENCE_MISSING)ifnotreq.gas_test_fresh:reasons.append(GAS_TEST_STALE)ifany(note.verifiedforeinreq.evidence):reasons.append(UNVERIFIED_EVIDENCE)ifreasons:return{task_id:req.task_id,gate:BLOCKED_OR_WAIT_HUMAN,reasons:reasons,evidence_refs:[e.refforeinreq.evidence]}return{task_id:req.task_id,gate:READY_FOR_MANUAL_REVIEW,note:仍需授权人员完成最终作业许可}app.post(/review)defreview(req:Request):returngate(req)Demo 的成功标准不是“AI给了一个很像专家的判断”而是它能够把对象歧义、过期图纸、隔离证据缺失、气检过期这些问题显式化并稳定进入BLOCK或WAIT_HUMAN。12. 上线后运维团队看什么把 Trace 从“日志”升级成业务证据生产级 Agent 最容易被忽略的一层是可观测性。普通接口只看HTTP 200/500不够一个 task_id 应贯穿Java、消息、Agent、Skill、规则、Evidence和人工动作。这样事故复盘和系统升级时才能回答“当时为什么放行/为什么拦截”。指标人话建议用途Gate False Pass本应拦截却放过去的比例高风险场景北极星Identity Ambiguity Recall真实存在对象歧义时能否发现验证消歧链是否漏风险Evidence Coverage关键Claim有合格证据的比例判断证据链是否闭合Stale Evidence Block Rate过期图纸/检测是否稳定拦截防旧数据被当当前事实Tool Timeout Escalation工具失败是否正确转人工/阻断检验降级逻辑Trace Completeness每次工具/规则/人工动作是否留痕审计与复盘Replay Success历史任务能否按当时快照重放升级回归测试部署和升级也要像普通生产系统一样做规则集、解析器、模型、Prompt、Skill都绑定版本新版本先做历史Case Replay再小流量灰度。只要Gate False Pass恶化就应该回滚而不是用“新模型平均分更高”解释过去。13. ROI 不按“OCR省多少分钟”算而按一套安全账本来算CSB报告中PEMEX Deer Park事故造成约1,230万美元与装置失用相关的财产损失。但本文不会把这笔损失直接拿来宣称“Agent可以避免”。真实企业算账时更可信的做法是用自己的历史数据构建风险账本。账本怎么量建议直接收益平均工单准备时长、返工次数、重复查图/核清单工时财务可审计作为确定性收益风险收益高风险拦截数 × 专家确认率 × 事件概率/损失估计用半年真实拦截数据校准不拍脑袋合规收益Evidence Coverage、Trace Completeness、过期文件拦截作为控制有效性证据知识收益Rule/Case复用率、Replay成功率、专家映射回写不建议强行货币化这套账还必须诚实地计入隐性成本WAIT_HUMAN 频率在上线初期会明显上升——系统比人严格会把很多以前“差不多就行”的单子拦下来授权人员的复核工作量随之增加。所以完整的财务模型里应该有一个负向因子专家复核工时增量 新增 WAIT_HUMAN 单数 × 平均复核时长 × 专家工时成本并给出它随规则调优逐步收敛的预估曲线。把这笔账主动摆到桌面上比只讲收益更容易赢得管理层信任——财务模型诚实项目才走得远。如果管理层一定需要一个财务模型可以用期望损失而不是“事故价值”叙事风险账本半年后用真实Gate数据重新校准 P、L、R年风险收益示例公式 N × P × L × RN一年高风险开管/拆盲板任务数P历史上经专家确认的对象/版本/前置条件重大问题概率L一次问题造成的平均返工、停工、物料、设备或项目损失R受控系统实际降低该问题流入后续作业的比例给管理层的一句话这套系统不是为了“每年少查几小时图纸”而是为了建立一个永远在线、可审计、不会因为疲劳而跳过前置条件的复核层它的价值最终要用真实拦截数据证明而不是靠PPT承诺“绝对安全”。14. 60 天 PoC先证明“能不能稳定停下来”再谈自动化率阶段核心工作Go / No-GoW1-2对象与数据基线选一个装置、20-30个典型开管点定义canonical work_point梳理数据源关键对象能否唯一标识关键数据是否可追溯W3图纸/清单解析PID、线表、盲板清单结构化版本绑定source_ref过期/错版是否能被识别而非静默通过W4现场只读接入边缘网关接OPC/Modbus/文件数据新鲜度与健康状态断链/过期是否进入明确降级状态W5Entity Evidence多层候选消歧、冲突工作台、Evidence Pack对象歧义是否稳定暴露W6规则与双GateRule Center、QualityGate、ManualReviewGateGate False Pass是否达到试点阈值W7Java/Python协同Outbox、幂等、状态同步、失败恢复网络闪断/重复消息后业务状态能否恢复W8Shadow Mode历史回放、故障注入、现场演练只给建议不改变作业流程真实问题拦截质量是否足以进入下一阶段还有一条经常被漏掉的验收项人机交互摩擦测试安排在 W5-W6。工业 AI 落地最大的阻力往往不是技术而是一线配合度——工艺员嫌扫码麻烦、承包商嫌证据上传繁琐。这期间要实测工艺员/承包商完成一次完整 Evidence Pack 确认的平均耗时是否超过原有纸质流程的 1.5 倍。一旦超过先做交互减法预填默认值、扫码即传、清单化点选而不是靠行政命令硬推——再安全的系统只要太慢就一定会被现场绕过去而被绕过的安全系统比没有系统更危险。PoC真正应该追求的不是“自动通过率80%”。在早期高风险场景里系统经常说“我不确定请人工确认”并不是失败只要它能稳定发现真实歧义、避免False Pass并且每一次停下来都有可解释证据就是非常有价值的结果。15. 最后把边界说清楚这个 Agent 能做什么不能做什么可以做不应该做读取并归一工单、PID、盲板清单、现场标签、隔离/检测证据直接控制DCS/PLC、改变阀位或下发生产设定值发现对象歧义、版本过期、证据缺失、工具失败用LLM置信度替代正向设备识别程序调用白名单Skill、生成Evidence Pack、触发Gate绕过企业许可、电子签名和授权责任人在不确定时暂停并请求人工确认把“接口失败/规则不可用”解释成默认通过保留task_id、Trace、Rule版本和人工动作供Replay承诺“绝对安全”或把公开事故营销化这篇文章真正想留下的东西开管作业只是一个场景。把表象拿掉以后它验证的是一套更通用的工业AI方法Raw Data → Data Governance → Canonical Object → Claim → Evidence → Rule/Skill/Knowledge → Domain Tool → Controlled Agent → QualityGate → ManualReviewGate → Trace/Replay → Risk Metrics。变的是业务对象不变的是“可追溯、可复核、可拦截、风险可度量”。结语工业现场不缺一个更会说话的模型。真正稀缺的是当证据不足、对象不唯一、工具失败、数据过期或责任边界不清时系统仍然能够冷静地停下来并且把“为什么停”完整交给人。如果AI要进入高风险业务流程这可能比“它像不像专家”更值得追求。参考资料与写作边界U.S. Chemical Safety and Hazard Investigation Board, Fatal Hydrogen Sulfide Release at PEMEX Deer Park Refinery, Investigation Report, February 2026. https://www.csb.gov/file.aspx?DocumentId6315CSB — PEMEX Deer Park Chemical Release case page. https://www.csb.gov/pemex-deer-park-chemical-release-/OPC Foundation — OPC Unified Architecture Part 1: Overview and Concepts. https://reference.opcfoundation.org/specs/OPC-10000-1/4Debezium — Outbox Event Router documentation. https://debezium.io/documentation/reference/stable/transformations/outbox-event-router.htmlSpring Cloud Circuit Breaker — Resilience4J reference. https://docs.spring.io/spring-cloud-circuitbreaker/reference/spring-cloud-circuitbreaker-resilience4j.htmlLangGraph — Interrupts / Human-in-the-loop documentation. https://docs.langchain.com/oss/python/langgraph/interruptsDuckDB — Data Sources / CSV and Excel ingestion documentation. https://duckdb.org/docs/stable/data/data_sources写作边界事故数据与调查结论来自CSB公开资料本文提出的架构、Rule字段、Gate指标、PoC周期、数据接入方式和ROI模型属于工程设计建议需要企业结合自身工艺、制度、系统安全区划和历史数据验证。本文不提供生产控制设定值也不替代任何法定/企业安全许可程序。 开错一只法兰之前：把正向设备识别做成生产级受控Agent证据链
工业 AI 受控落地系列 · 场景篇开错一只法兰之前把“正向设备识别”做成一条生产级受控 Agent 证据链从 PEMEX Deer Park 事故出发拆解数据接入、对象消歧、Rule Center、Java/Python 双栈、异常降级、双 Gate 与风险账本核心判断开管作业前的“AI识别”不是一个视觉识别项目而是一个对象身份、证据一致性与许可责任链问题。真正成熟的系统不是给出一个很高的置信度而是在对象无法唯一证明、证据过期、工具失败或规则冲突时稳定地停下来。先把结论说清楚2026年2月美国化学安全与危害调查委员会CSB发布 PEMEX Deer Park 炼厂硫化氢释放事故最终报告。事故发生于2024年10月10日承包商原本要打开一段已排空管线却误开了约5英尺之外、外观相同且仍带压的管段约27,000磅硫化氢释放造成2人死亡、13人送医。CSB 将“Positive Equipment Identification正向设备识别”列为核心安全问题之一。这个事实把问题讲得非常清楚高风险作业真正需要回答的不是“AI看照片能不能认出法兰”法兰管道连接件——两截管道之间可拆卸的盘状接合口并排的两个法兰外观几乎一样肉眼极难区分这正是“开错一只法兰”的由来而是“工单、PID、盲板清单、现场标签、隔离状态和检测记录能不能共同证明眼前这个物理对象就是许可里指定的那个对象”。一句人话我们需要的不是一个“会认东西的AI”而是一个没有证据就不往下走、出了冲突能告诉人为什么的证据编排器。读者先看什么你会得到什么工艺/设备/EHS事故链、Canonical Work Point、双 Gate、KPI如何把“对象确认”固化成可复核的作业前证据链Java/企业应用研发双栈架构、Outbox、幂等、状态机、规则中心怎样不推倒原系统把 Agent 以智能旁路方式接进去AI/Agent 工程师Claim/Evidence、Skill Registry、HITL、异常降级怎样把“模型能力”变成受控、可审计的生产工作流管理者/数智化负责人风险账本、False Pass、PoC路线为什么这不是OCR项目以及该如何判断是否值得投先看一张全景图从工单发起到 Trace 归档四个角色、八个阶段全部挂在同一个 task_id 上——上图即整套系统的运行骨架后文 15 节内容都是在展开这张图的某一块。1. 这不是“识别准确率”问题而是“错误对象放行”问题现场作业里最危险的一类错误往往不是“完全没信息”而是“信息很多而且每一份看起来都合理”。工单上有管线号PID上有图盲板清单有序号现场也有类似标签如果系统不能证明这些信息指向同一个物理对象就存在一个非常现实的缝隙错误对象可能在所有人都“觉得差不多”的情况下被放行。计算机里经常会把这类问题拆成识别、检索、OCR、图谱、工作流。但对现场来说只有一个问题能不能唯一确认。于是系统设计的北极星也应该随之改变——不是追求“视觉模型Top-1准确率更高”而是尽量降低 Gate False Pass本来应该被拦住的错误对象系统有没有放过去。术语翻译Gate False Pass人话本来应该被拦住的问题却被系统放过去了。对高后果作业来说这比“AI平均准确率95%”更值得盯。2. 第一公里不是 Agent而是把“证据供应链”做干净很多 Agent 方案第一张图就是 LLM、RAG、工作流。可真到化工现场第一公里往往是数据工程Excel字段漂移、PID版本混杂、设备位号别名、老DCS没有REST API、现场照片标签被遮挡、气体检测记录还有有效时间窗。源头不干净后面的 Evidence Pack 再漂亮也只是把 Garbage 包装成 JSON。数据源最常见的脏问题生产级处理进入 Evidence 的最低条件工单/审批数据库业务状态与现场任务不同步Java侧主数据状态快照task_id、作业类型、许可版本可追溯PID / 线表 / 盲板清单PDF扫描件、版本多、编号别名结构化解析 文档版本绑定 人工校对来源页/行可定位版本有效DCS/GDS/仪表无API、协议老、网络域隔离边缘网关只读采集OPC DA/UA、Modbus或文件落盘适配时间戳、新鲜度、采集健康状态可见现场标签/照片遮挡、反光、OCR误识别视觉/OCR只做交叉证据不能作为唯一身份依据检测/隔离记录记录过期、数据延迟有效时间窗状态校验未过期来源和责任人明确对多源Excel、CSV和仪表导出文件Polars适合做列级清洗、类型转换和批处理DuckDB适合直接查询一批CSV/Parquet/Excel并做临时分析。它们的价值不是“炫性能”而是让大量一次性Python脚本变成可测试、可复用的数据准备流水线。数据工程示例先把台账变成可验证输入而不是直接丢给大模型# 示例把多个设备/盲板台账先统一到 canonical schema import duckdb sql r SELECT trim(line_no) AS line_no, upper(trim(flange_id)) AS flange_id, cast(pid_revision AS varchar) AS pid_revision, try_cast(valid_from AS timestamp) AS valid_from, filename FROM read_csv(blind_lists/*.csv, union_by_nametrue, filenametrue) WHERE line_no IS NOT NULL rows duckdb.sql(sql).df()关键边界“解析成功”不等于“证据可信”。只有同时具备 source_ref、对象ID、版本、时间戳、schema校验结果以及必要的人工确认数据才有资格进入高风险 Evidence。3. 先给“要开的那个点”一个唯一身份Canonical Work PointEntity Resolution 听起来像算法名实际解决的是一个很朴素的问题工单里的“F-2041-17”、PID上的某个法兰符号、盲板表第17行、现场二维码和操作人员口中的“第二层东侧那个口”到底是不是同一个东西。术语翻译Entity Resolution人话解决“第二版”和“V2.0”是不是同一个版本、“这个现场标签”和“工单对象”是不是同一个物理点的问题。类比Canonical Work Point 相当于给每个作业点发一张唯一的“数字身份证”——不管它在工单、图纸、盲板清单还是现场叫什么别名系统最终只认这张证。我会先定义一个 canonical work_point把工单、图纸、清单、现场证据全部挂到这个统一对象上。Agent可以参与候选匹配但不能在高风险冲突下直接裁决“就是它”。Canonical Work Point把“一个现场点”变成跨系统共享对象work_point_id: WP-ARU-0417unit: ARUline_no: 6-H2S-2041-Apid_doc: PID-ARU-021pid_revision: R07flange_id: F-2041-17blind_list_id: BL-2026-091upstream_equipment: V-204downstream_equipment: E-217field_tag_required: true层级系统先看什么允许自动到哪一步L0 唯一编码line_no、flange_id、设备位号全一致且有效时可确认L1 主数据映射旧编码/别名 → canonical_id可自动映射但必须留审计L2 拓扑关系上下游设备、阀门、支路、PID拓扑只生成候选冲突即停L3 位置/上下文装置区、层高、方位、相邻设备补强候选不单独放行L4 视觉/OCR二维码、挂牌、照片、字符只做交叉验证L5 人工确认候选接近、标签缺失、高风险对象授权人员确认并写回映射真正成熟的回答不是“我有92%的把握这是F-2041-17”而是“存在两个候选对象拓扑证据无法唯一消歧现场标签不可见系统不进入下一步请由授权人员重新定位并确认。”4. 用户问“这个点能不能开”系统内部要拆成一组 ClaimClaim 可以理解成“必须被逐条证明的工程命题”。这样 Agent 的目标就不再是生成一段像专家的结论而是把每一个前置条件变成可验证对象。Claim人话Evidence / Tool失败动作C01 对象唯一工单必须只指向一个 work_pointcanonical_id 工单版本不唯一 → BLOCKC02 图纸当前有效不能拿旧版PID做当前作业发布状态 revision过期 → BLOCKC03 清单映射一致盲板/法兰清单与工单是同一对象映射Trace冲突 → BLOCKC04 现场身份可确认标签/位置/拓扑能把对象唯一找出来现场证据 人工确认不确定 → WAIT_HUMANC05 隔离状态完整上游/下游隔离条件已满足隔离记录/只读状态缺失 → BLOCKC06 前置检测有效检测记录仍在有效时间窗检测时间戳/记录过期 → BLOCKC07 人工许可完成高风险许可责任人已经会签Java审批流未完成 → WAIT_HUMAN5. Rule / Skill / Knowledge 分开是受控 Agent 的第一条红线这里最容易犯的错误是把SOP、企业制度、工具说明和知识库全部塞进Prompt然后告诉模型“请严格遵守”。在生产流程里硬约束必须从语言模型里拿出来。层人话例子为什么独立Knowledge系统知道什么PID符号、SOP、设备说明、历史Near Miss可检索但不能替代规则与当前状态SkillAgent允许做什么query_pid_graph、verify_isolation、build_evidence形成工具白名单与权限边界Rule哪些事绝不能被解释过去对象不唯一→BLOCK过期图纸→BLOCK高风险→人工可测试、版本化、灰度、回滚、审计生产里我更倾向做一个独立 Rule Center而不是把规则散落在代码和Prompt里。每条规则至少包含 rule_id、version、effective_from、severity、condition、action、source、test_cases。这样企业标准更新时可以做新旧版本回放和灰度而不是重新发一版Agent代码。规则中心示例硬约束是配置资产不是 Prompt 文案rule_id:LINE_OPENING_004version:3.2effective_from:2026-08-01severity:HIGHwhen:any:-work_point.unique false-pid.current_release false-isolation.evidence_complete falsethen:gate:BLOCKEDrequire_manual_review:truesource:enterprise_line_opening_standard生产环境里Rule Center 最怕两件事规则互相打架以及灰度失控。所以光有 YAML 还不够至少要再补两道工序规则冲突检测LINE_OPENING_004要发 v3.3发布前规则中心必须自动对新旧规则集做两层检查——静态层面扫描条件重叠与结论矛盾例如新规则放宽了隔离证据要求而另一条隔离标准仍要求证据完整两条规则在同一证据状态下会给出相反裁决运行时层面用历史 Evidence Pack 批量回放比对。检出冲突就禁止发布而不是指望运行时“谁先命中算谁的”。规则沙箱与回放Shadow Mode新规则上线前必须用过去 6 个月的真实 Evidence Pack 完整跑一遍输出新旧版本的 BLOCK / WAIT_HUMAN / PASS 差异表。差异只有两种可接受结局新规则拦下了旧规则漏掉的更好或差异逐条有人工签字说明理由。任何“新规则放行了旧规则拦下的案例”都必须单独评审后才能灰度灰度期间新旧规则并行打分Shadow 数据达标才正式切换。# Rule Center 发布卡点示意publish_check:conflict_scan:required# 与现有规则集做条件重叠/结论矛盾扫描shadow_replay:corpus:last_6mo_evidence_packs# 过去6个月真实证据包回放report:block_diff_summary# 新旧规则 BLOCK/WAIT_HUMAN 差异表approval:relaxed_cases:manual_sign_off# 新规则放行了旧规则拦下的案例 → 逐条签字这样 Rule Center 才不是“配置文件仓库”而是一条带发布门禁的规则资产线。6. 生产级架构让 Agent 夹在业务系统和专业工具之间而不是凌驾其上这套架构最重要的不是“用了几个Agent”而是边界清晰现场OT系统只读接入Java业务系统掌握身份、权限、工单、审批、签名和最终业务状态Python Agent负责理解、检索、Skill编排、Evidence Pack和受控推理规则和专业工具各自拥有独立版本。架构原则AI 是增强路径不是安全流程的单点故障。Agent不可用、模型不可用、外部工具超时都应该降级到原有人工流程任何降级都不能绕过对象确认和作业许可。7. 老 DCS / GDS 没 API 怎么办先做“只读适配层”企业现场最大的工程现实之一是很多系统根本没有现代REST API。DCS、GDS、PLC、仪表和老SCADA可能通过OPC DA、OPC UA、Modbus甚至定时导出文件提供数据。这里不需要强行把现场系统“云原生化”更不应该让Agent直接连控制网络做写操作。更稳妥的做法是在OT与IT之间增加边缘数据接入层协议适配、只读缓存、时间戳、数据质量标记和健康检查在边缘完成向上只暴露统一的只读接口。OPC UA本身就是面向工业系统互操作的信息交换标准可以覆盖传感器、控制系统、MES到企业系统。现场条件接入方式Agent能看到什么失败时怎么处理支持 OPC UA边缘UA Client订阅当前值、时间戳、质量码连接异常→Evidence stale→WAIT_HUMAN仅 OPC DAWindows网关/DA-UA桥接经转换后的只读点位桥接失败→不缓存“上次成功值”冒充当前值Modbus设备协议网关轮询离散/寄存器只读快照超时→标记UNAVAILABLE不自动重试到“碰巧成功”无在线接口受控文件落盘/人工上传带批次/时间戳的文件快照超过新鲜度阈值→BLOCK或人工确认为什么强调“只读”这类 Agent 的目标是证据收敛和风险拦截不是替代DCS/PLC控制回路。把写控制值的权限与Agent隔离既降低安全风险也更容易通过企业OT安全评审。8. 夜间外部工具超时怎么办失败不能被“重试成成功”对生产系统来说工具失败本身不可怕最危险的是失败被静默吞掉或者系统拿上一次缓存结果继续往下走。每个Skill都应该有明确的工具契约status、source_ref、observed_at、freshness、confidence、error_code、retryable。故障系统动作最终状态PID图谱服务超时短超时 有界重试 Circuit BreakerTOOL_UNAVAILABLE → WAIT_HUMAN气检数据超过有效时间窗不使用旧值替代EVIDENCE_STALE → BLOCKEDDCS/边缘网关离线标记数据源不可用并告警DEGRADED_TO_HUMAN规则服务不可用禁止绕过规则中心RULE_ENGINE_UNAVAILABLE → BLOCKEDLLM/RAG不可用关闭智能解释保留确定性检查人工流程继续AI增强能力降级Spring生态可以用 Circuit Breaker、TimeLimiter、Retry 等机制做外部依赖保护。关键不是采用哪一个库而是把“失败怎么进入业务状态”写清楚不能把异常当PASS也不能让无限重试把夜间作业卡成一个不可解释的半死状态。9. Java Python不推倒重构也不让两个世界互相污染很多传统企业的核心业务系统已经在Spring Boot里跑得很稳SSO、组织、RBAC、流程审批、电子签名、数据库事务、审计。这些东西没有必要因为上Agent就搬到Python。更可复制的路线是“Java稳业务Python做智能旁路”。Java / Spring Boot 保留Python Agent 新增身份认证、组织、RBACLLM意图理解、受限Planner工单/作业许可/审批/签名RAG、Entity Resolution辅助业务主状态、数据库事务Skill Router、Evidence Pack规则发布入口/版本元数据工具编排、Explain、Trace审计主表、归档、最终许可不得越权修改核心业务状态术语翻译Transactional Outbox人话避免“Java里任务已经保存了但发给Python Agent的消息恰好失败”这种半成功。业务数据和待发事件在一个本地事务里一起落库再由CDC/MQ可靠发布。类比相当于银行转账的“回执单机制”——账记了回执就一定发得出去要么都成要么都不成不存在“钱扣了、对方却没收到”的半成功。Python侧仍然要做幂等同一个 event_id task_id 重复投递十次也只能产生一次有效业务动作。Java收到Agent回执后也不能盲目覆盖状态而要校验当前 state_version避免旧事件把新状态“回滚”。双栈一致性允许消息重复不允许业务动作重复-- Java 本地事务示意BEGIN;INSERTINTOwork_task(task_id,state,state_version)VALUES(T-42,AGENT_PENDING,1);INSERTINTOoutbox_event(event_id,task_id,event_type,payload)VALUES(E-1001,T-42,REVIEW_REQUESTED,{...});COMMIT;-- Python 消费端idempotency_keyE-1001:T-42ifalready_processed(idempotency_key): ack_and_skip()还有一个容易被忽略的极端场景人工已经在 Java 侧取消了工单Python Agent 却恰好在此时返回了 READY_FOR_MANUAL_REVIEW。如果 Java 只校验 state_version这条迟到回执仍可能把已取消的工单“复活”进复核队列。所以 Java 收到 Agent 回执时要做双重校验先校验 state_version 防乱序回滚再校验工单的业务终态——工单已是 CANCELLED 或 COMPLETED 时回执不触发任何状态机流转直接落审计日志归档-- Java 侧回执校验示意UPDATEwork_taskSETagent_receipt:payload,receipt_statusDISCARDED_TERMINALWHEREtask_id:task_idANDstate_version:expected_version-- 防乱序回滚ANDstateNOTIN(CANCELLED,COMPLETED);-- 终态直接丢弃-- 0 rows affected → 写审计日志工单已终态Agent 回执不入状态机原则是Agent 的回执永远只是“输入”不是“指令”。业务状态机的钥匙始终握在 Java 手里。10. Agent 的真正产物不是“结论”而是一张可展开的 Evidence Pack现场人员不需要看一段AI总结更需要看到一张“身份卡”对象是谁、证据有哪些、哪里一致、哪里没确认、哪条规则命中、为什么必须等人工。Evidence Pack让“为什么不能继续”可以被人复核{task_id:T-42,work_point_id:WP-ARU-0417,identity:{line_no:6-H2S-2041-A,flange_id:F-2041-17,pid_revision:R07},evidence:[{type:PID,ref:PID-ARU-021#R07,verified:true},{type:blind_list,ref:BL-2026-091#row17,verified:true},{type:field_tag,ref:photo://T-42/img3,verified:false,reason:tag_occluded}],rule_hits:[FIELD_TAG_NOT_VISIBLE],gate:WAIT_HUMAN,reason:现场身份无法唯一确认}如果使用LangGraph这类状态编排框架可以把人工复核点设计成可持久化 interrupt流程在需要授权人员确认时暂停保存状态等待人工输入后从同一个thread恢复。但这里的关键仍然不是框架名字而是人工中断必须进入业务状态、可重放、可审计。11. 一个最小可运行 Demo不发许可只演示“证据不足就停”下面的Demo故意不控制DCS、不计算安全设定值也不自动签发作业许可。它只演示三件事对象是否唯一、证据是否有效、规则是否允许继续。FastAPI Demo输出理由和证据引用而不是一个黑盒 PASSEDfromdatetimeimportdatetime,timezonefromfastapiimportFastAPIfrompydanticimportBaseModel appFastAPI()classEvidence(BaseModel):kind:strref:strverified:boolobserved_at:datetime|NoneNoneclassRequest(BaseModel):task_id:strcandidate_ids:list[str]pid_current:boolisolation_ok:boolgas_test_fresh:boolevidence:list[Evidence]defgate(req:Request):reasons[]iflen(set(req.candidate_ids))!1:reasons.append(WORK_POINT_NOT_UNIQUE)ifnotreq.pid_current:reasons.append(STALE_PID)ifnotreq.isolation_ok:reasons.append(ISOLATION_EVIDENCE_MISSING)ifnotreq.gas_test_fresh:reasons.append(GAS_TEST_STALE)ifany(note.verifiedforeinreq.evidence):reasons.append(UNVERIFIED_EVIDENCE)ifreasons:return{task_id:req.task_id,gate:BLOCKED_OR_WAIT_HUMAN,reasons:reasons,evidence_refs:[e.refforeinreq.evidence]}return{task_id:req.task_id,gate:READY_FOR_MANUAL_REVIEW,note:仍需授权人员完成最终作业许可}app.post(/review)defreview(req:Request):returngate(req)Demo 的成功标准不是“AI给了一个很像专家的判断”而是它能够把对象歧义、过期图纸、隔离证据缺失、气检过期这些问题显式化并稳定进入BLOCK或WAIT_HUMAN。12. 上线后运维团队看什么把 Trace 从“日志”升级成业务证据生产级 Agent 最容易被忽略的一层是可观测性。普通接口只看HTTP 200/500不够一个 task_id 应贯穿Java、消息、Agent、Skill、规则、Evidence和人工动作。这样事故复盘和系统升级时才能回答“当时为什么放行/为什么拦截”。指标人话建议用途Gate False Pass本应拦截却放过去的比例高风险场景北极星Identity Ambiguity Recall真实存在对象歧义时能否发现验证消歧链是否漏风险Evidence Coverage关键Claim有合格证据的比例判断证据链是否闭合Stale Evidence Block Rate过期图纸/检测是否稳定拦截防旧数据被当当前事实Tool Timeout Escalation工具失败是否正确转人工/阻断检验降级逻辑Trace Completeness每次工具/规则/人工动作是否留痕审计与复盘Replay Success历史任务能否按当时快照重放升级回归测试部署和升级也要像普通生产系统一样做规则集、解析器、模型、Prompt、Skill都绑定版本新版本先做历史Case Replay再小流量灰度。只要Gate False Pass恶化就应该回滚而不是用“新模型平均分更高”解释过去。13. ROI 不按“OCR省多少分钟”算而按一套安全账本来算CSB报告中PEMEX Deer Park事故造成约1,230万美元与装置失用相关的财产损失。但本文不会把这笔损失直接拿来宣称“Agent可以避免”。真实企业算账时更可信的做法是用自己的历史数据构建风险账本。账本怎么量建议直接收益平均工单准备时长、返工次数、重复查图/核清单工时财务可审计作为确定性收益风险收益高风险拦截数 × 专家确认率 × 事件概率/损失估计用半年真实拦截数据校准不拍脑袋合规收益Evidence Coverage、Trace Completeness、过期文件拦截作为控制有效性证据知识收益Rule/Case复用率、Replay成功率、专家映射回写不建议强行货币化这套账还必须诚实地计入隐性成本WAIT_HUMAN 频率在上线初期会明显上升——系统比人严格会把很多以前“差不多就行”的单子拦下来授权人员的复核工作量随之增加。所以完整的财务模型里应该有一个负向因子专家复核工时增量 新增 WAIT_HUMAN 单数 × 平均复核时长 × 专家工时成本并给出它随规则调优逐步收敛的预估曲线。把这笔账主动摆到桌面上比只讲收益更容易赢得管理层信任——财务模型诚实项目才走得远。如果管理层一定需要一个财务模型可以用期望损失而不是“事故价值”叙事风险账本半年后用真实Gate数据重新校准 P、L、R年风险收益示例公式 N × P × L × RN一年高风险开管/拆盲板任务数P历史上经专家确认的对象/版本/前置条件重大问题概率L一次问题造成的平均返工、停工、物料、设备或项目损失R受控系统实际降低该问题流入后续作业的比例给管理层的一句话这套系统不是为了“每年少查几小时图纸”而是为了建立一个永远在线、可审计、不会因为疲劳而跳过前置条件的复核层它的价值最终要用真实拦截数据证明而不是靠PPT承诺“绝对安全”。14. 60 天 PoC先证明“能不能稳定停下来”再谈自动化率阶段核心工作Go / No-GoW1-2对象与数据基线选一个装置、20-30个典型开管点定义canonical work_point梳理数据源关键对象能否唯一标识关键数据是否可追溯W3图纸/清单解析PID、线表、盲板清单结构化版本绑定source_ref过期/错版是否能被识别而非静默通过W4现场只读接入边缘网关接OPC/Modbus/文件数据新鲜度与健康状态断链/过期是否进入明确降级状态W5Entity Evidence多层候选消歧、冲突工作台、Evidence Pack对象歧义是否稳定暴露W6规则与双GateRule Center、QualityGate、ManualReviewGateGate False Pass是否达到试点阈值W7Java/Python协同Outbox、幂等、状态同步、失败恢复网络闪断/重复消息后业务状态能否恢复W8Shadow Mode历史回放、故障注入、现场演练只给建议不改变作业流程真实问题拦截质量是否足以进入下一阶段还有一条经常被漏掉的验收项人机交互摩擦测试安排在 W5-W6。工业 AI 落地最大的阻力往往不是技术而是一线配合度——工艺员嫌扫码麻烦、承包商嫌证据上传繁琐。这期间要实测工艺员/承包商完成一次完整 Evidence Pack 确认的平均耗时是否超过原有纸质流程的 1.5 倍。一旦超过先做交互减法预填默认值、扫码即传、清单化点选而不是靠行政命令硬推——再安全的系统只要太慢就一定会被现场绕过去而被绕过的安全系统比没有系统更危险。PoC真正应该追求的不是“自动通过率80%”。在早期高风险场景里系统经常说“我不确定请人工确认”并不是失败只要它能稳定发现真实歧义、避免False Pass并且每一次停下来都有可解释证据就是非常有价值的结果。15. 最后把边界说清楚这个 Agent 能做什么不能做什么可以做不应该做读取并归一工单、PID、盲板清单、现场标签、隔离/检测证据直接控制DCS/PLC、改变阀位或下发生产设定值发现对象歧义、版本过期、证据缺失、工具失败用LLM置信度替代正向设备识别程序调用白名单Skill、生成Evidence Pack、触发Gate绕过企业许可、电子签名和授权责任人在不确定时暂停并请求人工确认把“接口失败/规则不可用”解释成默认通过保留task_id、Trace、Rule版本和人工动作供Replay承诺“绝对安全”或把公开事故营销化这篇文章真正想留下的东西开管作业只是一个场景。把表象拿掉以后它验证的是一套更通用的工业AI方法Raw Data → Data Governance → Canonical Object → Claim → Evidence → Rule/Skill/Knowledge → Domain Tool → Controlled Agent → QualityGate → ManualReviewGate → Trace/Replay → Risk Metrics。变的是业务对象不变的是“可追溯、可复核、可拦截、风险可度量”。结语工业现场不缺一个更会说话的模型。真正稀缺的是当证据不足、对象不唯一、工具失败、数据过期或责任边界不清时系统仍然能够冷静地停下来并且把“为什么停”完整交给人。如果AI要进入高风险业务流程这可能比“它像不像专家”更值得追求。参考资料与写作边界U.S. Chemical Safety and Hazard Investigation Board, Fatal Hydrogen Sulfide Release at PEMEX Deer Park Refinery, Investigation Report, February 2026. https://www.csb.gov/file.aspx?DocumentId6315CSB — PEMEX Deer Park Chemical Release case page. https://www.csb.gov/pemex-deer-park-chemical-release-/OPC Foundation — OPC Unified Architecture Part 1: Overview and Concepts. https://reference.opcfoundation.org/specs/OPC-10000-1/4Debezium — Outbox Event Router documentation. https://debezium.io/documentation/reference/stable/transformations/outbox-event-router.htmlSpring Cloud Circuit Breaker — Resilience4J reference. https://docs.spring.io/spring-cloud-circuitbreaker/reference/spring-cloud-circuitbreaker-resilience4j.htmlLangGraph — Interrupts / Human-in-the-loop documentation. https://docs.langchain.com/oss/python/langgraph/interruptsDuckDB — Data Sources / CSV and Excel ingestion documentation. https://duckdb.org/docs/stable/data/data_sources写作边界事故数据与调查结论来自CSB公开资料本文提出的架构、Rule字段、Gate指标、PoC周期、数据接入方式和ROI模型属于工程设计建议需要企业结合自身工艺、制度、系统安全区划和历史数据验证。本文不提供生产控制设定值也不替代任何法定/企业安全许可程序。