Agent 执行代码为什么需要沙箱？放进 Docker 就安全吗？

知识点详解：一段统计脚本，为什么可能影响业务服务器？

先确定它完成任务究竟需要什么

假设用户上传一份销售 CSV，希望 Agent 按月份汇总销售额，再生成一张图。

正常情况下，脚本只需要读这份 CSV，使用已准备好的分析库，把结果写到输出目录。它不需要读取其他用户的文件，不需要知道生产数据库密码，也不需要控制宿主机上的其他进程。

这就是设计执行环境的起点：从任务需要反推可用能力，而不是先把服务器上的资源都提供给它，再要求模型“不要乱用”。

即使没有人故意攻击，生成的脚本也可能出现无限循环、重复写文件、读取错误路径等问题。把代码交给另一个模型检查，可以帮助发现问题，但不能替代真正的执行限制。

一次任务的环境应该怎样准备？

对前面的 CSV 任务，可以给它单独的临时工作空间。输入文件放在只读位置，输出目录允许写入，其他任务的数据不挂进来。

同时，给运行过程设置时间上限、内存和 CPU 限额，并限制进程数、可写空间等资源。哪一种限制由哪个组件执行，要按实际运行时配置，不能以为开了一个容器就全部具备。

网络也要单独处理。如果统计不需要联网，就不开放外部访问。如果需要获取特定数据，优先通过受控工具或明确允许的出口访问，而不是提供不受限制的网络。

执行结束以后，后端读取退出状态和日志，检查输出文件是否在允许目录、大小和格式是否符合要求，再交给用户。不要让脚本通过返回一个路径，就让后端去读取任意宿主文件。

这套流程里，输入准备、运行限制、产物取回都是应用的职责。模型负责提出和编写任务代码，不负责批准自己的访问范围。

Docker 提供了什么，又没有自动解决什么？

Docker 会使用 namespace 等机制隔离进程看到的环境，用 cgroup 等机制管理资源，也可以结合 capability、seccomp 和其他系统安全措施收紧权限。Docker 安全文档说明了这些组成部分及配置风险。

但普通容器和宿主机通常共享内核，容器配置、运行时和内核漏洞仍然影响隔离效果。

更直接的问题甚至不需要漏洞：如果把宿主敏感目录挂进容器，并且允许写入，脚本就可能在已授予的权限范围内改掉里面的文件。把 Docker 控制接口暴露进去，也可能让代码获得远超本次分析需要的能力。

因此，“我用了 Docker”只是介绍了技术组件，还没有回答权限到底收紧到什么程度。面试时至少应该补上：哪些目录可见、是否允许出网、有没有敏感凭据、资源上限在哪里执行，以及任务之间怎样隔开。

什么时候需要评估更强的隔离？

如果只是内部可信代码执行，和向公开用户开放任意代码执行，风险差别很大。

后一种场景需要假设输入可能带有恶意，也需要考虑一个任务能否影响其他租户。除了收紧容器配置，还可以评估 gVisor、虚拟机或微虚拟机等方案。

例如，gVisor通过用户态应用内核处理许多系统接口，减少程序直接接触宿主内核的范围。它不是“再加一个容器标签”，也不是没有成本：系统调用兼容性、文件与网络性能，都可能影响程序运行。

选择时要用实际工作负载测试。CSV 分析能运行，不代表需要特殊系统能力的程序也能正常运行。更强隔离的收益，需要和启动时间、兼容性及运维复杂度一起考虑。

验收不只测“图能画出来”。还要确认访问未授权测试目录会被拒绝，超时任务能终止，任务 A 看不到任务 B 的输入，任务结束后临时环境不会继续留着敏感文件。测试用无敏感内容的专用样本，不必拿真实生产数据冒险。

面试官继续追问

把删除命令加入黑名单，能不能代替沙箱？

不能。程序可以通过不同库和系统接口完成相似动作，限制几个命令名覆盖不了全部路径。

命令检查可以作为辅助，真正的限制应落实在文件访问、进程权限和执行环境上。没有写权限时，换一种写法也不应该获得写权限。

代码需要安装依赖，怎么办？

可以把常用依赖提前放进受控镜像。确实需要动态安装时，再限定可信来源、包版本、网络范围和资源预算。

下载依赖本身也是执行风险的一部分。不要让“缺一个包”变成无限制访问网络、安装任意代码的理由。

有了沙箱，可以把生产数据库写权限交给它吗？

沙箱不会自动理解业务后果。即使宿主机没有受到影响，一段被授权的 SQL 仍然可能改坏业务数据。

高风险写操作应该走独立的受控接口，检查当前身份、操作范围、幂等性和必要审批。隔离计算环境，和批准业务动作，是两道不同的限制。

面试速记卡

• 基本假设：模型生成代码也属于不可信程序。
• 沙箱目标：限制文件、网络、权限和资源，不只更换运行位置。
• Docker 边界：提供隔离组件，但共享内核和错误配置仍有风险。
• 执行流程：最小输入、受限运行、检查产物、清理环境。
• 高风险操作：沙箱不能代替业务鉴权、幂等和审批。