OMP provider 与 extension 控制粒度对比

makoMakoGo 于 2026-05-06 发布

1. 先说结论

OMP 现在有两层控制面：

  1. disabledProviders

    • 直接禁整个 provider
    • 是更上游、更硬的总开关
    • 被禁的 provider 连 load() 都不会跑

  2. disabledExtensions

    • 禁单个条目
    • 不是固定枚举，而是 capability 定义出来的 extension ID
    • 适合精确屏蔽某个 skill / MCP server / hook / slash command

一句话概括：

另外，OMP 对不同 capability 的控制粒度并不统一：

2. disabledProviders：整族禁用

2.1 它到底怎么生效

provider 过滤发生在：

关键逻辑是：先把 disabledProviders 里的 provider ID 过滤掉，再进入 loadCapability() 后续流程。也就是说，被禁的 provider 不只是“结果不显示”，而是不会去扫描对应目录、不会去读对应配置文件、不会去产出任何 capability 条目。

这也是为什么：

之后，相关的 MCP、skills、context files、hooks、tools、commands 会一起消失。

2.2 当前可用的 provider ID

当前代码里注册过的 provider ID 有这些：

来源：

2.3 例子

disabledProviders:
  - claude
  - claude-plugins
  - codex
  - gemini
  - opencode
  - cursor
  - cline
  - windsurf
  - vscode
  - github

这会直接砍掉这些 provider 提供的全部能力。

所以像：

如果你的目标是“OMP 完全不要碰它们的兼容配置”，就直接放进 disabledProviders，不需要额外 patch。

3. disabledExtensions：单条目禁用

3.1 它不是固定枚举

disabledExtensions 不是预定义常量表，而是 capability 自己定义的条目 ID。

来源：

当前明确支持这些形状：

对应代码例如：

3.2 例子

disabledExtensions:
  - skill:semantic-compression
  - mcp:context7
  - slash-command:ctx-insight
  - tool:my-custom-tool
  - hook:pre:bash:guard-dangerous-command
  - context-file:user:CLAUDE.md

3.3 这个机制的边界

disabledExtensions 是条目级，不是来源级。

也就是说你可以禁：

但不能直接表达这种语义：

这种需求当前更接近 provider 级控制，而不是 item 级控制。

4. 现在各 capability 的控制粒度到底有多粗

4.1 Skills：相对最细，但还是后置过滤

skills 现在已经有来源级开关：

相关文件：

但它的实现方式不是 provider 前置禁用，而是：

  1. 先 loadCapability(skillCapability.id, ...)
  2. 把各 provider 的 skill 都跑出来
  3. 再按 source 做过滤

所以它的粒度虽然细，但架构上仍然是先扫、后筛。

4.2 MCP：只有部分细粒度控制

upstream 当前 MCP 相关设置主要是：

相关文件：

也就是说，upstream 目前没有对齐 skills 那种 mcp.enableClaudeUser / mcp.enableCodexUser 的来源级开关。

当前 upstream 能做的是：

但不能原生表达：

所以如果目标是：

这块 upstream 粒度还是不够。

4.3 Context files：没有专门分类开关

context files 没有看到类似：

相关定义：

所以当前只能靠：

其中 disabledExtensions 的形状是：

注意这里粒度也不算特别细，因为它是按：

来区分，不带更深层的路径语义。

4.4 Commands：schema 里有开关，但当前看起来没接好线

schema 里定义了：

位置：

但当前在 packages/coding-agent/src 里，基本只看到它们出现在 schema 定义里，没有看到明确的 runtime 读取路径。

所以对 commands 更准确的说法是：

单个 command 仍然可以靠 disabledExtensions 禁：

4.5 Hooks：没有专门来源开关

hooks 当前没有看到类似：

相关定义：

当前能做的是：

单个 hook 的 ID 形状是：

4.6 Tools：内置工具很细，外部 custom tools 很粗

这里要分两类。

A. 内置工具

内置工具已经有很多专门开关，例如：

这些都在：

所以内置工具这一层，OMP 粒度其实不算差。

B. 外部 / custom tools

但对 provider 带进来的外部 tool，当前没有看到：

相关定义：

所以 custom tools 仍然主要靠：

单个 tool 的 ID 形状是：

5. 这套设计的真实特点

OMP 现在不是“所有 capability 都有统一来源级控制”的设计。

更准确地说，它是一个粒度不对称的系统：

所以当前最稳定的经验法则是：

  1. 想切整族来源，用 disabledProviders
  2. 想切单个具体对象，用 disabledExtensions
  3. 想做“只禁某 provider 的某 capability、但保留同 provider 的其它 capability”
    • skills 部分支持
    • MCP 只支持很有限的子集
    • 其它 capability 基本还不够细

6. 实用写法

6.1 整族兼容层直接砍掉

disabledProviders:
  - claude
  - claude-plugins
  - codex
  - gemini
  - opencode
  - cursor
  - cline
  - windsurf
  - vscode
  - github

6.2 只禁单个条目

disabledExtensions:
  - skill:semantic-compression
  - mcp:context7
  - slash-command:ctx-insight
  - tool:my-custom-tool
  - hook:pre:bash:guard-dangerous-command
  - context-file:user:CLAUDE.md

6.3 什么时候该优先用哪一个