应根据工作负载的代码可信度、网络访问、凭据、生命周期、文件系统、状态和资源上限，为 agent 选择计算方式。范围受限的 API 调用不需要沙箱。不受信任的生成代码则需要隔离，而普通应用进程或容器配置可能无法提供足够保护。
这套升级阶梯可以避免简单的数据库读取获得文件系统和 shell，同时让高风险代码远离长期有效的应用凭据。
使用能够满足任务的最低层级
flowchart TD
A[Scoped API call] -->|needs application logic| B[In-process function]
B -->|needs async or longer work| C[Background job]
C -->|needs package or process isolation| D[Isolated process or container]
D -->|runs untrusted code| E[Hardened sandbox]
E -->|needs full machine control or long-lived isolation| F[Dedicated VM]
升级层级会增加能力和运维工作，但不会自动提高安全性。拥有无限制网络访问和生产凭据的沙箱，可能比范围严格受限的服务端 API 更危险。
第 0 层：范围受限的 API 调用
如果任务已经可以表达为数据库查询、对象读取、邮件发送或部署请求，应使用类型明确的后端操作。Agent 只提供受约束的参数，凭据、授权、校验和审计则由服务端负责。
这一层不提供通用代码执行。它应该是普通产品操作的默认选择，也符合语义化工具设计原则。
第 1 层：进程内函数
对于能在请求生命周期内完成的短时、可信转换和编排，应使用应用代码。限制可用模块，并避免提供商密钥进入模型可见输入。
这一层不能通过 eval、shell 或动态 import 运行生成的代码。超时可以终止请求等待，却无法可靠停止所有子进程或外部影响。
第 2 层：后台任务
如果任务可能超过请求超时时间、需要计划重试，或应该独立控制速率，应移入队列。持久化操作记录并确保任务具备幂等性，因为队列可能重复投递。
任务 worker 提供持久调度，但不构成安全边界。它通常运行可信应用代码，访问权限也与服务相似。持久执行指南介绍了检查点和结果未知的场景。
第 3 层：隔离进程或容器
对于需要安装依赖、使用文件系统或采用不同 CPU 与内存限制的可信代码，应使用独立进程或容器。移除多余权限，尽可能使用只读基础文件系统，只挂载必需文件，并限制出站网络访问。
除非平台提供更强边界，否则容器会共享宿主机内核。应将它视为工作负载打包和进程隔离方式，再判断运行时配置是否符合威胁模型。
第 4 层：强化沙箱
不受信任或模型生成的代码应该在沙箱中运行。为每次运行提供临时文件系统，严格限制 CPU、内存、进程数量和墙上时间，并为出站网络设置允许列表。只注入任务范围的凭据，运行结束后撤销凭据并销毁环境。
清理前将已批准的输出持久化到对象存储。扫描产物，并避免向模型返回不受限制的 stdout 或二进制内容。沙箱指南介绍了逃逸路径和测试用例。
第 5 层：专用 VM
如果任务需要独立内核边界、特权系统行为、特殊依赖、长期桌面环境或客户专属隔离，应使用专用虚拟机。强化镜像、限制 metadata service 访问、及时打补丁，并定义销毁流程。
不能只因为 agent 曾经使用，就让 VM 永久存续。长期运行的计算机会不断积累凭据、文件、软件包和网络信任。不需要持久化时，应从已知镜像重新构建。
选择层级前判断六项要求
- 代码可信度： 所有指令和依赖是否都由团队控制，还是用户或模型可以提供代码？
- 权限： 工作负载必须访问哪些凭据和资源？
- 网络： 它不需要网络、只需固定允许列表、需要访问公网，还是需要访问私有服务？
- 生命周期与状态： 它会在几秒内结束、等待数小时，还是需要一台持久运行的计算机？
- 运行时能力： 它是否需要 shell、浏览器、安装软件包、可写文件系统、内核功能或 GPU？
- 资源上限： 哪些 CPU、内存、进程、输出和费用限制可以阻止任务失控？
Cloudflare 的 Project Think介绍了一种相似的 agent 工作负载分层设计。具体产品映射因提供商而异，但通用思路不变：只有需求确实增加时，才从范围受限的操作升级到隔离计算。
测试真实边界，而不是名称
验证文件系统挂载、网络出口、密钥可见性、进程限制、终止、产物导出和清理。在隔离环境中尝试访问禁止的主机和其他租户的资源。确认平台记录了创建此次运行所用的镜像、策略、身份和操作。
下方的提示词会先对当前工作负载分类，再提出基础设施建议。它通常能找出完全不需要 shell 的任务，这比把容器改名为沙箱更能改善安全性。