工业自动化公司 CrossnoKaye：让大模型规划调查，让隔离沙箱算出可验证的数字

在工业现场，一个错误的数字可能让维修团队跑错机器。CrossnoKaye 在其 AWS 技术博客中描述了这个具体风险：大语言模型擅长理解工程语境、规划调查步骤，但无法对数百万传感器读数可靠地执行统计计算或物理平衡。如果让模型直接'算'出结果，它可能误命名一列数据、截掉一段时间窗口，或者以破坏下游图表渲染的格式输出。

CrossnoKaye 的解法是把'想'和'算'彻底分开。其 agentic 系统 AURA 让大模型负责规划调查路径——比如'先加载过去 24 小时 94 个工厂的关键报警，再按设施、规则和间隔时间分组，最后区分重复触发的单一规则和多种设备同时故障'——但所有实际数字计算都在 Amazon Bedrock AgentCore 的隔离 Python 微虚拟机中执行。模型写代码，沙箱跑代码，验证器检查输出。

验证机制分三步。第一，在分配沙箱之前，Sandbox Orchestrator 服务验证输入契约，最多将 50 个数据集（物理 I/O、合成读数、设定值日志、报警历史、电价表）暂存到微虚拟机工作区。第二，沙箱内部附加一个确定性验证器，检查模型声明的每个输出表是否以 pandas.DataFrame 形式存在于内存中，所有必需列和类型是否匹配，然后直接序列化为 Apache Parquet 二进制文件——而不是解析自由格式的标准输出文本。第三，如果脚本抛出异常或缺少必需列，没有任何未经验证的数字会到达用户；Temporal 工作流捕获错误信息作为结构化重试提示，让代理修正 Python 逻辑后在干净沙箱中重新计算。

这个设计让一个具体场景成为可能：一位运营总监要求 AURA 审查 94 个工厂过去 24 小时的所有关键报警并识别主要机械风险。代理在沙箱中加载报警摘要，按设施、规则和间隔时间分组。Python 分析区分出一个工厂 103 次关键触发来自两条重复的储罐液位规则，和另一个工厂 58 次触发在氨检测、蒸发器故障和热气阀之间一秒内密集出现——后者指向级联设备故障，需要安全团队立即介入。

但仅有可验证的计算还不够。文章用采石场的例子说明了另一半问题：一个骨料采石场运行初级、次级和三级碎石机，一个班次内后半段产线跳了两次。操作员在控制室看到次级碎石机故障，清除报警重启产线，几小时后又跳了。仅看历史数据的时间戳，次级碎石机在三级之后几秒故障，看起来像是碎石机本身的问题。AURA 之所以能给出正确诊断，是因为它同时读取了传送带布局和已部署的基础控制联锁逻辑：三级碎石机下方的循环皮带打滑，触发了三级的过载联锁；该联锁的上游安全联锁随即停掉次级碎石机，防止把石头堆到停转的下游设备上。维修人员检查皮带，几分钟内确认并修复了打滑。

CrossnoKaye 强调，这个诊断能力来自一个前提：设备拓扑、基础控制逻辑和传感器数据在同一个系统中。如果代理只能看到历史数据的时间戳，它无法追踪实际的控制逻辑链条。这也是为什么文章把'先统一设备模型和控制逻辑，再添加 AI'列为第一条经验教训。

安全方面，这套架构依赖四层独立防线：Amazon Bedrock Guardrails 评估每个提示和完成；AgentCore 沙箱在隔离环境中运行，没有到工厂设备的网络路由、凭证或 API 路径；边缘 Kubernetes 集群上的基础控制叙述执行确定性状态机守卫、变化率钳位和联锁，不能被云服务或 AI 代理绕过；最底层是物理机械和现场布线的硬接线保护。自动化例程严格以只读模式运行，任何设定值变更都需要操作员以企业身份明确批准。

CrossnoKaye 自报的结果包括：APC 应用将生产吞吐量提高 11–17%，平均降低总设施能源成本 21%；批干燥时间标准差降低 34%；在采石场运营中识别出每年超过 50,000 吨的可回收生产差距。这些数字来自公司自身报告，未经独立验证。

这套架构的适用边界也很明确：它要求企业已经拥有从边缘控制到云端优化的完整平台。CrossnoKaye 的 ATLAS 同时管理设备模型、基础控制软件、历史数据库和优化应用，所以 AURA 在单一安全边界内原生访问工厂的完整运行状态。对于大多数面临'螺栓式'接入挑战的工业 AI 项目——控制逻辑锁在专有 PLC 代码中，各系统使用不同命名约定——先统一设备模型本身就是需要数年完成的工程任务，不是添加一个 AI 代理就能跳过的步骤。