dsh-plugin-auto-review

English | 中文

给 DeepSeek Harness（dsh）加一个 auto mode：会话处于受审查的权限预设时，每一条 shell 命令在执行之前先交给一个 review 模型，模型决定放行、转人工、还是拒绝。

它把"每条命令都弹窗问人"换成"由模型判断"，而不是换成"无条件信任"。

结论	行为	主模型 / 用户看到什么
allow	继续 tools/pre-execute 瀑布流（next()）	无任何额外内容，命令照常执行
ask	返回 { kind: 'ask' }，经 ctx.approval 路由	弹出人工权限确认框，并附带 review 理由
deny	返回 { kind: 'deny', reason }	工具报错结果里带着拒绝理由，主模型据此调整

review 无法完成时（没有可用模型路由、超时、传输错误、返回值无法解析）不会默默放行，而是落到 onUnavailable（默认 ask）。

沙箱升级（sandbox_permissions）刻意不由模型代答：离开文件沙箱仍然是人的决定，这类审批请求原样交给人工应答者。

工作方式

插件只注册一个 tools/pre-execute 监听器，自身不持有任何状态：

1. 工具名不在 tools 里、或调用方会话当前的权限预设不在 presets 里，直接放过 —— 其它会话的行为与没装这个插件完全一致。
2. 把命令、声明用途、工作目录、解析出的沙箱模式与工作区根目录组成 JSON，发一次有上限的辅助模型请求（ctx.llm.stream）。
3. 回答必须是一个 JSON 对象 —— {"decision":"allow"|"ask"|"deny","reason":"…"} —— 再映射到 harness 自己的 PreToolDecision 词汇表。

harness 本体一行未改：tools/pre-execute 提供待执行的调用，ctx.approval 提供人工通道，ctx.permissionPresets 提供 GUI 里已经能渲染的模式开关。

安装

dsh plugin --profile web add dsh-plugin-auto-review

然后在该 profile 的 cordis.patch.yml 里加上受审查的预设与插件行：

- id: permission
  config:
    defaultPreset: workspace-write
    presets:
      read-only:        { sandbox: read-only,          approval: ask }
      workspace-write:  { sandbox: workspace-write,    approval: ask }
      auto:
        sandbox: workspace-write
        approval: ask
        name: Auto (sandbox + review)
        description: workspace-write 之上，每条命令都过一遍 review 模型。
      auto-full-access:
        sandbox: danger-full-access
        approval: ask
        name: Auto (full access + review)
        description: 不用文件沙箱，改由 review 模型作为唯一的闸。
      danger-full-access: { sandbox: danger-full-access, approval: never }

- insert:
    - id: auto-review
      name: dsh-plugin-auto-review
      config:
        presets: [auto, auto-full-access]
        tools: [bash, pwsh]
        reasonLanguage: Chinese

patch 会整体替换目标行的 config，所以要保留的预设需要一并重写。这里必须显式给 defaultPreset：auto 与 workspace-write 的旋钮组合相同（workspace-write + ask），两者靠持久化的 permission/preset 选择区分。

当前会话用 /permission auto 切换；新会话的默认值在 Settings → Permission 里选。

该让哪个预设受审查？

预设	sandbox	什么时候用它
auto	workspace-write	宿主机有可用沙箱后端（bubblewrap / Landlock）：沙箱是外层边界，模型审查是第二道闸
auto-full-access	danger-full-access	宿主机没有可用沙箱后端，受限命令根本跑不起来：此时模型审查就是那道闸，用它取代每条命令的升级弹窗

配置项

键	默认	含义
presets	['auto']	受管的权限预设名；其它预设完全不受影响
tools	['bash','pwsh']	需要审查的工具名
provider / model	跟随会话路由	review 用的模型；两者必须同时给出
maxTokens	512	review 回答的输出上限
timeoutMs	30000	单次 review 的墙钟上限
onUnavailable	ask	review 无法完成时的兜底结论（ask / deny / allow）
maxCommandChars	4000	交给 review 的命令文本截断长度
skipPatterns	[]	命中任一正则则跳过 review 直接放行
reasonLanguage	English	理由使用的语言 —— 写死而不靠推断，因为这段文字会直接进人工弹窗

skipPatterns 默认空是有意的：宽松的正则就是闸门上的洞 —— ^ls 也能匹配 ls; rm -rf /。要用就锚定整条命令（^ls( -[a-zA-Z]+)?$），否则留空。

测试

npm test        # node test.mjs

用例把插件挂在一个假 ctx 上（不启动 harness、不联网），覆盖 allow / ask / deny 三条路径、请求框架、路由与预算选择、非受审工具与其它预设的放过、skipPatterns、无 agent 的调用、无法解析的回答、传输失败，以及被 timeoutMs 兜住的卡死 review。

已知边界

• 每条被审查的命令多一次模型往返。 高频只读命令也照付；skipPatterns 是唯一的省法。
• 边界命令的判定不确定。 同一条命令这次 allow、下次 ask 都可能。要硬规则就改 reviewSystem() 里的规则（例如：读取工作区之外的任何路径一律 ask）。
• 审查者只看到一条命令，看不到对话。 只在会话历史里才能看出的意图它无法判断，所以"用途与命令不符"只能靠命令自身暴露。
• 只审查 shell 工具。 文件写入类工具交给文件沙箱与文件观察策略约束。
• 决策记录在 stderr（[auto-review] <decision>: <command> — <reason>），没有单独的持久化会话事件类型。

许可

MIT © 2026 Guangda Liu