前言¶

在 DeepSeek Harness（DSH）里，工具调用不只有“能不能执行”的问题。内置工具、第三方工具和 MCP 工具进入同一个运行路径后，部署方常常需要按工具名和参数做统一约束：某些只读工具放行，某些 shell 或外部工具要求审批，某些删除类工具直接拒绝。

dsh-tool-policy 是一个针对 DSH 的社区插件，用来在工具调用执行前插入一层声明式策略。它不是 DeepSeek AI 维护的官方组件，也不等同于 DSH 官方的能力沙箱。下面介绍它的能力、安装方式和典型配置。

这是什么¶

一句话定位：dsh-tool-policy 允许、询问或拒绝 DeepSeek Harness 的工具调用，且发生在工具执行之前。

它面向的是单次工具调用，不是一次会话级的授权，也不是一组能力的运行时隔离。它提供 deny-by-default 的策略层：默认拒绝，只有命中显式规则才进入对应处理。它覆盖内置工具、第三方工具和 MCP 工具，并在工具体运行前匹配可观察的工具名和可选参数模式。

已核实的基础信息如下：

• 仓库：Drifter-yh/dsh-tool-policy
• 许可：MIT
• 运行环境：Node >=22.19
• peer dependencies：
• @deepseek-ai/cordis >=4.0.1 <5
• @deepseek-ai/dsh-tools >=0.1.0-rc.5 <0.2.0

核心功能¶

dsh-tool-policy 的功能比较集中：

1. 在工具调用执行前应用 allow、ask 或 deny 规则。
2. 为内置工具、第三方工具和 MCP 工具提供 deny-by-default 的策略层。
3. 匹配可观察的工具名，并可选择匹配参数模式。
4. 使用第一条命中规则生效的规则模型。
5. 支持锚定的工具名模式，并允许一个通配符 *。
6. 使用 JSON Pointer 描述参数条件。
7. 支持 trace: true，通过 Cordis logger 输出不含参数值的决策 trace。

这里的“策略”主要面向工具调用本身：它判断某个具体调用是否允许、是否要求审批、是否直接拒绝。它不负责能力沙箱、参数改写或工具体执行。

安装与启用¶

资料中给出的安装命令如下：

pnpm add dsh-tool-policy @deepseek-ai/cordis @deepseek-ai/dsh-tools

安装后，可以在 DSH 配置中启用该插件。建议先保持默认拒绝，再按工具名逐步添加 allow、ask 或 deny 规则。

一个最小配置片段如下：

defaultDecision: deny
rules:
  - tool: 'read_*'
    decision: allow
  - tool: 'bash'
    decision: ask
    reason: 'Shell execution requires approval.'

这个配置片段表达了两条意图：

• 未命中规则的工具调用默认拒绝。
• 命中 read_* 的工具调用允许继续。
• 命中 bash 的工具调用进入需要审批的路径。

如果操作者需要排查某个调用为什么被允许、询问或拒绝，可以打开决策 trace：

trace: true

开启后，插件通过 Cordis logger 输出决策 trace。该 trace 不包含参数值，适合作为“为什么不命中某条规则”的排查线索。

典型用法¶

下面是一个更完整的策略配置片段。它同时覆盖只读工具、shell、MCP 工具和删除类工具：

defaultDecision: deny
rules:
  - tool: 'read_*'
    decision: allow
  - tool: 'bash'
    decision: ask
    reason: 'Shell execution requires approval.'
  - tool: 'mcp__*'
    decision: ask
    reason: 'External tool calls require approval.'
  - tool: 'delete_*'
    decision: deny
    reason: 'Delete operations are disabled in this deployment.'

这个配置片段表达了四条常见意图：

1. read_*：允许匹配到的只读工具调用。
2. bash：shell 执行需要审批。
3. mcp__*：外部工具调用需要审批。
4. delete_*：在当前部署中禁用删除操作。

规则顺序会影响结果。插件使用第一条命中规则生效的规则模型，因此如果同一调用可能命中多条规则，应把更具体的规则放在前面。

适用场景与注意¶

dsh-tool-policy 适合这些场景：

• 在无人值守任务中运行 deny-by-default 的工具调用白名单。
• 对 mcp__* 等外部工具调用要求审批。
• 对已知的删除类工具调用在执行前拒绝。
• 在同一个 DSH 部署中对内置工具、第三方工具和 MCP 工具使用统一规则。

使用上需要保留几个边界：

1. 它是 per-call policy 层，不是 sandbox。能力执行仍依赖 DSH 的运行时隔离和沙箱配置。
2. 它不实现沙箱、能力强制、shell 语义分析或等价操作检测。
3. 一条 deny 规则让命中的工具调用不可用，不等于在系统中彻底禁止破坏性行为。
4. 它不改写参数，也不执行工具体。
5. 它会随当前 dsh 进程权限运行。安装前应检查源码、许可证和依赖版本，确认它符合部署方的安全要求。
6. 生产环境中，策略路由应与更严格的 DSH 沙箱组合使用，而不是替代沙箱。

链接¶

仓库地址：

https://github.com/Drifter-yh/dsh-tool-policy

如果要继续评估，可以从 defaultDecision: deny 的默认姿态开始，先把高风险工具设为 ask 或 deny，再逐步放开只读和低风险工具。