重庆工厂里的智能体，已经伸手到设备旁边

重庆制造企业这两年在上的智能体场景很具体：设备点检记录填报、工艺参数查询、备件库存核对、质检报告摘要、售后工单分派。这些活原本由班组、工艺员、库管员分头做，现在交给一个接了 MES、ERP、设备网关的智能体。工厂数字化走到智能体这一步，效率确实上来了，但 IT 部门心里没底：它能读工艺参数，能不能改？它能查库存，能不能直接下采购单？它连了设备网关，会不会把一条控制指令发错对象？问题不在模型聪不聪明，而在它被允许碰什么。读完本文，你可以拿到一张可以落地的权限清单，知道工厂里的智能体安全运行时该从哪里设护栏。

厂商给出的判断：护栏要放在框架之外

2026 年 10 月 21 日，NVIDIA 发布 OpenShell 参考架构，把它对智能体安全的判断写得很直接：提示词、模型护栏和 Agent 框架影响的是智能体想做什么，运行时控制强制的才是它被允许做什么。这句话值得重庆的工厂 IT 反复读几遍，因为很多企业目前的护栏都放在前一层——写更长的系统提示、加敏感词过滤、在 Agent 框架里做工具白名单。这些有用，但都还在“意图”层面。这也划出了智能体安全运行时和模型护栏的分工：前者管执行边界，后者管输出倾向。

OpenShell 是一个以 Apache 2.0 协议开源的安全运行时，做法是把每个智能体放进隔离环境，把操作者的指令转成可验证的策略，运行前检查、运行中强制。它约束四类东西：文件、网络、工具、凭据。边界的特殊之处在于，它位于模型与 Agent 框架之外，所以开源模型和闭源模型都适用；官方还提到它可以跑在 NVIDIA Vera CPU 上，作为开源软件也能扩展到 Arm、Intel 等平台，并支持 Codex、Claude Code 等智能体运行框架。对工厂来说，这意味着不必为了上护栏而换掉现有的模型选型。

软件层之外，还有一层带外看门狗

同一时间，NVIDIA 开发者博客介绍了 Sentry：一颗跑在 BlueField-4 DPU 上的看门狗，独立于主机运行，在芯片内执行策略。官方口径是，智能体试图越出软件边界时，Sentry 会在毫秒级将其隔离并停止；即使主机上的运行时被攻陷，看门狗仍在工作。它基于 DOCA 构建，可以检查智能体的请求与响应、提供可验证遥测、校验智能体身份，并对数据、工具、API 和服务执行细粒度的零信任访问策略。

这里要把时间线说清楚，避免被宣传口径带偏。Sentry 计划在明年初发布，而且只在 BlueField-4 上运行，属于整套方案里约束偏紧、门槛也高的一层。现阶段开发者和安全团队能动手的是 DOCA Argus、DOCA Flow、OVS-DOCA 这些库和微服务，用来做带外可观测性和基础设施侧的执行实验。软件运行时和硬件看门狗不是替代关系：前者决定日常边界，后者负责主机失守后的兜底。

照搬到重庆不现实，但分层思路可以借

重庆制造企业的机房条件差异很大。两江新区、西部（重庆）科学城的一些新厂，虚拟化、容器、边缘网关比较齐；璧山、江津、永川的一些老厂，MES 还是十多年前上的，服务器就放在车间旁边，办公网和设备网之间的分区并不严格。直接照搬参考架构不现实，但智能体安全运行时的四类边界可以直接映射到工厂现场：

  • 文件：只开放白名单目录，工艺图纸、配方、质检标准一律只读；临时目录单独挂载，退出即清。
  • 网络：只允许访问 MES、ERP 的指定接口和内部知识库，默认禁止公网出站；确需查外部资料时走代理并留日志。
  • 工具：把“查询”和“变更”拆成两组，变更类工具默认关闭，按工单临时开启，用完即关。
  • 凭据：给智能体单独身份，发短期令牌，绝不使用管理员账号或某个员工的长效账号。

这四列看起来简单，真正难的是把“为什么需要”写清楚。很多工厂的智能体之所以权限过大，不是技术上做不到按需授权，而是上线时图省事，把一套服务账号直接复用。等到要审计，才发现这个账号同时能读财务、能改库存、能连设备网关，谁也说不清它到底该有什么。

搬到重庆要改的四件事

监管与合规：面向公众提供生成式人工智能服务需要按相关规定履行备案；企业内部使用虽然场景不同，但数据分类分级、个人信息保护、日志留存这些要求跑不掉。等保 2.0 里的身份鉴别、访问控制、安全审计三块，落到智能体上就是：它有独立身份、权限可核对、每次工具调用有记录。三样缺一样，出了事就说不清。

语种与现场语言：工厂的工单、点检表、异常描述里全是缩写和口语，比如“飞边”“缩水”“拉伤”“打刀”“闷车”，还有重庆本地方言口音。策略引擎要能识别这些表达对应的真实动作，否则要么误拦，要么放过。上线前拿三个月的真实工单做一轮语料核对，比在测试环境里造数据有用。

成本：带外 DPU 不是中小配套厂现在就该上的东西。软件层优先，算力先用现有服务器和边缘盒子，等只读场景跑稳、拦截日志证明有价值，再评估硬件。把预算花在权限梳理和日志治理上，回报比买新设备快。

口径：日志留多久、谁能查、误拦了谁负责恢复、智能体导致的业务损失怎么定责，这些要在上线前写进制度，而不是等出事再开会。口径不清，一线班组就会绕过智能体手工操作，护栏等于白设。

护栏和 RPA、堡垒机不是一回事

不少工厂已经把这类需求交给 RPA 或堡垒机，觉得再加一层运行时是重复投资。三者管的层面并不相同。RPA 管的是“照着界面点”，脚本把流程写死，界面一变就断；堡垒机管的是“人怎么登进服务器”，解决的是运维入口的审计；运行时护栏管的是“智能体在运行中能调用什么”，对象是文件、网络、工具和凭据。智能体的动作不是固定脚本，它会根据上下文临时组合工具，所以护栏必须能在运行前判断这一次调用是否越界，而不是只检查登录身份。

另一个误区是把模型护栏当成安全边界。模型护栏能降低有害输出、减少幻觉，但它拦不住一个被提示注入影响的智能体去调用本来就有权限的工具。真正能兜底的是权限本身：如果这个工具默认关闭，注入成功也发不出去。重庆企业在做方案时，建议把预算按“权限梳理、运行时控制、模型护栏”这个顺序排，而不是反过来。

先从哪类场景开始

建议从只读、可回滚、频次高的场景开始：设备点检记录查询、备件库存核对、工艺文件检索、质检报告摘要。这些场景即使智能体判断错了，代价是“查得不准”，不是“改错了”。等只读场景的拦截日志稳定，再逐步放开带确认的写操作，比如生成采购申请草稿、生成工单草稿。每一步都保留人工确认，不追求一步到位的自动化。

供应商选型时问三个问题

重庆本地的集成商、云服务商、安全厂商都在推智能体方案，报价单上写得都很全。选型时问三个问题就够了：一是智能体用的是独立身份，还是复用某个员工账号；二是工具权限能不能按工单临时开启、到期自动回收；三是拦截日志能不能导出成你们审计系统认识的格式。三个问题有一个答不上来，方案就还停在演示阶段。

四条不能越过的红线

设备控制、工艺变更、安全联锁、付款审批，这四类动作不论智能体多有把握，都要有人按下确认。智能体可以做的是把信息收齐、把异常标出来、把草稿写好、把依据列出来；不能做的是替人承担后果。AI 不签字、不承诺、不替代判断，这不是保守，而是把责任放回它该在的位置。

还要提醒一句：运行时护栏不是一次性工程。工艺变了、系统升级了、供应商换了，权限清单就得跟着改。建议每季度做一次权限复核，把三个月没调用过的工具权限收掉。权限只会越加越多，主动做减法的人很少，这正是风险积累的地方。

可执行的起步动作

这周先做一张 Agent 权限清单，四列：文件、网络、工具、凭据。每一列写清楚当前智能体能碰什么、为什么需要、谁批准、怎么撤销。清单做完，再谈上不上运行时。下一周挑一个只读场景，比如设备点检记录查询或备件库存核对，跑两周，把拦截日志拿出来看：哪些是误拦，哪些是真越界，哪些是权限给多了。用真实日志说话，比任何方案汇报都有说服力。

如果工厂还没有专职安全团队，就从 IT、设备、工艺、采购各抽一个人，组成一个临时小组，一个人负责清单，一个人负责日志，一个人负责业务流程确认。别等组织架构调整，先把首个只读场景的边界跑通。

资料来源与口径说明

  • NVIDIA 官方博客《NVIDIA OpenShell Reference Architecture》，2026 年 10 月 21 日，厂商一手材料。
  • NVIDIA 开发者博客《Inside NVIDIA Sentry: Secure AI Agents at Runtime》，2026 年 10 月 21 日，厂商一手材料。
  • NVIDIA 于 2026 年 9 月 28 日发布的 Open Agent Safety Platform 相关新闻稿，厂商口径。

说明：厂商材料中的“毫秒级隔离”“容量提升”等表述属于厂商自述，实际效果需要在企业自己的网络、主机和业务负载下压测验证。本文不引用未经核实的第三方企业案例，也不把厂商预测当作已发生的事实。