过去一年，Agent 的能力边界被迅速拉高。它不再只是“会聊天的大模型”，而是在越来越多的场景里真正拥有了“手脚”：能写代码、改文件、跑测试、装依赖、发请求，甚至直接操作本地终端。

但问题也恰恰出在这里。

一旦 Agent 可以直接在开发机上执行命令，它就不再只是一个推理系统，而变成了一个半可信执行体：正常情况下它是高效助手，异常情况下它也可能是一个“拿着系统权限的自动脚本”。模型幻觉、Prompt Injection、第三方仓库里的恶意指令、错误的工具调用路径，都会把风险从“回答错了”升级为“真的把你的环境改坏了”。

于是，一个绕不开的问题摆在所有 Agent 产品面前：

怎么让 Agent 真正自动化地干活，同时又不把宿主机暴露在不可控风险里？

这就是 Agent Sandbox 的价值所在。

“系统安全能力的下限，决定了 Agent 自动化能力的上限。”

问题

在没有成熟沙箱之前，最常见的办法是“人工确认”：Agent 每执行一步命令，每改一次文件，都弹窗询问用户要不要继续。

这种做法看起来安全，但实际上只解决了心理安慰，并没有真正解决底层风险。

第一，它会快速演变成严重的中断疲劳。一个稍微复杂一点的重构任务，可能要经历十几次读写文件、数十次 shell 调用、若干次网络请求。每一步都确认，Agent 的自动化价值会被彻底抵消。

第二，它对真实攻击并不可靠。开发者并没有足够的时间在一秒钟内审完一长串 bash 命令，更不可能靠肉眼持续识别被混淆过的脚本、链式调用或隐蔽的外带逻辑。换句话说，弹窗确认本质上是在把安全责任转嫁给用户，而不是在系统层面建立边界。

真正可持续的方案不是“每一步都问你”，而是：

  • 默认把 Agent 放进一个边界明确的运行区域；
  • 边界内自动执行，不打扰用户；
  • 一旦越界，由底层机制直接拦截，而不是事后追责。

这就是现代 Agent 沙箱的核心设计目标：把安全从“交互层提醒”下沉到“执行层约束”。

方案演进

从当前行业实践看，Agent 沙箱大致形成了三条路线。它们并不是谁绝对淘汰谁，而是分别适合不同的产品形态。

1. 容器型沙箱

这一类方案通常基于 Docker 或容器池，把代码执行环境封装进独立容器，再通过 API 或任务调度系统与 Agent 主流程解耦。

它的优势很明显：环境一致性好，依赖管理成熟，易于做多租户调度，也方便把环境变量、文件系统和网络策略统一配置。很多云端 Agent 平台、代码执行服务、Browser + Code 一体化沙箱都属于这一路线。

但它的局限同样明显：
如果你的目标是“让 Agent 直接辅助用户本地开发”，Docker 会显得偏重。你需要处理 volume 映射、UID/GID、路径同步、宿主文件状态与容器视图的一致性，以及本地开发工具链与容器内部环境的错位问题。它更适合“把任务送进一个隔离盒子里执行”，而不天然适合“在用户当前工作区无缝协作”。

2. MicroVM 型沙箱

这一类典型代表是 Firecracker 体系或基于它的代码执行平台。它的优势是隔离强度极高，接近虚拟机级别，天然适合云端多租户场景，也更适合执行不可信代码。

问题在于，它依赖的是更重的基础设施。
如果你做的是在线代码执行、SaaS Agent Runtime、批量任务调度，它非常合适；但如果你要做的是本地 CLI Agent、IDE 内嵌助手、能直接接触当前仓库和本地工具链的开发助手，它又太远了。用户真正想要的是“在我的机器上帮我干活”，而不是“先把我的上下文迁移到云端再执行”。

3. OS 级本地沙箱

这正是 @anthropic-ai/sandbox-runtime 最有代表性的路线。

它不引入 Docker daemon，不要求完整虚拟化，也不试图重新发明一个执行环境，而是直接调用操作系统原生的安全机制，把一个普通进程“套上手铐”再运行。

这条路线的核心价值在于：
它不解决环境一致性问题，而是专注解决权限边界问题。

对于本地 Agent 场景，这个取舍非常重要。因为本地 Agent 最需要的不是再造一个新环境，而是在用户当前环境中，以最小权限安全执行。

推荐方案

如果你的目标是做本地 CLI Agent、IDE 辅助编码、MCP 风格的本地工具执行层，@anthropic-ai/sandbox-runtime 是目前非常值得重点关注的一条路线。

它最值得推荐的地方，不是“功能最多”，反而是“边界最清晰”。

它的设计非常克制：
只聚焦在两件最核心的事上——文件系统访问控制和网络访问控制。
它不试图替你管理整个运行环境，不做浏览器虚拟化，不做一体化桌面，不做大而全的 agent platform，而是作为一个基础运行时，给 Agent 的命令执行层加上 OS 级约束。

它的核心思想

可以概括成一句话：

Secure by default，按需打洞。

也就是说，进程默认拿到的是受限权限，只有你显式声明允许访问的文件路径、可写目录、可连通域名，才会被放行。这样一来，安全模型就从“执行之后看看有没有出事”，转变成“启动之前先决定它理论上能做什么”。

它的跨平台实现

从公开资料和业界分析看，它的实现思路大致是：

  • 在 macOS 上，基于 sandbox-exec / Seatbelt profile 动态生成规则并执行；
  • 在 Linux 上，基于 bubblewrap 结合 namespace 隔离，并辅以 seccomp / 网络代理约束。

这意味着它本质上属于：

OS 原生机制驱动的本地轻量级进程沙箱
而不是 Docker 容器，也不是 Firecracker microVM。

这个分类非常关键。因为它决定了它的优点和短板都非常鲜明。

方案对比

如果把当前几类方案放到同一张图里看，差异会更清楚。

方案类型隔离强度启动成本本地工作区协作环境一致性适合场景
OS 级沙箱中到高很低很强弱本地 CLI、IDE Agent、MCP 本地工具
Docker 容器中低到中中强云端执行、服务化工具、私有化平台
MicroVM很高中弱很强多租户云执行、不可信代码运行
All-in-One 沙箱中到高中弱到中强浏览器+代码+文件一体化 Agent 平台

为什么我更推荐 sandbox-runtime？

因为如果你的目标不是“搭建一个云端执行平台”，而是“让 Agent 安全地操作本地工程”，那么真正重要的指标就不是“能不能打成镜像”，而是：

  • 是否能直接作用于当前文件系统；
  • 是否能尽量减少环境迁移成本；
  • 是否能把安全边界下沉到操作系统层；
  • 是否足够轻，能支持高频 Agent 调用。

在这些维度上，它确实有明显优势。

它的不足

但推荐并不意味着它是银弹。恰恰相反，@anthropic-ai/sandbox-runtime 的短板非常值得单独讲清楚，因为这决定了它更适合做“本地执行边界层”，而不是“万能沙箱”。

1. 它解决的是权限隔离，不是环境隔离

这是最容易被忽略的一点。

sandbox-runtime 并不会给你一个全新的 Python、Node、glibc 或系统依赖环境。
你在沙箱里运行的解释器，本质上还是宿主机已有的解释器；你调用的 python、node、git、curl，本质上还是宿主机工具链。

这意味着：

  • 它不会天然解决依赖污染；
  • 不会自动帮你隔离不同项目的运行时版本；
  • 也不会替你管理 pip install、npm install 安装到了哪里。

如果你在沙箱里直接执行 pip install xxx，它安装的位置仍然受宿主机 Python 配置影响。最常见的情况包括：

  • 装到当前虚拟环境；
  • 装到用户级 site-packages；
  • 装到系统 Python 环境；
  • 或因权限不足直接失败。

所以它不适合作为“环境管理器”，而更适合作为“权限约束器”。

2. 复杂项目下，打洞配置并不轻松

“默认拒绝、按需允许”是安全的，但对复杂工程来说也意味着配置成本。

一个稍大的 Agent 工作流可能需要：

  • 访问当前仓库；
  • 调用 git；
  • 读写缓存目录；
  • 连 npm / PyPI / GitHub / 私有制品库；
  • 调用语言服务器、编译器、测试工具；
  • 访问 .venv、node_modules、临时目录、socket 文件。

你如果想真正把边界收紧，就必须梳理清楚这些路径和域名。这个过程技术上是正确的，但工程上并不轻。对团队来说，前期最大的成本往往不是“接入代码”，而是“弄清楚到底哪些资源应该被允许”。

3. 对网络控制的强度有边界

它的网络策略很重要，但从架构上看，它更偏向“受控代理 + 规则限制”，而不是一个完整的、无逃逸空间的网络虚拟化体系。

这意味着它对大多数常规 Agent 工具调用已经足够，但如果你把对手模型设定为“有意规避限制的恶意执行体”，那就必须清楚：
它不是等价于 microVM 级别的绝对网络封闭。

4. Windows 原生支持不是它的强项

它的设计天然更适合 Unix-like 系统。
如果你的用户群体主要是 macOS 和 Linux 开发者，这问题不大；但如果你想做面向 Windows 大规模开发者的通用方案，就必须提前评估兼容层、WSL 或替代实现。

5. 资源限制不是它的主战场

OS 级权限沙箱擅长限制“能访问什么”，但不天然等于“能消耗多少资源”。
如果 Agent 写了死循环、启动异常多的子进程、或者跑出高内存任务，单靠这类运行时通常还不够，仍然需要额外的 timeout、进程树清理、资源配额策略配合。

如何使用

从产品形态上，它既适合当 CLI，也适合作为 TypeScript/Node 里的库集成。

前置步骤

如果准备在工程里接入，建议先做这几件事：

  1. 确认你的目标平台是否是 macOS / Linux 优先；
  2. 明确 Agent 需要操作的最小资源集合；
  3. 列出必须访问的目录、缓存路径、域名和端口；
  4. 梳理依赖安装策略，决定“依赖装在宿主机哪里”；
  5. 明确是否需要额外叠加 timeout / 资源限制。

这一步其实比“npm install”更重要。
因为沙箱真正难的不是装上，而是正确建模权限边界。

安装方式

如果你是做产品集成，更推荐把它装到项目依赖里，而不是只做全局 CLI。

npm install @anthropic-ai/sandbox-runtime

为什么推荐装到项目里？

因为这样你可以：

  • 把沙箱配置和 Agent 工具链一起版本化；
  • 在应用启动时动态生成策略；
  • 在不同任务里按需切换不同沙箱配置；
  • 把初始化、包装命令、日志采集纳入自己的执行框架。

全局 CLI 更适合手工实验，项目依赖更适合真正产品化。

使用方式

常见调用方式是：

  1. 先初始化沙箱配置；
  2. 再把待执行命令包装成受控命令；
  3. 最后通过你自己的执行器去启动。

示意代码可以写成这样：

import { SandboxManager } from '@anthropic-ai/sandbox-runtime'

const config = {
  network: {
    allowedDomains: ['api.github.com', 'registry.npmjs.org', 'pypi.org']
  },
  filesystem: {
    denyRead: ['~/.ssh', '~/.aws', '~/.kube'],
    allowWrite: ['.', './tmp', './.sandbox-cache']
  }
}

await SandboxManager.initialize(config)

const sandboxedCmd = await SandboxManager.wrapWithSandbox(
  'python script.py'
)

如果你的 Agent 框架本身会调 shell、python、node 或编译器，那么最推荐的接入方式不是“把整个 Agent 套进去”，而是：

把所有高风险 tool call 的执行层统一包一层 sandbox runtime。

也就是让：

  • Agent 主循环仍在宿主进程里；
  • 真正执行 shell / script / tool 的那一跳进入沙箱。

这样会比“整个系统全部沙箱化”更容易控制，也更符合现有 Agent 框架的演进路径。

依赖怎么装

这个问题在实际落地里特别重要，因为很多人第一次接入就会踩坑：
沙箱限制了权限，但你的依赖到底装在哪？

推荐做法一：依赖提前装在宿主机虚拟环境里

如果是 Python 工具，最稳妥的方式通常是：

  • 先在宿主机创建 venv；
  • 把依赖装到这个 venv；
  • 再让沙箱只允许执行该 venv 下的解释器和项目目录。

例如：

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

之后让 Agent 调用：

.venv/bin/python your_tool.py

这样沙箱解决的是“它能访问什么”，而虚拟环境解决的是“它运行在哪套依赖上”。

推荐做法二：Node 工具依赖跟项目走

如果是 TypeScript / Node 侧工具，建议把 @anthropic-ai/sandbox-runtime 和业务依赖一起装在项目里，由项目本身管理 node_modules。
这样便于版本锁定，也更适合团队协作。

不太推荐的做法

不建议把“依赖安装”本身完全交给 Agent 在受限环境里临时处理，除非你已经把：

  • 写权限目录、
  • 缓存目录、
  • 制品源域名、
  • 执行工具链路径

都设计好了。

否则很容易出现这种情况： 沙箱本身没问题，但 pip install、npm install 因权限、缓存、路径、代理或锁文件位置被卡住，最后误以为是沙箱不可用。

最佳实践

如果你准备在产品里真正落地，我建议遵循下面这套方法，而不是“先全开，之后再补”。

1. 先做最小权限模型

默认只放行：

  • 当前工作目录；
  • 明确的临时目录；
  • 必需的包管理域名；
  • 必需的代码托管域名。

像 ~/.ssh、~/.aws、~/.kube、shell profile、全局配置目录，应该一开始就设为敏感路径。

2. 把沙箱放在 tool 层，而不是 prompt 层

不要指望通过 prompt 告诉模型“不要乱来”来替代底层约束。
正确方法是：模型可以自由决定动作，但动作真正落地时，必须经过统一的受控执行层。

3. 权限建模要按任务类型拆分

不同任务需要的边界完全不同。
例如：

  • 代码重构任务：允许写项目目录，不一定需要联网；
  • 依赖安装任务：允许访问 npm / PyPI，但未必需要读 SSH；
  • 文档生成任务：只需写 docs 目录；
  • Git 操作任务：可能需要读 .git，但不该碰用户全局配置。

最佳实践不是“一套配置走天下”，而是按任务模板生成不同沙箱策略。

4. 把它和 timeout / 审计日志一起用

sandbox-runtime 非常适合作为边界层，但你最好同时补齐：

  • 命令级超时；
  • 子进程树清理；
  • stdout/stderr 审计；
  • 违规访问日志；
  • 关键目录变更记录。

这样它才能从“研究性质的安全层”变成“能进入生产体系的执行边界”。

5. 不要把它当成环境管理器

这点值得重复一遍。
它负责限制权限，不负责帮你构建完美运行环境。
要把它和 venv、nvm、mise、direnv、项目级依赖管理一起搭配使用，而不是幻想它单独解决一切。

谁在用

从当前公开信息与业界讨论看，这条路线最典型的使用者当然是 Claude Code 这类本地 Agent 工具。它背后的需求非常明确：既要减少人为确认次数，又要让模型能在本地开发环境中真正自动执行。

除此之外，这套思路也特别适合下面几类工具：

  • 本地 CLI Agent；
  • IDE / 编辑器中的编程助手；
  • 基于 MCP 的本地资源访问层；
  • 本地自动化脚本代理；
  • 需要“读当前项目、受限写入、有限联网”的开发者工具。

换句话说，只要你的产品目标是“让 Agent 贴近用户真实环境工作”，而不是“把任务整个迁移进云端”，这一路线就非常有现实价值。

未来方向

从行业演进看，Agent 沙箱大概率会朝着三个方向继续发展。

1. 端云分化继续加深

本地场景会继续偏向 OS 级轻量沙箱，因为它最贴近开发者工作流；
云端场景则会继续偏向容器池、microVM 和托管 runtime，因为它们更适合多租户和高隔离需求。

2. 本地方案会补强审计与策略编排

单纯“能拦”还不够，未来一定会更重视：

  • 违规访问可观测性；
  • 策略模板化；
  • 多任务类型权限预设；
  • 与 MCP / tool registry 的深度联动；
  • 企业内网与本地代理联动审计。

3. 混合架构会成为主流

未来最现实的架构很可能不是单选题，而是：

  • 本地文件读写、轻量命令执行：走 OS 级沙箱；
  • 高风险脚本、重依赖环境、浏览器自动化：走容器或微虚拟机；
  • 统一由 Agent Orchestrator 根据任务类型进行路由。

在这个架构里，@anthropic-ai/sandbox-runtime 的角色不会是“唯一沙箱”，而会是：

本地执行路径上的默认安全底座。

结尾

如果只从“隔离强度”比较，@anthropic-ai/sandbox-runtime 当然不是最重、最硬的方案；但如果你真正理解它的定位，就会发现它恰恰打中了当下本地 Agent 最现实的需求：

  • 不重建环境，
  • 不脱离工作区，
  • 不依赖庞大基础设施，
  • 直接在 OS 层给 Agent 戴上手铐。

它的价值不在于“替代一切”，而在于它为本地 Agent 提供了一条非常务实的安全路径：
让 Agent 在真实环境里工作，同时把最危险的越界行为尽量挡在系统边界之外。

这也是为什么，在当前各种 Agent 沙箱路线里，如果你的场景是本地开发、CLI 工具、MCP 执行层、IDE 辅助，我会优先推荐 @anthropic-ai/sandbox-runtime。
它不是终局，但很可能是今天最值得认真研究和尽快落地的一块拼图。

💬 互动话题：你在开发 Agent 时，是如何解决代码执行安全问题的？踩过哪些坑？欢迎在评论区留言讨论！