前言¶
在 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 的功能比较集中：
- 在工具调用执行前应用
allow、ask或deny规则。 - 为内置工具、第三方工具和 MCP 工具提供 deny-by-default 的策略层。
- 匹配可观察的工具名，并可选择匹配参数模式。
- 使用第一条命中规则生效的规则模型。
- 支持锚定的工具名模式，并允许一个通配符
*。 - 使用 JSON Pointer 描述参数条件。
- 支持
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.'
这个配置片段表达了四条常见意图：
read_*：允许匹配到的只读工具调用。bash：shell 执行需要审批。mcp__*：外部工具调用需要审批。delete_*：在当前部署中禁用删除操作。
规则顺序会影响结果。插件使用第一条命中规则生效的规则模型，因此如果同一调用可能命中多条规则，应把更具体的规则放在前面。
适用场景与注意¶
dsh-tool-policy 适合这些场景：
- 在无人值守任务中运行 deny-by-default 的工具调用白名单。
- 对
mcp__*等外部工具调用要求审批。 - 对已知的删除类工具调用在执行前拒绝。
- 在同一个 DSH 部署中对内置工具、第三方工具和 MCP 工具使用统一规则。
使用上需要保留几个边界：
- 它是 per-call policy 层，不是 sandbox。能力执行仍依赖 DSH 的运行时隔离和沙箱配置。
- 它不实现沙箱、能力强制、shell 语义分析或等价操作检测。
- 一条
deny规则让命中的工具调用不可用，不等于在系统中彻底禁止破坏性行为。 - 它不改写参数，也不执行工具体。
- 它会随当前
dsh进程权限运行。安装前应检查源码、许可证和依赖版本，确认它符合部署方的安全要求。 - 生产环境中，策略路由应与更严格的 DSH 沙箱组合使用，而不是替代沙箱。
链接¶
仓库地址：
https://github.com/Drifter-yh/dsh-tool-policy
如果要继续评估，可以从 defaultDecision: deny 的默认姿态开始，先把高风险工具设为 ask 或 deny，再逐步放开只读和低风险工具。
