01核心判断CORE JUDGMENT
F-012 把沙箱讲成给 Agent 的一间房：信任不该建立在"它不会犯错"上，该建立在"它犯错也出不了这间房"上。这篇笔记回答下一个问题：房间和房间不一样，怎么评？
核心判断是：沙箱不是一个安全插件，是权限工程的一种形态。评估一个隔离方案，评的不是"有没有沙箱"这个是非题，而是权限模型完不完整：边界在哪里定义、由谁定义、能不能改、出入怎么审。市面上的方案——从开源自建到托管服务——真正的差异集中在这些权限语义上，而不在隔离技术本身的名字里。
一句话版本：采购沙箱，采购的是一套权限语义；合同里要的不该是"隔离"两个字，该是四个维度的具体答案。
02"有沙箱"为什么不够THE CHECKBOX TRAP
"沙箱"一个词，盖住了巨大的实现差异：进程级隔离、容器、微虚拟机，强度差着数量级；临时房间和长驻房间，风险形态完全不同；有网络出口和没有网络出口，是两种世界。问"有沙箱吗"，得到的"有"，在信息量上约等于零。
类比很直接：问房东"门有锁吗"，不如问"钥匙在谁手里、配过几把、丢了怎么换"。锁的存在是最不重要的事实，锁的权限语义才是。
这就是打勾项陷阱：采购清单上写"需支持沙箱隔离"，供应商打勾，双方都觉得安全问题解决了——实际上双方只是就一个词达成了共识，而这个词没有定义。
03评估的四个维度FOUR DIMENSIONS
边界定义。F-012 的三面墙——文件、网络、资源——各自的粒度和默认值。关键看默认：默认全开、按需收紧的沙箱，实际是装饰；默认全关、按需开口的，才在做权限。追问方式很简单：什么都不配置时，房间里的代码能不能读到宿主的家目录、能不能访问外网？
生命周期。房间怎么生、怎么灭。用完即弃（每个任务新房间，干完拆掉）显著优于长驻（房间越住越"脏"，上个任务的残留成为下个任务的环境）；快照与还原能力决定了"出事回滚"是分钟级还是不可能。
出入管制。进：代码和数据怎么进房间，进去前有没有人或规则把关；出：产物怎么离开房间——这就是 F-012 说的那扇门，沙箱管过程，门管结果，没有出口管制的沙箱只做了一半。
可审计性。房间里发生的事有没有日志：跑了什么命令、碰了什么文件、连了什么地址。N-006 说过日志是"能从结果回溯到起点的链"；对沙箱，这条链还有个特殊价值——它是隔离方案自证清白的唯一方式：说"没出过事"，和拿出"每件事的记录"，是两种可信度。
04组织维度：配置也是权限CONFIG IS PERMISSION
技术维度之外，还有一层常被漏掉：谁有权改沙箱的配置。墙的位置如果人人可挪，墙就不存在。配置变更要有自己的权限分级和留痕——这是"权限的权限"，元层面的同一个问题。
与它相伴的是一个比"逃逸"更日常的风险：配置漂移。从公开的事故复盘看，戏剧性的沙箱逃逸在真实运维里是小概率事件，更常见的是这样的：为了让某个任务跑通，临时开一个网络口子，忘了关；为了调试方便，挂载一个宿主目录，留下了。房间还在，墙上的洞越来越多——每个洞在开的时候都有正当理由。对策不神秘：口子有到期时间，配置定期对账，漂移量进监控。
最后是审批粒度：隔离方案是"批一次、永久用"，还是随任务风险重新评估？前者省事，后者才和"动作按可撤回性分层"（N-006）的思想接得上。
05产品化的两面PRODUCTIZATION CUTS BOTH WAYS
已见的公开样本里，隔离方案正在从"安全团队自建"走向"产品化供给"：开源的 Agent 沙箱项目、把隔离执行做成服务的产品，都在增多。产品化的好处实在——下限被抬高了，小团队不必从零造墙。
但它同时把第 02 节的陷阱放大了："有沙箱"从一个需要工程投入的承诺，变成一个可以采购的打勾项。越容易打勾，越少有人追问四个维度。产品化解决的是"墙怎么砌"，解决不了"墙该砌在哪"——后者是权限设计，永远是使用者自己的作业。
所以判断保持不变：无论自建还是采购，评估的问题是同一组。供应商能替你回答"怎么隔离"，不能替你回答"隔离什么、对谁隔离、谁说了算"。
06边界声明BOUNDARY
本篇的四维框架是对公开方案与通用安全工程实践的归纳，不针对、不评价任何具体产品；"产品化增多"是基于公开信息的观察，方向是否持续，站内信号台账继续跟踪。具体方案的强度对比（进程/容器/微虚拟机的技术细节）超出本篇范围——那是安全工程的专业领域，本篇只解决"非安全背景的人怎么问对问题"。
07检查清单CHECKLIST
- 什么都不配置时，房间的三面墙各是开的还是关的？
- 房间是用完即弃，还是长驻？还原一次要多久？
- 产物出房间，过不过那扇门？谁确认？
- 房间里的命令、文件、网络访问，有完整日志吗？
- 沙箱配置谁能改？改动留痕吗？口子有到期时间吗？
- 审批是一次性的，还是随任务风险重评？
- 最坏一次逃逸或泄漏，爆炸半径估过吗？