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 托管的 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 围绕三个核心层构建：

首先，工厂从边缘层开始就在软件中定义。在每个设施中，一台本地部署的 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 包运行两条持续流水线，按可配置的每实例节奏和工厂设置变化时的事件驱动触发器运行。合成读数算法计算派生的工程指标，例如热流分布、资产健康指数、能量强度和物料平衡偏差，并将它们与物理 I/O 一起写回历史数据库。闭环优化应用在基础控制层之上运行，将这些派生的合成读数与物理模型、模型预测控制（MPC）、强化学习、公用事业电价和天气预报相结合，计算出最优设定点调度。Amazon Simple Queue Service (Amazon SQS) FIFO 队列在将设定点分派到边缘集群上的本地基础控制叙述之前，按设施对每个调度和状态更新进行排序，CrossnoKaye 报告每天运行 650,000 次闭环控制操作。

第三，AURA 在平台边界内以微服务和持久化 Temporal 工作流的形式运行在 Amazon Elastic Kubernetes Service (Amazon EKS) 上。在调用者的企业权限下，AURA 代理查询内部 Atlas Data 网关，以单一一致的模型读取设施或机队的运行状态：上下游设备拓扑、已部署的基础控制叙述和联锁、物理 I/O 和合成读数、设置变更和报警历史、活动优化调度，以及在 Amazon Bedrock Knowledge Bases 中索引的工厂文档。

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

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

客户端与边缘接入：工程师和模型上下文协议（MCP）客户端通过 AWS WAF 和公共 Application Load Balancer 连接，API 网关在此验证企业单点登录（SSO）或 MCP 凭证。边缘遥测和控制计划通过 Amazon VPC Lattice（使用 AWS Identity and Access Management（IAM）Signature Version 4（SigV4）进行身份验证）和 Amazon MSK 传输。
上下文检索与受保护推理：AURA 工作流通过 Atlas Data 网关读取工厂状态，并将提示和组织范围的检索增强生成（RAG）查询通过 Model Gateway 路由到基础模型、Amazon Bedrock Guardrails 和 Amazon Bedrock Knowledge Bases。
运行时计算调度：对于统计、热力学或多数据集数学计算，工作流通过 gRPC 将输入数据集流式传输到 AURA 内部的 Sandbox Orchestrator 服务。
会话协调与实时流式传输：在交互式会话中，Sandbox Orchestrator 跟踪活动沙箱会话 ID，并通过用于 Valkey 的 Amazon ElastiCache 流式传输实时进度。
隔离的 Python 执行：Sandbox Orchestrator 使用 AWS SDK 调用 Amazon Bedrock AgentCore 运行时（Amazon Bedrock AgentCore 的一项能力）的端点，在隔离的代码解释器微虚拟机中暂存数据集并运行模型编写的 Python。
工件存储与 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 沙箱相结合，支持三种运行模式：

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

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

热对话沙箱与干净的单次运行流水线对比

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

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

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

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

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

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

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

通过 Amazon SES 实现自动化夜班 Routines 和带引用的 Briefs

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

一个工业冷水机组的夜班捕获案例展示了其端到端的工作方式：

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

纵深防御工业安全

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

Amazon Bedrock Guardrails 和可验证来源（Observe）：通过 AURA 的 Model Gateway 路由的每个提示和补全都由 Amazon Bedrock Guardrails 评估，以执行内容、主题和安全策略。Knowledge Base 检索按组织隔离，每个 Brief 都需要经过验证的内联引用，注明分析了哪些时间窗口以及传感器数据不可用的任何时段。
气隙隔离的只读沙箱与人工审批提案（Propose）：Amazon Bedrock AgentCore Code Interpreter 微虚拟机运行在由 AWS 管理的隔离环境中，没有网络路由、凭证或 API 路径可触及工厂设备。自动化例程（Routines）严格以只读模式运行。当工程师通过交互式会话提出设置变更时，平台要求以操作员的公司身份进行明确的人工审批，并在事后通过工厂遥测验证物理结果。
边缘侧不可绕过的确定性一级基础控制（有界与基础控制）：云优化应用不直接驱动现场硬件。它们运行在平台的基础控制层之上，在工程批准的包络范围内下发设定值调度。在工厂现场，边缘 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 分析，并将带有引用的简报发送到工程师的收件箱，一键交接至预加载的聊天），意味着操作员在正常 routine 中就能看到价值，而无需去使用单独的产品。
在代码中而非提示词中强制执行数据、覆盖范围和安全契约：在工厂中，缺失一小时的传感器数据与一小时无事件并不相同，未经核验的计算可能把维护人员派往错误的机器。在工具契约中明确数据覆盖缺口，在 AgentCore 沙箱内提取二进制 Apache Parquet 输出之前验证 pandas.DataFrame schema，并在边缘 Kubernetes 集群上强制执行确定性的基础控制边界，从而在概率模型错误到达操作员或设备之前将其捕获。

结论

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

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

关于作者

Raphael Simon

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

Anu Jayanthi

Anu 是 AWS 的高级解决方案架构师。她与初创公司创始人和工程团队合作，将大胆的想法转化为可投入生产的系统，从生成式 AI 应用到能够采取现实行动的智能体工作流。她乐于与客户共同学习，帮助他们在 AWS 上成长过程中找到正确的路径。