NVIDIA 前几天在 GitHub 上放了个东西，叫 OpenShell。
一句话讲清楚：它是给成批自主 agent 用的沙箱运行时，用来控制这些 agent 能碰什么、不能碰什么。
这个方向不新。新的是它把权限当成第一等公民来设计，而不是等它跑起来之后，在旁边挂个日志盯着。
大家把讨论方向搞偏了
聊 agent，大家聊的都是它能不能把活干完。没人问它干活的时候手伸了多长。
可一个 agent 之所以有用，恰恰是因为它能读文件、装包、调 API、拿凭据。这四样砍掉任何一样，它就是个会聊天的文本框。所以“限制它”听起来像自废武功。
OpenShell 的解法是：给你，但只按我写好的范围给。
用户先声明每个 agent 能触及什么，运行时强制执行。听起来很普通。真正不一样的是执行的位置。内核层面，每个 agent 跑在各自的沙箱里，能访问哪些文件、能发起哪些系统调用，由内核限制住。所有网络连接在离开沙箱之前必须过一遍策略检查。
也就是说，agent 自己写什么代码、怎么绕，都没用。它出不去。
凭据这条最实在
OpenShell 不让 agent 接触真实凭据。只有在请求要发往已经批准的端点时，才把凭据注入进去。
这条我认为是整套设计里最值得看的。
很多人做 agent 安全的思路是：把真 key 给它，然后在旁边盯着。问题在于，盯的成本永远高于不给的成本。你没法穷举一个会自己写代码的东西能拿这把 key 干什么。
不给，才是真省事。
改策略之前，先算一遍
这条比较偏门。
你在 OpenShell 里改一条策略，系统在批准之前会先用形式化验证预判这次改动会放开哪些访问。比如改完之后，某个凭据能连上一台新主机，或者能调一个新的 API 方法。这类高风险变更会被挂起，等人来审。
老实说，形式化验证这一块我只懂一半。具体怎么算的，我没吃透，先放在这里。
但那个思路我吃透了，而且觉得该被更多人抄：权限变更的审查应该发生在批准之前，不是出事之后。
现在大部分工具的做法是，改完生效，事后从日志里翻。翻日志这件事本身就是承认前面没拦住。
开发者拿它开发它自己
这条我不确定该当技术细节看，还是当宣传看。
OpenShell 采用 agent-first 的开发方式，就是用它所支持的那类智能体来驱动自己的工作流，开发项目自身。仓库里的 CONTRIBUTING.md 讲流程，AGENTS.md 讲编码约定。
有点自举的意思。也可能是那种“我们自己先用”的说法。这条我没有更多证据，不敢下判断。
你大概率不需要它
它是给要同时跑一批 agent 的团队用的。要 Linux，或者 Apple Silicon 的 macOS，或者带 WSL 2 的 Windows（还在实验阶段）。要 Docker、Podman 或者主机虚拟化。安装是 curl 拉一个 install.sh 执行，默认的沙箱镜像是个什么都没装的最小化 Ubuntu，agent 得自己接。
这些我都没跑过，只看了文档。上手教程里接的是 OpenCode 加免费的 OpenRouter 模型，跑第一个 agent，看它在需要新权限时怎么弹出来让你批。整条路径我没验证，标一下。
但那个思路，你抄得动，而且不用装任何东西。
第一条，先划格子再放进去。开一个新项目，别让 agent 一上来就拿到整个目录，先给它一个子目录，跑通再加。改的范围也一样。
第二条，别把真凭据塞给它。这条尤其对。你要是图省事把自己那把 key 贴进 prompt 里，后面出什么事都是你自己担。
第三条，加权限的时候先想一下这一加会放开什么。撤销很方便，这句话是真的，但它撤销不了已经发生的那次调用。
补一句遥测
OpenShell 默认开匿名遥测。范围限定了，只收运营类别和计数，不采集沙箱名、主机名、文件路径、提示词、凭据、提供商或模型名称、用户内容。
范围算克制。但默认开，就意味着要你自己去关。网关设 OPENSHELL_TELEMETRY_ENABLED=false，Helm 装的话设 server.telemetryEnabled=false，编译阶段也能整个拆掉。
我不做价值判断，只提醒一句：默认项很多人是不看的。
最后
许可证是 Apache 2.0，版本还在 0.1.x，1,852 次提交，仓库里行为准则、贡献指南、安全政策都齐。这些是脚手架层面的信息，我列一下，判断留给上面那些。
就这些。有试过的、或者觉得我哪条讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。