SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场safe-run

safe-run

部署与运维

查看项目

更新于 10-16 09:20

技能介绍

用途

Safe Run 用于为 AI 开发与运维工作选择安全的执行边界。它把任务先分类成「理解这台机器」或「完成一份工作」，再选择最小、最清楚的安全边界，在 Codex、Claude Code 或其他 harness 原生沙盒，与 OpenShell 隔离 worker 之间进行路由。

该技能适用于工作同时可能涉及 host 真实状态、代码修改、跨系统 API、凭证、长时间自主执行或多 agent 的场景，也适用于判断一个任务应留在哪种执行边界内。

核心模型

技能的核心理念是先区分工作物件：

  • 工作物件是「这台机器」时，倾向使用 Codex / Claude Code / 当前 harness 原生沙盒，利用 host-native filesystem、host runtime/logs、host process state。
  • 工作物件是「一份任务」时，倾向使用 OpenShell isolated worker，使用 cloned/copied workspace、scoped network/API、brokered credentials。
  • 若同时需要两者，则拆分为多个阶段（split into phases）。

路由原则

先问：这个 AI 的主要工作物件，是「目前这台 host 的真实状态」，还是「一个可以独立封装、完成后丢弃的 task」？

Route A：harness 原生沙盒

选择 Codex、Claude Code 或当前 harness 的原生 sandbox，条件包括：

  • 需要直接读取 host 的 /etc、/var/log、/proc、/sys、package 状态、systemd、socket 或 process state。
  • 需要同时理解 repo 与真实部署环境。
  • 使用者正在交互式 debug，且会实时监督操作。
  • 工作的主要价值来自「看到真实 host」，不是建立干净 worker。
  • 可以用原生 sandbox 做「大范围只读 + 少量明确可写路径」。

不要把「原生沙盒」等同于特定技术，应使用当前 harness 在目前 OS 上实际提供的机制：Codex 使用 Codex 原生 sandbox；Claude Code 使用 Claude Code 原生 sandbox；其他 harness 只有在能验证其原生 sandbox 能力时才使用。

Route B：OpenShell isolated worker

选择 OpenShell，条件包括：

  • 工作可以从 repo、artifact、task description 或明确输入重建。
  • AI 要长时间自主执行，没有人持续盯着。
  • 需要跨 Git hosting、cloud API、CI、issue tracker、artifact registry、internal API 等多个外部系统。
  • 需要凭证，但不希望 agent process 直接持有真正凭证。
  • 需要明确控制 egress、API method/path、provider、credential destination。
  • 需要同时跑多个 worker，彼此 filesystem 与生命周期隔离。
  • 完成后希望直接 destroy worker，不留下 host runtime 污染。

在 OpenShell 路径中，OpenShell 是主要的外部 capability boundary，不要依赖某个 harness 的内建 approval 来代表整体安全边界。

Route C：混合任务

如果任务同时需要真实 host 状态、isolated worker、外部 API / credential、长时间 autonomous execution，不要直接把整台 host bind mount 到 OpenShell。优先拆成：

  • Phase 1：host-aware investigation，使用 harness native sandbox，做读日志、检查配置、检查 runtime/process、提取最小证据，产出 bounded evidence / artifact。
  • Phase 2：task execution，使用 OpenShell worker，做 clone/copy repo、修改、测试、调用已批准的 API、创建 patch/branch/PR。

只有当 Phase 2 必须持续读取 live host data，而且无法用 snapshot、log export、API 或明确 artifact 取代时，才考虑 OpenShell explicit read-only bind mount。

使用方式

OpenShell 前置闸门

只要路由结果需要 OpenShell，在执行任何 OpenShell setup、policy、provider 或 sandbox command 前：

  1. 先确认目前 harness 能读取 NVIDIA OpenShell 的 skills。
  2. 若无法证明已安装，执行：
npx skills add NVIDIA/OpenShell
  1. 安装后，先读取本次工作相关的 NVIDIA/OpenShell skill，再产生或修改 OpenShell policy。

NVIDIA/OpenShell skills 不被视为本 Skill 随附内容，而是独立安装的 upstream dependency。如果无法安装或无法读取 upstream skill，不要凭记忆猜 OpenShell 的最新 policy schema 或 CLI 参数；应停在设计/规划层，或改走不依赖 OpenShell 的路径。

Harness 原生沙盒闸门

走 Route A 前：

  • 确认当前 harness 与 OS。
  • 确认该 harness 的原生 sandbox 目前真的启用。
  • 确认至少能表示需要的 read scope、writable workspace、network boundary、必要的 approval / escalation。

若原生 sandbox 不存在、被停用、或无法满足最小边界，不要假装安全；改用 OpenShell、Docker/VM 隔离，或停止高风险 mutation。不要把 bubblewrap 写成跨平台前提；Linux、macOS、Windows 的原生机制不同，路由只依「harness 是否能在目前平台提供所需 boundary」判断。

判断矩阵

任务特征 Harness 原生沙盒 OpenShell
读真实 host /etc / logs / process 优先 不优先
交互式系统 debug 优先 不优先
单一 repo、使用者在旁监督 优先 可选
isolated disposable coding worker 可用 优先
长时间 autonomous task 不优先 优先
多 worker 平行 有限 优先
多外部系统 API 可做但分散 优先
credential 不可暴露给 agent harness-specific 优先
API method/path 细粒度限制 harness-specific 优先
需要直接理解 host runtime 优先 除非明确 RO bind
完成后整个环境可丢弃 普通 优先

快速决策

按顺序判断：

  1. 需要 live host state 吗？是 → Route A；否 → 下一题。
  2. 工作能从明确输入重建吗？否 → Route A 或先做 Route A 取证；是 → 下一题。
  3. 是否长时间自主、跨多外部系统、需要 credential 或多 worker？是 → Route B；否 → 原生 sandbox 通常更简单。
  4. 两边条件都成立？拆 Route C，不先做大范围 host bind。

典型案例

  • 系统故障分析：「分析目前这台 server 的 Nginx / runtime / logs，找出 timeout 根因」→ native-sandbox，理由：真实 host 就是工作物件。
  • 交互式 code change：「修改目前 repo，跑测试，我在旁边看结果」→ native-sandbox，理由：单一 workspace、交互监督、原生 sandbox 成本最低。
  • Issue 到 PR：「收到 issue 后自动 clone、修改、测试、push branch、开 PR」→ openshell，理由：task-isolated、可重建、需要 Git provider 与长时间自主执行。
  • 跨系统调查后修正：「先看 staging host 的实际 logs 与 config，再修 repo 并调用 Git / cloud API」→ native-sandbox -> evidence -> openshell，理由：调查阶段需要 host-native view，实作阶段适合 isolated capability boundary。

OpenShell 使用原则

路由到 OpenShell 后：

  • workspace 默认独立建立，不默认 expose host filesystem。
  • provider / credential 使用 OpenShell 的机制，不直接把长期 secret 丢进 agent environment。
  • egress 与 API scope 只开本 task 需要的最小集合。
  • host bind mount 默认不用；若必要，优先 read-only，且明确列出 source、target、理由与移除条件。
  • 不把 production mutation 权限和一般 coding 权限放在同一 worker。
  • worker 完成后保留必要 artifact / commit / logs，再停止或删除 sandbox。

限制与避免做法

  • 不要为了统一而统一：把所有 Codex / Claude Code 都走 OpenShell，再加大量 host bind mounts，会同时失去 host-native debug 的简洁性与 isolated worker 的干净边界。
  • 不要把原生 approval 当成 autonomous worker 的完整边界。
  • 不要用 OpenShell 模拟整台真实 host；如果工作核心是理解现有 machine，优先使用 harness 原生 sandbox。

路由输出

需要明确记录时，输出一行：

execution_boundary=native-sandbox reason=host-aware

或：

execution_boundary=openshell reason=autonomous-cross-system

或：

execution_boundary=split reason=host-investigation-plus-isolated-execution

若选 OpenShell，再补：

openshell_skill=verified

只有已确认 NVIDIA/OpenShell skill 可读取时才能标记 verified。