CrossnoKaye用Bedrock AgentCore在隔离沙箱里跑工业AI计算
AWS博客介绍了CrossnoKaye的ATLAS控制平台与AURA智能体：AI读取工厂设备拓扑、控制逻辑与传感器数据，数值计算交由AgentCore代码解释器的隔离微虚拟机执行；文中效果数据均为CrossnoKaye自行报告。
AI解读：AURA可读取同一平台内的设备上下游拓扑、基础控制叙事与联锁、物理I/O和合成读数、设定变更与报警历史，并在Amazon Bedrock AgentCore的隔离代码解释器微虚拟机中运行模型编写的Python完成统计和物理平衡计算。
CrossnoKaye报告其ATLAS覆盖 100 多个工业设施、13,000 个受控资产，存储超 22 万亿个机器数据点，每天新增超 500 亿条读数，运行 1,000 多个先进过程控制应用；这些应用使产量提升 11%–17%、设施总能源成本平均降低 21%。
AURA分三种模式：Chats使用带 15 分钟滑动TTL的预热沙箱会话；Tasks与Routines每次运行分配一次性新微虚拟机，结束后调用StopCodeInterpreterSession，避免跨次污染和空闲计费。
为让计算结果可核验，AURA在沙箱内追加确定性校验程序，要求输出表为具备指定列和类型的pandas.DataFrame，并序列化为Apache Parquet；脚本报错或缺列时捕获traceback作为结构化重试提示，在干净沙箱中重跑。
安全边界分四层：Bedrock Guardrails与引用校验、只读且无网络路由的沙箱与人工作业审批、边缘端不可绕过的确定性基础控制、以及独立于软件的硬连线物理保护。自动Routines只读运行，不会自动改变控制。
文中采石场案例显示，AURA结合输送带布局与联锁逻辑，把二次破碎机故障追溯到三次破碎机下方循环皮带打滑触发联锁，而非破碎机本身；这是一个个别案例，不能据此推断普遍效果。
AWS机器学习博客发文介绍CrossnoKaye如何用Amazon Bedrock AgentCore把AI推理接入重工业现场控制。文章作者为Raphael Simon，内容基于CrossnoKaye的架构说明与运行经验。
核心做法是：CrossnoKaye的ATLAS平台统一管理设施模型、基础控制软件、历史数据库和优化应用，AURA智能体因此能在同一安全边界内读取工厂运行状态；涉及统计或物理平衡的数值问题，交由AgentCore代码解释器在隔离微虚拟机中运行Python计算，而非让大模型直接口算。
AURA在哪些模式下运行
AURA运行在Amazon EKS上，以微服务和Temporal持久化工作流实现，按调用者的企业权限查询内部Atlas Data网关。它有三种运行模式：Chats为多轮交互式工程对话，单轮可跨最多 200 个设施；Tasks是绑定不可变版本快照的可重复参数化调查，产出带引用证据表和图表的结构化Brief；Routines由时间表、传感器阈值、变化率窗口、报警或设备模式切换触发，在后台自动调查。
两种模式对状态的要求不同：Chats将一个预热AgentCore会话绑定到对话，用Amazon ElastiCache for Valkey记录会话ID，TTL为 15 分钟滑动窗口，超时后重新分配；Tasks和Routines每次运行都新建一次性微虚拟机，计算完成后立即停止会话，避免上一次运行的状态污染下一次，也避免空闲沙箱计费。
- Chats：交互式调查，预热会话降低延迟
- Tasks：参数化、可重复，绑定版本快照
- Routines：后台自动触发，只读模式运行
数值结果如何变得可核验
CrossnoKaye团队在开发早期发现，让模型自由编写Python并打印JSON或文本摘要过于脆弱：模型偶尔会写错列名、丢掉部分时间窗口，或输出格式破坏下游图表渲染。
为此，AURA在每次AgentCore运行外加强制数据契约：分配沙箱前校验输入契约，最多暂存 50 个数据集到微虚拟机工作区；在沙箱内追加确定性校验程序，确认每张声明的输出表都以pandas.DataFrame存在于内存且列与类型齐全，并直接序列化为二进制Apache Parquet；若脚本抛异常或缺列，Temporal工作流捕获traceback和模式不匹配，作为结构化重试提示让智能体修正后在新沙箱中重跑，未经验证的数字不会送达用户。
- 分配前校验输入契约，最多暂存 50 个数据集
- 沙箱内校验输出表结构与类型，序列化为Parquet
- 失败则结构化重试，不发布未验证结论
安全边界与人的位置
文章强调工业安全不能依赖大模型遵守提示词。AURA与ATLAS共用从云到边缘Kubernetes集群的平台，因此CrossnoKaye在四层设置边界：所有经过Model Gateway的提示与补全都由Bedrock Guardrails按内容、主题和安全策略评估，知识库检索按组织隔离，每份Brief要求可验证的行内引用；AgentCore代码解释器微虚拟机无网络路由、无凭据、无通往工厂设备的API路径，自动Routines只读，交互式会话中的设定变更提案须由人员在企业身份下明确批准，之后再用现场遥测核验实际结果；云优化应用不直接驱动现场硬件，只能在工程批准的包络内下发设定点计划，边缘集群本地实时执行状态机保护、变化率限制、运行边界和联锁，云服务、优化应用和AI智能体都无法绕过；最底层依靠安全继电器、本地可编程跳闸、机械泄压和超温装置等硬连线保护。
- Guardrails与引用校验：观察层
- 只读无网络沙箱与人工作业审批：提议层
- 边缘确定性控制不可被云端或AI绕过
- 独立硬连线物理保护作为最后一层
效果数据的归属与范围
文章给出的运营数字均标注为CrossnoKaye报告：100 多个工业设施、13,000 个受控资产、超 22 万亿个机器数据点、每天超 500 亿条新读数、1,000 多个实时先进过程控制应用；这些应用使产量提升 11%–17%，设施总能源成本平均下降 21%；每年 9,000 多次控制软件部署、超 100 万运行小时且零安全事故；每天 65 万次闭环控制动作。
这些是公司自报数据，文章没有提供第三方审计或对照实验细节。采石场故障追溯和凌晨 2 点冷水机组Routine发现冷凝器侧结垢，均为单个案例，说明的是该架构在该场景下能做什么，不能据此推断普遍节能比例、岗位影响或竞争胜负。
- 产量提升 11%–17%、能源成本降 21% 为CrossnoKaye自报
- 运行规模数字同样来自公司报告
- 个案演示不构成普遍效果证据