Codex 和 Claude 的 skill/mcp/plugin/marketplace 如何兼容？

June 1, 2026 · 4 min read

Skill、MCP、Plugin、Marketplace 四个扩展体系完全可以兼容，不需要重构现有生态。

层级定义：MCP 是底层通信协议，Skill 是 Agent 任务封装，Plugin 是 IDE 原生扩展，Marketplace 是分发层。
兼容核心：三层映射规则——MCP 工具 → Skill 动作 → Plugin 功能，统一全局 ID 标识。
落地方案：Codex 内置 MCP 桥接层，可直接调用 Claude 生态的所有 Skill 无需额外开发。
价值收益：一次开发多端分发，开发者无需为不同平台重复实现相同功能。

四个概念的本质区别

先把四个概念的层级理清楚，很多人混为一谈，其实从上到下四层边界非常清晰：

Marketplace：最上层，负责扩展的搜索、分发、版本管理、付费结算，不管扩展是什么技术栈实现
Skill：面向 Agent 层的任务封装，一个 Skill 对应一个完整的可执行任务（比如上传图片到 OSS、添加一篇博客），内部可以调用多个 MCP 工具
MCP：Model Context Protocol，底层通信协议，定义了 Agent 怎么和外部工具交互的标准格式，不管工具运行在本地还是云端
Plugin：IDE/编辑器原生扩展，直接操作宿主环境的API（比如 VSCode 插件可以读写文件、操作编辑器界面）

兼容的核心逻辑

兼容不需要重写任何现有系统，只需要做三层映射：

1. ID 统一

给每个功能分配全局唯一的标识符，比如 oss-image-upload 这个功能：

MCP 工具名：mcp__oss__upload_image
Skill 名：oss-image-upload
Plugin 命令名：extension.oss.uploadImage
Marketplace 分发 ID：kimigao.oss-image-upload

所有层都用同一个根标识，只是加不同的前缀区分层级。

2. 参数 schema 统一

所有层都用 JSON Schema 定义参数格式，不管是 MCP 工具的入参、Skill 的参数、还是 Plugin 命令的参数，都用同一个 schema 定义：

{
  "type": "object",
  "properties": {
    "filePath": { "type": "string" },
    "bucket": { "type": "string", "default": "cosmos-x" }
  },
  "required": ["filePath"]
}

3. 调用链路自动转换

Agent 调用 Skill 的时候，自动转换为对应的 MCP 工具调用或者 Plugin 命令调用：

如果是本地有 MCP 服务运行，直接调用 MCP 工具
如果是在 VSCode 环境，直接调用 Plugin 命令
如果都没有，从 Marketplace 自动下载安装对应的扩展

Codex 和 Claude 的具体兼容方案

Claude 生态已经有大量成熟的 Skill 和 MCP 工具，Codex 不需要重新实现，只需要加一个 MCP 桥接层：

Codex 内置 MCP 客户端，支持连接本地和云端的 MCP 服务
实现 Skill 到 MCP 工具的自动映射，Claude 的 Skill 可以直接在 Codex 中调用
Marketplace 层打通，Claude 和 Codex 共用同一个扩展市场，开发者上传一次，两边都能搜到

实际使用效果

现在我自己的博客写作工作流已经完全打通了：

在 Codex 中写博客，需要上传图片的时候直接调用 oss-image-upload Skill
底层自动调用 Claude 生态的 OSS MCP 工具上传到阿里云，返回 CDN 链接
不需要切换到 Claude 界面，也不需要手动复制粘贴链接，全程在 Codex 中完成

未来展望

接下来的方向是完全消除平台差异：

开发者写一个 Skill，自动兼容所有支持 MCP 协议的 Agent（Claude、Codex、GPT-4o 等）
不需要为不同 Agent 单独做适配，一次开发全生态可用
Marketplace 统一审核、分发、结算，开发者只需要专注于功能本身

四个概念的本质区别​

兼容的核心逻辑​

1. ID 统一​

2. 参数 schema 统一​

3. 调用链路自动转换​

Codex 和 Claude 的具体兼容方案​

实际使用效果​

未来展望​

References​