人工智能

CrossnoKaye 如何借助 Amazon Bedrock AgentCore 为物理 AI 奠定基础

工业运营所面临的 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 托管的微 VM 沙箱中编写并运行 Python 工作负载，同时配合 Amazon Bedrock Guardrails 和本地边缘安全控制。本文介绍 CrossnoKaye 如何在 AWS 上架构 ATLAS 和 AURA，AURA 如何在交互式聊天、可重复任务和自动化例程中使用 Amazon Bedrock AgentCore，以及团队在生产环境中运行物理 AI 的经验教训。

解决方案概述

ATLAS 通过现有的 PLC 和 DCS 基础设施控制工业过程，从窑炉、破碎机、干燥室、烤箱和螺旋冷冻机，到冷水机组、涡轮机、阀门和压缩机，无需客户拆除并更换工厂硬件。图 1 展示了本地 ATLAS 边缘集群、持续云优化和 AURA 如何在 AWS 上协同工作。

CrossnoKaye ATLAS edge clusters stream plant telemetry to AWS, where cloud optimization and AURA agents run analysis in Amazon Bedrock AgentCore

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

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

首先，工厂从边缘开始就在软件中定义。在每个设施中，一个本地 ATLAS 控制面板配备冗余计算机、电源和网络交换机（以便在更换故障硬件组件时本地控制不中断），运行本地 Kubernetes 集群，该集群使用契约优先的微服务，将 AWS 上的 ATLAS 云平台扩展到工厂车间。在云中，ATLAS 编写、验证并版本化设施的基础控制叙述（定义设备状态机、序列、运行边界、联锁和报警规则），这些内容被下载到边缘设备，并针对现有设备和控制器在本地运行。CrossnoKaye 报告称，每年超过 9,000 次控制软件部署和超过 100 万运行小时，且零安全事故。每个边缘设备还充当仅出站的 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 Data 网关，以单一一致的模型读取设施或设备群的运行状态：上下游设备拓扑、已部署的基础控制叙述与联锁、物理 I/O 与合成读数、设定值变更与报警历史、活动优化计划，以及索引在 Amazon Bedrock Knowledge Bases.

中的工厂文档。将设备布局、基础控制逻辑和传感器数据置于同一系统中，在诊断工厂问题时会产生切实的差异。在一家运行初级、二级和三级岩石破碎机的骨料采石场，工厂后段在同一个班次内两次跳闸。从控制室看，操作员看到二级破碎机故障，清除报警并重启生产线，结果几小时后它再次跳闸。仅从历史数据库时间戳看，二级破碎机在三级破碎机之后几秒发生故障，这使它看起来像是破碎机问题。由于 AURA 还读取输送机布局和已部署的基础控制联锁，其调查遵循了实际的控制逻辑。三级破碎机下方的一条循环皮带正在打滑，触发了三级破碎机的过载联锁。该联锁的上游安全联锁立即停止二级破碎机，以防止将已停机的下游破碎机埋入石料中。工厂经理没有去追查一个并不存在的破碎机故障，而是派操作员检查循环皮带，在几分钟内确认并修复了打滑问题。

图 1 中的编号流程展示了 AURA 调查在 AWS 上的运行方式：

  1. 客户端与边缘入口：工程师和模型上下文协议（MCP）客户端通过 AWS WAF 和公共 Application Load Balancer 连接，API 网关在此验证企业单点登录（SSO）或 MCP 凭证。边缘遥测和控制计划通过 Amazon VPC Lattice（使用 AWS Identity and Access Management（IAM）Signature Version 4（SigV4）进行身份验证）和 Amazon MSK 传输。
  2. 上下文检索与受控推理：AURA 工作流通过 Atlas Data 网关读取工厂状态，并将提示词和组织范围的检索增强生成（RAG）查询通过 Model Gateway 路由到基础模型、Amazon Bedrock Guardrails 和 Amazon Bedrock Knowledge Bases。
  3. 运行时计算调度：对于统计、热力学或多数据集数学计算，工作流通过 gRPC 将输入数据集流式传输到 AURA 的内部 Sandbox Orchestrator 服务。
  4. 会话协调与实时流式传输：在交互式会话中，Sandbox Orchestrator 跟踪活动的沙箱会话 ID，并通过 Amazon ElastiCache for Valkey 流式传输实时进度。
  5. 隔离的 Python 执行：Sandbox Orchestrator 使用 AWS SDK 调用 Amazon Bedrock AgentCore 运行时的端点（这是 Amazon Bedrock AgentCore 的一项能力），在隔离的代码解释器微 VM 中暂存数据集并运行模型编写的 Python。
  6. 工件存储与 Brief 交付：经验证的 Apache Parquet 输出、图表和带引用的 Brief 通过 AWS PrivateLink保存到 Amazon S3，并由 Amazon Simple Email Service（Amazon SES） 将自动化 Brief 交付给工厂团队。

演练

AURA 将 Amazon Bedrock 上的基础模型（各 AWS 区域的模型可用性请参阅 Amazon Bedrock 用户指南中的 Supported models by AWS Region ）与 Amazon Bedrock AgentCore Code Interpreter（Amazon Bedrock AgentCore 的一项能力）中的隔离 Python 沙箱相结合，支持三种运行模式：

  • Chats：交互式多轮工程对话，可跨越单个机组、一条工艺线或多站点组合（单轮最多 200 个设施）。
  • Tasks：可重复的参数化调查，绑定到不可变的版本快照，生成带有引用证据表和图表的结构化技术 Brief。
  • Routines：由计划、传感器阈值、变化率窗口、报警或设备模式转换触发的自动化后台监视器。

以下各节探讨这些工作流背后的四项架构决策。

热对话沙箱与干净的单次运行管道

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

  • 在交互式 Chat 中，工程师逐步探索假设：加载 94 个设施 24 小时内的关键报警，过滤掉某个站点中反复抖动的储罐液位传感器，并将压缩机跳闸与环境湿球温度相关联。每一轮都启动冷沙箱会清除内存中的表并增加延迟。对于 Chats，Sandbox Orchestrator 将一个热 Amazon Bedrock AgentCore 会话绑定到 Amazon ElastiCache for Valkey 中的对话，并设置 15 分钟的滑动生存时间（TTL），如果工程师在空闲超时过期后返回，则透明地配置一个替代会话。
  • 在计划 Task 或凌晨 2:00 的 Routine 中，可复现性优先。每次运行都必须从干净环境开始，不残留先前运行的状态。对于 Tasks 和 Routines，Sandbox Orchestrator 每次运行都会配置一个全新的单次使用 AgentCore 微 VM，并在计算完成后立即用 StopCodeInterpreterSession 停止会话，从而防止跨运行污染和空闲沙箱费用。

这种热会话设计使跨设施范围的排查在单次对话中即可实际完成。当运营总监要求 AURA 审查过去 24 小时内 94 个设施的所有关键报警并识别主要机械风险时，该智能体会从 Atlas Data 网关将设施报警摘要加载到其 AgentCore 沙箱中，并按设施、规则和到达间隔时间对激活事件进行分组。Python 分析并不按原始报警数量对站点排序，而是将一个工厂（其 103 次关键激活来自两条重复触发的储罐液位规则）与另一个工厂（其 58 次激活在一秒内先后涉及氨检测、蒸发器故障和热气阀）区分开来，从而将安全和维护团队直接指向存在级联设备故障的设施。

可验证的计算，而非未经核验的模型运算

当工程师要求 AURA 分析工艺趋势或审计班次绩效时，响应中的数字必须精确。在 AURA 开发的早期阶段，团队发现，让模型编写自由形式的 Python 脚本、将 JSON 或文本摘要打印到标准输出，这种做法过于脆弱：模型偶尔会写错列名、丢弃部分时间窗口，或以破坏下游图表渲染的方式格式化输出。

为使运行时计算可验证，AURA 对每次 Amazon Bedrock AgentCore 运行都强制执行严格的数据契约：

  1. 预先契约验证与多源暂存：在分配沙箱会话之前，Sandbox Orchestrator 会验证输入契约，并将最多 50 个数据集暂存到 microVM 工作区，这些数据集结合了物理 I/O、派生的合成读数、设定日志、报警历史和公用事业费率表。
  2. 沙箱内 DataFrame 模式验证：该服务并不解析来自标准输出的自由形式文本，而是向模型的 Python 脚本追加一个确定性的验证框架。在沙箱内，该框架会验证每个声明的输出表是否作为 pandas.DataFrame 以内存中的形式存在，并具有所有必需的列和类型，然后将验证过的表直接序列化为二进制 Apache Parquet 文件。
  3. 自动自我纠正：如果脚本引发 Python 异常或遗漏必需列，则不会有任何未经核验的数字到达用户。Temporal 工作流会将 traceback 和模式不匹配捕获为结构化重试提示，以便智能体修正其 Python 逻辑，并在发布任何结论之前，在干净的沙箱中重新运行计算。

通过 Amazon SES 发送自动化夜班 Routine 和引用的 Brief

工厂工程师无法全天候监控 100 个设施的仪表盘，而许多设备问题最初表现为夜班期间的缓慢漂移。AURA Routines 在后台运行，监视特定的工艺条件（例如制冷级的吸气压力漂移、批次干燥曲线落后于规格，或计划外的手动设定值覆盖），并在触发时自动启动调查。

一个工业冷水机组的夜班捕获案例展示了这一流程如何端到端运作：

  1. 自动检测与沙箱化根因分析（凌晨 02:00–02:03）：凌晨 2:00，一个 Routine 检测到低压级吸气压力漂移，并以只读模式启动其固定的 Task。在 Amazon Bedrock AgentCore 沙箱内，智能体将冷凝器逼近温度与低压级吸气压力在物理读数和合成读数上进行关联分析，排除传感器漂移和制冷剂充注不足，并隔离出冷凝器侧污垢。
  2. 确定性引用验证（凌晨 02:04）：在发布 Brief 之前，AURA 会解析每一条内联引用，并验证每一项主张都链接到 Amazon S3 中保存的遥测窗口、设定变更记录或沙箱输出产物。不会自动进行任何控制变更。
  3. 通过 Amazon SES 交付 Brief 并一键移交至 Chat：在触发后四分钟内，AURA 通过 Amazon SES 向工厂工程团队发送格式化的 HTML Brief 电子邮件，其中包含诊断结果、引用的信号轨迹以及一个“在 AURA 中调查”按钮。当首席工程师在早班交接会之前选择该按钮时，AURA 会验证该工程师的实时设施权限，并打开一个预加载了 Brief 证据的交互式 Chat，以便团队可以提出后续问题或立即发出工单。

纵深防御的工业安全

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

  1. Amazon Bedrock Guardrails 与可验证溯源（Observe）：所有经由 AURA 的 Model Gateway 路由的提示和补全都由 Amazon Bedrock Guardrails 评估，以强制执行内容、主题和安全策略。知识库检索按组织隔离，每份 Brief 都要求经过验证的内联引用，并注明分析了哪些时间窗口以及传感器数据不可用的任何时段。
  2. 气隙只读沙箱与人工批准的提案（Propose）：Amazon Bedrock AgentCore Code Interpreter 微虚拟机在隔离的 AWS 托管环境中运行，没有通往工厂设备的网络路由、凭证或 API 路径。自动化 Routine 严格以只读模式运行。当工程师使用交互式会话提出设定值变更时，平台要求以操作员的企业身份进行明确的人工批准，并在之后通过工厂遥测验证物理结果。
  3. 边缘侧不可绕过的确定性 Level 1 基础控制（Bounded and Base Control）：云优化应用不直接驱动现场硬件。它们运行在平台的基础控制层之上，在工程批准的包络范围内下发设定值调度。在工厂现场，边缘 Kubernetes 集群实时本地运行下载的基础控制叙述，强制执行确定性状态机防护、变化率钳制、运行边界和设备联锁，这些无法被云服务、优化应用或 AI 智能体绕过。
  4. 独立的物理硬件保护：在 ATLAS 软件定义控制器之下，工厂的物理机械和现场布线强制执行独立的硬接线保护层，包括安全继电器、本地可编程跳闸以及机械压力释放和过温装置。

结果与经验教训

CrossnoKaye 报告称，在食品加工、工业制冷、骨料与采矿以及制造场所，将软件定义边缘控制、持续云优化和 AURA 相结合，使批次干燥时间标准差降低了 34%（另有 6% 的产品在目标产量规格内完成），并在采石场运营中识别出每年超过 50,000 吨的可回收产能缺口。凭借超过 5,000 个 AI 智能体监控客户设施中超过 10,000 项工厂资产（包括 ATLAS 机群中超过 13,000 台受控设备和设备单元），过去需要数小时导出历史数据库 CSV、交叉比对 PLC 梯形逻辑并构建电子表格的调查，现在可在四分钟内完成，并在早班交接会议之前通过 Amazon SES 交付带引用的技术 Brief。

在跨工业设施构建和运营 AURA 的过程中，有三条经验尤为突出：

  1. 在引入 AI 之前统一工厂模型和控制逻辑：只有当智能体能够在一个一致的模型中读取过程拓扑、已部署的基础控制叙述和联锁、设定值变更历史以及优化器状态，而不是拼凑六个互不连接的工厂系统时，它才能诊断真实的物理根本原因，例如区分下游再循环皮带打滑与二级破碎机故障。
  2. 将价值嵌入运营商的日常工作流，而不是作为一个需要单独去使用的工具：工厂团队忙于运行设备。如果 AI 助手是一个独立的目的地，工程师必须从空白提示开始，日常采用就会停滞。将 AURA 嵌入每日轮班节奏（后台例程在夜间捕捉异常，在 Amazon Bedrock AgentCore 中运行 Python 分析，并将带引用的简报投递到工程师的收件箱，一键交接进入预加载的聊天），意味着操作员在正常日常工作中就能看到价值，而无需去使用一个单独的产品。
  3. 在代码中而非提示词中强制执行数据、覆盖范围和安全契约：在工厂中，缺失一小时的传感器数据并不等同于一小时没有事件，而未经验证的计算可能会把维护人员派往错误的机器。在工具契约中明确数据覆盖缺口，并在从 AgentCore 沙箱中提取二进制 Apache Parquet 输出之前验证 pandas.DataFrame 模式，并在边缘 Kubernetes 集群上强制执行确定性的基础控制边界，从而在概率模型错误到达操作员或设备之前将其捕获。

结论

要在重工业中实现可靠的物理 AI，需要将模型建立在工厂实际的设备拓扑和控制逻辑之上，并用可验证的 Python 计算为每一项定量结论提供支撑。结合 Amazon Bedrock Guardrails 与 Amazon Bedrock AgentCore 中隔离的 Python 沙箱，ATLAS 和 AURA 使智能体能够基于实时设施本体、基础控制叙述、设定值历史、物理 I/O、优化状态和合成读数进行推理，通过 Amazon SES 交付可核查的工程答案和带引用的技术 Brief，同时将确定性的安全控制牢牢保留在工厂现场。

要详细了解如何构建具备隔离代码执行能力的智能体，请参阅 Amazon Bedrock AgentCore 开发人员指南 或访问 CrossnoKaye 了解物理 AI 如何正在改变重工业。

关于作者