AI Agent 在你电脑上跑命令,你真的放心吗

上周我尝试让 Agent 帮我重构一个项目（其实就是想偷个懒）。它跑了大概 20 分钟，中间噼里啪啦执行了四十多条 shell 命令——装依赖、改配置、跑测试，甚至还动了 .git 目录。

跑完我回头看了一眼日志，发现了其中的风险：中间有好几步，如果它命令写偏了一个字符（比如把 rm -rf ./tmp/ 写成了 rm -rf /），我的本地环境大概率挂了。

最可怕的是，当 Agent 每一步都弹窗问我“允许执行吗”的时候，我发现自己根本没仔细看——点了二十次“允许”之后，那个确认按钮已经变成了我的肌肉记忆（我甚至都想打开全部同意的权限）。

这就是今天要聊的问题：「Agent 越来越能干活了，但谁来管住它的手？」

弹窗确认，其实是个心理安慰

很多人觉得，让 Agent 每执行一步都弹窗确认就够了。看起来很“科学”，实际上有两个致命问题。

第一，「中断疲劳」。一个正经的重构任务，可能涉及十几次文件读写、几十条 shell 调用。如果每一步都确认，Agent 的自动化价值就直接归零了。你雇了个助手，结果它每个动作都要你签字，那跟你自己干有什么区别？（这还不如我自己手写呢。）

第二，「弹窗防不住真正的风险」。你真的能在 1 秒钟内审完一长串 bash 命令吗？被混淆过的脚本、链式调用、隐蔽的数据外带——肉眼根本看不出来。本质上，「弹窗确认是在把安全责任甩给用户，而不是在系统层面建立边界。」

「🔑 核心观点：车速越快，护栏越重要。你不能靠“每次变道都问一下副驾”来解决安全问题。」

真正可持续的方案是：「把 Agent 放进一个边界明确的区域，边界内自动跑，越界直接拦——不打扰，不甩锅，靠机制而不是靠注意力。」

这就是 Agent 沙箱要干的事。

三条路线，各有各的算盘

目前行业里做 Agent 沙箱，大致有三条路线。它们不是谁淘汰谁，而是各适合不同的场景（或者说坑位）。

1. 容器型：Docker 一把梭

把代码执行环境塞进独立容器，通过 API 和 Agent 主流程解耦。优点很明显：环境一致性好、多租户调度方便。很多云端 Agent 平台（比如那些做代码执行服务的）都走这条路。但如果你要做的是“让 Agent 在我的本地项目里帮我干活”，Docker 就有点笨了。Volume 映射、路径同步、宿主文件和容器视图的一致性……一堆问题等着你。它更适合“把任务送进隔离盒子执行”，不太适合“在我当前工作区无缝协作”。

2. MicroVM：最硬的隔离

Firecracker 体系，隔离强度接近虚拟机级别。云端多租户、不可信代码执行——这个路线非常合适。但基础设施太重，离用户太远。如果你做的是本地 CLI Agent、IDE 内嵌助手，你要的是“在我的机器上帮我干活”，而不是“先把上下文搬到云端再执行”。

3. OS 级本地沙箱：最轻，也最贴身

这就是 @anthropic-ai/sandbox-runtime 走的路线。不引入 Docker daemon，不搞虚拟化，直接调用操作系统原生的安全机制（给一个普通进程“戴上手铐”再运行）。它解决的不是环境一致性问题，而是「权限边界问题」。对于本地 Agent 来说，这个取舍非常关键——你最需要的不是再造一个新环境，而是在当前环境里以最小权限安全执行。

如果你不是在搭建云端平台，而是在做“让 Agent 安全操作本地工程”——真正重要的指标不是“能不能打成镜像”，而是：能不能直接作用于当前文件系统、能不能减少环境迁移成本、能不能把安全边界下沉到 OS 层、够不够轻以支持高频调用。

sandbox-runtime：克制，才是最大的优点

推荐 @anthropic-ai/sandbox-runtime，不是因为它功能最多，恰恰是因为它「边界最清晰」。

它只做两件事：「文件系统访问控制 + 网络访问控制」。不搞浏览器虚拟化，不做一体化桌面，不试图当大而全的 agent platform。

核心思想一句话：「Secure by default，按需打洞。」

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

跨平台实现上：

• 「macOS」：基于 sandbox-exec / Seatbelt profile 动态生成规则。
• 「Linux」：基于 bubblewrap + namespace 隔离，辅以 seccomp / 网络代理约束。

本质是 OS 原生机制驱动的本地轻量级进程沙箱——不是 Docker，不是 Firecracker，分类搞清楚，优缺点才看得明白。

怎么接？

接入之前，我建议先做以下五件事（这比 npm install 重要得多）：

1. 「确认你的目标平台」：是否 macOS / Linux 优先（Windows 用户可能得等等）。
2. 「列出最小资源集合」：Agent 真的需要读 ~/.ssh 吗？
3. 「梳理必须访问的资源」：包括目录、缓存路径、域名和端口。
4. 「决定依赖安装策略」：“装在宿主机哪里”这个问题要想清楚。
5. 「明确是否需要额外叠加」：比如 timeout 或资源限制。

沙箱真正难的不是装上，而是「正确建模权限边界」。

安装建议装到项目依赖里，而不是全局 CLI：

npm install @anthropic-ai/sandbox-runtime

装到项目里，你可以把沙箱配置和 Agent 工具链一起版本化，按任务类型动态切换策略。

最推荐的接入方式

不要把整个 Agent 套进沙箱，而是：「只把高风险 tool call 的执行层统一包一层 sandbox。」

Agent 主循环仍在宿主进程，真正执行 shell / script 的那一跳进入沙箱。这样比“全系统沙箱化”更容易控制，也符合现有 Agent 框架的演进路径。

示意代码（伪代码，感受一下逻辑）：

import { SandboxManager } from'@anthropic-ai/sandbox-runtime'const config = {network: {allowedDomains: ['api.github.com', 'registry.npmjs.org']  },filesystem: {denyRead: ['~/.ssh', '~/.aws', '~/.kube'], // 这些死也别给权限allowWrite: ['.', './tmp']  }}awaitSandboxManager.initialize(config)const cmd = awaitSandboxManager.wrapWithSandbox('python script.py')

依赖怎么装？这里最容易踩坑

很多人第一次接入就卡在这里——最后误以为是沙箱不可用，其实是 pip install 因为路径、缓存、权限被卡住了。

「我的建议是」：

• 「Python 工具」：先在宿主机建 venv，装好依赖，再让沙箱只允许执行该 venv 下的解释器。
• 「Node 工具」：把 @anthropic-ai/sandbox-runtime 和业务依赖一起装在项目里，由项目管理 node_modules。

不建议把“依赖安装”本身完全交给 Agent 在受限环境里处理——除非你已经把写权限目录、缓存目录、源域名都设计好了。

它不是银弹：五个短板你必须知道

推荐归推荐，但 sandbox-runtime 的短板必须讲清楚，因为它们决定了它适合做“本地执行边界层”，而不是“万能沙箱”。

1. 「解决的是权限隔离，不是环境隔离」：沙箱里跑的还是宿主机的 Python、Node。它负责限制权限，不负责管不同项目的运行时版本。
2. 「打洞配置并不轻松」：一个稍大的工作流可能要访问仓库、调用 git、连 npm……把边界收紧，就得逐条梳理资源。
3. 「网络控制有边界」：它的网络策略偏向“受控代理”，不是 microVM 级别的绝对网络封闭。
4. 「Windows 原生支持不是强项」：设计天然更适合 Unix-like 系统，Windows 开发者可能得走 WSL。
5. 「资源限制不是它的主战场」：它擅长限制“能访问什么”，不天然等于“能消耗多少资源”。死循环依然得靠额外的 timeout 解决。

落地五条建议

如果你准备在产品里真正用起来，我建议遵循这五条：

1. 「先做最小权限模型」：默认只放行工作目录。~/.ssh、~/.aws 这些一开始就设为敏感路径。
2. 「沙箱放 tool 层，不放 prompt 层」：别指望通过 prompt 告诉模型“不要乱来”。模型可以自由决定动作，但动作落地时必须经过受控执行层。
3. 「按任务类型拆权限」：代码重构允许写项目目录；依赖安装允许访问域名。一套配置走天下不如按任务模板生成策略。
4. 「补齐 timeout + 审计日志」：加上命令级超时、子进程树清理、stdout/stderr 审计。
5. 「别把它当环境管理器」：它负责限制权限。要和 venv、nvm、mise 搭配使用。

未来长什么样？

从行业演进看，Agent 沙箱大概率往三个方向走：

• 「端云分化继续加深」：本地场景偏向 OS 级轻量沙箱（最贴近开发者），云端偏向容器池 and microVM。
• 「本地方案补强审计与策略编排」：未来会更重视违规访问的可观测性、策略模板化、与 MCP 的深度联动。
• 「混合架构成为主流」：本地读写走 OS 级沙箱，高风险脚本走容器。sandbox-runtime 的角色是「本地执行路径上的默认安全底座」。

如果只比隔离强度，@anthropic-ai/sandbox-runtime 当然不是最硬的方案。但它打中了本地 Agent 最现实的需求：「不重建环境、不脱离工作区、直接在 OS 层给 Agent 戴上手铐。」

它的价值在于为本地 Agent 提供了一条非常务实的安全路径。如果你的场景是本地开发、CLI 工具、IDE 辅助——它很可能是今天最值得认真研究的一块拼图。

参考链接

• Anthropic Sandbox Runtime[https://github.com/anthropics/sandbox-runtime]
• Claude Code 安全架构[https://docs.anthropic.com/en/docs/claude-code/security]

「最后，留个互动：」

你在用 Agent 帮写代码时，有没有遇到过它“自作主张”删文件或者乱改配置的情况？你是怎么“管”住它的？欢迎在评论区聊聊。

「下篇预告：」sandbox 实践。