1. 什么是大模型里的"设计沙箱"？
1.1 一句话解释：让大模型在安全边界里动手干活
大模型本身只是生成文本，它并不会天然拥有"执行能力"。但在真实应用里，我们常常希望它能分析文件、运行代码、调用 API、生成图表、处理图片、打开网页、检索数据库。这时候就需要把模型和外部工具连接起来。问题是，一旦模型能调用工具，它就不再只是"会说话"，而是开始"能行动"。
所谓大模型沙箱，就是给这些行动加上一层可控环境。它允许模型发起工具调用，但真正执行必须在隔离环境里完成，并受到权限、网络、文件、资源、时间、日志和审计的约束。
通俗地说，沙箱就像给 Agent 准备的一间实验室：里面可以运行代码、处理文件、尝试方案，但不能随便翻宿主机文件、不能随便访问内网、不能无限占用资源，更不能拿到生产密钥。
2. 为什么大模型应用越来越需要沙箱？
2.1 因为模型不可靠，用户输入也不可靠
大模型可能会生成错误命令，也可能会误解用户意图。用户输入里也可能夹带恶意提示，比如让模型忽略系统指令、读取环境变量、删除文件、上传数据。这类问题在普通聊天里最多是回答错，但在工具调用和代码执行场景里，错误会变成真实动作。
所以，沙箱设计的第一原则就是"不信任"。不完全信任用户输入，也不完全信任模型输出，更不让模型直接碰生产资源。模型可以提出"我想调用某个工具"，但应用层必须校验：这个工具能不能用？参数是否合法？是否越权？是否会带来危险后果？
2.2 因为工具调用会带来真实后果
如果一个 Agent 只是写一段解释，即使错了也可以重来。但如果它能运行代码、写文件、访问数据库、调用业务 API，就必须考虑安全边界。比如数据分析助手需要读用户上传的 Excel，但不应该读取服务器上的其他文件；代码执行器可以安装依赖，但不应该任意访问外网；客服 Agent 可以查询订单，但不应该绕过权限查询所有用户订单。
3. 大模型沙箱架构应该怎么设计？
3.1 不要把沙箱理解成一个 Docker 容器，它是一整条安全执行链路
很多人一提沙箱，第一反应就是容器。但在大模型应用里，沙箱不是某一个技术点，而是一个完整系统。它至少包括入口层、模型决策层、策略护栏层、沙箱管理层、隔离执行层和结果层。
入口层负责鉴权、限流和输入清洗；模型决策层负责理解任务并生成工具调用意图；策略护栏层负责判断这个调用是否安全；沙箱管理层负责创建隔离环境、分配资源、挂载文件；执行层负责真正运行代码或工具；结果层负责输出过滤、日志审计和 Trace 回放。
4. Tool Calling 和沙箱是什么关系？
4.1 模型只负责发起调用，应用层负责真正执行
工具调用的典型流程是：应用先告诉模型有哪些工具可以用；模型根据用户问题生成一个结构化工具调用请求；应用收到请求后校验参数，并在应用侧执行工具；执行结果再交回模型组织最终回答。OpenAI 的函数调用文档也把这个流程拆成多步：请求模型、接收工具调用、应用侧执行、把工具输出交回模型、再得到最终答复。
这就说明一个重点：模型不应该直接执行代码。模型只是"建议调用什么"，执行应该发生在应用侧，并且最好发生在受控沙箱里。
5. 沙箱有哪些常见类型？怎么选？
5.1 容器沙箱：最常见的工程方案
容器适合大多数代码执行、数据分析、文件处理场景。它的优势是生态成熟、启动快、成本相对低，也方便用 Kubernetes 或其他调度系统管理。但容器不是绝对安全边界，具体安全性取决于配置，比如是否限制系统调用、是否只读挂载、是否禁网、是否限制资源、是否避免特权模式。
5.2 微虚机或虚拟机：更强隔离，但成本更高
如果执行的是高风险代码，或者涉及强合规场景，微虚机和虚拟机往往比普通容器更稳。代价是启动速度、资源成本和运维复杂度更高。
5.3 WebAssembly：轻量、权限细，适合安全执行小任务
WebAssembly 适合轻量脚本执行、浏览器侧或本地隔离。它启动快，权限边界细，但系统能力和生态不如完整容器，通常不适合需要复杂依赖和重计算的任务。
5.4 远程 Sandbox：开箱即用，适合 Agent 快速搭建
像 E2B 这类沙箱基础设施，主要面向 AI Agent 的安全代码执行环境。它适合快速搭建 Agent 的执行能力，但要评估数据合规、成本和对第三方服务的依赖。LangChain 也有 Sandbox 工具思路，把代码执行封装成工具，Agent 在需要执行时调用沙箱工具，而不是直接在本机运行。
6. 权限控制怎么设计？
6.1 最小权限是核心原则
沙箱不是"放进去就安全"，真正安全的是权限足够小。默认应该禁止一切能力，需要什么能力再按需开放。比如任务只是分析用户上传的 CSV，就只挂载这个文件，不要挂载整个项目目录；任务不需要访问网络，就默认断网；任务只需要访问某个 API，就用 allowlist 只允许访问指定域名。
6.2 六条边界一定要管住
文件边界：限制可读写目录，敏感文件不挂载。网络边界：默认禁网或白名单。资源边界：限制 CPU、内存、磁盘和执行时间。密钥边界：不把真实密钥交给模型或沙箱，而是通过服务端代理调用。工具边界：工具白名单和参数校验。输出边界：执行结果要脱敏、过滤和审计。
7. 沙箱生命周期如何管理？
7.1 一次任务一个临时环境，用完就销毁
在多用户 Agent 系统里，最稳妥的方式是：按任务创建临时沙箱，初始化必要环境，执行任务，净化结果，然后销毁环境。这样可以最大限度减少状态污染，也能避免不同用户之间互相影响。
7.2 生产环境还要考虑启动速度和资源回收
为了降低启动延迟，可以把常用依赖做成基础镜像，也可以维护一批预热沙箱。为了避免资源泄露，必须设置最大执行时间、最大空闲时间、最大磁盘占用和强制回收策略。沙箱不是创建完就完事，真正麻烦的是高并发下的资源调度、状态清理和日志追踪。
8. 常见风险与治理方案
8.1 Prompt Injection：让模型越权的常见入口
用户可能在输入、文档、网页内容里嵌入恶意指令，诱导模型忽略系统约束、读取密钥、外传文件。治理方式包括工具白名单、参数校验、敏感操作确认、上下文隔离和输出审计。
8.2 代码风险：模型生成的代码必须当作不可信代码
模型生成的代码可能死循环、删除文件、访问网络、下载恶意依赖、扫描内网。治理方式包括只读文件系统、禁网或白名单、资源限制、依赖白名单、执行超时和日志告警。
8.3 数据泄露与资源爆炸
数据泄露通常来自密钥暴露、文件越权和任意外连；资源爆炸则来自长时间运行、大文件生成、重复工具调用。治理时要把安全和成本一起看：CPU、内存、磁盘、网络、token、工具调用次数，都应该有预算。
9. 大模型沙箱适合哪些场景？哪些场景不适合？
9.1 适合：数据分析、代码执行、文件处理、实验验证
沙箱非常适合数据分析助手、代码执行器、文件格式转换、图表生成、测试运行、网页提取、教学演示和 Agent 实验环境。这些场景共同特点是：模型需要动手执行，但执行内容可以放在隔离环境里，而且结果可检查、可回滚。
9.2 不适合：直接操作高危生产资源
不建议让沙箱直接持有生产数据库写权限、长期高权限密钥，也不建议让它执行不可回滚动作，比如转账、删除账号、批量发货、批量退款。高风险动作应走审批、二次确认、dry-run 或人审流程。
10. 如何评估一个沙箱设计是否靠谱？
10.1 安全指标、稳定指标、成本指标都要看
安全指标包括越权拦截率、敏感数据泄露次数、网络违规访问次数、危险命令拦截次数。稳定指标包括任务成功率、失败率、超时率、回收成功率、环境启动耗时。成本指标包括单次沙箱成本、平均运行时长、CPU/内存使用率、缓存命中率。
10.2 还要能复盘
上线后，必须能回答：这次任务是谁发起的？模型为什么选择这个工具？工具参数是什么？策略层有没有放行？沙箱里执行了什么？读写了哪些文件？访问了哪些网络？结果有没有经过过滤？这就是 Trace 和审计的价值。
11. 面试高频追问怎么答？
11.1 大模型为什么需要沙箱？
因为一旦模型具备工具调用和代码执行能力，就会产生真实副作用。沙箱可以把这些动作限制在隔离环境里，控制文件、网络、资源和权限，避免模型错误或恶意输入造成安全事故。
11.2 沙箱和普通 Docker 有什么区别？
Docker 可以是沙箱执行的一种实现方式，但大模型沙箱不等于 Docker。它还包括权限策略、工具校验、网络控制、密钥代理、结果过滤、审计日志和生命周期管理。
11.3 如何避免模型偷看密钥？
不要把密钥以环境变量或文件形式暴露给沙箱。高权限调用应该由服务端代理完成，沙箱只拿到短期、低权限、范围受限的凭证，最好还要有调用审计和额度控制。
11.4 如果沙箱执行失败怎么办？
先记录错误和 Trace，再按错误类型处理：依赖缺失可以重试或切换镜像；超时可以缩小任务；权限不足可以解释原因；高危操作应拒绝并提示用户。不要把底层错误栈原样暴露给终端用户。
12. 总结：沙箱设计的本质，是给大模型的"行动能力"加安全边界
大模型沙箱不是为了让模型更自由，而是为了让模型安全地执行。它让 Agent 可以写代码、跑脚本、处理文件、访问工具，同时通过隔离、权限、资源、网络、密钥和审计，把风险控制在可接受范围内。
真正成熟的沙箱设计，不是"我用了容器"，而是能讲清楚：模型怎么发起工具调用，应用层怎么校验，沙箱怎么创建，权限怎么限制，执行结果怎么过滤，日志怎么审计，失败后怎么回收和降级。
面试时只要抓住一句话就够了：大模型沙箱的核心，是让模型能动手，但不能乱动手。
附：30 秒快答模板
"大模型沙箱是为了让 Agent 在可控环境里执行代码、调用工具、处理文件和访问外部资源。设计时我会分成模型决策层、策略护栏层、沙箱管理层、隔离执行层和观测审计层。模型只负责提出工具调用意图，应用层要做权限校验、参数校验和风险判断，再把任务放到容器、微虚机、WebAssembly 或远程沙箱里执行。沙箱必须遵守最小权限、短生命周期、网络限制、资源限制、密钥不暴露和全链路审计。它的核心不是让模型更自由，而是让模型安全地动手。"