AI 编程工具越装越乱？我的 MCP 和 Skills 统一管理方案

建议直接喂给 AI 分析文章解读，分析方案是否是自己想要的，然后让 Codex 来执行。

最近我在整理本机的 AI 编程工具配置。一开始看起来只是一个很简单的问题：

我有 Codex，也有 Claude Code，还有一个 CC Switch。那 MCP 和 Skills 到底应该放在哪？谁来统一管理？哪些东西可以共享，哪些东西必须保留在各自工具里？

但真正整理起来才发现，这里面很容易混。

尤其是 MCP 和 Skills，看起来都像是“给 AI 增强能力”的东西，但它们在 Codex、Claude Code、CC Switch 里的管理机制完全不一样。

如果用同一套逻辑去管理，很容易出现这种情况：

• • CC Switch 里关了，但 Codex 里还能看到；
• • Codex 插件页面里能看到，但不知道它来自哪里；
• • 手动复制了 Skill 文件夹，结果 CC Switch 界面里没有；
• • 禁用了某个 MCP，再打开时不知道配置从哪恢复；
• • Codex 独有能力被误放进共享管理里，后面越整理越乱。

所以这篇文章就是我这次整理后的最终方案。

核心目标只有一个：

用 CC Switch 统一管理该共享的东西，同时保留 Codex 和 Claude Code 各自独有的能力边界。

一、先说最终结论

这套方案里，MCP 和 Skills 要分开看。

1.1 MCP 的最终方案

共享 MCP 统一交给 CC Switch 管理。

也就是说，如果一个 MCP 同时适合 Codex 和 Claude Code 使用，就把它登记到 CC Switch 中，由 CC Switch 控制它对 Codex、Claude Code 是否可见。

当前我的共享 MCP 是：

Codex 独有 MCP 不进 CC Switch。

比如：

所以 MCP 的管理口径是：

• • 共享 MCP：CC Switch 统一管理 Codex 和 Claude Code 的可见性；
• • Codex 独有 MCP：保留在 Codex 自己的配置里；
• • Claude Code 独有 MCP：保留在 Claude Code 自己的配置里；
• • CC Switch 修改 MCP 后，需要重启目标 App 和会话；
• • 如果 CC Switch 关闭 Codex 侧某个 MCP，Codex 插件页面会直接不显示它，效果类似删除。

1.2 Skills 的最终方案

共享 Skills 统一放在 ~/.agents/skills。

但这里和 MCP 最大的区别是：

CC Switch 不负责管理 Codex 侧共享 Skills 的可见性。

因为 Codex 会直接扫描：

1
~/.agents/skills

所以只要共享 Skill 在这个目录里，Codex 就能发现它。

Codex 中某个 Skill 是否启用，应该在 Codex 插件/技能页面里管理。

而 Claude Code 不会按这个方式直接使用共享目录，它实际读取的是：

1
~/.claude/skills

所以 Claude Code 的共享 Skill 可见性，由 CC Switch 通过单个 Skill 软链接来控制。

Skills 的管理口径是：

• • 共享 Skills：统一放在 ~/.agents/skills；
• • Claude Code：通过 CC Switch 管理哪些共享 Skills 可见；
• • Codex：直接扫描 ~/.agents/skills，不通过 CC Switch 管共享 Skills 可见性；
• • Codex 是否启用某个 Skill：在 Codex 插件/技能页面管理；
• • Codex 独有 Skill：保留在 ~/.codex/skills；
• • Codex 系统 Skill、插件 Skill：不迁移、不交给 CC Switch。

二、为什么 MCP 和 Skills 不能用同一种管理方式？

这个问题是整个方案的关键。

我一开始也以为：

既然 Skills 可以放到 ~/.agents/skills，那 MCP 是不是也能放到某个共享目录，然后让 Codex 和 Claude Code 自动扫描？

后来实际验证后发现，不是这样。

2.1 Skills：Codex 会自动扫描共享目录

Codex 对 Skills 有一套目录扫描机制。

它会扫描：

1
~/.agents/skills

也会扫描：

1
~/.codex/skills

还会显示 Codex 系统 Skill、插件 Skill 等。

所以 Codex 插件页面里的 Skills 是一个聚合视图，不代表所有 Skills 都归 CC Switch 管。

比如 Codex 插件页面里看到的 Skills，可能来自：

也就是说，Codex 能看到一个 Skill，不代表它是 CC Switch 分配过去的。

这也是为什么：

CC Switch 关闭 Codex 的 Skill 软链接，并不能阻止 Codex 发现 ~/.agents/skills 里的 Skill。

因为 Codex 本来就会扫共享目录。

2.2 MCP：Codex 不会像 Skills 一样扫描共享目录

MCP 就不一样了。

Codex 的 MCP 主要来自自己的配置文件：

1
~/.codex/config.toml

配置大概长这样：

1
2
3
4
[mcp_servers.context7]type = "stdio"command = "npx"args = ["-y", "@upstash/context7-mcp"]

Claude Code 的 MCP 主要来自：

1
~/.claude.json

配置大概长这样：

1
2
3
4
5
6
7
8
9
{  "mcpServers": {    "context7": {      "type": "stdio",      "command": "npx",      "args": ["-y", "@upstash/context7-mcp"]    }  }}

所以 MCP 必须进入目标应用自己的配置文件。

这就决定了：

MCP 可以由 CC Switch 同时管理 Codex 和 Claude Code 的可见性。Skills 不适合这么做，因为 Codex 会自己扫描共享 Skills 目录。

三、CC Switch 在这套方案里到底做什么？

CC Switch 的角色可以理解为：

它不是所有能力的唯一来源，而是共享能力的登记和分配入口。

但 MCP 和 Skills 的分配方式不同。

3.1 CC Switch 管 MCP：同步改两个应用的配置文件

CC Switch 中 MCP 的核心登记位置是：

1
~/.cc-switch/cc-switch.db

核心表是：

1
mcp_servers

当你在 CC Switch 里操作共享 MCP 时，影响大概是这样：

这里有一个很关键的点：

如果 CC Switch 把 Codex 侧某个 MCP 关闭了，Codex 插件页面里就看不到它了。

这不是单纯的“开关关掉”，而更像是这个 MCP 从 Codex 配置里移除了。

如果要重新启用，就要回到 CC Switch 里打开，因为 CC Switch 的数据库里保存着这个 MCP 的启动配置。

3.2 CC Switch 管 Skills：只管 Claude Code 的软链接

CC Switch 中 Skills 的核心登记位置也是：

1
~/.cc-switch/cc-switch.db

核心表是：

1
skills

但它对 Skills 的实际影响，主要是 Claude Code 侧的软链接：

1
~/.claude/skills/<skill> -> ~/.agents/skills/<skill>

也就是说：

所以对 Skills 来说，CC Switch 的重点是：

• • 登记共享 Skills；
• • 让 CC Switch 界面能看到这些 Skills；
• • 控制 Claude Code 是否能看到某个共享 Skill。

但 Codex 侧不靠 CC Switch 分配共享 Skills。

四、Codex 插件页面到底管理什么？

Codex 插件页面很容易让人误会。

因为它里面会出现插件、MCP、Skills 等不同类型的东西。

如果只看界面，很容易以为：

只要 Codex 插件页面能看到，就都归 Codex 插件系统管理。

其实不是。

4.1 Codex 管 MCP：影响 config.toml

Codex 当前能看到的 MCP，来自：

1
~/.codex/config.toml

也就是类似：

1
2
3
4
[mcp_servers.codegraph]type = "stdio"command = "codegraph"args = ["serve", "--mcp"]

Codex 插件页面可以管理当前可见 MCP 的启用/禁用。

但如果某个共享 MCP 是被 CC Switch 从 Codex 配置中移除的，那么 Codex 插件页面就不会显示它，也没有入口恢复。

这时要回到 CC Switch 中重新开启。

4.2 Codex 管 Skills：写入 [[skills.config]]

Codex 禁用某个 Skill 时，会影响：

1
~/.codex/config.toml

配置形态类似：

1
2
3
[[skills.config]]path = "/Users/didi/.agents/skills/<skill-name>/SKILL.md"enabled = false

重新启用后，这段禁用配置会被移除。

注意，这和 MCP 不一样。

Skill 文件还在 ~/.agents/skills 里，Codex 仍然能发现它，只是通过配置标记让它在当前 Codex 中不可用。

五、最终目录和文件关系

可以把整套方案理解成下面这张表。

再拆成几个关键文件：

六、添加和删除时应该怎么做？

6.1 添加共享 MCP

添加共享 MCP 时，要同步三处：

1. 1. 在 ~/.cc-switch/cc-switch.db 的 mcp_servers 表登记；
2. 2. 如果给 Codex 开启，写入 ~/.codex/config.toml；
3. 3. 如果给 Claude Code 开启，写入 ~/.claude.json。

也就是说，MCP 不能只放一个文件夹。

它必须进入目标应用实际读取的配置文件。

6.2 删除共享 MCP

删除共享 MCP 时，也要同步清理：

1. 1. ~/.cc-switch/cc-switch.db 的 mcp_servers 记录；
2. 2. ~/.codex/config.toml 中对应 [mcp_servers.<name>]；
3. 3. ~/.claude.json 中对应 mcpServers.<name>；
4. 4. 如果 Claude Code 权限文件里有残留，再清理 ~/.claude/settings.json 中的 mcp__<name>__*。

6.3 添加共享 Skill

添加共享 Skill 时，要同步两处：

1. 1. 将 Skill 文件放入：

1
~/.agents/skills/<skill-name>/SKILL.md

1. 2. 在 ~/.cc-switch/cc-switch.db 的 skills 表登记。

第二步很重要。

因为 ~/.agents/skills 是共享文件源，但 CC Switch 界面还依赖自己的登记状态。

如果你只是手动把 Skill 文件夹丢进去，CC Switch 界面不一定能看到它。

6.4 删除共享 Skill

删除共享 Skill 时，要同步清理：

1. 1. ~/.agents/skills/<skill-name>；
2. 2. ~/.cc-switch/cc-switch.db 的 skills 记录；
3. 3. ~/.claude/skills/<skill-name> 软链接；
4. 4. 如果 Codex 有禁用残留，再清理 ~/.codex/config.toml 中对应的 [[skills.config]]。

七、几个容易踩坑的点

7.1 不要把 Codex 独有能力放进共享管理

比如 Codex 的 node_repl。

它是 Codex App 内部能力，依赖 Codex 自己的资源路径和环境变量，用来支撑 Browser / Chrome 插件等能力。

这种能力就应该留在 Codex 里，不要放到 CC Switch 里统一管理。

7.2 不要以为 CC Switch 能关闭 Codex 共享 Skills

对 Skills 来说，Codex 会扫描：

1
~/.agents/skills

所以 CC Switch 不是 Codex 共享 Skills 的可见性入口。

要关闭 Codex 中某个 Skill，应该去 Codex 插件/技能页面关闭。

7.3 不要把 MCP 当成 Skills 管

MCP 没有一个类似 ~/.agents/skills 的通用扫描目录。

共享 MCP 必须写入目标应用实际读取的配置文件：

• • Codex：~/.codex/config.toml
• • Claude Code：~/.claude.json

这也是为什么 MCP 可以交给 CC Switch 同时管理 Codex 和 Claude Code。

7.4 重启很重要

CC Switch 修改 MCP 后，需要重启目标 App 和会话。

否则你可能看到旧状态，然后误以为配置没有生效。

八、我的最终管理原则

最后总结一下。

这套方案的核心不是“所有东西都放到一个目录里”，而是：

共享的归共享，独有的归独有；能被工具自动扫描的，不强行再分配；必须写配置文件的，就交给统一入口同步配置。

具体就是：

• • MCP：共享的交给 CC Switch，同时管理 Codex 和 Claude Code；
• • Skills：共享文件放 ~/.agents/skills；
• • Claude Code Skills：由 CC Switch 通过软链接控制；
• • Codex Skills：Codex 自己扫描共享目录，启用/禁用由 Codex 插件页面控制；
• • Codex 独有 MCP / Skill：保留在 Codex，不放进共享管理；
• • 新增、删除共享能力时，不只改文件，还要同步 CC Switch 的登记状态。

这样整理之后，Codex、Claude Code、CC Switch 三者的边界就清楚了。

后面再添加 MCP 或 Skill，也不会出现“界面里看得到但实际不能用”“配置里还有残留”“独有插件被误共享”这类问题。

如果你也同时在用 Codex、Claude Code 和 CC Switch，建议先不要急着迁移文件。

先把 MCP 和 Skills 分开，再确认每个能力到底是共享的，还是某个工具独有的。

整理清楚这一步，后面才不会越管越乱。

觉得有用可以收藏一下。后面如果继续折腾 Codex、Claude Code、MCP、Skills 这些本地 AI 编程工作流，我也会继续整理成文档分享出来。