CrossnoKaye使用Amazon Bedrock

工业运营带来了AI挑战，这些挑战在典型的企业软件中并不明显。在大多数工厂中，工厂数据和控制逻辑分布在来自不同供应商的独立系统中：可编程逻辑控制器（PLC）和分布式控制系统（DCS）运行设备逻辑，历史记录器在特定于现场的命名方案下记录时间序列标签，监控控制和数据采集（SCADA）系统驱动操作员屏幕，而独立的优化工具或报警记录器则位于旁边。将外部AI代理附加到该堆栈中在实践中很少能很好地工作。每个系统都使用自己的命名约定。实际控制设备行为的逻辑（控制序列、状态机和安全互锁）被锁定在专有控制器代码中，外部工具无法检查。为可拆卸代理跨多个运营技术（OT）系统提供访问权限也意味着在工厂网络中分发凭证。

CrossnoKaye 采取了不同的方法，使用 Amazon Bedrock AgentCore 将物理AI带到重工业领域。其软件定义自动化平台ATLAS，将实时工厂数据和AI推理连接到食品和饮料工厂、工业制冷设施、 aggregates 矿场和制造场所设备的闭环控制。在100多个工业设施和13000个受控资产中，CrossnoKaye存储了超过220万亿个机器数据点，每天摄取超过500亿个新读数，并运行超过1000个实时高级过程控制（APC）应用程序；CrossnoKaye报告称，这些应用程序将生产吞吐量提高了11-17%，同时将总设施能源成本平均降低了21%。由于ATLAS已经在AWS上通过一个平台管理设施模型、基本控制软件、历史记录器和优化应用程序，因此CrossnoKaye的代理智能系统AURA，可以在单个安全边界内获得工厂完整运营状态的原生访问权限。

尽管拥有工厂上下文只是问题的一半。大型语言模型（LLMs）擅长解释工程上下文和规划调查，但它们无法在提示中可靠地计算数百万个传感器读数上的统计数据或物理平衡。为了使每个数字答案都有真实的数学依据，AURA使用Amazon Bedrock AgentCore中的代码解释器功能，在运行时在隔离的AWS管理的微VM沙盒中编写和运行Python工作负载，同时使用 Amazon Bedrock Guardrails 和本地边缘安全控制。本文涵盖了CrossnoKaye如何在AWS上架构ATLAS和AURA，AURA如何使用Amazon Bedrock AgentCore跨交互式聊天、可重复的任务和自动化例程，以及团队在生产中运行物理AI学到的经验。

解决方案概述

ATLAS控制现有PLC和DCS基础设施上的工业过程，从窑炉、破碎机、干燥室、烤箱和螺旋冷冻机到冷却器、涡轮机、阀门和压缩机，而无需客户拆卸和替换工厂硬件。图1说明了现场ATLAS边缘集群、连续云优化和AURA如何在AWS上协同工作。

图1：CrossnoKaye AURA和ATLAS物理AI架构与Amazon Bedrock AgentCore

ATLAS和AURA围绕着三个核心层构建：

首先，该工厂在软件层面从边缘开始定义。在每个设施中，一个配备冗余计算机、电源和交换机的本地 ATLAS 控制面板运行着本地 Kubernetes 集群，该集群采用面向合同的微服务，将 ATLAS 云平台扩展到工厂车间。在云端，ATLAS 开发、验证和版本化设施的基线控制叙事（定义设备状态机、序列、操作边界、联锁和报警规则），这些叙事被下载到边缘设备并在本地针对现有设备和控制器运行。CrossnoKaye 报告每年部署超过 9,000 次控制软件，累计运行超过 1 百万小时，且无任何安全事件。每个边缘设备还充当仅用于外出的信息技术/运营技术（IT/OT）网关，工厂内部不开放任何入站防火墙端口，通过 Amazon VPC Lattice 和 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 将高频遥测数据流传输到 AWS。如果云连接中断，工厂将继续在本地边缘集群上的基线控制叙事中安全运行。

其次，派生的工程信号和闭环优化应用程序在基线控制之上运行，使用相同的共享工厂模型。在云端，CrossnoKaye 的调度系统从 Amazon Simple Storage Service (Amazon S3) 中的版本化 Python 软件包运行两个连续管道，在工厂设置更改时根据可配置的每个实例的节奏和事件驱动触发器运行。合成读取算法计算派生的工程指标，如热流分布、资产健康指数、能源强度和物料平衡偏差，并将它们与物理 I/O 一同写入历史记录。闭环优化应用程序在基线控制层之上运行，结合这些派生的合成读取值与物理模型、模型预测控制（MPC）、强化学习、公用事业费率和天气预报来计算最优设定点计划。 Amazon Simple Queue Service (Amazon SQS) FIFO 队列按设施对每个计划和状态更新进行排序，然后向边缘集群上的本地基线控制叙事发送设定点。CrossnoKaye 报告该边缘集群每天运行 650,000 次闭环控制动作。

第三，AURA 在平台边界内作为微服务运行在 Amazon Elastic Kubernetes Service (Amazon EKS) 上，并具有持久的 Temporal 工作流。在调用者的企业权限下，AURA 代理查询内部 Atlas 数据网关，以在一个统一模型中读取设施或船队的运行状态：上游和下游设备拓扑、部署的基线控制叙事和联锁、物理 I/O 和合成读取值、设定点更改和报警历史、活动优化计划，以及索引在 Amazon Bedrock Knowledge Bases 中的工厂文档。

将设备布局、基础控制逻辑和传感器数据放在同一个系统中，在诊断工厂问题时能带来实质性的差异。在一个同时运行初级、二级和三级破碎机的 aggregates 矿场，在单个班次中，工厂的后半部分停机了两次。从控制室，操作员看到了二级破碎机故障，清除了警报，并重新启动了生产线，但几小时后又停机了。在历史记录时间戳中，二级破碎机在三级破碎机之后几秒钟发生故障，这看起来像是一个破碎机问题。因为 AURA 还读取传送带布局和部署的基础控制互锁，所以它的调查遵循了实际的控制逻辑。三级破碎机下面的一个循环传送带在打滑，这触发了三级破碎机的过载互锁。该互锁的上游安全互锁立即停止了二级破碎机，以防止将下游停止的破碎机埋在石头里。而不是追逐一个幽灵破碎机故障，工厂经理派一名操作员去检查循环传送带，并在几分钟内确认并修复了打滑。

The numbered flows in Figure 1 trace how an AURA investigation runs on AWS:

客户端和边缘入口：工程师和模型上下文协议 (MCP) 客户端通过 AWS WAF 和公共应用负载均衡器连接，API 网关验证企业单点登录 (SSO) 或 MCP 凭证。边缘遥测和控制计划通过 Amazon VPC Lattice（使用 AWS 身份和访问管理 (IAM) 签名版本 4 (SigV4) 进行身份验证）和 Amazon MSK 流动。
上下文检索和受保护推理：AURA 工作流通过 Atlas 数据网关读取工厂状态，并将提示和组织范围的检索增强生成 (RAG) 查询通过模型网关路由到基础模型、Amazon Bedrock Guardrails 和 Amazon Bedrock 知识库。
运行时计算调度：对于统计、热力学或多数据集数学，工作流通过 gRPC 将输入数据集流式传输到 AURA 的内部 Sandbox Orchestrator 服务。
会话协调和实时流：在交互式会话中，Sandbox Orchestrator 跟踪活动的 Sandbox 会话 ID，并通过 Amazon ElastiCache for Valkey 流式传输实时进度。
隔离的 Python 执行：Sandbox Orchestrator 使用 AWS SDK 调用 Amazon Bedrock AgentCore 运行的端点，Amazon Bedrock AgentCore 的功能，在隔离的代码解释器微 VM 中编排数据集并运行模型编写的 Python。
工件存储和 Brief 交付：验证的 Apache Parquet 输出、图表和引用的 Brief 保存到 Amazon S3，通过 AWS PrivateLink，Amazon Simple Email Service (Amazon SES) 向工厂团队交付自动 Brief。

演练

AURA 在 Amazon Bedrock 上组合基础模型（有关 AWS 区域的模型可用性，请参阅 Amazon Bedrock 用户指南中的按 AWS 区域支持的模式）与 Amazon Bedrock AgentCore 中的隔离 Python 沙盒，Amazon Bedrock AgentCore 的功能，跨三种操作模式：

聊天：交互式、多轮工程对话，涵盖单个单元、工艺线或多站点投资组合（单次对话中最多 200 个设施）。
任务：可重复、参数化的调查，与不可变版本快照绑定，以生成具有引用证据表格和图表的结构化技术简报。
例程：由计划、传感器阈值、变化率窗口、警报或设备模式转换触发的自动后台监视器。

以下部分探讨了这些工作流背后的四个架构决策。

温暖的对话沙盒与干净的单次运行管道比较

交互式调试和自动工厂报告具有不同的状态要求：

在一个交互式聊天中，工程师逐步探索假设：加载 94 个设施 24 小时的关键警报，过滤掉一个地点的聊天式液位传感器，并将压缩机跳闸与环境湿球温度相关联。在每次对话中启动冷沙盒会清除内存表并增加延迟。对于聊天，沙盒协调器将一个温暖的 Amazon Bedrock AgentCore 会话绑定到 Amazon ElastiCache for Valkey 中的对话，具有一个 15 分钟的滑动生存时间 (TTL)，如果工程师在空闲超时后返回，则透明地预配一个替换会话。
在计划的任务或凌晨 2:00 的例程中，可重复性是首要的。每次运行都必须从一个干净的环境中开始，没有任何来自先前运行的遗留状态。对于任务和例程，沙盒协调器为每次运行预配一个新鲜的单次使用的 AgentCore 微 VM，并在计算完成后立即停止会话 StopCodeInterpreterSession，防止跨运行污染和空闲沙盒费用。

这种暖会话设计使得跨整个机队的故障排除在单个对话中成为可能。当运营总监要求 AURA 审查 94 个设施过去 24 小时的所有关键警报并确定主要机械风险时，代理从 Atlas Data 网关加载机队警报摘要到它的 AgentCore 沙盒中，并按设施、规则和到达间隔时间对激活进行分组。而不是按原始警报计数对站点进行排名，Python 分析将一个有 103 次关键激活来自两个重复的储罐液位规则的工厂与一个在彼此一秒内跨越氨检测、蒸发器故障和热气阀门激活的 58 次激活的工厂区分开来，直接指向具有级联设备故障的设施，为安全和维护团队。

可验证计算而不是未经验证的模型数学

当工程师要求 AURA 分析一个过程趋势或审计班次性能时，响应中的数字必须是精确的。在 AURA 的发展初期，团队发现让模型编写自由形式的 Python 脚本，将 JSON 或文本摘要打印到标准输出太脆弱了：模型偶尔会误命名列，丢弃部分时间窗口，或以破坏下游图表渲染的方式格式化输出。

为了使运行时计算可验证，AURA 对每个 Amazon Bedrock AgentCore 运行强制执行严格的数据合同：

upfront 合同验证和多源暂存：在分配沙盒会话之前，沙盒协调器验证输入合同并将多达 50 个数据集暂存到微 VM 工作区，结合物理 I/O、派生的合成读数、设置日志、警报历史记录和公用事业费率表。
沙盒中的 DataFrame 方案验证：服务应用程序在模型的 Python 脚本中附加了一个确定性验证框架。在沙盒中，该框架验证每个声明的输出表是否作为 pandas.DataFrame 存在于内存中，并具有所有必需的列和类型，并将验证后的表直接序列化为二进制 Apache Parquet 文件。
自动自我纠正：如果脚本引发 Python 异常或遗漏必需列，未经验证的数字不会到达用户。Temporal 工作流捕获跟踪回溯和方案不匹配作为结构化重试提示，以便代理修复其 Python 逻辑并在发布任何结论之前在一个干净的沙盒中重新运行计算。

通过 Amazon SES 自动执行夜间轮班例程和引用简报

工厂工程师无法全天候监控分布在 100 个设施上的仪表板，而许多设备问题在夜间轮班开始时都是缓慢的漂移。AURA 例程在后台运行，监控特定的工艺条件（例如制冷阶段吸力压力漂移、批量干燥曲线落后于规范或非计划的手动设定点覆盖），并在触发时自动启动调查。

一个工业冷却器厂的夜间轮班案例展示了端到端的工作方式：

自动检测和沙盒中的根本原因分析（02:00–02:03 AM）：凌晨 2:00，例程检测到低级吸力压力漂移并以其附着的任务在只读模式下启动。在 Amazon Bedrock AgentCore 沙盒中，代理将冷凝器接近温度与低级吸力压力在物理和合成读数中进行关联，排除传感器漂移和低制冷剂充电，并隔离冷凝器侧污垢。
确定性引用验证（02:04 AM）：在发布简报之前，AURA 解析每个内联引用，并验证每个声明是否链接到 Amazon S3 中的保存遥测窗口、变更记录或沙盒输出工件。不会自动进行控制更改。
通过 Amazon SES 发送简报和一键聊天交接：在触发后的四分钟内，AURA 通过 Amazon SES 向工厂工程团队发送格式化的 HTML 简报电子邮件，其中包含诊断、引用的信号轨迹和一个“在 AURA 中调查”按钮。当首席工程师在晨会之前选择该按钮时，AURA 验证工程师的实时设施权限，并打开一个预加载了简报证据的交互式聊天，以便团队可以提出后续问题或立即发布工作订单。

纵深工业安全

在一个工业厂中，运营安全不能依赖于 LLM 在提示中遵循指令。因为 ATLAS 和 AURA 从云到工厂地面的边缘 Kubernetes 集群共享同一平台，CrossnoKaye 对 AI 和优化工作负载在四个独立层上执行严格边界：

Amazon Bedrock 护栏和可验证的来源（观察）：通过 AURA 的模型网关路由的每个提示和完成都会由 Amazon Bedrock 护栏评估，以执行内容、主题和安全策略。知识库检索按组织隔离，并且每个简报都需要经过验证的内联引用，注明分析了哪些时间窗口以及任何传感器数据不可用的时期。
Air-gapped只读沙盒和人工批准的建议（建议）：Amazon Bedrock AgentCore代码解释器微VM在隔离的、AWS管理的环境中运行，没有网络路由、凭证或API路径连接到工厂设备。自动例程严格以只读模式运行。当工程师使用交互式会话建议设置更改时，平台要求在操作员的法人身份下明确人工批准，并在之后通过工厂遥测验证物理结果。
不可绕过的确定性边缘1级基本控制（有界和基本控制）：云优化应用程序不直接驱动现场硬件。它们在平台的基本控制层上运行，通过在工程批准的包内调度设定点计划。在工厂车间，边缘Kubernetes集群实时本地运行下载的基本控制叙述，执行确定性状态机保护、变化率限制、操作边界和设备互锁，云服务、优化应用程序或AI代理都无法绕过。
独立的物理硬件保护：在ATLAS软件定义控制器之下，工厂的物理机械和现场接线执行独立的硬接线保护层，包括安全继电器、本地可编程跳闸和机械泄压及过温装置。

结果和经验教训

在食品加工、工业制冷、骨料和采矿以及制造场所，CrossnoKaye报告说，结合软件定义的边缘控制、持续云优化和AURA将批量干燥时间标准差降低了34%（产品在目标产量规范内完成率提高了6%），并在采石场作业中确定了每年超过50,000吨的可回收生产差距。随着超过5,000个AI代理监控客户设施中超过10,000个工厂资产（包括ATLAS车队中超过13,000个受控设备和设备单元），以前需要花费数小时导出历史记录CSV文件、交叉引用PLC梯形逻辑和构建电子表格的调查现在可以在不到四分钟内完成，并通过Amazon SES在晨会之前提供引用的技术简报。

在跨工业设施建设和运营AURA过程中，有三个经验教训脱颖而出：

在添加AI之前统一工厂模型和控制逻辑：当代理能够在一个一致的模型中读取过程拓扑、部署的基本控制叙述和互锁、设置更改历史记录和优化器状态时，它才能诊断真实的物理根本原因，例如区分下游循环皮带打滑和二级破碎机故障，而不是将六个断开的工厂系统集成在一起。
在操作员的日常工作流程中提供价值，而不是作为一个单独的工具去使用：工厂团队正忙着运行设备。如果AI助手是一个单独的目的地，工程师必须从一个空白提示开始，日常采用就会停滞。将AURA嵌入到日常交接班节奏中（其中后台例程在夜间捕获异常，在Amazon Bedrock AgentCore中运行Python分析，并向工程师的收件箱交付引用的简报，并单击手柄进入预加载的聊天），这意味着操作员在他们的正常工作流程中看到价值，而无需去使用单独的产品。
在代码中而非提示中强制执行数据、覆盖范围和安全合同：在一个工厂中，缺少一小时传感器数据与一小时无事件的数据并不相同，而未经验证的计算可能会让维护团队前往错误的机器。在工具合同中明确数据覆盖范围的缺失，在 AgentCore 沙盒内验证 pandas.DataFrame 模式，在边缘 Kubernetes 集群上强制执行确定性基础控制界限，可以在错误到达操作员或设备之前捕获概率模型错误。

结论

重工业中可靠的物理人工智能需要将模型基于工厂的实际设备拓扑和控制逻辑，并通过对每一个定量声明提供可验证的 Python 计算来支持。与 Amazon Bedrock Guardrails 和 Amazon Bedrock AgentCore 中的隔离 Python 沙盒一起，ATLAS 和 AURA 允许代理对实时设施本体、基础控制叙述、设置历史、物理 I/O、优化状态和合成读数进行推理，通过 Amazon SES 提供可检查的工程答案和技术简报，同时确保确定性安全控制牢牢地保持在工厂现场。

欲了解更多关于构建具有隔离代码执行代理的信息，请参阅 Amazon Bedrock AgentCore 开发者指南，或访问 CrossnoKaye 了解物理人工智能如何改变重工业。

关于作者

Raphael Simon

Raphael 是 CrossnoKaye 的首席技术官，他领导 ATLAS 软件定义自动化平台和 AURA 智能系统的技术愿景和架构。他是开源 Goa 和 Goa-AI 设计优先框架的创始人和主要贡献者，用于在 Go 中构建微服务和代理系统。此前，他担任 RightScale 的首席技术官，并在 Flexera 担任过高级工程领导职位。

Anu Jayanthi

Anu 是 AWS 的一名高级解决方案架构师。她与初创公司创始人及工程团队合作，将大胆想法转化为可生产的系统，从生成式人工智能应用到采取实际行动的代理工作流。她喜欢与客户一起学习，帮助他们找到在 AWS 上的正确路径，并在他们成长的过程中提供支持。