dsh plugin 能做什么、不能做什么？DeepSeek Harness 插件的能力与权限边界

dsh plugin 的能力边界由三层决定：安装期只看 allowBuilds 授权，启动期看它装进了哪个 profile，运行期看工具调用能否通过沙箱权限层与你的审批。 插件与 dsh 同进程运行，能力面很宽，但落地最后一公里始终握在权限层和你手里。

概览：一条 dsh plugin 授权命令，不等于它的全部权限

判断一个 DSH plugin「能做什么」，要按时间分三层看，混层是最常见的误判来源。 下表把三层各自决定什么列清楚（来源）：

一句话概括三层的关系：安装期授权的是「代码可以跑」，运行期授权的是「这一次操作可以落地」，两者不能互相推导，也不该混着判断。想先弄清插件本身是什么，读《dsh plugin 是什么意思》。

能力面：DSH plugin 通过 ctx 能注册什么

插件是导出 apply 函数的模块，ctx 是它与宿主唯一的交互面——能力面就在这个面上（来源）。 官方给出的注册入口主要有这几类：

这张表也解释了「为什么插件权限等于 dsh 的权限」：官方文档在讲工具契约时明确，注册后的贡献是同进程的类型化贡献，不是序列化边界——插件代码就跑在 dsh 进程里（来源）。所以它的能力下限很高，真正的约束来自下面两层。

安装期边界：DSH plugin 的 allowBuilds 是不进沙箱的真实执行

GitHub 源码安装时要求你放行的 allowBuilds，官方定义是「授权该包的代码在你的机器上于安装时执行」——不在任何沙箱内（来源）。 判断与操作按四步：

1. 先确认装的是什么形态 —— npm 预构建包发布时已构建好产物，装完即用，预期：不需要任何构建脚本授权，风险面最小；
2. 只有 git 源码才要求放行 —— pnpm 10 起默认拒绝执行 git 依赖的构建脚本，首次 add 会失败并打印需要放行的包名，预期：你拿到的是精确的包名，而不是一个模糊的范围；
3. 放行就等于给执行许可 —— 把包名写进 profile 的 pnpm-workspace.yaml：

allowBuilds:
  dsh-hello-plugin: true

预期：重新 add 后脚本在安装时执行，此后的行为你无法预知也来不及拦； 4. 拿不准就别授权 —— 改装 npm 预构建版或 tarball，预期：装完即用，不需要任何构建授权。

这条边界最容易被误读成「安装时的临时动作」，实际它是真实执行：授权之前先审源码，或换来源更可靠的分发形态。

运行期边界：DSH plugin 工具调用要过权限层与审批

插件注册了工具，不等于工具能随便落地——每次调用都要过沙箱档位校验与人工审批（来源）。 按一次调用的顺序走四步：

1. 插件声明权限策略扩展点 —— 官方建议权限判断不要写进工具本体，而是用 tools/pre-execute（放行 / 拒绝 / 追问）、ctx.tools.guard()（不可撤销的最终拒绝）、tools/execute（环绕派发，可加超时与重试）这些扩展点（来源）。预期：工具体保持纯粹，策略集中可查；
2. 调用携带权限档位参数 —— 需要放宽时，请求带 sandbox_permissions，并在 justification 里写明理由才能通过校验。预期：档位只允许朝更宽的方向变化，同级请求会被判为非法升级（讨论原文）；
3. 权限策略要求审批时弹窗问你 —— 涉及审批的操作，Web UI 会在执行前弹窗征求同意，批准后才继续（来源）。预期：这是执行前最后一道人工闸口；
4. 越权请求被拒 —— 档位不够又不满足升级条件时，调用被拦下。预期：任务表现为「停下来等答复」，而不是悄悄绕过。

记住两个推论：插件与模型都无法绕过审批；弹窗出现时看不清操作内容就别点允许，那是你手上唯一的否决机会。沙箱档位被反复拒绝的排查，见《沙箱权限升级被拒排查》。

三条容易混淆的 DSH plugin 边界

把边界划清，能避免「装了个插件就以为交出了电脑」或「以为审批能拦住一切」这两类相反的错误。 三条边界按「插件 / 工具 / profile / 审批」四个对象划分（来源）。

1. 插件权限 ≠ 工具调用的权限：插件注册得再多，单次调用仍要过档位与审批；反过来，插件在 apply 里跑的非工具代码是进程内代码，不经过工具审批链路。所以插件来源本身就是一道判断。
2. 一个插件 ≠ 一套独立权限：profile 决定它被加载进哪套运行栈，同一个插件装进 web 与 headless 是两个独立实例、各自组合。装错 profile 是「装完没反应」的常见原因。
3. 审批是闸口不是审计：审批拦的是执行前，不是运行中的行为。要可控可审计，优先选带审批门控与审计日志的插件，装完再用下文方式核对。

怎么查一个 DSH plugin 的边界：三步核对

别只看插件描述，用三条命令与一个入口把它落到具体位置。 按顺序执行（来源）：

1. 确认它在当前 profile 里 —— dsh plugin --profile web list。预期：看到包名与版本，说明它属于这套运行栈；
2. 确认它进了生效的组合层 —— dsh --profile web --dump-config | grep -n "^# =="。预期：生效层里出现该插件的层，而不是只躺在依赖清单里；
3. 确认它注册了什么 —— 在终端里对照它加载时打印的注册项（工具名、命令名），或在会话里看工具列表。预期：注册项与插件描述对得上，多出意料之外的能力就该警惕；
4. 核对来源与兼容状态 —— 打开 DSH Plugin Hub 的「设置 → 插件市场」，在插件详情里看来源是 npm 还是 GitHub、兼容的 DSH 版本与验证状态。预期：来源可溯、版本对口，再决定是否长期保留。

装的时候还会弹一次确认窗口，把将要执行的安装命令与来源摆在你面前。

与其事后靠命令逐条反查插件注册了什么，不如在安装那一步就用 Hub 把来源、版本与执行命令核对一遍——确认弹窗会把这几项列全。访问 https://dsh-plugin.org/zh/ 即可了解详情。

来源：构建一个工具（官方文档）、第一个插件（官方文档）、打包与安装插件（官方文档）、官方 Quickstart、Discussion #1149