工业智能体如何隔离推理与执行授权

AI 能读懂设备手册、生成合法命令，不代表它有权操作设备。这篇文章讨论的，是工业 AI Agent 从「提出动作」走到「执行动作」之间，应该设置怎样的授权边界：模型负责建议，独立的应用组件决定是否放行。

它没有展示新模型，也没有报告安全实验结果，而是提出了一套可以在沙箱里验证的架构。对要给 Agent 接工具、接执行接口的程序员，最值得读的是三个细节：批准必须绑定具体命令，执行前必须重新检查条件，已经执行过的请求不能靠重发再执行一次。

为什么读到的内容不能变成操作权限

工业 Agent 接触的输入很杂：设备手册、维护日志、事故报告、操作员消息、工单、传感器摘要，以及外部工具返回的数据。这些内容能帮助模型判断，但不能因此获得定义权限的资格。

提示注入（Prompt Injection）就发生在这条边界上。例如，一份维护文档夹带指令，要求 Agent 忽略限制，申请操作职责范围之外的设备。如果应用只靠提示词告诉模型「不要听可疑内容」，最终仍是在让模型自己判断该不该服从。

作者把这里容易混淆的东西拆成三类：

• 数据是 Agent 可以阅读、分析的信息。
• 指令是系统定义的任务和操作规则。
• 权限是可信应用组件实际执行的许可约束。

读到一条要求，不等于获得执行这条要求的权限。

这个区分决定了系统怎么搭。AI Decision Engine 理解请求并提出结构化命令；授权网关检查身份、策略和前置条件；Physical AI Action Engine 只执行检查通过的命令。拒绝或暂缓的请求也要记录结果。

重点不在于一定要部署三个独立服务。作者明确说，这是一种设计模式，具体组件可以不同。真正需要独立的是权限判断：即使模型生成了越权提案，它也不能凭自己的输出绕过执行入口。

对于写工具调用接口的人，这里有一个直接的提醒：结构化输出解决的是命令如何表达，授权网关解决的是命令能否执行。字段齐全、格式正确，只完成了前一件事。

为什么审批必须绑定这一次具体操作

「操作员已经点过同意」还不够。必须知道，对方到底同意了什么。

原文用下面的命令说明审批对象需要具体到设备、动作和参数：

{ "asset_id": "pump-17", "action": "set_operating_parameter", "parameters": { "target_value": 42 }, "approval_expires_at": "example-expiry-time" }

要看的是 asset_id、action、parameters 和 approval_expires_at 这几个字段之间的绑定关系。其中 pump-17、42 都只是示例，example-expiry-time 也是占位值，不能当作实际设备配置或可用的过期时间。

假设操作员批准了这份命令，但另一个组件在执行前换了设备，或者把目标参数改了。原来的批准不能继续有效。系统应当拒绝，或者要求重新授权。

因此，审批不能只记录一句「已同意」，还要绑定相关设备、动作、参数、请求身份和有效期，并借助合适的命令标识或完整性机制，发现审批后到执行前的变化。

这里还有容易漏掉的一层：拿几个字段做比较，并不自动等于完整性保护。生产系统需要明确命令的表示方式，保护审批记录，并防止未经授权的修改和重放。原文没有给出具体协议，也没有说明如何实现这些保护，不能把这段示例 JSON 直接当成完整方案。

命令状态也要跟着管理。否则，一条原本有效的请求可能被再次提交，变成重复操作。唯一命令标识、过期检查、重放检测、受保护的审批记录，以及明确的状态跟踪，都是作者提出的控制手段。

命令没改、审批没过期，为什么还要再检查

因为设备状态可能已经变了。

操作员审批时，机器处于允许执行的状态；命令在队列或网络里等待期间，传感器报告了新的情况。此时命令内容完全一致，审批也没有过期，但批准时依赖的条件已经不成立。

这属于检查时与使用时不一致的问题，即 TOCTOU（Time-of-Check to Time-of-Use）：检查通过和真正执行之间存在时间差，条件可能在这段时间里改变。

作者建议，尽可能靠近执行时刻重新核验：

• 目标设备是否仍在授权范围内。
• 审批是否仍然有效，参数是否与批准的请求一致。
• 当前设备状态是否满足操作条件。
• 命令是否已经执行，或者已经被作废。

任何必要条件失败，都应拒绝或暂缓执行，不能凭之前的一次批准继续放行。

不过，「尽量靠近执行」不是消除时间差的保证。能做到什么程度，取决于系统时序、控制器能力、通信可靠性，以及错误动作的后果。原文没有提供统一的原子执行方案，也没有声称网关可以解决全部竞态问题。

AI 授权网关必须配合既有工业安全保护，不能替代安全联锁。

接入真实设备之前，作者建议先用 Agent、正常与恶意文档、沙箱命令网关和最小权限凭据组成测试环境。测试应覆盖正常授权、文档注入、越权设备、审批后改参数、设备状态变化，以及已执行命令的重放。

评估也不能只看拦住了多少请求。原文列出五项指标：未授权动作成功率、合法任务成功率、审批绕过率、策略执行覆盖度、审计完整性。一个把所有请求都拒绝的网关，无法证明系统能安全地完成工作。

审计记录则要把整条链串起来：原始请求、提议动作、请求身份或服务账号、授权决定、命令参数、审批有效性、执行前检查，以及最终结果。记录本身也需要访问控制和防篡改保护，敏感信息按组织的日志与留存规则处理。

我的判断

我认可这篇文章对职责边界的划分。模型可以帮助理解复杂输入，但最终执行权限交给可检查、可测试的应用逻辑，更便于追查一次操作为什么被允许。

它尤其补上了只关注提示注入时容易忽略的风险：即使没有恶意文档，审批后参数被改、旧命令被重复提交、设备状态发生变化，也可能让执行出问题。它们需要命令完整性、状态管理和执行前检查，单纯加强提示词并不能覆盖。

但这是一份设计建议，不是经过实验验证的安全方案。作者明确说明，测试场景和预期结果都是提议，没有给出实际拦截率、误拦率、执行延迟，也没有与其他架构做对照。

同样，独立网关并不天然可信。如果规则缺失、审批记录能被改，或执行端存在绕过入口，图上多一个组件也无法建立可靠边界。原文提出了这些问题，但没有展开具体实现。

与只在提示词里限制 Agent 相比，这套思路把约束放到了应用执行路径上；与简单的「执行前人工确认」相比，它进一步追问批准对象有没有变化、批准条件是否仍成立。至于是否需要新增一个服务，应根据现有执行链路判断，核心是检查必须生效，而不是组件数量。

能拿来做什么

• 给 Node Agent 接执行工具时，让模型先提交结构化提案，再由可信入口核验身份、设备范围和动作权限，避免模型输出直接触发执行。
• 设计前端审批页时，明确展示设备、动作、参数和有效期，并让后端审批记录绑定同一份命令；关键字段变化后要求重新授权。
• 在沙箱中加入审批后改参、审批过期、状态变化和重复提交用例，同时统计合法任务是否被错误阻断。
• 把请求、审批、检查和执行结果串成可追踪的记录，使排查问题时能区分模型提议错误、授权失败和执行条件不满足。