一、实测到的三档

配置里真实写着三档预设，每档都是【沙箱 ＋ 审批】一对：

• read-only——沙箱只读，审批 ask。
• workspace-write——沙箱写工作区，审批 ask（默认）。
• danger-full-access——全权，审批 never。

默认值从环境变量来：DSH_PERMISSION_MODE 没设就按 workspace-write。

二、算一笔账：为什么不用三个开关

假如把【只读】【可写】【全权】做成三个独立开关：

• 三个开关有 2 的 3 次方 ＝ 8 种组合；
• 其中一半是自相矛盾的——比如【只读沙箱 ＋ never 审批】：看起来最严，实际上连问都不问。

改成三档枚举，就只有 3 种组合，每一种都自洽。

这就是【单调】要解决的问题：规则不能出现【比上一档更松，却号称更严】的状态。

三、单调在工程上意味着什么

• 可以整档收紧：从 workspace-write 收到 read-only，一定是变严。
• 可以整档放松：反过来一定是变松，且放松的那一档自带显式标记（danger-full-access 这个名字就是警告）。
• 不能部分放宽：想要【只读但允许删临时文件】这种口味，档位里没有——要么进档，要么写自己的规则插件。

换句话说：单调的代价是灵活性，换来的是可推理——看到档位名就知道能做多少事。

四、为什么 Guard 尤其需要单调

因为 Guard 是收口的地方：它一乱，后面所有判断都失去基准。

规则系统里最危险的不是【太严】，是【严得没有形状】——同一个操作这回被拦、下回放行，人就学会绕过它。

单调 = 可预期。可预期的守卫，才管得住一个会自己写程序的 Agent。

五、动手 Demo：三档权限与【单调】

三档枚举，加一笔组合数的账：

tiers = [
    ("read-only", "read-only", "ask"),
    ("workspace-write", "workspace-write", "ask   <- 默认"),
    ("danger-full-access", "danger-full-access", "never"),
]
for a, b, c in tiers:
    print("  %-20s %-18s %s" % (a, b, c))
print()
print("  三个自由开关: pow(2, 3) =", pow(2, 3), "种（一半自相矛盾）")
print("  三档枚举:     3 种（每种都自洽）")

实跑输出：

--------------------------------------------------------------------
三档权限与【单调】
--------------------------------------------------------------------
  配置里真实写着三档预设：

  档位                   沙箱                   审批
  ---------------------------------------------------------------
  read-only              read-only              ask
  workspace-write        workspace-write        ask      <- 默认
  danger-full-access     danger-full-access     never
  ---------------------------------------------------------------

  默认值从环境变量来：DSH_PERMISSION_MODE 没设就等于 workspace-write。

  算一笔账：为什么是【三档枚举】，不是三个独立开关？

    三个可自由开关的选项      2 的 3 次方 = 8 种组合
                              其中一半自相矛盾（比如只读沙箱配 never 审批）
    三个枚举档位              3 种组合，每一种都自洽

  【单调】的意思就在这儿：档位只能整档上、整档下，不能拼凑。
  规则一旦能自由组合，就会出现【比上一档更松，却号称更严】的怪状态。

三档不是【低中高】，是三份自洽的组合——每档里沙箱与审批已经配好对了。 默认那档来自环境变量：不设也能跑，但要知道自己跑在哪一档。 组合数的对比说明单调的价值：枚举用 3 种换掉了 8 种里的自相矛盾。

30 秒实验

1. 把三档表抄下来，指出哪一档允许【不问人就动手】。
2. 解释一下：为什么【只读沙箱 ＋ never 审批】是自相矛盾的组合？
3. 想一想你的日常场景该用哪一档——理由是什么？

常见误区

1. 错误：权限就是几个可以自由勾选的开关。——纠正：是三档枚举——沙箱与审批已经配好对，只能整档换。
2. 错误：danger-full-access 只是名字吓人。——纠正：它的审批是 never，真的不问人——名字就是警告。
3. 错误：单调限制太死，不实用。——纠正：单调换来的是可推理、可预期；真要更细的规则，就该写自己的规则插件。

• ☐ 下一节（4.5.2 Approval 与 Sandbox 为什么必须放在不同层）

相关笔记

• Tool Execution Pipeline：一次工具调用究竟要经历哪些阶段 —— 沙箱在调用中，审批在调用前
• 第三层：用 Hook 改变执行规则 —— 三档就是三条规则插件的组合
• 对系统漏洞进行量化评估 —— 把风险做成可比较的等级
• 🐳 DeepSeek Harness · 索引