装了三十个工具的会话，每轮都要为没用上的二十九个付一次账。这笔账不写在计费面板上，只写在你还剩多少上下文里。dsh-capability-menu 不给你新能力，只决定哪些能力的定义出现在模型眼前。
工具定义是每轮都要重付的固定开销
工具定义不是代码，是随请求发出去的结构化文本：名字、一句描述、一套参数 schema。它不缓存，也不会因为这轮没调用就省略。
于是有两笔开销。体积那笔一目了然：工具越多单轮固定成本越大，且与任务无关。更隐蔽的是选择成本：候选越多选错概率越高，名字相近的 MCP 工具挤在一起时，模型只能靠描述去猜。
删工具是拿能力换空间，手工裁剪是把判断变成人肉劳动。三档是第三种：把「可见」和「可用」拆开。
一个上位概念，把 tool 和 skill 收进同一张表
插件立了个上位概念 capability，Tool 与 Skill 只是它的两种实例。tool 执行动作，由 ctx.tools 索引，action 为 execute，含 MCP 工具与可编目的原生工具（归入 built-in 分组）；skill 承载方法与流程，由 ctx.skills 索引，action 为 load。
收益是档位、规则、检索、目录只需一套语义。代价是模型侧多两个元工具：meta_search 搜当前会话可用的按需能力，返回总数与是否截断，按 id 查详情给参数 schema；meta_invoke 是统一执行面，Tool 走完整 ctx.tools 管线，Skill 加载 SKILL.md，传 force: true 可重载。
三档在模型眼里分别长什么样
差别不在「能不能用」，而在「模型知不知道它存在」。
| 档位 | tool | skill |
| --- | --- | --- |
| 常驻 | 定义随请求提供，可直接调用 | 名称与简介进 <available_skills> |
| 按需 | 不给定义，先 meta_search 搜到 ID 与 schema，再 meta_invoke | 不进 <available_skills>，搜到后经 meta_invoke 加载 |
| 禁用 | 不给定义，meta_search 也看不到，调用被拒 | 同样不可见 |
按需与禁用的差别常被低估。按需是「有索引不给全文」，模型知道这类东西存在，可以主动查；禁用连索引都不给，模型连自己缺什么都无从判断。所以禁用放确实不该碰的，按需放低频的。
成本口径要说清：三档不是把开销降到零，而是把「N 个工具的定义」换成「两个元工具加一次往返」。两个元工具默认常驻、菜单里不能禁用，所以「全部走按需」不成立。检索本身要付往返与 token，高频工具留常驻是因为检索成本会累积到超过定义成本。
规则优先级为什么排成这个样子
手写规则五级，按序匹配，未命中则常驻：
| 优先级 | 规则 | 例子 |
| --- | --- | --- |
| 1 | disabled 精确或通配 | 'mcp__secret__*' |
| 2 | resident 精确 | bash |
| 3 | on-demand 精确 | example_skill |
| 4 | resident 通配 | 'mcp__gongfeng__*' |
| 5 | on-demand 通配 | 'mcp__*' |
| 默认 | 未命中 | 常驻 |
禁用排最前，精确与通配同级。禁用表达的是「不许」，不该被任何便利规则推翻：一行 mcp__secret__* 能整体封掉一台服务器，哪怕你之前逐个点过常驻。这是安全侧的不对称——错封可发现、可回滚，错放未必。同一套优先级也解释了另一个现象：菜单点档位写入的正是精确规则，一条 disabled 通配就能把它盖掉，界面提示「分类未生效」。
精确优先于通配，理由朴素：越具体的陈述越像有人真的想过。你写下 bash 常驻，不该被顺手敲的 mcp__* 带走。再往下，同为精确或同为通配时也常驻，没命中任何规则同样常驻，这是「失败时倾向可见」——规则写矛盾了工具还看得见，只多花点上下文；反过来工具莫名消失，模型会绕路、误判，甚至说做不到。
几处需要先想清楚的地方
run_code 不进这个插件的目录、也不出现在菜单里，但手写通配仍可能匹配到它。设成按需或禁用等于废掉 DSH Code Mode，而它不在菜单里，排查时也很难想到这一层。
界面选择存在 stateFile 里，默认 ${DSH_HOME:-~/.dsh}/capability-menu-policy.json，与默认 patch 同目录且各 Profile 共用，隔离得在 policy 与 registry 两个 entry 里指定同一个文件。想清掉界面选择只留 patch 规则，必须停止 DSH 后删状态文件，运行中删会被下一次落盘写回去。注册 MCP 服务器会写进 patch，请求头之类的凭据是明文。
安全结论照原文读：静态扫描给的是「含敏感能力」——具备执行外部命令、读写删除本地文件、读密钥类环境变量中的至少一项，涉及主机 registry.npmjs.org；站点同时写明尚无人工评估、未做风险分级，「暂未覆盖不等同于无风险」。版本口径也不一致：站点实装记录是 dsh 0.2.1-rc.2，README 自述验证版本是 0.2.1-rc.3；加上 19 个 peerDependencies 且未声明 dsh 版本约束，落在 0.2.1 预发布带上能不能跑，以自己宿主为准。
总结
三档的价值不在省下多少 token，而在把「每轮要读多少工具」变成可按能力粒度调的参数。想对照同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：装了多台 MCP 服务器、工具数到几十上百的会话；长任务这类预算紧的场景；能分出高频与长尾并愿意写进 patch 的人。
不适合：一个会话只用三五个工具，多两个元工具就是净支出；团队里没人愿意读 YAML 与维护规则，这套东西的正确性全压在规则上；想要装完不用管的心智模型，因为它引入了「工具可能在也可能不在」这个额外状态。
标签：能力菜单、DeepSeek Harness、上下文预算、工具编排
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。