Sandbox

上一篇我写过，为什么我最后选了 Anthropic 的 sandbox-runtime。 当时想得很简单。 我不想为了一个个人 AI 助手，一上来就搞 Docker、远程 VM、完整容器平台。 那套当然更强，但成本也更高。 我真正想要的是一个轻量边界：Agent 还能在本机干活，但不能随便摸到宿主机所有东西。 所以我选了 Anthropic 的 runtime。 但真正接进去以后，我很快发现一件事： 沙箱不是一个开关。它更像 Agent runtime 里的一条执行边界。 尤其是 Molibot 这种形态。 它不只是一个网页里的聊天框。 它同时服务 Web、Telegram、飞书、微信、QQ。 里面还有 subagent、工具调用、审批恢复、长任务、会话持久化。 这时候真正难的，已经不是“怎么把命令放进沙箱跑”。 真正难的是： 当沙箱挡住 Agent 时，runtime 接下来应该怎么办？ 这篇就记录一下，我把 sandbox-runtime 接进 Molibot 时踩过的几个坑。 我一开始只想给 bash 套一层沙箱 Molibot 是我自己做的本地优先 AI 助手。 它的核心不是某个聊天入口，而是一套共享 runtime： Web Chat 可以对话、传文件、看运行状态； Telegram、飞书、微信、QQ 都接到同一套 Agent； Agent 可以调用 bash、MCP、图片生成、搜索、subagent； 会话、设置、审批记录、任务记录都落在本地 JSON/SQLite。 所以我最开始的目标很克制： 先只管 Agent 和内置 subagent 的 bash； Browser、MCP、渠道收发先不进沙箱； 普通 shell 默认在 sandbox 里跑； 文件系统、网络、环境变量从设置页控制； 真要用宿主机能力，再走人工审批。 听起来是一个挺正常的工程任务。 ...

上周我尝试让 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 映射、路径同步、宿主文件和容器视图的一致性……一堆问题等着你。它更适合“把任务送进隔离盒子执行”，不太适合“在我当前工作区无缝协作”。 ...

我一开始以为，给 Agent 加 Sandbox 这件事并不复杂： 把 bash 套进隔离层 限一下文件系统 限一下网络 再处理一下环境变量 但真把它放进一个真实产品里，问题马上就不是“能不能隔离”，而是： 既要让 Agent 真能干活，又不能让它顺手把宿主机掀了。 这次我在自己的 Agent Runtime 里，先后被两个非常具体的场景逼着重构权限模型： curl 在沙箱里访问网络，一直报错 agent-browser 要打开网页并截图，但它本质上不是普通网络请求，而是宿主浏览器能力 最后我做出来的，不只是一个 Shell Sandbox，而是一整套： bash 执行边界 Host Capability 审批 白名单复用 自动续跑 配置脱敏 多渠道结构化审批 这篇文章，我就完整讲讲这套东西是怎么从真实问题里长出来的。 我在真实 Agent 产品里落地 Sandbox 的全过程 从 curl 报错，到 agent-browser 审批升级，我是怎么把权限、审批、配置安全真正做成产品能力的 如果你最近在做 Agent，而且这个 Agent 不是纯聊天，而是真的会： 调 bash 装依赖 读写文件 连网 调本机工具 打开网页、截图、控制浏览器 那你迟早会遇到一个问题： “让 Agent 能干活”和“让 Agent 不乱来”之间，根本不是加一个开关就能解决的。” 一开始我也以为，所谓 Sandbox，无非就是： 把 bash 套进一个 OS-level sandbox 限文件系统 限网络 再处理一下环境变量 听上去很合理。 但真把它放进一个真实产品里，你很快就会发现： ...

过去一年，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 体系或基于它的代码执行平台。它的优势是隔离强度极高，接近虚拟机级别，天然适合云端多租户场景，也更适合执行不可信代码。 ...