模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第17章 — 安全模型对比
Token用量: 约 4,600 input + 1,160 output

17.2 沙箱化

如果说权限提示解决的是“该不该做”，那么 sandboxing（沙箱化）解决的是更硬的一层问题：即便模型判断错了、规则漏了、插件越界了，它实际上还能造成多大伤害？ 一旦问题进入这一层，真正有用的就不再是提示词，而是操作系统级能力隔离。

在这方面，Claude Code 明显领先于 OpenCode 和 OMO。它采用了 OS-level sandbox（操作系统级沙箱），例如 Linux 上的 bubblewrap、macOS 上的 Seatbelt。Anthropic 还提到过一个非常关键的数字：这类安全策略带来了 84% 的风险/授权负担下降。具体分母细节当然重要，但从架构层面看，真正关键的不是数字本身，而是它说明了一件事：一旦把安全控制下沉到 OS 边界，很多原本必须靠频繁人工确认来兜底的风险，就能被能力限制直接削弱。

这和单靠 prompt 或权限规则完全不是一个层次。Prompt 可能被忽略，规则可能被绕过，分类器可能判断错；但如果进程本身拿不到某些目录、拿不到某些网络能力、拿不到更高权限，那么即使上游出了问题，伤害半径仍然被压缩了。这种思路在安全工程里属于 capability-based safety（基于能力边界的安全），也就是通过限制“能做什么”来兜底，而不是只限制“应该做什么”。

OpenCode 本身并没有把 OS 级沙箱作为它的核心安全特征，OMO 也没有。它们当然不是因此就“不安全”，但安全模型更多依赖权限判断、工具边界、hook 守卫和使用纪律。换句话说，如果某个 shell 或文件工具已经获准在宿主机上运行，那么宿主本身拥有的权限就仍然是关键前提。

这件事在 autonomous agent 场景里尤其重要。编码智能体的风险，从来不只是“模型说错一句话”，而是它能调 shell、能写文件、能碰网络、能接第三方服务。一旦这些能力被整合在一起，单纯靠上层提示和规则很难形成最后防线。沙箱化是少数在“推理已经失败以后”依然有效的控制手段。

当然，沙箱也有代价。它会增加实现复杂度，会降低某些真实开发工作流的兼容性，还可能让用户在一些明明合理的任务上碰到“权限墙”。有些开发场景确实需要更广的文件系统访问、网络访问或系统调用能力。因此，商业产品必须不断在“安全收口”和“开发体验”之间做权衡。

但无论如何，有一个结论几乎已经很难回避：只要 agent 能执行 shell、修改文件、接触凭证，OS 级沙箱就迟早会从“高级特性”变成“基础配置”。OpenCode 和 OMO 代表的是“非沙箱优先架构”的当前状态与优缺点，Claude Code 则代表了下一阶段的成熟方向。

还需要注意一点：沙箱不是权限系统的替代品，而是权限系统之后的后备防线。权限系统负责尽量别让危险动作发生，沙箱负责危险动作真的发生时别让后果无限扩大。前者更像“前门保安”，后者更像“防火隔间”。两者不能互相替代。

对未来开源 agent 平台来说，Claude Code 的做法给了一个非常清楚的信号：如果系统越来越自主，那么只做 prompt 安全和授权弹窗是不够的。OpenCode 与 OMO 在这方面的空缺，也恰恰说明这将成为未来演进的重要方向。

最好的安全栈，大概率会是三层叠加：清晰权限、运行时守卫、OS 级沙箱。在这三层里，沙箱往往是最不花哨、却最诚实的一层，因为它真正限制了“即使出事，还能坏到什么程度”。