什么是 OpenAI Codex

Codex 是 OpenAI 的编码代理。它可以读取代码库、规划修改、编辑文件、在沙箱中运行命令，并生成差异文件供你审核——所有这些功能都可通过四个界面实现，这四个界面共享相同的配置：Codex 应用、IDE 扩展、命令行界面 (CLI) 以及用于长时间运行或后台任务的云/Web 环境。因为这四个界面读取的是相同的代码库。 ~/.codex 配置、MCP 服务器或插件（您设置一次后）会在终端和 IDE 之间跟随您。

简而言之： Codex 与其说是一个单一的工具，不如说是一个运行时环境——在这里，技能、应用程序连接和 MCP 服务器围绕编码任务组合在一起，而不是在每个项目中重新构建相同的设置。

开发者为何采用 Codex

大多数“AI编码助手”的比较都集中在模型质量上，但更有趣的转变在于结构。Codex将以前集成在一个巨大的系统提示符中的三个功能拆分了出来： 指示 （AGENTS.md） 可重复使用的程序 （技能），以及 工具访问 （应用程序和 MCP 服务器）。正是这种分离使得插件成为可能——插件只是将这三者打包在一起，可以作为一个整体进行安装和卸载，而无需将样板代码粘贴到每个新的聊天窗口中。

实际结果是：团队可以规范 Codex 如何审查拉取请求、阅读 Sentry 问题或起草文档，并将该标准作为可安装的软件包发布，而不是作为无人阅读的 wiki 页面发布。

安装和配置 Codex

CLI 是查看配置生效速度最快的方式。Codex 将设置存储在 ~/.codex/config.toml 默认值（可通过以下方式覆盖） CODEX_HOME （针对特定项目）。

# 在 CLI 代码库 /plugins 中打开插件浏览器 # 直接从 CLI 代码库添加 MCP 服务器 mcp add context7 -- npx -y @upstash/context7-mcp # 查看正在运行的会话中的活动 MCP 服务器 /mcp

要进行更精细的控制——例如超时、工具允许列表、每个工具的审批模式——请编辑 config.toml 直接。以下是一个用于构建流式 HTTP MCP 服务器的最小、实用模块：

[mcp_servers.figma] url = "https://mcp.figma.com/mcp" bearer_token_env_var = "FIGMA_OAUTH_TOKEN" [mcp_servers.figma] startup_timeout_sec = 20 tool_timeout_sec = 45

插件 vs 技能 vs 应用 vs MCP

这四个术语在营销文案中经常被混用，这正是新手容易犯错的原因。当你决定安装哪些软件时，真正重要的区别在于以下几点。

所以当有人说“安装 GitHub 插件”时，实际安装到你机器上的可能是一个技能、一个应用程序连接、一个 MCP 服务器，或者三者兼有——插件只是一个包装器，使之可以安装和共享。

插件目录

无论您是在应用程序中浏览插件还是在 CLI 中浏览插件，Codex 都将插件分为三组：

• 由 OpenAI 精选 — 所有 Codex 用户均可使用的已审核插件。
• 与您分享 — ChatGPT 工作区中其他成员已在内部发布的插件。
• 由您创建 — 您自己搭建并添加到工作区的插件。

安装方法在任何地方都一样：打开插件的详情页面，选择安装（或 安装插件 在命令行界面 (CLI) 中），根据提示连接所需的任何外部应用程序，然后在使用前启动一个新线程。插件上线后，您现有的审批设置仍然控制着插件的权限——安装插件并不会授予其所有权限。

要禁用插件而不将其删除，请将其条目切换为 config.toml：

[plugins."gmail@openai-curated"] enabled = false

Codex插件生态系统

截至撰稿时，OpenAI 的精选目录专注于一系列特定的工具，而非庞大的应用商店目录——这是有意为之，因为每个精选插件都经过了审核。第三方和工作区开发的插件远不止于此，但它们的信任保障各不相同，因此了解它们之间的区别至关重要。

如何解读插件卡

本指南中的每个插件都标明了它所遵循的信任边界类型：

发展

文档与设计

生产率

调试

部署

GitHub 集成

GitHub 之所以能获得特殊待遇，是因为 Codex 为其提供了一个精心打造的插件和更深入的第一方集成，此外还有一个专用的 GitHub Action，用于通过 CI 触发运行。实际上，这意味着有三个不同的入口点：从 GitHub 的用户界面将 Codex 分配给 issue，从 CLI 对已检出的仓库调用 Codex，或者在每个 PR 的工作流文件中触发它。采用 Codex 进行代码审查的团队通常会从 Action 开始，因为它不需要每个贡献者都在本地配置 Codex。

Figma集成

Figma 通过其自身的 MCP 服务器而非 Codex 端集成连接到 Codex，无论本地（桌面应用）还是远程（托管）模式均是如此。这完美地诠释了插件模型的优势：OpenAI 无需构建 Figma 专用工具，只需提供良好的 MCP 支持，其余工作均由 Figma 自身的服务器完成。但缺点是，服务器的行为、速率限制和可靠性不受 OpenAI 的控制。

概念整合

这款精心打造的 Notion 插件整合了页面和数据库的读写功能，并针对工程输出（例如提交日志、PR 摘要、事件时间线）进行了优化，使其能够转化为结构化的 Notion 内容。对于那些已经将 Notion 作为决策权威来源的团队来说，这无疑是一项显著的优势，因为它省去了“需要有人手动更新文档”的步骤。

Slack 集成

与 GitHub 类似，Slack 也提供精选插件和更深入的原生集成。实际区别体现在对延迟敏感的工作流程中：原生集成通常支持更丰富的触发机制（例如，由 Slack 消息触发 Codex 运行，而不仅仅是 Codex 向 Slack 发布内容），而插件通常只能实现从 Codex 到频道的单向通信。

Sentry 集成

对于已经快速交付的团队来说，Sentry 可以说是最具杠杆效应的插件，因为它将“发现错误 → 查找堆栈跟踪 → 查找提交 → 提出修复方案”简化为一个对话循环。但需要注意的是：如果您不限定查询范围（例如，未解决的问题、最近 24 小时内的问题、特定项目），Codex 会很乐意为过时或重复的问题提出修复方案。因此，提示信息的精确性在这里比本指南中的几乎任何其他部分都更为重要。

浏览器自动化

对于任何运行在浏览器而非 API 中的功能——例如验证 UI 更改、抓取没有公开 API 的页面、驱动登录流程——Codex 都使用浏览器 MCP 服务器，而不是专用的“浏览器插件”。文档中重点提到的两个 MCP 服务器是 Playwright 和 Chrome DevTools，它们都可以通过 MCP 进行控制。Codex 应用还自带应用内浏览器和 Chrome 扩展程序，以便在“查看页面”和“编辑代码”之间建立更紧密的联系。

终端工作流程

CLI 是日常实际进行插件和 MCP 配置的地方。以下是一些值得记住的命令：

/plugins # 通过市场浏览、安装和切换插件 /mcp # 列出当前会话中活动的 MCP 服务器 codex mcp add # 从 shell 添加新的 MCP 服务器 codex mcp --help

在插件浏览器的市场标签页中，按下 空间 在已安装的插件上，可以切换该插件在当前会话中的开启或关闭状态——当您想要排除某个插件是导致意外工具调用的原因，但又不想完全卸载它时，这个功能非常有用。

代理商.md

AGENTS.md 是大多数 Codex 配置中最被低估的组件。Codex 在执行任何操作之前都会读取它，并根据全局文件构建指令链。 ~/.codex/AGENTS.md 从项目根目录到当前工作目录之间的每个目录，每个嵌套文件都会覆盖或修改其上方的文件。

# AGENTS.md ## 仓库要求 - 在提交 pull request 之前运行 `npm run lint`。 - 当您更改行为时，请在 docs/ 中记录公共实用程序。

嵌套 代理.覆盖.md 文件允许特定的子目录（例如，具有更严格规则的支付服务）完全替换其上方的指南，而不是附加到其上——这在 monorepo 中很有用，因为“运行测试”在每个包中意味着不同的事情。

记忆

Codex 的本地内存系统独立于 ChatGPT 的 Web 内存，默认情况下处于关闭状态。启用后，Codex 可以将空闲的、符合条件的过往会话的上下文信息转换为本地内存文件。 ~/.codex/memories/它会在过程中删减秘密信息，并跳过短暂的聊天记录，因此不会总结仍在进行中的工作。

[特征] 记忆 = 真

两个值得了解的设置： 记忆.使用记忆 控制是否将过去的记忆注入到新的记忆会话中，以及 memorys.disable_on_external_context 完全避免依赖网络搜索或 MCP 工具调用的聊天记录占用内存——如果您不希望 Sentry 分诊会话用其他人的堆栈跟踪污染内存，这将非常有用。

提示、上下文和循环工程

三种相关但又截然不同的技能，将那些与 Codex 对抗的开发者与那些能够利用 Codex 快速处理积压工作的开发者区分开来。

迅速工程

要具体说明你想改变什么，以及“完成”后的样子，而不仅仅是症状。“修复不稳定的结账测试”不如“结账测试在折扣码断言方面间歇性失败——重现该问题，找出竞争条件，并添加回归测试”更有说服力。

上下文工程

这取决于 Codex 的访问权限，而不是你输入的内容：正确的 AGENTS.md 作用域、已启用的正确 MCP 服务器以及已打开的正确文件。即使你的提示信息措辞完美，如果 Codex 无法访问实际控制你所询问行为的配置文件，仍然会失败。

循环工程

设计可重复的“提议→运行→检查→重复”循环，而不是一次性提示，这种做法非常有效——例如，让 Codex 在每次更改后运行测试套件，并不断迭代直到测试通过，而不是手动检查每次尝试。Codex 的 Cookbook 中直接记录了这种迭代修复循环模式。

多智能体和子智能体工作流程

Codex 支持子代理——主 Codex 会话可以将特定任务委派给具有作用域的代理实例。其实际应用场景是并行处理独立任务：一个子代理运行测试套件并返回结果，而主会话则继续编辑，而不是由一个代理串行执行所有操作。这比插件或 MCP 更新、更高级，值得将其视为一种优化手段，前提是你的单代理工作流程已经稳定可靠，而不是作为起点。

实际工作流程，一步一步来

1. 使用 Codex 构建 React 应用程序

首先搭建一个包含清晰的 AGENTS.md 文件的脚手架（包含包管理器和测试命令等信息），然后以结果为导向提示用户选择功能。要求在组件开发的同时编写测试用例，而不是事后才提出。

2. 使用 Sentry 插件修复生产环境中的错误

确定查询范围，在修复之前要求找出根本原因，并要求在同一差异中进行回归测试。

3. 直接从 Figma 生成 UI

将 Codex 指向特定帧，而不是整个文件——大文件会减慢 MCP 检查速度，并增加引入不相关组件的可能性。

4. 根据 GitHub 提交记录编写文档

5. 重构遗留代码库

编写代码之前，先要一份计划。循环工程在遗留代码重构中发挥着关键作用——让 Codex 重构一个模块，运行测试套件，只有在测试通过后才继续进行。

6. 自动审核拉取请求

GitHub Action 是这里正确的切入点——它能触发每个 PR 的 Codex 审查，而不是依赖某人记得手动请求审查。

7. 生成 SQL 迁移

如果没有精心设计的数据库插件，这通常会通过项目范围的 MCP 服务器来运行，用于您的数据库，迁移始终需要手动审核和应用，而不是自动执行。

8. 部署到 Vercel

即使预览部署已经变得习以为常，生产环境的部署也应该保留人工审批步骤。

最佳实践

的

• 保持 AGENTS.md 的范围明确具体——一条清晰的规则胜过五条模糊的规则。
• 在以下位置启动新插件 迅速的 切换到审批模式之前 汽车。
• 卸载不常用的插件——每个已安装的工具都是攻击面。
• 将 MCP 服务器凭据的范围缩小到任务所需的最低限度。

禁忌

• 不要依赖记忆来记住那些必须始终适用的规则——请使用 AGENTS.md。
• 不要为了“省事”而授予插件生产环境写入权限——它省去的正是发现错误的那一步。
• 不要因为安装了就将不相关的 MCP 服务器堆叠到一个会话中——每个服务器都会向上下文中添加令牌，并可能导致工具混淆。

初学者常犯的错误

• 将插件的安装视为一次性决策，而不是随着项目的成熟而重新审视其权限。
• 写作提示应描述症状，而不是期望的最终状态。
• 完全跳过 AGENTS.md，并在每个提示中重新解释项目约定。

存储库组织清单

• 根目录下的 AGENTS.md 文件，包含测试命令、包管理器和禁止操作。
• 仅当子目录确实存在差异时才需要嵌套 AGENTS.override.md 文件。
• 项目范围 .codex/config.toml 适用于此仓库特有的 MCP 服务器
• 以下简要列出哪些插件已获准加入此仓库以及原因。

常问问题

结论

插件系统让 Codex 从一个非常优秀的自动补全工具，摇身一变成为一个可以真正融入团队现有工具（例如 GitHub、Figma、Sentry、Slack 和 Notion）的智能代理，而无需你编写任何粘合代码。当然，这一切都不能取代良好的判断力：仔细审查差异，明确审批模式的范围，并确保 AGENTS.md 文档的规范性。不妨先从一个能够解决日常琐事的插件入手，熟悉其审批设置，然后再逐步扩展。真正节省时间的流程往往并非最复杂的，而是你真正坚持使用的那个。