Codex 插件指南：6 款实用插件推荐、安装方法与工作流搭配（2026）
如果你正在用 Codex 编程，添加一个 MCP 服务可能只需要一条命令。但要把合适的技能、OAuth 服务连接和服务端配置配合起来，往往还得逐项设置。
Codex 插件解决的就是这类问题：把相关能力打包成一次安装。例如，Vercel 插件将平台开发知识和工作流整合起来，让你不必从零拼装每一个环节。本文介绍插件系统的工作方式、六款值得了解的插件，以及如何搭配出适合自己的开发工具组合。
译者说明： 本文根据读者提供的英文原文翻译并适度润色，保留六款插件的功能、优缺点、适用场景、费用说明及 FAQ。原文提到官方目录有 12 款插件、社区另有 39 款以上，这是原文写作时的统计口径；功能清单、服务价格和测试版状态也沿用原文描述。安装后需要新会话等操作细节已参考 OpenAI 官方插件文档调整，实际可用性以当前客户端和服务商说明为准。
Codex 插件是什么，如何工作
Codex 插件是可以安装的能力组合包，能够将技能、App 连接和 MCP 服务放在一起。安装一个插件，可以同时为代理增加任务指引、外部工具和服务连接配置；需要账号授权的部分，再按提示完成认证。
原文介绍，Codex 插件系统于 2026 年 3 月推出，Vercel、GitHub、Sentry 和 Linear 等公司的插件陆续进入目录。文中涉及的许多 MCP 服务也支持其他编码代理，因为 MCP 本身是开放协议。插件是否跨工具兼容，则要看各自提供的版本和集成方式。
插件、MCP 服务与 VS Code 扩展有什么区别
| 类型 | 主要作用 | 常见使用方式 |
|---|---|---|
| MCP 服务 | 通过 MCP 协议向代理提供工具和数据 | 在 ~/.codex/config.toml 中配置，或通过 codex mcp add 添加 |
| Codex 插件 | 将技能、MCP 配置、服务连接等组合为可安装的工作流 | 从插件目录安装，按需完成授权 |
| VS Code 扩展 | 为编辑器增加面板、语法高亮、检查器、调试等能力 | 在编辑器的扩展市场安装 |
一个 MCP 服务可以让代理访问某个外部系统的 API；一个插件则可以在服务连接之外，继续提供“如何使用这些工具”的技能指引和认证配置。前者解决连接问题，后者进一步组织工作方式。
VS Code 扩展主要扩展编辑器本身，Codex 插件主要扩展代理可以执行的任务。它们可以同时使用，但不是同一种扩展机制。
如何安装和管理 Codex 插件
在桌面应用中安装
- 打开支持 Codex 的桌面应用，进入 Plugins（插件）。
- 浏览或搜索目录，打开目标插件的详情页。
- 选择安装按钮；如果插件需要连接外部服务，按提示完成 OAuth 等授权。
- 安装后开启一个新聊天，再要求 Codex 使用插件。
有些插件会在安装时要求认证，另一些会等到首次调用时再提示。
在 CLI 中安装
先启动 Codex CLI，再在交互界面输入 /plugins：
codex
/plugins/plugins 是 Codex 会话中的命令，不是单独的 shell 命令。插件浏览器会按 marketplace（插件市场）展示可用条目；你可以查看详情、安装或卸载，并在已安装插件上按空格键启用或停用。安装后，开启新的 CLI 会话再使用插件提供的技能和工具。
仓库级与个人插件
如果你要分享自己的插件，还可以使用仓库级或个人插件市场。原文给出的目录组织示例是：
- 仓库级插件： 插件文件放在
$REPO_ROOT/plugins/my-plugin/，通过.agents/plugins/marketplace.json声明，方便团队在同一仓库中发现和安装。 - 个人插件： 把
~/.codex/plugins/my-plugin/作为个人插件的存放路径，并按插件市场的配置方式注册。
这些是文件组织与分发方式，不能把“目录里存在插件文件”理解为“已自动安装并启用”。创建自己的插件时，请结合构建插件文档完成注册、安装和新会话验证。
原文还提到，已安装的插件会缓存在 ~/.codex/plugins/cache/。安装插件不会自动放宽 Codex 的权限设置；MCP 服务和 App 连接也可能需要额外配置或认证。
2026 年值得了解的 6 款 Codex 插件
这六款插件分别对应部署、代码协作、错误监控、项目管理、设计和 AI 开发。下面的顺序沿用原文，选择时更应该看你正在使用哪些服务。
| 插件 | 核心用途 | 更适合的工作场景 |
|---|---|---|
| Vercel | 平台知识、开发约定与部署工作流 | 在 Vercel 上构建和部署应用 |
| GitHub | 仓库、Issue、PR 与 CI 信息 | 在编码过程中完成代码协作 |
| Sentry | 错误事件、堆栈与根因分析 | 从线上错误追踪到代码修复 |
| Linear | 工单、项目和团队信息 | 将任务跟踪与代码改动衔接起来 |
| Figma | 设计上下文、组件映射与设计稿生成 | 在设计稿和前端代码之间协作 |
| Hugging Face | 模型、数据集、Spaces 和文档搜索 | 为 AI 功能寻找模型与资料 |
1. Vercel 插件
Vercel 插件于 2026 年 3 月推出，原文介绍它提供面向 Codex、Claude Code 和 Cursor 的支持。它的一个突出特点是平台知识注入：除了提供工作流入口，还会在会话开始时加载 Vercel 产品、API 和开发模式之间的关系，并根据正在编辑的文件补充相关指引。
主要功能：
- 原文列出 38 项技能，覆盖 eve、Next.js、AI SDK、AI Gateway、Turborepo、Vercel Functions、存储、中间件、定时任务、队列、功能开关与可观测性。
- 3 个面向部署、性能优化和 AI 架构的专门代理。
- 5 个斜杠命令，包括
/deploy、/env、/status和/marketplace。 - 写入前校验，帮助识别已弃用的开发模式、停止维护的包和过时的 API 名称。
- 4 个生命周期钩子，用于分析仓库、按上下文注入技能和校验输出。
优点： 代理在执行任务前就能获取 Vercel 的开发约定；/deploy 可以将预览或生产部署纳入编码会话；写入前校验有助于减少过时 API 带来的返工。
局限： 它更强调平台知识和生命周期集成，与单纯提供 API 工具的 MCP 集成有所不同；技能覆盖面较广，熟悉各项能力需要一些探索。
适合谁： 已经在 Vercel 上开发，希望代理理解平台模式并直接参与部署的团队。它还可以与独立的 Vercel MCP 服务 mcp.vercel.com 配合，处理项目、域名和日志等账号操作。具体命令、代理和钩子能否使用，需结合当前宿主支持情况。
费用： 原文列为免费，Vercel 平台资源另按服务商规则计费。
2. GitHub
GitHub 插件把仓库、Issue、Pull Request、CI/CD 和安全信息带入编码会话。原文将其介绍为 OpenAI 插件目录收录的 GitHub 集成，将 GitHub 第一方 MCP 服务、技能和认证配置组合起来，减少手动接线工作。
主要功能：
- 浏览仓库、搜索文件和分析提交。
- 创建和更新 Issue、PR，添加评论，合并代码并管理审阅者。
- 监控 GitHub Actions，分析构建失败。
- 查看代码扫描告警和 Dependabot 漏洞告警。
- 访问 GitHub Discussions、通知和 Projects 信息。
- 使用 lockdown 模式限制不受信任贡献者内容的暴露，降低公开仓库中的提示词注入风险。
优点： 第一方 MCP 服务更容易跟进 GitHub API 的变化；支持远程 OAuth 以及基于个人访问令牌（PAT）的本地部署；公开仓库维护者还可以利用 lockdown 模式收紧内容访问范围。
局限： 工具种类较多时，可能需要更明确地描述任务，让代理选对工具。远程 OAuth 与本地 Docker 加 PAT 是不同的连接方式，各自有配置要求。
适合谁： 将代码审查、Issue 跟踪和 CI/CD 放在 GitHub 上的团队，以及需要维护公开仓库的开发者。
费用： 原文列为免费，访问范围沿用已授权 GitHub 账号的权限。
3. Sentry
Sentry 插件将错误监控接入编码代理。按照原文介绍，安装后会配置 Sentry MCP 服务，并提供相关技能和 /seer 等命令，让你搜索问题、读取堆栈和获取根因分析建议。
主要功能：
- 使用自然语言搜索 Sentry Issue 和单个错误事件。
- 获取问题详情、事件信息和完整堆栈。
- 更新问题状态、调整负责人并管理解决进度。
- 通过 Sentry Seer AI 获取自动根因分析建议。
- 支持自托管 Sentry 实例。
- 使用设备码 OAuth，原文给出的令牌缓存路径为
~/.sentry/mcp.json。
优点： 可以在编码会话中完成排查、分配和标记解决；Seer 在原始堆栈之外补充根因建议；自托管支持适合有本地部署需求的团队。
局限： 根因分析依赖错误上下文和堆栈质量，建议仍需要结合代码验证。免费套餐的错误事件额度也可能无法覆盖生产环境的使用量。
适合谁： 已经用 Sentry 跟踪线上错误，希望把问题链接直接交给 Codex、接着定位和修复代码的团队。
费用： 插件本身按原文描述免费。原文列出的 Sentry Developer 免费套餐包含每月 5,000 次错误事件，Team 付费套餐起价为每月 26 美元；购买前请以 Sentry 当前报价为准。
4. Linear
Linear 插件通过 OAuth 2.1 为代理提供工单、项目和团队工作流访问能力。原文介绍，它将 Linear 托管的 MCP 服务与连接配置打包，减少单独配置步骤。
它与 Codex for Linear 连接器的方向不同：这里的插件是让 Codex 访问 Linear；后者则是在 Linear 中把任务交给 Codex。
主要功能：
- 查找、创建和更新工单，支持标题、描述、状态、优先级、负责人、标签和截止日期等字段。
- 查询和更新项目。
- 创建和管理评论。
- 查询团队与团队成员。
- 通过 OAuth 2.1 自动为用户注册连接，每位成员使用自己的 Linear 账号认证。
优点： 操作归属于实际完成授权的人，而非共享机器人账号；服务由 Linear 托管，无需维护额外基础设施；可以直接在编码会话里创建工单、更新状态和添加评论。
局限： 原文将其描述为非开源服务，无法自行托管或自由修改工具集；原文写作时的工具范围以核心工单管理为主，尚未覆盖 cycles、路线图和 initiatives 等全部能力。
适合谁： 使用 Linear 跟踪工作，希望在开发过程中查找关联问题、创建任务并同步工单状态的团队。
费用： 原文介绍该集成向 Linear 用户免费开放；免费套餐最多支持 250 个工单，Basic 套餐按年付费时起价为每位用户每月 10 美元。当前额度和价格以 Linear 说明为准。
5. Figma
Figma 插件将设计稿上下文带入编码流程，也提供将生成的界面写回 Figma 的能力。原文介绍，插件组合了 Figma MCP 服务与设计转代码技能：既能读取布局、样式和组件信息，也能把网页或组件转换为可编辑的 Figma 原生图层。
如果目录条目暂时不可用，也可以查看 Figma MCP 服务的独立接入方式。原文提到插件曾出现阶段性不可用的情况。
主要功能：
get_design_context：提取选中画框的布局、样式、变量和组件数据，返回用于代码实现的上下文。generate_figma_design：将运行中的网页或组件转换为可编辑的 Figma 画框。get_variable_defs：获取选区中的设计令牌、变量和样式。get_code_connect_map：将 Figma 组件映射到代码库中的对应组件。search_design_system：搜索已连接的设计库，寻找可复用资源。create_design_system_rules：生成规则文件，指导代理如何把设计转换为代码。
优点： 原文所述默认输出为 React 与 Tailwind，也可调整为其他框架；Code Connect 有助于复用项目已有组件库；写回能力可以生成可编辑图层，而不是一张无法拆解的图片。
局限： 设计转代码更依赖设计文件本身的结构质量，组件和变量使用一致时效果更好。原文将相关能力描述为测试阶段免费、后续计划按用量收费，当前开放范围与费用需查看 Figma 说明。
适合谁： 经常在 Figma 和前端代码之间切换，希望读取设计规格、生成组件，或将界面结果带回设计工具的开发者与设计团队。
费用： 沿用原文的测试阶段免费口径，不代表当前所有账号和相关功能都免费。
6. Hugging Face
Hugging Face 插件让 Codex 通过自然语言访问 Hub 上的模型、数据集、Spaces、论文和文档。原文介绍，它把 Hugging Face 技能与 MCP 服务 hf.co/mcp 组合为一次安装。
主要功能：
- 按任务、库和框架等条件搜索模型。
- 按作者、标签和领域等条件搜索数据集。
- 搜索 Spaces，寻找托管的 AI 应用和工具。
- 按主题搜索机器学习研究论文。
- 使用自然语言检索 Hugging Face 各类库的文档。
- 通过 Spaces 上兼容 MCP 的 Gradio 应用调用社区工具。
优点： 可以直接提出“找一个小于 2GB、支持 ONNX 的文生图模型”这样的筛选需求；兼容的 Gradio Spaces 可让代理调用图像生成、转写等工具；文档搜索有助于获取当前库指南和 API 说明。
局限： 核心定位是模型、数据集和资料发现，不会因为安装插件就自动在本地完成模型运行或训练。Spaces 工具能否使用，也取决于作者是否持续维护 MCP 兼容性。
适合谁： 正在开发 AI 功能，需要查找模型、数据集或相关库文档的开发者。
费用： 原文列为免费。调用具体 Spaces 或底层计算服务时，还要查看对应服务的限制和费用。
如何搭配自己的 Codex 插件组合
如果项目部署在 Vercel，可以从 Vercel 与 GitHub 开始：前者补充平台开发知识和部署工作流，后者让代理获取 PR、Issue 和 CI 状态，减少在编码窗口与浏览器之间来回切换。
再根据实际技术栈补充：
- 需要处理线上错误： 添加 Sentry，让错误监控与代码修复衔接起来。
- 团队在 Linear 跟踪任务： 添加 Linear，在开发过程中同步工单与评论。
- 前端实现依赖设计稿： 添加 Figma，读取设计规格并复用组件关系。
- 正在开发 AI 功能： 添加 Hugging Face，搜索模型、数据集和库文档。
- 有额外基础设施需求： 例如使用 Vercel Functions 的团队，可再按实际架构选择基础设施相关插件。
原文建议从 3～5 款插件起步。这更适合作为控制复杂度的经验建议，而非固定性能门槛。插件带来的工具和上下文开销取决于具体实现及宿主加载方式，不常用的插件可以先停用。
从已有工作流开始使用插件
插件把部署、错误监控、设计和项目管理等外部能力整理成可安装的组合，减少分别配置技能、服务连接和 MCP 的重复工作。
原文特别推荐在 Vercel 技术栈中从 Vercel 插件开始，因为它不仅连接工具，还提供平台知识与开发约定。如果你的项目没有使用 Vercel，就从自己每天使用的服务入手：GitHub、Sentry 或 Linear 往往更容易对应到明确任务。
选择一项具体工作验证插件是否有用，例如“读取这个 PR 的 CI 失败日志并定位原因”，或“结合这条 Sentry 问题的堆栈修复异常”。当插件确实缩短了这段流程，再逐步增加其他能力。
常见问题
Codex 插件与 MCP 服务有什么区别？
MCP 服务通过 Model Context Protocol 暴露工具和信息，可以通过 config.toml 或 codex mcp add 配置。插件是一种组合与分发方式，可以把 MCP 配置、技能和服务连接一起打包，让相关能力作为同一套工作流安装。
Codex 插件也能用于 Claude Code 和 Cursor 吗？
不能仅凭插件支持 Codex 就认定它支持其他工具。底层 MCP 服务可以面向兼容 MCP 的代理复用，插件包本身仍需要对应宿主的支持。原文以 Vercel 为例：它先面向 Claude Code 和 Cursor 构建，再于 2026 年 3 月加入 Codex 支持。
同时运行多少插件才不会影响性能？
没有适用于所有插件和项目的固定数量。原文给出的经验范围是 3～5 款；更实际的做法是只启用当前工作需要的插件，观察工具选择和上下文负担，再调整组合。
可以自己开发 Codex 插件吗？
可以。插件使用 .codex-plugin/ 目录中的 plugin.json 清单，并可指向技能、.mcp.json 和 .app.json 等配置文件。具体结构与分发方式见构建插件。原文提到的“自助发布即将开放”属于当时的产品状态，准备公开发布时应查看当前提交指南。