NVIDIA/OpenShell

解决什么问题

Agent 一旦能读文件、装包、调 API、使用凭证，才算真正干活；也正是在这一刻，它变得危险。常见做法是把 Agent 丢进一个容器、发一个 service account，然后祈祷它不往外网发数据。OpenShell 补的是「Agent 能做实事」和「Agent 不能把数据带出去」之间的缺口：每个 Agent 跑在独立沙箱里，文件访问、系统调用和对外连接都按声明的策略在运行时拦截。

有什么不同

多数 Agent 沙箱本质是受限镜像加一个网络代理，策略写在配置里，构建时检查一次或者干脆不检查。OpenShell 在 kernel 层逐次拦截，更少见的是对策略变更做形式化验证——在生效前标出「这个改动会让某个新主机可以带着凭证访问」这类风险，等人工确认。第二个差异点是凭证：Agent 看不到真实 secret，只有发往批准端点的请求才会被注入。相对 Docker、Kubernetes NetworkPolicy 这类通用隔离，它是 Agent 感知的；相对托管型 Agent 平台，控制面留在自己手里，可以 Helm 部署 gateway。

适合谁

适合真正在跑一批有文件系统和网络权限的编码/运维 Agent 的平台工程师和安全工程师——那些被问「这个 Agent 到底能碰到什么」却答不上来的团队。也适合在合规或多租户环境下必须自托管 gateway 的部署。只想拿单个 Agent 做实验的个人开发者不必上这套：一个普通容器加一个限权 API key 就够，策略编写和审批流程纯属额外负担。

上手成本

需要 Linux、Apple Silicon 的 macOS 或 WSL 2 下的 Windows（实验性），外加 Docker、Podman 或宿主机虚拟化。走 Kubernetes 路线时 CNI 必须真正执行 NetworkPolicy，这是实打实的基础设施约束。安装是仓库里的一个 shell 脚本。项目很新（2026 年 2 月创建），README 自己把 0.1.x 称为稳定发布节奏的起点，API 和策略 schema 预计还会动；默认开启匿名遥测，部分环境需要关掉。许可证为 Apache-2.0，比较宽松，但你接入的是一个 pre-1.0 的控制面。

点评

这是个新项目但早期关注度异常高：241 天拿到约 19.2k stars，近一个月 +9,666（月榜第 6），外加一条 496 分的 Hacker News 讨论——热度集中在一次爆发而非长期积累，所以人气说明它切中了痛点，不代表它成熟。kernel 级拦截加策略变更验证确实是差异化的方向，NVIDIA 的背景也让持续维护比较可信。风险在于最有意思的那一半——策略变更的形式化验证——恰恰是 0.1.x 阶段最可能单薄或固执的地方，而且整套设计默认你愿意跑一个 gateway。要把 Agent 放到生产数据附近，值得认真评估；只是想要个容器的话，没必要。