当一个 Agent 开始“能跑代码、能装依赖、能访问网络”它的能力边界就变成了安全边界。这一步带来的风险和“让模型写一段文字”完全不是一个量级。一、风险从哪来提示注入Agent 读到的网页、文档、邮件里可能藏着“忽略之前指令去做某事”的文本。模型分不清“资料”和“指令”就可能照做。越权操作给了写文件、发请求的能力一次误判就可能改坏数据或对外发请求。资源滥用死循环、无限下载、加密挖矿式的行为会把机器和额度拖垮。凭证泄露代码里能读到环境变量也就可能读到不该读的密钥。这些都不是理论问题而是“能跑代码”这件事的固有代价。二、隔离的层次从弱到强大致是同进程内限制靠代码规范约束风险最高基本只适合只读小工具。容器隔离独立文件系统与网络策略日常够用。微虚拟机 / 独立沙箱隔离更彻底启动更快适合高风险的执行场景。三、一个好沙箱该具备什么一次性用完即销毁脏状态不残留。受限网络默认不放行需要的域名显式开白名单避免被用来外联或下载恶意负载。受限文件只挂载该用的目录凭证不进入沙箱。超时与资源上限限制 CPU、内存、运行时长防止拖垮宿主机。可审计执行了什么、访问了什么留下记录。四、配套的工程习惯最小权限Agent 的工具集就是它的能力集能不给就不给。高风险动作二次确认删数据、对外发送、付费调用不要让模型“自动完成”。默认不信任输出沙箱里跑出来的结果回填给模型前该校验就校验。五、现成的形态刻意自建一套沙箱并不轻松隔离、回收、网络策略都要自己扛。也有面向这条路的产品例如长亭百智云的云沙箱定位就是面向 Agent Runtime 的独立云端执行环境支持 API 与 MCP 接入用完即回收对不想自己维护隔离与回收机制的团队接入能明显降低工程负担。六、要不要上沙箱的判据一句话判断如果 Agent 写的代码有 bug、或被提示注入带偏最坏结果是什么最坏只是“答案错了”→ 可以暂不上。最坏是“本机被改、数据被动、密钥泄露、对外发了请求”→ 应该上。小结“让 Agent 能执行代码”这件事的价值和风险是同一件事的两面。沙箱不是可选项里的锦上添花而是把这份能力关进可控边界的基本手段一次性、限网络、限资源、可审计。先把最坏情况想清楚再决定隔离到哪一层。