DeepSeek Harness 权限与审批：给 Agent 上一把 human-in-the-loop 的安全阀

这是「工程化五篇」的最后一篇，也把 DeepSeek Harness 系列收个尾。前十二篇从「是什么」一路走到「怎么生产化」，最后必须回答一个绕不开的问题：Agent 要读写你的文件、执行你的命令，凭什么？谁说了算？

Harness 的答案是两层：**用户审批（User Approval）**决定「这一次具体动作能不能放行」，**权限预设（Permission Presets）**把「沙箱模式 + 审批策略」打包成用户一眼能懂的开关。这一篇就讲这俩。

一、审批服务：一个问题，四个答案

用户审批的 seam（ctx.approval）回答的唯一问题是：「这个具体动作，可以继续吗？」

它持有共享的请求/结果词表、ctx.approval 分发服务、approval/request 的 answerer waterfall、log-only 的审计对，以及每个会话的 ask/never 策略。UI 通道可以提供人类 answerer，ACP 自动化桥则为它自己的 agent 提供一次性机器决策。

每次请求都会拿到一个全新的 ApprovalRequestId，结果是一个封闭的、fail-closed 的枚举：

ts 复制代码

type ApprovalOutcome = 'allowed-once' | 'rejected' | 'cancelled' | 'unavailable'

allowed-once：唯一的一种「放行」，而且只放行被问的那个动作，一次性；
rejected：明确拒绝；
cancelled：请求被中止撤回；
unavailable：没有 answerer 能答（缺失、不拥有、抛错、返回非法值都归到这一档）。

最关键的是那句：调用方（如 tools、tool-bash）只认 allowed-once，其余全部 deny，unavailable 也 fail-closed。换句话说，宁可误伤也不误放------「没人回答」绝不等于「默认通过」。

二、ask / never：策略在 answerer 之前生效

ApprovalPolicy 决定「在交互式 answerer 跑之前，先发生什么」：

ask（默认） ：委托给组合好的 answerer 链，链上没人答就落到 fail-closed 的 unavailable；
never ：不 prompt 任何人 ，每次询问确定性返回 rejected。这是「严格 headless 姿态」（CI、无人值守运行）用的，它的结果是「不用问也能知道」。

策略在 waterfall 分发之前就在服务内部强制执行了------所以哪怕有 answerer 后来用 prepend 注册，也绕不过 never 。这个顺序保证了一个底线：never 就是真的 never。

真正的决策走 approval/request 这条 waterfall ：answerer 拥有该请求就返回结果，否则调 next() 委托给下一个；第一个 answer 占据唯一的决策槽。

ts 复制代码

// 概念示意：注册一个审批 answerer
ctx.on('approval/request', (req, next) => {
  if (req.toolName === 'bash' && isDangerous(req.reason)) {
    return askUserInUI(req)      // 拥有并决策，返回 ApprovalOutcome
  }
  return next()                  // 不拥有，委托给下一个 answerer
})

三、审计对：问过、也记下「怎么答的」

审批不是黑盒。每一次询问，服务都会追加一对 log-only 的审计事件：

approval/asked：问过了什么；
approval/decided：最终怎么答的。

ApprovalRequestId 把这一对事件配对，但故意不让它和 tool-call id 或 agent/session id 互换 ------每个身份域各归各。这对审计事件 log-only，不进模型 transcript：模型可见的，是调用方派生出的工具结果，加上当前运行时上下文快照。

这意味着什么？你事后能完整回放「某次危险操作，当时问了什么、谁批的、批没批」，而这一串审计又不污染模型的记忆。可追溯性（第六篇）在这里又和安全性（第七篇）接上了------Harness 的这些能力从来不是孤岛。

四、权限预设：把两个旋钮打包成一个开关

沙箱模式和审批策略是两个独立的旋钮，但对普通用户来说「两个旋钮」不如「一个开关」直观。权限预设层就是干这个的：

ts 复制代码

interface PresetSpec {
  sandbox: SandboxMode      // 'workspace-write' | 'danger-full-access' | ...
  approval: ApprovalPolicy  // 'ask' | 'never'
  name?: string
  description?: string
}

内置预设表默认就两条：

预设	sandbox	approval	含义
`workspace-write`	`workspace-write`	`ask`	只写工作区，危险动作要问
`danger-full-access`	`danger-full-access`	`never`	全访问，绝不问（最危险）

预设层自己不执行任何强制 ------它只是记录用户意图，然后通过每个旋钮自己的 setter 写进去。执行、prompt 叙事、replay 该读哪个旋钮还读哪个。切换时它会先追加一条 log-only 的 permission/preset 事件，再逐个写变了的那几个旋钮。

还有个派生概念 custom ：当会话当前的两个旋钮组合不匹配任何预设时，current() 返回 custom。它是派生态，永远不是切换目标------客户端可以显示它，但不能「切到 custom」。

五、避坑清单

unavailable 不等于放行 。answerer 没答、抛错、返回非法值，全都 fail-closed 成 unavailable，调用方一律 deny。别把「没人答」当成「默认通过」。
never 是硬底线 。它先于 waterfall 强制，prepend 注册的 answerer 也绕不过去。无人值守场景想要「绝不弹窗」，就用 never。
allowed-once 只批一次。它只放行被问的那一个动作，不是「这一会话放行」也不是「这一类动作放行」。高频危险操作会反复问，这是特性不是 bug。
审计对是 log-only，别指望它进模型 。approval/asked + approval/decided 不进 transcript，模型看到的是派生工具结果 + 上下文快照。要用它做追溯，去会话日志里查，别去 prompt 里找。
预设只记意图不执行强制 。permission/preset 事件是记录「选了哪个」，真正的约束靠 sandbox mode 和 approval policy 各自的 setter 落地。别以为发了 preset 事件就等于强制作业完成了。

六、系列总结：回看这 13 篇

到这里，DeepSeek Harness 系列全部走完了。分两个半场：

上半场（01-08）------搞懂它是什么：

入门概念：Model + Harness = Agent，一切皆插件；
快速上手：安装、多模型、profile、黑匣子日志；
架构与评测：插件树、seam、轮次与步骤；
插件开发实战：注册工具、监听事件、提供服务；
Cordis 元框架：Context、副作用可逆、时空可组合性；
会话日志与可追溯性：resume / fork / replay / telemetry；
沙箱与安全机制：Landlock / Seatbelt / ACL；
子 Agent 编排：把 Claude Code / Codex 当员工。

下半场（09-13）------把它用进生产：

运行形态：web / headless / sdk 三种身份；
SDK 集成：Python 与 TS 双轨嵌入；
配置与 Patch：改行为不碰源码；
可观测性：OpenTelemetry 遥测；
权限与审批：human-in-the-loop 安全阀。

如果整个系列只记一句话，我会选这句：DSH 的价值不在某一项功能，而在于它把 Agent 技术栈的组装权------包括「谁能动什么」的决策权------交还给了开发者。 从「模型是零件」到「工具是插件」到「子 Agent 是员工」到「权限是 seam」，它始终在做同一件事：去锁死、可替换、可组合、可归因。

它今天未必是你生产环境的最优解，但它揭示的方向------Agent 的每个能力都该是可插拔、可审计、可被安全策略约束的------大概率会成为接下来几年这个领域的主旋律。啃下这 13 篇，无论未来哪个 Harness 胜出，你对「Agent 该怎么搭、怎么管」都会有一张清晰的地图。

参考：deepseek-ai/deepseek-harness 官方仓库 docs/subsystems/approval.md、docs/subsystems/permission-presets.md。