10 月 22 日，Hacker News 上出现了一个 276 分、140 多条评论的帖子：NVIDIA 开源的 OpenShell，自我描述是「autonomous AI agents 的安全、私有运行时」。这个分数在近期的 agent 基础设施话题里算很高，评论区没有出现一边倒的赞叹，反而吵出了几个相当有意思的分裂：有人追问它和 Lima、gVisor 的关系，有人直接发问「为什么要用 AI 口味重新发明虚拟化和容器化」，也有人贴出自己用 sidecar 加中间人代理做凭证注入的土方案，问产品化之后到底好在哪。
这些问题恰好是理解 OpenShell 的正确入口。它不是一个新虚拟机，也不是又一个 Docker 封装，而是把 agent 权限的执行点从「模型自律」这一层，一路下沉到了内核。这篇文章基于其官方架构文档、GitHub 仓库与新闻稿，拆开这套系统，给出工程判断。
一、Agent 权限的三层空心化
先看 OpenShell 想解决的问题。今天给一个编码 agent 权限，实际上是三层防线叠加，而每一层都是空心的。
第一层是系统提示词。「你不能访问生产数据库」这句话写在 system prompt 里，本质是劝诫。本站上周那篇讲 WhatsApp 帮助页面藏指令的长文已经展示过：不可信内容进入上下文后，模型对「origin 是用户还是网页」的区分并不可靠。提示词防线防的是意外，防不了故意。
第二层是 harness 的软约束。工具白名单、AGENTS.md 约定、CLI 的参数过滤，都在 harness 层。但 HN 评论区有人一句话点破：所有 agent 最终都会写 bash 然后执行它。harness 允许执行 shell，就等于允许执行一切 shell 能做的事，白名单只是提高了门槛，没有关闭通道。
第三层是容器。把 agent 关进 Docker 是当前最流行的答案，但粒度粗得像个闸刀：网络要么全通要么全断，挂了宿主目录就是整个目录，凭证以环境变量进去，任何在容器内跑起来的代码都能 env 一把读走。10 月 18 日本站写过 OpenCode 泄露事件，根因之一正是凭证在进程环境里躺着。
更系统的表述是安全圈最近常提的「致命三要素」：私有数据访问权、不可信输入、对外通信能力。一个 agent 三者齐备，注入成功的那一刻就是失守的开始。而今天的默认配置，几乎是在主动把三要素凑齐。
OpenShell 的赌注是：别再劝模型守规矩，让内核来执行规矩。
二、三层架构：谁决策，谁执行，谁被关
OpenShell 的架构文档把系统切成三个部件，信任边界画得极其明确。
Gateway 是控制平面，跑在可信侧。它管 sandbox 的生命周期，校验身份，分发策略和设置，挂载 provider，决定谁能对哪个沙箱做什么。可以把它理解为这套系统的「户籍警加钥匙柜」。
Supervisor 是决策者，同样在可信侧。它检查每个请求是否违反策略，负责提供凭证、解析 DNS、打开被批准的连接，并保持与 gateway 的链路。它是全系统唯一「允许」这个词的说出者。
Sandbox 是被关起来的那一侧，和不信任的 agent 共享边界。它拥有 agent 的进程，能从可信的 /proc 数据里识别「到底是哪个程序发起了这次请求」，把 TCP 和 DNS 流量转交给 supervisor。关键在于：sandbox 永远不做策略决策，它只报告 agent 想干什么，然后等 supervisor 裁决。
这个划分解决了一个老问题：可信计算基到底包含谁。答案是不包含 agent，也不包含 agent 跑的任何代码，连 sandbox 组件本身都没有决策权。一次网络请求的完整旅程分五步：agent 发起 TCP 连接或 DNS 查询，sandbox 识别调用程序，请求经双方互认证的 HTTP/2 通道送到 supervisor，supervisor 对照策略检查并按需注入凭证，通过后才由 supervisor 打开真实连接并中转流量。工作负载唯一被允许的出站路径就是这条到 supervisor 的通道，外围网络围栏拒绝其余一切，agent 连 DNS 服务器和云元数据端点都摸不到。
Linux 后端的具体实现相当硬核：工作负载以单一非 root 身份运行，不持有任何 Linux capabilities；Landlock 限制文件系统访问，这是内核原生的非特权访问控制框架；seccomp 用户通知把网络操作阶段化，拦截 TCP 打开和 DNS 查询并上交 supervisor。值得注意的是「sandbox 从可信进程观测中识别调用程序」这一条——它防的是 agent 耍小花招：用一个程序的名义申请权限，再把流量转给另一个程序跑。
失败策略全部倒向关闭：supervisor 没有确认隔离边界就位之前，agent 进程根本不启动；连接中断，agent 当场冻结，只有原来那个 supervisor 进程能重连续跑，换个进程拿有效凭证也接管不了。每次 sandbox 重启都开启新的一代，JWT 和 TLS 证书全部换新，旧的立即失效。
三、两个真正巧妙的设计
架构分工只是骨架，真正体现设计功力的是两个机制。
第一，凭证不入境。 OpenShell 引入 provider 概念：把一个服务名映射到一个存储好的凭证。agent 代码里只出现服务名，真实凭证由 supervisor 在出口处按策略注入到发往批准端点的请求里。这意味着沙箱内不存在任何值得偷的东西——没有 gateway 签名密钥，没有 gateway JWT，没有 provider 凭证。传统的 sidecar 加中间人代理方案（HN 评论区就有人晒过自建版）思路相同，但要把互认证、DNS 解析、按程序识别、失败冻结这一整套做全并不容易，OpenShell 把它做成了产品。
第二，策略变更过形式化验证。 策略是会腐化的：今天为调试放开一个端口，明天忘了关。OpenShell 的 prover 用 SMT 求解器在策略生效前做两类检查。边界检查回答「这份候选策略是否超出了环境允许的最大边界」，比如企业给所有 agent 定的总策略，父 agent 还可以用它审查自己给子 agent 写的策略，命令是 openshell-prover check candidate.yaml --boundary boundary.yaml，超出边界时直接给出反例，形如 counterexample: filesystem write /tmp。提案风险检查在 agent 每次提议新网络规则时自动运行，专门标记「用凭证访问新主机」「调用新 HTTP 方法」「摸云元数据地址」这类高风险增量，命中就卡住自动批准，转人工审查。
把权限审查从人工读 diff 变成机器可判定的数学问题，这个思路在 agent 基础设施里还是第一次产品化。prover 独立于 gateway 运行，可以塞进 CI 流水线单独使用——即便你不用 OpenShell 跑 agent，拿它审 infra 策略也有价值。
四、横向对比：它不是又一个容器
回应评论区那个尖锐的问题——「为什么用 AI 口味重造虚拟化」。把 OpenShell 放进坐标系里就清楚了。
对 Docker/Podman：容器给的是粗粒度一刀切，OpenShell 给的是每连接细粒度策略，且同一份策略在 Docker、Podman、Kubernetes、MicroVM 四种运行时上语义一致，因为裁决权永远在共享的 supervisor 和策略引擎，运行时只负责建边界。差异不在隔离强度，在策略粒度与跨平台一致性。
对完整虚拟机：评论区高赞观点认为该把整个 harness 关进 VM，因为 harness 自身也可能被注入。这是信任模型的真实分歧：OpenShell 假设 harness 在可信侧，只关 agent 的工作负载；VM 派则连 harness 一起关。两条路线不互斥，VM 管宏观，OpenShell 管微观，嵌套使用完全可行。
对 gVisor、Firecracker：那些隔离的是内核，OpenShell 执行的是策略，两层正交。你完全可以在 MicroVM 里再跑 OpenShell。
对 WASM code mode：有人设想只允许 agent 写跑在 WASM 沙箱里的代码以获得强控制。思路干净，但表达能力受限，大量工具链迁不过去。OpenShell 选择给完整 Linux，靠内核围栏兜底，是工程上更现实的妥协。
对本站上周写过的微软 MXC：那篇解决的是「模型生成的代码在哪跑」，一篇 SDK 管九种后端；OpenShell 解决的是「agent 全生命周期治理」——身份、策略、凭证、审计四位一体，顺带把策略验证也包了。前者是执行容器，后者是运行时平台，互补而非竞争。
五、工程判断：五个坑
材料很亮眼，但落地前必须看清它的边界。
其一，形式化验证不是全量验证。 prover 的 coverage 只有五个域，GraphQL、MCP、WebSocket、JSON-RPC 规则直接 unsupported；符号链接导致的路径歧义判 unsupported；超过 1024 条网络规则返回 inconclusive。文档明确写了「两种检查回答不同问题，过其一不等于过其二」。看到 within_boundary 就放心、看到其他结果当失败处理，这是纪律，不是可选项。
其二，策略摩擦真实存在。 每个新端点、新凭证用途都可能触发人工审查。设计上这是特性，但组织上意味着你要么养一支策略审查的值班文化，要么把边界策略写得足够宽然后慢慢收紧。上来就写最严策略的团队，会被 agent 每天几十次的批准请求淹死。
其三，平台成熟度不均。 Linux 后端最完整；macOS 只支持 Apple Silicon；Windows 靠 WSL 2 且标注实验。Kubernetes 部署要求 CNI 强制执行 NetworkPolicy，网络没配平的集群会得到虚假的安全感。
其四，性能开销没有官方基准。 每个 TCP 连接和 DNS 查询都要经 supervisor 中转裁决，seccomp 用户通知本身也有上下文切换成本。文档用「每条连接独立流加独立背压」缓解了慢下载阻塞控制面的问题，但延迟数字要自己测，别默认它免费。
其五，信任假设要认清。 harness 被注入时怎么办？OpenShell 的模型里 harness 是可信侧的一部分。它把凭证失窃这条路堵死了，但没有、也不承诺解决「注入诱导 agent 用合法权限作恶」。致命三要素里还剩「数据外泄」这一角，需要配合内容侧防御与出口审计。另外遥测默认开启，介意的话部署时记得设置环境变量或 Helm 参数关掉。
六、更大的图景：Agent 运行时正在成为新操作系统
把视线拉远一点。9 月 28 日 NVIDIA 发布这个平台时，同时亮出了可选的 Sentry 组件——一个跑在 BlueField-4 DPU 上的 watchdog，宣称毫秒级隔离失控 agent。软件定义策略、硬件执行隔离，这套组合拳说明 NVIDIA 想占的是「agent 基础设施」这个生态位，而不是卖一个沙箱工具。
更有意思的是隐喻层面的迁移：OpenShell 管的这些东西——进程、文件、网络、凭证、身份、策略——过去都是操作系统的职权。当 agent 成为主要的「程序员」，为 agent 管理权限的运行时就成了新的 OS，而「策略即代码加策略验证」就是这个新 OS 的包管理器。prover 那个 counterexample: filesystem write /tmp 的输出，像极了编译器给你指出类型错误：权限的错误正在从运行时事故变成编译期错误。
回头看本站这几周的叙事线：10 月 18 日 OpenCode 泄露是凭证管理的失败，10 月 19 日「网站对 agent 关门」是外部世界对不受约束 agent 的反弹，10 月 21 日 WhatsApp 帮助页藏指令是提示词防线的失守。三个故事指向同一个结论：agent 与外部世界之间缺一层可信的执行基础设施。OpenShell 是目前这个方向上最系统化的开源答案——它未必是最终答案，HN 评论区那些「为什么不直接用 VM」的质疑也依然成立，但「执行点必须下沉」这个方向，恐怕没有回头路了。
17747 个 star、1834 个 fork、563 个开放 issue，以及几乎每天都有提交的推送记录，说明社区已经在用脚投票。接下来几个月，这套架构会被抄几轮、被骂几轮、被改几轮——而 agent 安全的下半场，才刚刚开场。