沙箱拦得住「能不能跑」，拦不住「该不该跑」

Agent 一接到 shell 和写文件权限，团队最先加的往往是沙箱：容器、landlock、隔离目录，防止误删库、防扫盘。这很必要，但不够。

DeepSeek Harness 文档里有一句很清醒：强制约束留在独立的沙箱/审批轴上；plan mode、工具钩子、权限门禁是另一条线。换句话说，沙箱回答「这段代码在哪种隔离环境里执行」，权限回答「这一步在当前任务状态下允不允许发生」。两件事叠在一起，才叫生产级边界。

一、沙箱解决的是爆炸半径

沙箱的价值是：即使模型发出了危险命令，也尽量把破坏限制在可回收的空间里。文件系统隔离、网络策略、资源限额、进程生命周期，都属于这一层。

它擅长处理「跑错了」：删错文件、死循环占满 CPU、意外访问宿主机路径。它不擅长处理「不该跑」：在未审批时发生产部署、在只读任务里写生产配置、把客户数据拷到外网。

把所有安全希望压在沙箱上，等于假设危险动作可以发生，只要环境够硬。生产里更稳的假设是：很多动作根本不该进入执行队列。

二、权限解决的是合法动作集合

权限层看的是任务状态与动作语义。典型问题包括：

• 当前是 plan 模式还是执行模式？
• 这个工具是否在白名单？
• 写入路径是否越界？
• 是否需要人工审批后才能继续？

dsh 里 tools/pre-execute 这类钩子，本质上就是执行前的门禁：允许、拒绝、或改写决策。它和沙箱后端可以同时存在——先问该不该调，再问在哪跑。

一个实用判据：如果关掉沙箱，系统是否仍能拒绝明显越权动作？如果不能，说明你只有隔离，没有治理。

三、为什么必须拆成两轴

因为失败模式不同，修复方式也不同。

沙箱失败，表现是逃逸、误伤宿主机、资源打满。修复靠更强隔离与更清晰的工作区边界。

权限失败，表现是流程上「合法地做错事」：测试环境任务却调了生产 API，review 任务却直接 push main。修复靠状态机、审批点、最小权限签发。

混成一锅的后果是：出了事故，你说不清是隔离不够，还是门禁缺失。排障会变成互相甩锅。更糟的是，团队会用「我们已经有沙箱了」当作上线绿灯，却从未定义过哪些动作在当前阶段根本不该出现。

四、落地时怎么配

建议按这条顺序补齐：

1. 先定义工作区与默认拒绝：没声明的工具、路径、网络，一律不可用
2. 再上沙箱：让允许执行的动作也只能在隔离环境里发生
3. 给高风险动作加审批点：部署、删库、对外发送、改权限
4. 把门禁决策写进轨迹：谁允许、谁拒绝、依据哪条策略

plan mode 很适合做「先规划后执行」的闸：规划阶段可以读和提议，执行阶段才放开写与副作用。但请记住，plan mode 不是沙箱替代品，它管的是阶段权限。

还有一条容易忽略：权限要跟任务状态绑定，而不是只跟角色绑定。同一个 coding Agent，在「调研报错」和「合并发布」两种状态下，合法动作集合应该不同。

五、两个自检问题

第一，Agent 请求删除工作区外路径时，是沙箱拦住，还是权限层根本不放行？两者都拦最好；只有沙箱拦，说明治理偏晚。

第二，同一条命令在「调研任务」和「发布任务」里，权限是否不同？如果完全相同，说明你的权限没有绑定任务状态，只是静态工具列表。

结语

沙箱让错误更昂贵的破坏变便宜；权限让不该发生的动作更难发生。Harness 真正要守的，不是「代码跑得起来」，而是「在正确的约束下跑」。把隔离轴和审批轴拆开设计，系统才会既扛得住失手，也挡得住越权。