Article · AI translation
工业运营面临着典型企业软件中不会出现的 AI 挑战。在大多数设施中，工厂数据和控制逻辑分散在不同供应商的独立系统中：可编程逻辑控制器（PLC）和分布式控制系统（DCS）运行设备逻辑，历史数据系统按照各场地特有的命名方式记录时间序列标签，监控与数据采集（SCADA）系统驱动操作员界面，而独立的优化工具或报警日志记录器则在旁运行。实践中，将外部 AI 智能体附加到这一系统组合上通常效果不佳。每个系统都有自己的命名约定。真正决定设备如何运行的逻辑（控制序列、状态机和安全联锁）封存在专有控制器代码中，外部工具无法查看。让附加的智能体访问多个运营技术（OT）系统，还意味着要在工厂网络中分发凭证。CrossnoKaye 采用了不同的方法，利用 Amazon Bedrock AgentCore 将物理 AI 引入重工业。其软件定义自动化平台 ATLAS 将实时工厂数据和 AI 推理与食品饮料工厂、工业制冷设施、骨料采石场和制造基地的设备闭环控制连接起来。在超过 100 个工业设施和 13,000 项受控资产中，CrossnoKaye 存储了超过 22 万亿个机器数据点，每天摄取超过 500 亿条新读数，并运行超过 1,000 个实时高级过程控制（APC）应用；CrossnoKaye 报告称，这些应用将生产吞吐量提高了 11%–17%，同时使设施总能源成本平均降低了 21%。由于 ATLAS 已在 AWS 上的单一平台中管理设施模型、基础控制软件、历史数据系统和优化应用，CrossnoKaye 的智能体系统 AURA 能够在单一安全边界内原生访问工厂的完整运行状态。不过，掌握工厂背景只是问题的一半。大型语言模型（LLM）擅长理解工程背景并规划调查，但无法仅凭提示词可靠地对数百万条传感器读数进行统计计算或物料及能量衡算。为使每个数值答案都有实际计算支撑，AURA 使用 Amazon Bedrock AgentCore 的代码解释器功能，在隔离的 AWS 托管 microVM 沙盒中于运行时编写并执行 Python 工作负载，同时配合 Amazon Bedrock Guardrails 和本地边缘安全控制。本文介绍 CrossnoKaye 如何在 AWS 上构建 ATLAS 和 AURA 的架构、AURA 如何在交互式 Chats、可重复执行的 Tasks 和自动化 Routines 中使用 Amazon Bedrock AgentCore，以及团队从物理 AI 的生产环境运行中获得的经验。解决方案概览：ATLAS 通过现有的 PLC 和 DCS 基础设施控制工业流程，涵盖窑炉、破碎机、干燥室、烤箱、螺旋式冷冻机、冷水机组、涡轮机、阀门和压缩机，无需客户拆除并更换工厂硬件。图 1 展示了本地部署的 ATLAS 边缘集群、持续的云端优化和 AURA 如何在 AWS 上协同工作。图 1：采用 Amazon Bedrock AgentCore 的 CrossnoKaye AURA 和 ATLAS 物理 AI 架构。ATLAS 和 AURA 围绕 3 个核心层构建：首先，从边缘端开始，以软件定义工厂。在每个设施中，配备冗余计算机、电源和网络交换机的本地部署 ATLAS 控制面板（因此在更换故障硬件组件期间，本地控制仍可不间断运行）运行一个采用契约优先微服务的本地 Kubernetes 集群，将 AWS 上的 ATLAS 云平台延伸到工厂现场。 在云端，ATLAS 编写、验证设施的基础控制逻辑描述并对其进行版本管理（这些描述定义设备状态机、运行顺序、运行边界、联锁和报警规则）；这些描述会下载到边缘设备，并在本地针对现有设备和控制器运行。CrossnoKaye 报告称，每年部署控制软件超过 9,000 次，累计运行超过 100 万小时，且未发生安全事故。每台边缘设备还充当仅向外连接的信息技术／运营技术（IT/OT）网关，在厂区内部无需开放任何入站防火墙端口，并通过 Amazon VPC Lattice 和 Amazon Managed Streaming for Apache Kafka（Amazon MSK）向 AWS 持续传输高频遥测数据。如果云端连接中断，工厂仍会依靠本地边缘集群上的基础控制逻辑描述安全运行。其次，衍生工程信号和闭环优化应用使用同一个共享工厂模型，在基础控制之上运行。在云端，CrossnoKaye 的 Scheduling 系统从 Amazon Simple Storage Service（Amazon S3）中经过版本管理的 Python 软件包运行两条持续处理流水线，按可配置的实例级周期运行，并在工厂设置发生变化时由事件触发。合成读数算法计算衍生工程指标，例如热流分布、资产健康指数、能源强度和质量平衡偏差，并将其与物理输入／输出数据一同写回历史数据系统。闭环优化应用在基础控制层之上运行，将这些衍生的合成读数与物理模型、模型预测控制（MPC）、强化学习、公用事业费率和天气预报结合起来，计算最优设定值计划。Amazon Simple Queue Service（Amazon SQS）FIFO 队列按设施对每次计划和状态更新进行排序，然后将设定值发送给边缘集群上的本地基础控制逻辑描述；CrossnoKaye 报告称，该系统每天执行 650,000 次闭环控制操作。第三，AURA 以微服务和持久化 Temporal 工作流的形式，在平台边界内的 Amazon Elastic Kubernetes Service（Amazon EKS）上运行。在调用者的企业权限范围内，AURA 智能体查询内部 Atlas Data 网关，以通过一个一致的模型读取单个设施或设施群的运行状态：上游和下游设备拓扑、已部署的基础控制逻辑描述和联锁、物理输入／输出数据和合成读数、设置变更和报警历史、正在执行的优化计划，以及在 Amazon Bedrock Knowledge Bases 中建立索引的工厂文档。将设备布局、基础控制逻辑和传感器数据置于同一系统中，在诊断工厂问题时会带来切实的不同。在一座设有初级、二级和三级碎石机的骨料采石场，工厂的后半段在同一个班次内跳闸两次。操作员在控制室看到二级碎石机报故障，清除报警并重启生产线，但几个小时后生产线再次跳闸。单看历史数据系统中的时间戳，二级碎石机是在三级碎石机之后几秒钟报故障的，这使问题看起来出在碎石机上。由于 AURA 也会读取输送带布局和已部署的基础控制联锁，它的调查沿着实际控制逻辑展开。三级碎石机下方的一条回流输送带发生打滑，触发了三级碎石机的过载联锁。该联锁的上游安全联锁立即停止了二级碎石机，以防石料将已停机的下游碎石机掩埋。工厂经理没有继续追查并不存在的碎石机故障，而是派操作员检查回流输送带，在几分钟内确认并修复了打滑问题。 图 1 中编号的流程展示了 AURA 调查如何在 AWS 上运行：客户端与边缘入口：工程师和模型上下文协议（MCP）客户端通过 AWS WAF 和公有应用负载均衡器连接，API 网关在此验证企业单点登录（SSO）或 MCP 凭证。边缘遥测数据和控制计划经由 Amazon VPC Lattice（使用 AWS Identity and Access Management（IAM）签名版本 4（SigV4）进行身份验证）和 Amazon MSK 传输。上下文检索与受控推理：AURA 工作流通过 Atlas Data 网关读取工厂状态，并通过 Model Gateway 将提示词和限定在组织范围内的检索增强生成（RAG）查询路由至基础模型、Amazon Bedrock Guardrails 和 Amazon Bedrock Knowledge Bases。运行时计算调度：对于统计、热力学或涉及多个数据集的数学计算，工作流通过 gRPC 将输入数据集流式传输到 AURA 的内部 Sandbox Orchestrator 服务。会话协调与实时流式传输：在交互式会话中，Sandbox Orchestrator 跟踪活跃沙箱的会话 ID，并通过 Amazon ElastiCache for Valkey 实时传送进度。隔离的 Python 执行：Sandbox Orchestrator 使用 AWS SDK 调用 Amazon Bedrock AgentCore 运行时的端点；该运行时是 Amazon Bedrock AgentCore 的一项能力，用于暂存数据集，并在隔离的代码解释器 microVM 中运行由模型编写的 Python 代码。产物存储与简报交付：经过验证的 Apache Parquet 输出、图表和附有引证的简报通过 AWS PrivateLink 保存到 Amazon S3，Amazon Simple Email Service（Amazon SES）则将自动生成的简报发送给工厂团队。工作流程概览：AURA 将 Amazon Bedrock 上的基础模型（有关各 AWS 区域的模型可用性，请参阅《Amazon Bedrock 用户指南》中的“按 AWS 区域列出的受支持模型”）与 Amazon Bedrock AgentCore Code Interpreter 中的隔离 Python 沙箱结合使用；后者是 Amazon Bedrock AgentCore 的一项能力。这一组合涵盖 3 种运行模式：Chats：交互式、多轮工程对话，可涉及单个装置、一条工艺生产线或多个站点的设施组合（单轮最多涉及 200 座设施）。Tasks：可重复执行、参数化的调查，绑定到不可变的版本快照，生成包含引证证据表和图表的结构化技术简报。Routines：由时间计划、传感器阈值、变化率时间窗口、警报或设备模式切换触发的自动化后台监测任务。以下章节将探讨这些工作流背后的 4 项架构决策。常驻会话沙箱与干净的单次运行流水线之比较：交互式调试和自动化工厂报告对状态有不同要求：在交互式 Chat 中，工程师逐步探索假设：加载 94 座设施过去 24 小时的关键警报，过滤某一站点反复报警的储罐液位传感器，并分析压缩机跳闸与环境湿球温度的关联。如果每一轮都启动一个全新的沙箱，就会清除内存中的表，并增加延迟。对于 Chats，Sandbox Orchestrator 将一个保持运行的 Amazon Bedrock AgentCore 会话与对话绑定，并在 Amazon ElastiCache for Valkey 中设置 15 分钟的滑动生存时间（TTL）；如果工程师在空闲超时后返回，系统会自动创建替代会话。对于计划执行的 Task 或凌晨 2:00 运行的 Routine，可复现性是首要考虑。每次运行都必须从干净的环境开始，不得保留此前运行的任何状态。对于 Tasks 和 Routines，Sandbox Orchestrator 为每次运行创建一个全新的、仅使用一次的 AgentCore microVM，并在计算完成后立即使用 StopCodeInterpreterSession 停止会话，从而避免不同运行之间的状态相互污染和空闲沙箱费用。这种常驻会话设计使在单次对话中对整个设施群进行问题分诊成为可行。 当一位运营总监要求 AURA 审查过去 24 小时内 94 个设施的所有严重警报，并找出主要机械风险时，该智能体会通过 Atlas Data 网关将整个设施群的警报摘要加载到其 AgentCore 沙箱中，并按设施、规则和相邻警报之间的时间间隔对触发记录分组。Python 分析没有按警报原始数量对设施排序，而是区分出两种情况：一座工厂的 103 次严重警报触发来自两条反复触发的排放罐液位规则；另一座工厂的 58 次触发则涉及氨气检测、蒸发器故障和热气阀，而且彼此相隔不到 1 秒。这使安全和维护团队能够直接找到发生设备连锁故障的设施。以可验证的计算取代未经核实的模型运算 当工程师要求 AURA 分析工艺趋势或审查班次表现时，答复中的数字必须准确。在 AURA 开发初期，团队发现，让模型编写自由格式的 Python 脚本并将 JSON 或文本摘要打印到标准输出过于脆弱：模型偶尔会写错列名、遗漏部分时间窗口，或以破坏下游图表渲染的方式格式化输出。为使运行时计算可验证，AURA 对每次 Amazon Bedrock AgentCore 运行都实施严格的数据契约：预先验证契约并暂存多来源数据：在分配沙箱会话之前，Sandbox Orchestrator 会验证输入契约，并将最多 50 个数据集暂存到 microVM 工作区，其中包括物理 I/O、派生的合成读数、设定值日志、警报历史记录和公用事业费率表。沙箱内 DataFrame 模式验证：该服务不会解析标准输出中的自由格式文本，而是将确定性的验证程序附加到模型编写的 Python 脚本中。在沙箱内，该程序会验证每个声明的输出表都以 pandas.DataFrame 的形式存在于内存中，且包含所有必需的列和数据类型，并将通过验证的表直接序列化为二进制 Apache Parquet 文件。自动纠错：如果脚本引发 Python 异常或遗漏必需的列，任何未经验证的数字都不会呈现给用户。Temporal 工作流会将回溯信息和模式不匹配情况纳入结构化的重试提示，使智能体修正其 Python 逻辑，并在发布任何结论之前于干净的沙箱中重新运行计算。通过 Amazon SES 提供自动化夜班 Routines 和附有引文的 Briefs 工厂工程师无法全天候监看 100 个设施的仪表板，而许多设备问题始于夜班期间的缓慢偏移。AURA Routines 在后台运行，监测特定工艺状况（例如制冷级的吸气压力偏移、批次干燥曲线落后于规范要求，或计划外的手动设定值覆盖），并在条件触发时自动启动调查。某工业冷水机组工厂的一次夜班问题发现展示了这一流程如何从头到尾运作：自动检测与沙箱内根因分析（02:00–02:03 AM）：凌晨 2:00，一个 Routine 检测到低级吸气压力偏移，并以只读模式启动其固定的 Task。在 Amazon Bedrock AgentCore 沙箱内，该智能体对照物理读数和合成读数，分析冷凝器接近温度与低级吸气压力之间的关系，排除传感器漂移和制冷剂充注量不足，并将原因锁定为冷凝器侧结垢。确定性引文验证（02:04 AM）：在发布 Brief 之前，AURA 会解析每条行内引文，并验证每项结论都链接到 Amazon S3 中保存的遥测时间窗口、设定值变更记录或沙箱输出工件。系统不会自动更改任何控制设置。通过 Amazon SES 发送 Brief，并提供一键转入 Chat 的功能：触发后 4 分钟内，AURA 会通过 Amazon SES 向工厂工程团队发送一封经过格式化的 HTML Brief 邮件，其中包含诊断结果、附有引文的信号轨迹和一个“在 AURA 中调查”按钮。 当首席工程师在早班碰头会前选择该按钮时，AURA 会核验该工程师当前有效的设施访问权限，并打开一个已预载简报证据的交互式聊天界面，让团队可以立即提出后续问题或下达工单。纵深防御的工业安全：在工业工厂中，运行安全不能依赖大语言模型遵循提示词中的指令。由于 ATLAS 和 AURA 共用从云端到厂区边缘 Kubernetes 集群的同一平台，CrossnoKaye 通过 4 个相互独立的层级，严格限定 AI 和优化工作负载的行为：Amazon Bedrock Guardrails 与可核验的来源信息（观察）：通过 AURA 的 Model Gateway 路由的每条提示词和每项生成结果都由 Amazon Bedrock Guardrails 评估，以执行内容、主题和安全政策。知识库检索按组织隔离，每份简报都必须包含经过核验的文内引用，并注明分析了哪些时间段，以及传感器数据在哪些时段不可用。物理隔离的只读沙箱与经人工批准的提案（提议）：Amazon Bedrock AgentCore Code Interpreter microVM 在隔离的 AWS 托管环境中运行，没有通往工厂设备的网络路由、凭证或 API 路径。自动化例程严格以只读模式运行。当工程师通过交互式会话提出设置变更时，平台要求以操作人员的企业身份明确进行人工审批，并在之后通过工厂遥测数据核验实际效果。边缘侧不可绕过的确定性 Level 1 基础控制（约束与基础控制）：云端优化应用不会直接驱动现场硬件。它们通过在工程师批准的范围内下发设定值计划，在平台的基础控制层之上运行。在厂区现场，边缘 Kubernetes 集群在本地实时运行已下载的基础控制逻辑，执行确定性状态机防护、变化率限制、运行边界和设备联锁；云服务、优化应用或 AI 智能体均无法绕过这些机制。独立的物理硬件保护：在 ATLAS 软件定义控制器之下，工厂的实体机械和现场布线提供独立的硬接线保护层，包括安全继电器、本地可编程跳闸装置，以及机械式泄压和超温保护装置。成果与经验：CrossnoKaye 报告称，在食品加工、工业制冷、骨料与采矿以及制造业场所，将软件定义的边缘控制、持续的云端优化和 AURA 结合后，批次干燥时间的标准差降低了 34%（在目标成品率规格内完成的产品增加了 6%），并在采石场运营中发现每年超过 50,000 吨可挽回的产量缺口。在客户设施中，超过 5,000 个 AI 智能体监测着超过 10,000 项工厂资产（其中 ATLAS 设备群控制的装置和设备单元超过 13,000 个）；过去需要花费数小时导出历史数据库 CSV 文件、交叉核对 PLC 梯形逻辑并制作电子表格的调查，如今可在 4 分钟内完成，并在早班会议前通过 Amazon SES 送达附有引文的技术简报。在工业设施中构建和运行 AURA 的过程中，有 3 条经验尤为突出：添加 AI 前，先统一工厂模型和控制逻辑：智能体只有能够在一个一致的模型中读取工艺拓扑、已部署的基础控制逻辑和联锁、设置变更历史以及优化器状态，而非拼接 6 个互不相连的工厂系统，才能诊断真正的物理根因，例如区分下游循环输送带打滑与二级破碎机故障。 在操作人员的日常工作流程中提供价值，而不是让他们另行使用一款工具：工厂团队忙于运行设备。如果 AI 助手是一个独立的入口，工程师每次都必须从空白提示词开始，那么日常采用就会停滞。将 AURA 融入每天的轮班节奏（后台 Routines 在夜间发现异常，在 Amazon Bedrock AgentCore 中运行 Python 分析，并将附有引文的 Brief 发送到工程师的收件箱，工程师只需点击一次即可转入预先加载好内容的 Chat），意味着操作人员无需另行使用一款产品，就能在日常工作中看到其价值。在代码而非提示词中强制执行数据、覆盖范围和安全契约：在工厂里，缺少 1 小时的传感器数据与 1 小时内没有事件并不相同，未经验证的计算可能会让维修团队前往错误的机器。在工具契约中明确标示数据覆盖缺口，在从二进制 Apache Parquet 输出中提取数据前于 AgentCore 沙箱内验证 pandas.DataFrame 的模式，并在边缘 Kubernetes 集群上强制执行确定性的基础控制边界，可以在概率模型的错误影响操作人员或设备之前将其发现。结论 重工业中可靠的物理 AI 需要让模型以工厂实际的设备拓扑和控制逻辑为依据，并用可验证的 Python 计算支撑每一项定量主张。借助 Amazon Bedrock Guardrails 和 Amazon Bedrock AgentCore 中隔离的 Python 沙箱，ATLAS 和 AURA 使代理能够结合实时设施本体、基础控制说明、设定值历史、物理 I/O、优化状态和合成读数进行推理，通过 Amazon SES 提供可核验的工程答案和附有引文的技术 Brief，同时让确定性的安全控制牢牢留在工厂现场。要了解有关使用隔离代码执行构建代理的更多信息，请参阅《Amazon Bedrock AgentCore 开发人员指南》，或访问 CrossnoKaye，了解物理 AI 如何改变重工业。关于作者 Raphael Simon Raphael 是 CrossnoKaye 的首席技术官，负责领导 ATLAS 软件定义自动化平台和 AURA 智能系统的技术愿景与架构。他是开源 Goa 和 Goa-AI 设计优先框架的创始人及主要贡献者；这些框架用于以 Go 构建微服务和代理系统。此前，他曾担任 RightScale 的首席技术官，并在 Flexera 担任工程高管职务。Anu Jayanthi Anu 是 AWS 的高级解决方案架构师。她与初创企业创始人和工程团队合作，将大胆的想法转化为可投入生产的系统，涵盖生成式 AI 应用和能够在现实世界中采取行动的代理工作流程。她乐于与客户一同学习，帮助他们在成长过程中找到适合自己的 AWS 路径。