OpenShell sandbox 私有运行时怎么部署？

Hacker News 上讨论的 OpenShell 并不是用来提高模型能力的；它管理的是 AI Agent 执行任务时能够访问的资源。 部署 OpenShell 私有运行时时，先核对宿主系统和虚拟化后端，再准备 CLI 与本地 gateway，最后创建 sandbox 并运行首个 Agent。遇到问题时也应沿这条路径定位，不要一看到 Agent 不工作就重建沙箱。

现有资料列出的宿主环境包括 Linux、Apple Silicon macOS 和实验性的 WSL 2；执行侧需要 Docker、Podman 或主机虚拟化能力。 尤其不要把 WSL 2 支持理解成原生 Windows 支持。

安装脚本无法补齐的前置条件

排查时将宿主系统与执行后端分开检查。宿主系统不在当前支持范围内，或 Docker、Podman、主机虚拟化能力尚未就绪时，安装脚本无法补齐这些条件；反复执行同一脚本通常也解决不了问题。

执行前应以当前官方 Quickstart 与支持矩阵为准，确认操作系统、CPU 架构和所用虚拟化后端。 尤其是 WSL 2，目前在所给资料中仍标为实验性支持，不能据此推断所有 Windows 主机或 Intel Mac 都具有相同支持状态。

openshell sandbox create 报错时的排查顺序

排查时先记录操作系统与架构、按官方方式取得的版本、容器或虚拟化后端、执行的完整命令，以及脱敏后的错误信息。不要只保留最后一行报错，因为 gateway 尚未就绪和 sandbox 创建失败并不属于同一个阶段。

现有资料能够确认的 Quickstart 命令如下：

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

openshell sandbox create --name demo

第一条命令用于安装 CLI 组件，随后还需按官方文档准备本地 gateway，再执行 sandbox 创建。现有资料没有给出完整的 CLI 与 gateway 安装顺序、确定版本号或成功输出，也不足以确认更具体的子命令或终端结果。 如果失败发生在 CLI 或 gateway 准备阶段，应先回到 Quickstart 排查前置条件。只有这两部分已经就绪，才继续排查 sandbox 创建失败时的环境条件。

demo 创建成功但无法执行任务时的排查路径

基础 sandbox 默认使用精简 Ubuntu，本身没有预装 Agent。因此，demo 创建成功但里面没有 Agent，通常不能直接判定为 sandbox 损坏。

下一步应按当前官方文档运行首个 Agent，观察它提出的文件、系统能力和网络访问请求，再逐项决定是否批准。 如果资源请求已经出现但访问被拒绝，应先检查策略拦截情况，而不是立即重建环境。如果 Agent 本身尚未安装或启动，问题出在运行内容未准备好。现有资料没有提供具体审批界面路径和日志字段，这部分需要以当前仓库文档和实际环境为准。

权限边界、策略验证与多 Agent 调度

系统提示词只能约束模型的行为倾向，真正的资源边界由运行时控制。OpenShell 的结构可以理解为：gateway 接收管理请求，supervisor 协调 sandbox 与策略，sandbox 承载 Agent 的实际工作；文件、系统能力和网络连接都要在访问时接受检查。

策略变更还会经过形式化验证，以识别新规则可能开放的访问，再交给人工审核。 但这不等于对整个系统作出了安全证明，它只覆盖策略变更所暴露的风险。现有资料也没有证明“一 Agent 一 sandbox”、跨节点调度或固定生命周期，多 Agent fleet 的映射方式和调度能力仍需要单独验证。

Agent 凭据隔离与网络出口审计

在 OpenShell 的凭据设计中，Agent 不直接获得真实凭据，而由运行时把凭据附加到发往获批端点的请求上。 这能减少 API Key 出现在提示词、终端输出或 Agent 可读文件中的机会，但不会自动消除数据带出风险。

上线前仍要核对获批端点范围、凭据注入时机与轮换方式、访问记录是否可审计，以及 Agent 是否能通过其他渠道传出敏感数据。 如果网络策略过宽，或者测试环境与生产环境共用密钥，运行时隔离带来的收益会被明显削弱。

OpenShell 在生产环境中的验证项

现有资料更支持从代码审查 Agent 这类低风险任务开始试点，尚不足以证明 OpenShell 能直接满足生产环境要求。 上线前至少要自行验证生产环境高可用、Kubernetes 部署、跨节点调度、性能开销、多租户隔离和审计留存能力。现有资料尚不能证明这些生产能力。