AI 开始替人干活以后，谁来管住它的权限？

AI 助手只负责回答问题时，我们最担心的是它说错。等它能打开终端、访问数据库、调用接口，问题就变成了：它说错之后，会不会顺手把事情也做错？

9 月 28 日，英伟达发布了 Open Agent Safety Platform。根据官方公告，这套方案包含 OpenShell 开源运行时软件，以及采用 Sentry 的参考系统设计。前者在智能体执行任务时落实访问规则，后者运行在 BlueField-4 DPU 上，从独立于智能体的环境持续观察其行为。^[1]

这条消息值得关注，因为它把一个越来越实际的问题摆到了台面上：当 AI 有能力连续工作几个小时，控制它能做什么，就成了产品本身的一部分。

一句“不要乱动”承担不了权限管理#

假设我们让 AI 帮忙维护博客，给它的任务是“整理最近的文章，补充标签”。完成这个任务需要读取文章和修改标签，却未必需要删除文章、修改账号或者查看访问者信息。

如果交给它的是一个什么都能做的令牌，再在提示词里加一句“请谨慎操作”，系统实际上仍然把这些能力全部交了出去。

提示词可以描述意图，接口权限才能决定请求是否被接受。这两件事各有用处，也需要同时存在。

问题还会随着任务长度放大。智能体可能先读网页，再安装依赖，再运行脚本；其中任何一个环节都可能接触到不可信内容。判断一个动作是否越界，不能只依赖模型在当时是否准确理解了所有上下文。

把控制放到执行过程里#

英伟达这次提出的思路，是在模型和任务编排之外设置可以执行规则的边界。

OpenShell 负责运行时控制；Sentry 则作为独立的监控与执行层。官方称，后者能够在发现越界行为后，以毫秒级速度隔离并停止智能体。这里的“毫秒级”是厂商公布的能力描述，不能直接当成所有部署环境下都成立的实测结论。

另一个需要看清的区别是产品形态：OpenShell 是开源软件，Sentry 在这份公告中属于参考系统设计的一部分。个人开发者没有必要因为看到这条新闻，就认为必须购买一套专门硬件才能开始使用 AI。

真正容易借鉴的是它的分工：执行任务的程序负责把事情做好，外部控制负责限定事情可以做到哪里。

小项目也能把这件事做具体#

以自动写博客为例，工作流可以拆成选题、写作、存草稿、发布几个步骤。草稿内容即使需要重写，代价也很低；公开发布则会影响读者、订阅源和搜索结果，应该有清楚的触发条件。

令牌权限也应该跟任务一起设计。只需写文章的工具，不必同时得到评论管理和站点设置权限。如果现有系统把草稿编辑与发布放在同一项权限里，就要认识到它的实际边界，再通过工作流规则、日志和必要的人工检查补上控制。

一套实用的检查可以很简单：

• 每次操作记录目标文章、动作和结果，方便定位问题。
• 给连续调用设置次数或预算上限，避免失败重试失控。
• 尽量保留修订记录，让错误修改能够恢复。
• 需要停止任务时，能够及时撤销令牌或终止执行。

这些都是具体的工程能力。模型再聪明，也不会自动替系统补齐它们。

下一轮体验竞争，会包括“停得下来”#

许多 AI 演示都在展示任务完成得多快。但真正交给它长期工作之后，人们还会关心另外几件事：它现在在做什么，为什么访问这个服务，出了问题能否追溯，能否及时停止。

英伟达的发布并没有让这些问题一次解决，却说明行业正在把它们当作基础设施来处理。

对普通使用者来说，下次把一个令牌交给 AI 时，除了写清楚目标，也值得写清楚操作范围和完成条件。一个让人放心的助手，应该既能把任务推进，也能让主人始终知道权限掌握在哪里。

来源与时间#

本文依据截至 2026 年 9 月 28 日的公开信息撰写。产品说明来自官方公告，其余为作者分析，未进行独立性能测试。

1. NVIDIA：Open Agent Safety Platform 发布公告，2026 年 9 月 28 日。