工业智能体用实时数据和沙箱计算校验答案

工业 AI 能不能找到故障根因，先取决于它能否读懂设备之间的关系、实际运行的控制逻辑，以及可信的传感器数据。CrossnoKaye 的做法是先用 ATLAS 统一这些信息，再让 AURA 调用 Amazon Bedrock AgentCore 执行 Python 分析，把调查结果送进工程师的日常工作流。

这套案例值得读的地方，是它把模型推理、数值计算和设备控制拆开了。模型负责提出调查方向，代码负责计算与校验，现场控制系统负责守住运行边界。不过，文中的收益数据来自厂商报告，不能直接视为 AgentCore 或大模型单独带来的效果。

为什么接入传感器，还不足以判断故障

工厂里的信息通常分散在多个系统中：PLC、DCS 保存设备控制逻辑，historian 保存时间序列，SCADA 提供操作界面，优化工具和报警记录又各自独立。它们连设备名称都未必一致。

外接一个 Agent，即便拿到了所有传感器读数，也可能不知道某台设备为什么停机。决定设备行为的状态机、控制顺序和安全联锁，还锁在控制器代码里。跨系统接入还会增加工厂网络中的凭据管理负担。

ATLAS 的前提是把这些信息放进同一个设施模型。它兼容现有 PLC 和 DCS，不要求更换全部硬件；云端编写、验证和管理基础控制逻辑的版本，再下发到现场的 Kubernetes 集群执行。现场采用冗余计算机、电源和交换机，云连接中断时仍能继续运行。网关只向外建立连接，厂内不开放入站防火墙端口。

AURA 因此能同时读取设备拓扑、已部署的控制逻辑、联锁、报警、设置变更和优化计划，而不是临时拼接几个数据接口。

采石场案例最能说明区别。一个班次内，产线后半段停了两次，操作员看到二级破碎机报警，复位后却再次停机。AURA 结合输送带布局和联锁逻辑，发现三级破碎机下方的回料皮带打滑，触发过载保护，随后上游联锁停掉二级破碎机，避免石料继续堆入已经停止的下游设备。现场检查确认了皮带问题，并在几分钟内修复。

报警发生的位置，未必就是故障发生的位置。

这套统一模型已经有相当规模：CrossnoKaye 报告覆盖超过 100 个设施、13,000 个受控资产，保存超过 22 万亿个机器数据点，每天新增超过 500 亿条读数。云端还运行超过 1,000 个高级过程控制（APC）应用，每天执行 650,000 次闭环控制动作。AURA 是建立在这套既有自动化平台之上的。

怎样让模型算数，又不把输出当成事实

LLM 可以理解工程语境、规划调查，但不能可靠地在提示词里计算数百万条读数的统计结果或物理平衡。AURA 把这部分交给 AgentCore Code Interpreter：模型生成 Python，在隔离的 microVM 中运行。

难点不止是「能运行代码」。作者团队早期允许脚本向标准输出打印 JSON 或文字摘要，发现它很脆弱：模型会写错列名、漏掉部分时间窗口，输出格式也可能让下游图表渲染失败。

他们随后给计算过程加了三道约束。

首先，在分配沙箱前验证输入契约，一次最多准备 50 个数据集，可以同时包含物理读数、派生指标、报警、设置记录和电价表。

其次，在模型脚本后追加确定性的校验程序，检查声明的输出表是否确实是 pandas.DataFrame，必需列和类型是否完整，再直接序列化为二进制 Apache Parquet。下游读取的是通过检查的数据表。

最后，Python 异常或缺列会变成结构化重试信息，由 Temporal 工作流交给 Agent 修正，并在干净沙箱里重算。未经验证的结果不进入报告。

这里仍有一道边界：表结构正确，不代表分析方法正确。时间窗口选错、单位混用、因果判断失误，都可能生成一张格式合规的表。原文没有给出这类语义错误的覆盖率。

沙箱状态也按用途区分。Chats 为多轮调查保留热会话，通过 Amazon ElastiCache for Valkey 维护 15 分钟滑动 TTL；Tasks 和 Routines 每次启动全新 microVM，完成后调用 StopCodeInterpreterSession，避免前次变量污染结果，也减少空闲费用。

原文举例，一次 Chat 可以分析 94 个设施过去 24 小时的报警。Python 会区分「103 次报警来自两条反复触发的罐液位规则」和「58 次报警涉及氨检测、蒸发器及热气阀，且集中在一秒内」。后者更像设备级联故障。单看报警总数，优先级可能排反。

自动调查可以跑在凌晨，控制权要留在哪里

AURA 提供三种入口：Chats 用于交互调查，单轮最多覆盖 200 个设施；Tasks 把调查固化为参数化任务，绑定不可变版本快照；Routines 根据时间、阈值、变化速率、报警或设备模式变化自动启动任务。

这些入口解决的是不同工作节奏。工程师不需要每次打开一个空白聊天框，重新解释工厂发生了什么。

一个制冷厂案例中，Routine 在凌晨 2:00 检测到低压级吸气压力漂移，随后只读调用固定版本的 Task。Agent 在沙箱里关联冷凝器逼近温差与吸气压力，排查传感器漂移、制冷剂不足等可能，定位冷凝器侧污垢。到 2:04，带证据的技术简报已经通过 Amazon SES 发到工程团队邮箱。

发送前，系统逐条检查引用是否指向已保存的遥测窗口、设置变更记录或 Amazon S3 中的计算产物。工程师点击邮件中的入口后，系统重新验证当前设施权限，打开已经装载证据的 Chat。这个案例没有自动修改设备控制参数。

其安全设计分成四层：

1. Amazon Bedrock Guardrails 检查提示词和输出，知识检索按组织隔离，简报标注分析时段及缺失数据。
2. 计算沙箱没有通往设备的网络路由、凭据或 API；Routines 只读，交互会话提出的设置变更需要实名人工批准。
3. 云端优化只下发工程许可范围内的设定值计划，现场基础控制执行状态机、变化速率限制、运行边界和联锁，云服务与 Agent 无法绕过。
4. 更底层还有独立的安全继电器、本地跳闸及机械泄压、超温保护。

模型可以参与调查和提案，设备安全不能依赖它服从提示词。

我的判断

最有参考价值的是把不确定性关进可检查的接口：计算有数据契约，报告有证据，自动任务有固定版本，设备动作有独立约束。这比单纯要求模型「认真核对」更容易排查问题。

但它的建设前提很重。ATLAS 已经掌握设施模型、基础控制、历史数据和优化应用，AURA 才能在统一权限边界内调查。对只有零散日志和多个供应商接口的团队，先接一个 Agent 很难复制这种效果。统一数据名称、关系和权限，可能比编排 Agent 更费工夫。

收益也要拆开看。CrossnoKaye 报告 APC 应用提高吞吐量 11%–17%，设施总能源成本平均降低 21%；组合方案让批次干燥时间标准差降低 34%，达标产品增加 6%，并识别出采石场每年超过 50,000 吨的可恢复产量缺口。这些结果涉及基础控制、物理模型、MPC、强化学习和持续优化，不能全部归功于 AURA。

作者还报告每年超过 9,000 次控制软件部署、超过 100 万运行小时且无安全事故，以及超过 5,000 个 AI agents 监控超过 10,000 个资产。调查从数小时缩短到四分钟以内，但原文没有交代样本分布、失败率、人工复核成本，也没有与传统规则诊断或固定分析脚本提供对照数据。它展示了生产实践，收益归因仍需打问号。

能拿来做什么

• 给 Node 或 AI 编程工具接入分析能力时，可以让模型生成计算代码，再由确定性程序检查输出表、必需字段和类型；同时单独检查时间覆盖、单位与缺失值，别把「缺数据」当成「没事件」。
• 为多轮数据调查保留短时会话，为定时报告使用干净执行环境，并绑定任务版本。两类任务对延迟和复现的要求不同，不必共用一种会话策略。
• 做自动诊断报告时，把结论关联到原始数据窗口、变更记录和计算产物，让前端能直接展示证据并承接追问。引用检查能确认来源存在，结论是否充分仍需另行判断。
• 涉及配置变更或设备操作时，把调查、提案、批准和执行分开。权限校验、执行边界和结果回读应落在服务端及控制系统中，不能只写进系统提示词。