1. 为什么突然冒出 Memory、MCP、Plugin 这三个词很多朋友在刷 Codex 相关帖子时会频繁看到几个概念Memory、MCP、Plugin。有人把它们混为一谈有人看到一堆英文字母就头大还有人以为这是三个必须全部装上的东西。先说结论这三者不是并列关系也不是必须同时使用的功能而是 Codex 在不同层面扩展能力的三种机制。如果你把 Codex 理解成一个“AI 程序员实习生”那么Memory记忆相当于给这个实习生发了一个笔记本让他记住你项目的偏好和规则。MCP模型上下文协议相当于给这个实习生接通了公司内部系统他可以自己查数据库、看设计稿、读本地文件。Plugin插件相当于给这个实习生定制了一套工具箱和使用手册让他按照你规定的流程做事。很多教程一上来就贴配置代码完全没有解释“为什么要这样配置”结果读者照抄完不知道会在什么场景下触发这些能力遇到报错也完全没法排查。这篇文章是“献给普通人的 Codex 保姆级教程”系列的第四篇不追求把官方文档全部翻译一遍而是用最直白的方式讲清楚这三者的底层逻辑、配置方式、实战用法和避坑经验。适合人群已经能正常使用 Codex 基础功能但想进一步优化 Codex 工作流或者被这三个概念困扰的开发者。学完后你能分辨什么场景该用 Memory、什么场景该上 MCP、什么时候需要写 Plugin以及如何配置它们。2. Memory不是“记忆聊天记录”而是“记住项目规矩”2.1 Codex 的 Memory 到底记住什么很多初学者以为 Memory 就是让 Codex 记住你之前聊过什么下次继续聊。这个理解不完全对。Codex 的 Memory 在多数实现中指的是项目级或全局级的持久化上下文。它保存的不是对话内容而是“关于这个项目的知识”。举个例子你正在维护一个 Java 老项目项目里全部使用lombok并且禁止在 Controller 中直接写业务逻辑。如果你不配置 Memory每次让 Codex 写代码它都可能按照自己的理解生成一个没有使用 Lombok 的类或者把一堆业务逻辑塞进 Controller。如果你配置了 Memory并写入两条规则1. 本项目所有实体类必须使用 Lombok 的 Data 注解 2. Controller 层只做参数接收和结果返回不允许写业务逻辑那么后续 Codex 生成代码时会优先遵守这些约定。从产品形态上看这里需要区分两类 Memory对话级 Memory上下文窗口Codex 每次会话能记住多少内容通常由上下文窗口大小决定。持久级 Memory项目知识跨会话保存的长期信息也就是 Codex CLI 配置中的memory设置、知识点文件、或云端团队共享的知识库。真正让普通用户受益的是后者——持久级 Memory。2.2 Codex CLI 中如何配置 Memory以 Codex CLI 为例不同版本界面可能有差异但思路一致核心思路是通过配置文件或专属指令文件把“长期记忆”注入到每一次会话中。常见做法是使用config.toml中的memory字段也可以直接使用AGENTS.md或类似约定文件。# 文件路径~/.codex/config.tomlmacOS / Linux或 %USERPROFILE%\.codex\config.tomlWindows model gpt-5 memory [ 项目使用 JDK 17禁止使用已过时的 javax 命名空间, 代码提交前必须执行 mvn -q test 通过全部测试, 接口返回格式统一为 { code: 0, message: success, data: ... } ]如果 Codex CLI 版本较老或你的项目偏好用文件形式维护也可以在项目根目录创建一个AGENTS.md文件# 项目记忆文件 ## 技术栈 - 后端Spring Boot 3.2 MyBatis-Plus - 数据库MySQL 8.0 - 构建工具Maven ## 编码规范 - Service 层必须面向接口编程 - 所有日期字段使用 LocalDateTime禁止使用 Date - 统一异常处理禁止在 Controller 中 try-catch ## 约定 - 新功能必须编写单元测试覆盖率不低于 80% - 数据库变更脚本统一放在 src/main/resources/db/migration 目录2.3 配置了 Memory 后怎么验证你可以做一个小实验。在当前项目中新建一个临时 Java 类要求 Codex 生成一个“用户注册”功能。如果 Memory 生效Codex 生成的代码中会自然而然带上Data注解如果记忆文件中写了日期类型会用LocalDateTime而且不会在 Controller 中出现大量 try-catch。如果这些约定都没体现说明 Memory 没有正确加载。排查顺序如下检查 config.toml 路径是否正确。检查当前工作目录是否在项目根目录Codex 默认从当前目录加载项目记忆。检查AGENTS.md文件名是否拼写正确——注意是AGENTS.md不是AGENT.md。查看 Codex 启动日志看是否提示 memory 文件加载失败。2.4 Memory 的关键认知它不会自动维护Memory 不是“录完就完事”。随着项目发展技术栈调整、规范改变你需要手动更新记忆内容。我建议每两周或每个迭代结束查看一次 Memory 内容删除过期条目补充新约定。否则Codex 会根据过时记忆做出错误决策反而帮倒忙。3. MCP让 Codex 从“聊天机器人”变成“能动手的工具人”3.1 MCP 是什么为什么 Codex 需要它MCP 全称 Model Context Protocol模型上下文协议可以理解为一套标准通信协议让 AI 编程助手能够通过统一方式连接外部工具。没有 MCP 时Codex 只能基于你提供的代码和文字描述进行推理。虽然它能写代码但无法实时查询数据库、无法直接读取某个设计稿的样式参数、无法调内部 API。有了 MCP 后Codex 可以通过 MCP Server 连接本地文件系统数据库设计工具如 Figma、蓝湖浏览器自动化工具内部 API 网关测试平台换句话说MCP 把“AI 写代码”升级为“AI 能感知外部世界并调用工具”。有一个常见的对比问题Computer Use 和 MCP 的区别是什么这里简单解释一下MCP是“给 AI 一个 API 接口”AI 按照协议调用工具输入输出都是结构化数据。Computer Use是“给 AI 一双眼睛和一双手”AI 直接操作屏幕、键盘、鼠标更像模拟人类操作。MCP 更稳、更可控适合开发工具链集成Computer Use 更像通用自动化适合模拟人工操作的场景。如果只是想让你本地的 Codex 连接数据库或设计稿优先用 MCP。3.2 MCP 的核心概念Server 与 Client在 MCP 架构中通常有两个角色MCP Client发起工具调用的 AI 应用比如 Codex CLI。MCP Server提供具体工具的服务比如一个读取 MySQL 数据库的服务、一个读取本地文件的服务。以 Codex CLI 为例配置 MCP 的常见方式是在配置文件中声明 server然后 Codex 启动时自动加载这些 server。一个典型的 MCP Server 配置如下{ mcpServers: { my-db: { command: npx, args: [-y, modelcontextprotocol/server-sqlite, /path/to/database.db], env: { DATABASE_URL: mysql://user:passwordlocalhost:3306/mydb } }, fs: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /Users/me/projects] } } }解释一下my-db和fs是自定义的 server 名称你可以理解为给工具起的别名。command是启动命令npx表示通过 Node.js 生态运行某个包。args是传递给该命令的参数。env用于设置环境变量比如数据库连接串。3.3 Codex CLI 如何加载 MCP Server不同版本的 Codex CLI 配置方式会有差异。以较新版本为例你可以在config.toml中直接添加 MCP server 配置# 文件路径~/.codex/config.toml [mcp_servers.my-db] command npx args [-y, modelcontextprotocol/server-sqlite, /path/to/database.db] [mcp_servers.fs] command npx args [-y, modelcontextprotocol/server-filesystem, /Users/me/projects]配置完成后重新启动 Codex。启动时如果看到类似日志MCP server [my-db] connected MCP server [fs] connected说明 MCP Server 加载成功。注意不要一边写mcpServersJSON一边写mcp_serversTOML 片段两套配置同时存在可能导致 Codex 只读取其中一种格式。建议统一使用 config.toml 的 TOML 格式。3.4 实战演示通过 MCP 连接本地时间服务为了让你直观感受 MCP 的用途这里给出一个非常简单的本地时间服务示例。我们让 Codex 通过 MCP 调用一个能够返回当前时间的小工具。先创建一个简单的 Python HTTP 服务作为 MCP Server 的底层能力# 文件路径my_mcp_time_server.py from http.server import HTTPServer, BaseHTTPRequestHandler from datetime import datetime import json class TimeHandler(BaseHTTPRequestHandler): def do_GET(self): if self.path /time: now datetime.now().isoformat() body json.dumps({current_time: now}).encode(utf-8) self.send_response(200) self.send_header(Content-Type, application/json; charsetutf-8) self.send_header(Content-Length, str(len(body))) self.end_headers() self.wfile.write(body) else: self.send_response(404) self.end_headers() if __name__ __main__: server HTTPServer((127.0.0.1, 8765), TimeHandler) print(Time server running at http://127.0.0.1:8765) server.serve_forever()运行这个服务python my_mcp_time_server.py然后在浏览器或 curl 中验证curl http://127.0.0.1:8765/time预期输出{current_time: 2025-06-14T10:30:00.123456}这是一个最简单的“外部能力服务”。真正的 MCP Server 还需要按照 MCP 协议封装工具定义但核心思路就是这样Codex 通过 MCP 协议访问服务能力拿到结构化数据再结合你的代码上下文完成任务。3.5 热词里提到的“蓝湖 MCP”“Figma 插件 Open Figma MCP”怎么理解网络热词中频繁出现“蓝湖 MCP”“Figma 插件 Open Figma MCP”这些本质上是第三方团队为设计协作平台开发的 MCP Server 实现。使用场景非常典型前端开发时设计稿在蓝湖或 Figma 上里面有精确的间距、颜色、字体大小。以前你需要肉眼对照设计稿写 CSS配置了蓝湖 MCP 或 Open Figma MCP 后可以让 Codex 读取设计稿中的元素属性然后自动生成对应的样式代码。MCP 工具的关键价值是把 AI 变成了能“看到设计方案”的队友而不是抽象的代码生成器。不过第三方 MCP Server 质量参差不齐。推荐优先选择社区活跃、维护频率高的官方或知名团队项目避免使用来源不明的 MCP Server防止恶意工具读取你的本地文件或泄露敏感信息。4. Plugin给 Codex 定制的“工具箱与操作手册”4.1 Codex 的 Plugin 机制是什么如果你用过 IDE 或编辑器对“插件”这个词应该不陌生。Codex 的 Plugin 也是一种扩展机制但它不只是“加一个按钮”而是可能会添加自定义命令修改 Codex 的默认行为增加预设的 Prompt 模板提供与第三方工具的深度集成自定义代码审查规则在 Codex 中Plugin 和 MCP 的边界有时会让新手混淆。简单来说MCP 是打通 Codex 与外部工具之间的数据通道。它解决的是“Codex 无法访问外部数据和服务”的问题。Plugin 是修改 Codex 自身的行为逻辑。它解决的是“Codex 不够懂你的开发流程”的问题。举一个通俗的例子MCP 相当于给 Codex 配了一台可以随时查看企业数据库的电脑Plugin 相当于给了 Codex 一本《这个项目该怎么写的操作手册》。4.2 Codex CLI 中 Plugin 的表现形式以本地 CLI 为例Codex 的 plugin 通常通过专门的插件目录或配置文件管理。一个常见的插件文件结构如下~/.codex/plugins/ ├── myplugin/ │ ├── plugin.toml │ └── commands/ │ ├── review.md │ └── clean.md其中plugin.toml定义插件元数据# 文件路径~/.codex/plugins/myplugin/plugin.toml name my-project-plugin version 1.0.0 description 为项目提供代码审查与清理指令而commands/目录下放的是自定义 Prompt 模板。例如review.md# 代码审查指令 请对本次改动进行代码审查重点检查 1. 是否遵循项目 Memory 中约定的命名规范 2. 是否存在明显的 SQL 注入风险 3. 是否缺少必要的异常处理 4. 是否有未使用的 import 或重复代码 审查结果按以下格式输出 - 风险等级高 / 中 / 低 / 无 - 问题文件文件路径 - 问题描述具体原因 - 修复建议可执行的修改方案配置完成后你在 Codex 中调用自定义指令时Codex 会加载该模板并按照模板中定义的步骤执行任务。4.3 第三方 Plugin 生态从 dsh plugin 看开源插件管理热词中出现了dsh plugin --profile web add dshmarket、awesome dsh plugin等关键词这反映了 Codex / 相关 CLI 工具已经出现了插件市场的雏形。以 dsh 为例一个与开发工作流相关的 CLI 工具可以通过类似命令安装插件dsh plugin --profile web add dshmarket这条命令的作用是从dshmarket插件源安装适用于 web 开发 profile 的插件。装完后dsh plugin tree可以查看已加载的插件树dsh plugin tree输出可能类似plugins/ ├── base │ ├── git-helper │ └── commit-template └── web ├── react-router-snippets └── tailwind-inspector有的用户会遇到这样的报错dsh: plugin tree failed to load: failed to apply loader entry include (cordi...)这种问题通常是因为插件依赖链不完整或某个插件版本与当前 CLI 不兼容。排查思路是查看已安装插件列表dsh plugin list尝试移除最近安装的可疑插件dsh plugin remove plugin-name清理插件缓存再看是否恢复。这些命令虽然不全是 Codex 官方内置能力但它们展示了一个重要趋势AI 编程工具的扩展能力正在全面生态化。未来 Codex 的 Plugin 也会更像 VS Code 插件市场那样拥有统一的安装、更新、卸载机制。4.4 为什么你会看到“Plugin”和“MCP”被混在一起讨论热词中有大量混合关键词比如unity mcp、cocoscreator mcp、matlab mcp、cursor连接蓝湖mcp、bp搭建mcp服务器。这说明大家在实际使用中已经把“MCP”当成一种通用集成方式而“Plugin”则被理解为更广义的扩展。产生混淆的核心原因在于很多时候一个 MCP Server 的交付形式就是一个插件。例如一个 Figma 的 MCP Server它可能是以“Figma 插件”的形式分发Open Figma MCP也可能是以 npm 包形式分发。两者在不同入口看到看起来都是 plugins但本质都是通过 MCP 协议与 Codex 交互。我的建议是不要在术语分类上过度纠结。只要你能回答以下几个问题就已经够用了这个东西负责提供什么能力数据查询 / 文件操作 / 设计稿读取 / 行为约束它是独立服务还是要嵌入 Codex 进程配置后Codex 是通过 MCP 调用它还是通过 Plugin 指令触发它5. Memory、MCP、Plugin 三者的关系与选型5.1 一张表看懂三者的定位维度MemoryMCPPlugin核心作用提供长期知识与规范提供外部工具与数据能力修改 Codex 行为与流程类比项目规则笔记API 接口的标准化通道自定义工具箱和操作手册数据流向从记忆到 Codex单向Codex 与外部服务双向从模板/预设到 Codex单向或双向典型场景项目代码规范、技术栈锁定查数据库、读设计稿、调接口自定义代码审查、自动提交信息模板配置复杂度低中中到高调试难度低中中适合人群所有用户有工具集成需求的开发者有固定工作流的团队5.2 实际项目中如何选型不要一上来就三个全上。我的建议是分阶段推进第一阶段先配置 Memory。这是成本最低、收益最明显的一步。把团队规范写进记忆文件AI 生成的代码质量立刻上一个台阶。第二阶段按需接入 MCP。当你发现 Codex 需要频繁查数据库、读文件、对接设计工具时再考虑启用 MCP Server。优先加 1~2 个最常用的工具验证稳定后再扩展。第三阶段沉淀 Plugin。当团队有固定的代码审查、发布检查、命名规范校验等流程时把这些流程固化成 Plugin 模板让 Codex 自动按模板执行。如果你一上来就同时配置大量 MCP Server 和 Plugin很可能发生的问题是MCP Server 启动失败导致 Codex 整体异常。Plugin 指令模板互相冲突。Memory 中的规范与 Plugin 模板里的要求不一致。5.3 一个常见错误把 Memory 当作 MCP 的替代品有人觉得“既然 Memory 能告诉 Codex 项目规范那我还配 MCP 干嘛直接在 Memory 里写清楚规则让它别乱来不就行了”这种想法混淆了两者边界。Memory 里只能写“静态知识”例如这个项目用 Spring Boot 3.2禁止使用java.util.Date所有接口必须返回统一结果类但你无法在 Memory 里写“实时数据”例如当前数据库里用户表的结构某张订单表的最近 30 天数据量某个测试环境的接口返回内容这些动态信息必须通过 MCP 才能在运行时获取。所以Memory 回答的是“你应该怎么做”MCP 回答的是“你需要的现实数据是什么”。两者配合才能发挥最大效果。6. 常见问题与排查清单6.1 高频问题汇总问题现象可能原因解决思路Codex 启动时报 MCP server 连接失败端口被占用 / 依赖未安装检查端口与依赖先手动启动 MCP Server 验证Memory 中写的规范没有被遵守配置文件路径不对 / 文件名拼写错误确认AGENTS.md位于项目根目录文件名不要写错Plugin 里的指令无法触发插件目录结构不对 / 指令名冲突确认commands目录下模板命名正确避免中文或特殊字符MCP Server 能连上但 Codex 无法识别工具MCP 协议版本不匹配检查 Codex 与 MCP Server 的协议版本尽量使用官方推荐版本Codex 中文输出变成乱码终端编码不一致Windows 优先使用 Windows Terminal并确保代码文件 UTF-8 编码6.2 “process exited with code 3221225477”这类报错意味着什么热词中出现了process exited with code 3221225477 / 0xc0000005 (memory access violation)的内容。这类报错本质上是内存访问违规通常和 MCP Server / Plugin 进程崩溃相关。常见触发场景某个 MCP Server 使用了不兼容的 Node.js 原生模块。配置了多个 MCP Server其中一个崩溃导致整体退出。插件加载了超出内存限制的大文件。排查步骤先逐个禁用 MCP Server找到引发崩溃的那个。查看崩溃前 Codex 日志中最后加载的模块。如果某个 server 是通过npx启动的手动执行一次对应命令看是否稳定。清理该 server 的缓存目录或重新安装依赖。这种问题不是 Codex 本身不稳定更多是 MCP/Plugin 生态中的第三方依赖质量问题。6.3 其他热词带来的排错提示热词中还有一条cc switch local proxy failed while handling codex endpoint /responses. provi...这通常出现在 Codex 通过代理访问接口时。出现这类情况优先检查代理配置是否过期。网络环境是否有特殊限制。代理工具是否在系统级设置中覆盖了 Codex 的请求。建议不在技术教程中展开讨论代理细节因为不同网络环境差异很大。6.4 排查总清单无论遇到什么扩展相关的问题按以下顺序排查最小化验证禁用所有 MCP/Plugin只保留 Memory看问题是否消失。逐项启用每启用一个扩展重启 Codex 并执行一个简单测试。日志优先查看 Codex 的 debug 日志不要猜。版本固定确认 Codex CLI、MCP Server、插件版本之间是否兼容。回归测试修复后执行一次实际开发任务不要只验证“能启动”。7. 最佳实践与工程建议7.1 Memory 的维护规范Memory 内容要简短明确不要大段粘贴团队 Wiki。Codex 每次读取都会消耗上下文如果记忆文件过长反而会挤占代码上下文空间。使用正面表达例如“必须使用Data注解”而不是“不要忘记加Data”。正面指令更容易被模型遵循。定期检查在新的迭代开始前打开记忆文件删除不再适用的条目。7.2 MCP 的安全边界使用 MCP 时重点关注安全问题最小权限MCP Server 只开放必要的目录或数据表不要把所有文件路径都暴露给 Codex。来源可信使用第三方 MCP Server 前检查其开源仓库的 star 数、最近提交时间、issue 响应情况。拉取恶意工具到本地可能造成敏感数据泄露。敏感信息隔离生产数据库的账号密码不要直接写进 MCP 配置文件。优先使用环境变量注入。日志脱敏启用 MCP Server 后Codex 对话日志中可能包含数据库查询内容注意日志脱敏。7.3 Plugin 的团队协作如果是团队使用建议将 Plugin 模板纳入版本控制放在独立的仓库中。团队成员 clone 项目后通过统一脚本安装插件确保所有人的 Codex 行为一致。以下是一个简单的同步脚本示例#!/bin/bash # 文件路径scripts/sync-codex-plugins.sh set -e PLUGIN_SOURCE_REPOgityour-git-server:codex-plugins.git PLUGIN_DIR$HOME/.codex/plugins if [ ! -d $PLUGIN_DIR/.git ]; then git clone $PLUGIN_SOURCE_REPO $PLUGIN_DIR else git -C $PLUGIN_DIR pull fi echo Codex plugins synced from $PLUGIN_SOURCE_REPO7.4 性能与稳定性建议MCP Server 数量控制在 5 个以内过多会导致启动缓慢。尽量避免在 MCP Server 中使用本地大文件扫描。如果你使用的是老旧机器插件启用后出现卡顿优先查看内存占用。生产环境使用 Codex 时建议将 Memory、MCP、Plugin 的配置拆分为独立的 profile方便切换。8. 总结与动手建议到这里我们已经把 Codex 的三大扩展能力梳理完了。核心要点再强调一遍Memory是长期记忆告诉 Codex 项目规范和背景知识配置最简单收益最直接。MCP是工具调用协议让 Codex 能连接数据库、设计稿、文件系统等外部服务适合需要动态数据的场景。Plugin是行为扩展把团队固定的开发流程固化成模板或指令适合有标准化流程的团队。对于普通用户我建议的下一步是先打开 Codex 配置文件写下你当前项目最重要的一条技术规范比如“本项目必须使用Data注解”。然后运行一次 Codex让它写一个简单的类。确认规范生效后再去研究 MCP 和 Plugin。Codex 的学习曲线并不陡峭真正影响体验的是你如何组织扩展能力。只要按照“Memory 定基础、MCP 补数据、Plugin 定流程”的思路去搭建你的 Codex 会越来越像一个真正熟悉你项目的“资深开发”。希望这篇教程能帮你少走一些弯路。如果后面配置过程中遇到具体的报错欢迎在评论区带上你的操作系统、Codex 版本和配置文件我会尽量帮大家分析。 Codex扩展机制解析：Memory、MCP与Plugin的区别与实战
1. 为什么突然冒出 Memory、MCP、Plugin 这三个词很多朋友在刷 Codex 相关帖子时会频繁看到几个概念Memory、MCP、Plugin。有人把它们混为一谈有人看到一堆英文字母就头大还有人以为这是三个必须全部装上的东西。先说结论这三者不是并列关系也不是必须同时使用的功能而是 Codex 在不同层面扩展能力的三种机制。如果你把 Codex 理解成一个“AI 程序员实习生”那么Memory记忆相当于给这个实习生发了一个笔记本让他记住你项目的偏好和规则。MCP模型上下文协议相当于给这个实习生接通了公司内部系统他可以自己查数据库、看设计稿、读本地文件。Plugin插件相当于给这个实习生定制了一套工具箱和使用手册让他按照你规定的流程做事。很多教程一上来就贴配置代码完全没有解释“为什么要这样配置”结果读者照抄完不知道会在什么场景下触发这些能力遇到报错也完全没法排查。这篇文章是“献给普通人的 Codex 保姆级教程”系列的第四篇不追求把官方文档全部翻译一遍而是用最直白的方式讲清楚这三者的底层逻辑、配置方式、实战用法和避坑经验。适合人群已经能正常使用 Codex 基础功能但想进一步优化 Codex 工作流或者被这三个概念困扰的开发者。学完后你能分辨什么场景该用 Memory、什么场景该上 MCP、什么时候需要写 Plugin以及如何配置它们。2. Memory不是“记忆聊天记录”而是“记住项目规矩”2.1 Codex 的 Memory 到底记住什么很多初学者以为 Memory 就是让 Codex 记住你之前聊过什么下次继续聊。这个理解不完全对。Codex 的 Memory 在多数实现中指的是项目级或全局级的持久化上下文。它保存的不是对话内容而是“关于这个项目的知识”。举个例子你正在维护一个 Java 老项目项目里全部使用lombok并且禁止在 Controller 中直接写业务逻辑。如果你不配置 Memory每次让 Codex 写代码它都可能按照自己的理解生成一个没有使用 Lombok 的类或者把一堆业务逻辑塞进 Controller。如果你配置了 Memory并写入两条规则1. 本项目所有实体类必须使用 Lombok 的 Data 注解 2. Controller 层只做参数接收和结果返回不允许写业务逻辑那么后续 Codex 生成代码时会优先遵守这些约定。从产品形态上看这里需要区分两类 Memory对话级 Memory上下文窗口Codex 每次会话能记住多少内容通常由上下文窗口大小决定。持久级 Memory项目知识跨会话保存的长期信息也就是 Codex CLI 配置中的memory设置、知识点文件、或云端团队共享的知识库。真正让普通用户受益的是后者——持久级 Memory。2.2 Codex CLI 中如何配置 Memory以 Codex CLI 为例不同版本界面可能有差异但思路一致核心思路是通过配置文件或专属指令文件把“长期记忆”注入到每一次会话中。常见做法是使用config.toml中的memory字段也可以直接使用AGENTS.md或类似约定文件。# 文件路径~/.codex/config.tomlmacOS / Linux或 %USERPROFILE%\.codex\config.tomlWindows model gpt-5 memory [ 项目使用 JDK 17禁止使用已过时的 javax 命名空间, 代码提交前必须执行 mvn -q test 通过全部测试, 接口返回格式统一为 { code: 0, message: success, data: ... } ]如果 Codex CLI 版本较老或你的项目偏好用文件形式维护也可以在项目根目录创建一个AGENTS.md文件# 项目记忆文件 ## 技术栈 - 后端Spring Boot 3.2 MyBatis-Plus - 数据库MySQL 8.0 - 构建工具Maven ## 编码规范 - Service 层必须面向接口编程 - 所有日期字段使用 LocalDateTime禁止使用 Date - 统一异常处理禁止在 Controller 中 try-catch ## 约定 - 新功能必须编写单元测试覆盖率不低于 80% - 数据库变更脚本统一放在 src/main/resources/db/migration 目录2.3 配置了 Memory 后怎么验证你可以做一个小实验。在当前项目中新建一个临时 Java 类要求 Codex 生成一个“用户注册”功能。如果 Memory 生效Codex 生成的代码中会自然而然带上Data注解如果记忆文件中写了日期类型会用LocalDateTime而且不会在 Controller 中出现大量 try-catch。如果这些约定都没体现说明 Memory 没有正确加载。排查顺序如下检查 config.toml 路径是否正确。检查当前工作目录是否在项目根目录Codex 默认从当前目录加载项目记忆。检查AGENTS.md文件名是否拼写正确——注意是AGENTS.md不是AGENT.md。查看 Codex 启动日志看是否提示 memory 文件加载失败。2.4 Memory 的关键认知它不会自动维护Memory 不是“录完就完事”。随着项目发展技术栈调整、规范改变你需要手动更新记忆内容。我建议每两周或每个迭代结束查看一次 Memory 内容删除过期条目补充新约定。否则Codex 会根据过时记忆做出错误决策反而帮倒忙。3. MCP让 Codex 从“聊天机器人”变成“能动手的工具人”3.1 MCP 是什么为什么 Codex 需要它MCP 全称 Model Context Protocol模型上下文协议可以理解为一套标准通信协议让 AI 编程助手能够通过统一方式连接外部工具。没有 MCP 时Codex 只能基于你提供的代码和文字描述进行推理。虽然它能写代码但无法实时查询数据库、无法直接读取某个设计稿的样式参数、无法调内部 API。有了 MCP 后Codex 可以通过 MCP Server 连接本地文件系统数据库设计工具如 Figma、蓝湖浏览器自动化工具内部 API 网关测试平台换句话说MCP 把“AI 写代码”升级为“AI 能感知外部世界并调用工具”。有一个常见的对比问题Computer Use 和 MCP 的区别是什么这里简单解释一下MCP是“给 AI 一个 API 接口”AI 按照协议调用工具输入输出都是结构化数据。Computer Use是“给 AI 一双眼睛和一双手”AI 直接操作屏幕、键盘、鼠标更像模拟人类操作。MCP 更稳、更可控适合开发工具链集成Computer Use 更像通用自动化适合模拟人工操作的场景。如果只是想让你本地的 Codex 连接数据库或设计稿优先用 MCP。3.2 MCP 的核心概念Server 与 Client在 MCP 架构中通常有两个角色MCP Client发起工具调用的 AI 应用比如 Codex CLI。MCP Server提供具体工具的服务比如一个读取 MySQL 数据库的服务、一个读取本地文件的服务。以 Codex CLI 为例配置 MCP 的常见方式是在配置文件中声明 server然后 Codex 启动时自动加载这些 server。一个典型的 MCP Server 配置如下{ mcpServers: { my-db: { command: npx, args: [-y, modelcontextprotocol/server-sqlite, /path/to/database.db], env: { DATABASE_URL: mysql://user:passwordlocalhost:3306/mydb } }, fs: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /Users/me/projects] } } }解释一下my-db和fs是自定义的 server 名称你可以理解为给工具起的别名。command是启动命令npx表示通过 Node.js 生态运行某个包。args是传递给该命令的参数。env用于设置环境变量比如数据库连接串。3.3 Codex CLI 如何加载 MCP Server不同版本的 Codex CLI 配置方式会有差异。以较新版本为例你可以在config.toml中直接添加 MCP server 配置# 文件路径~/.codex/config.toml [mcp_servers.my-db] command npx args [-y, modelcontextprotocol/server-sqlite, /path/to/database.db] [mcp_servers.fs] command npx args [-y, modelcontextprotocol/server-filesystem, /Users/me/projects]配置完成后重新启动 Codex。启动时如果看到类似日志MCP server [my-db] connected MCP server [fs] connected说明 MCP Server 加载成功。注意不要一边写mcpServersJSON一边写mcp_serversTOML 片段两套配置同时存在可能导致 Codex 只读取其中一种格式。建议统一使用 config.toml 的 TOML 格式。3.4 实战演示通过 MCP 连接本地时间服务为了让你直观感受 MCP 的用途这里给出一个非常简单的本地时间服务示例。我们让 Codex 通过 MCP 调用一个能够返回当前时间的小工具。先创建一个简单的 Python HTTP 服务作为 MCP Server 的底层能力# 文件路径my_mcp_time_server.py from http.server import HTTPServer, BaseHTTPRequestHandler from datetime import datetime import json class TimeHandler(BaseHTTPRequestHandler): def do_GET(self): if self.path /time: now datetime.now().isoformat() body json.dumps({current_time: now}).encode(utf-8) self.send_response(200) self.send_header(Content-Type, application/json; charsetutf-8) self.send_header(Content-Length, str(len(body))) self.end_headers() self.wfile.write(body) else: self.send_response(404) self.end_headers() if __name__ __main__: server HTTPServer((127.0.0.1, 8765), TimeHandler) print(Time server running at http://127.0.0.1:8765) server.serve_forever()运行这个服务python my_mcp_time_server.py然后在浏览器或 curl 中验证curl http://127.0.0.1:8765/time预期输出{current_time: 2025-06-14T10:30:00.123456}这是一个最简单的“外部能力服务”。真正的 MCP Server 还需要按照 MCP 协议封装工具定义但核心思路就是这样Codex 通过 MCP 协议访问服务能力拿到结构化数据再结合你的代码上下文完成任务。3.5 热词里提到的“蓝湖 MCP”“Figma 插件 Open Figma MCP”怎么理解网络热词中频繁出现“蓝湖 MCP”“Figma 插件 Open Figma MCP”这些本质上是第三方团队为设计协作平台开发的 MCP Server 实现。使用场景非常典型前端开发时设计稿在蓝湖或 Figma 上里面有精确的间距、颜色、字体大小。以前你需要肉眼对照设计稿写 CSS配置了蓝湖 MCP 或 Open Figma MCP 后可以让 Codex 读取设计稿中的元素属性然后自动生成对应的样式代码。MCP 工具的关键价值是把 AI 变成了能“看到设计方案”的队友而不是抽象的代码生成器。不过第三方 MCP Server 质量参差不齐。推荐优先选择社区活跃、维护频率高的官方或知名团队项目避免使用来源不明的 MCP Server防止恶意工具读取你的本地文件或泄露敏感信息。4. Plugin给 Codex 定制的“工具箱与操作手册”4.1 Codex 的 Plugin 机制是什么如果你用过 IDE 或编辑器对“插件”这个词应该不陌生。Codex 的 Plugin 也是一种扩展机制但它不只是“加一个按钮”而是可能会添加自定义命令修改 Codex 的默认行为增加预设的 Prompt 模板提供与第三方工具的深度集成自定义代码审查规则在 Codex 中Plugin 和 MCP 的边界有时会让新手混淆。简单来说MCP 是打通 Codex 与外部工具之间的数据通道。它解决的是“Codex 无法访问外部数据和服务”的问题。Plugin 是修改 Codex 自身的行为逻辑。它解决的是“Codex 不够懂你的开发流程”的问题。举一个通俗的例子MCP 相当于给 Codex 配了一台可以随时查看企业数据库的电脑Plugin 相当于给了 Codex 一本《这个项目该怎么写的操作手册》。4.2 Codex CLI 中 Plugin 的表现形式以本地 CLI 为例Codex 的 plugin 通常通过专门的插件目录或配置文件管理。一个常见的插件文件结构如下~/.codex/plugins/ ├── myplugin/ │ ├── plugin.toml │ └── commands/ │ ├── review.md │ └── clean.md其中plugin.toml定义插件元数据# 文件路径~/.codex/plugins/myplugin/plugin.toml name my-project-plugin version 1.0.0 description 为项目提供代码审查与清理指令而commands/目录下放的是自定义 Prompt 模板。例如review.md# 代码审查指令 请对本次改动进行代码审查重点检查 1. 是否遵循项目 Memory 中约定的命名规范 2. 是否存在明显的 SQL 注入风险 3. 是否缺少必要的异常处理 4. 是否有未使用的 import 或重复代码 审查结果按以下格式输出 - 风险等级高 / 中 / 低 / 无 - 问题文件文件路径 - 问题描述具体原因 - 修复建议可执行的修改方案配置完成后你在 Codex 中调用自定义指令时Codex 会加载该模板并按照模板中定义的步骤执行任务。4.3 第三方 Plugin 生态从 dsh plugin 看开源插件管理热词中出现了dsh plugin --profile web add dshmarket、awesome dsh plugin等关键词这反映了 Codex / 相关 CLI 工具已经出现了插件市场的雏形。以 dsh 为例一个与开发工作流相关的 CLI 工具可以通过类似命令安装插件dsh plugin --profile web add dshmarket这条命令的作用是从dshmarket插件源安装适用于 web 开发 profile 的插件。装完后dsh plugin tree可以查看已加载的插件树dsh plugin tree输出可能类似plugins/ ├── base │ ├── git-helper │ └── commit-template └── web ├── react-router-snippets └── tailwind-inspector有的用户会遇到这样的报错dsh: plugin tree failed to load: failed to apply loader entry include (cordi...)这种问题通常是因为插件依赖链不完整或某个插件版本与当前 CLI 不兼容。排查思路是查看已安装插件列表dsh plugin list尝试移除最近安装的可疑插件dsh plugin remove plugin-name清理插件缓存再看是否恢复。这些命令虽然不全是 Codex 官方内置能力但它们展示了一个重要趋势AI 编程工具的扩展能力正在全面生态化。未来 Codex 的 Plugin 也会更像 VS Code 插件市场那样拥有统一的安装、更新、卸载机制。4.4 为什么你会看到“Plugin”和“MCP”被混在一起讨论热词中有大量混合关键词比如unity mcp、cocoscreator mcp、matlab mcp、cursor连接蓝湖mcp、bp搭建mcp服务器。这说明大家在实际使用中已经把“MCP”当成一种通用集成方式而“Plugin”则被理解为更广义的扩展。产生混淆的核心原因在于很多时候一个 MCP Server 的交付形式就是一个插件。例如一个 Figma 的 MCP Server它可能是以“Figma 插件”的形式分发Open Figma MCP也可能是以 npm 包形式分发。两者在不同入口看到看起来都是 plugins但本质都是通过 MCP 协议与 Codex 交互。我的建议是不要在术语分类上过度纠结。只要你能回答以下几个问题就已经够用了这个东西负责提供什么能力数据查询 / 文件操作 / 设计稿读取 / 行为约束它是独立服务还是要嵌入 Codex 进程配置后Codex 是通过 MCP 调用它还是通过 Plugin 指令触发它5. Memory、MCP、Plugin 三者的关系与选型5.1 一张表看懂三者的定位维度MemoryMCPPlugin核心作用提供长期知识与规范提供外部工具与数据能力修改 Codex 行为与流程类比项目规则笔记API 接口的标准化通道自定义工具箱和操作手册数据流向从记忆到 Codex单向Codex 与外部服务双向从模板/预设到 Codex单向或双向典型场景项目代码规范、技术栈锁定查数据库、读设计稿、调接口自定义代码审查、自动提交信息模板配置复杂度低中中到高调试难度低中中适合人群所有用户有工具集成需求的开发者有固定工作流的团队5.2 实际项目中如何选型不要一上来就三个全上。我的建议是分阶段推进第一阶段先配置 Memory。这是成本最低、收益最明显的一步。把团队规范写进记忆文件AI 生成的代码质量立刻上一个台阶。第二阶段按需接入 MCP。当你发现 Codex 需要频繁查数据库、读文件、对接设计工具时再考虑启用 MCP Server。优先加 1~2 个最常用的工具验证稳定后再扩展。第三阶段沉淀 Plugin。当团队有固定的代码审查、发布检查、命名规范校验等流程时把这些流程固化成 Plugin 模板让 Codex 自动按模板执行。如果你一上来就同时配置大量 MCP Server 和 Plugin很可能发生的问题是MCP Server 启动失败导致 Codex 整体异常。Plugin 指令模板互相冲突。Memory 中的规范与 Plugin 模板里的要求不一致。5.3 一个常见错误把 Memory 当作 MCP 的替代品有人觉得“既然 Memory 能告诉 Codex 项目规范那我还配 MCP 干嘛直接在 Memory 里写清楚规则让它别乱来不就行了”这种想法混淆了两者边界。Memory 里只能写“静态知识”例如这个项目用 Spring Boot 3.2禁止使用java.util.Date所有接口必须返回统一结果类但你无法在 Memory 里写“实时数据”例如当前数据库里用户表的结构某张订单表的最近 30 天数据量某个测试环境的接口返回内容这些动态信息必须通过 MCP 才能在运行时获取。所以Memory 回答的是“你应该怎么做”MCP 回答的是“你需要的现实数据是什么”。两者配合才能发挥最大效果。6. 常见问题与排查清单6.1 高频问题汇总问题现象可能原因解决思路Codex 启动时报 MCP server 连接失败端口被占用 / 依赖未安装检查端口与依赖先手动启动 MCP Server 验证Memory 中写的规范没有被遵守配置文件路径不对 / 文件名拼写错误确认AGENTS.md位于项目根目录文件名不要写错Plugin 里的指令无法触发插件目录结构不对 / 指令名冲突确认commands目录下模板命名正确避免中文或特殊字符MCP Server 能连上但 Codex 无法识别工具MCP 协议版本不匹配检查 Codex 与 MCP Server 的协议版本尽量使用官方推荐版本Codex 中文输出变成乱码终端编码不一致Windows 优先使用 Windows Terminal并确保代码文件 UTF-8 编码6.2 “process exited with code 3221225477”这类报错意味着什么热词中出现了process exited with code 3221225477 / 0xc0000005 (memory access violation)的内容。这类报错本质上是内存访问违规通常和 MCP Server / Plugin 进程崩溃相关。常见触发场景某个 MCP Server 使用了不兼容的 Node.js 原生模块。配置了多个 MCP Server其中一个崩溃导致整体退出。插件加载了超出内存限制的大文件。排查步骤先逐个禁用 MCP Server找到引发崩溃的那个。查看崩溃前 Codex 日志中最后加载的模块。如果某个 server 是通过npx启动的手动执行一次对应命令看是否稳定。清理该 server 的缓存目录或重新安装依赖。这种问题不是 Codex 本身不稳定更多是 MCP/Plugin 生态中的第三方依赖质量问题。6.3 其他热词带来的排错提示热词中还有一条cc switch local proxy failed while handling codex endpoint /responses. provi...这通常出现在 Codex 通过代理访问接口时。出现这类情况优先检查代理配置是否过期。网络环境是否有特殊限制。代理工具是否在系统级设置中覆盖了 Codex 的请求。建议不在技术教程中展开讨论代理细节因为不同网络环境差异很大。6.4 排查总清单无论遇到什么扩展相关的问题按以下顺序排查最小化验证禁用所有 MCP/Plugin只保留 Memory看问题是否消失。逐项启用每启用一个扩展重启 Codex 并执行一个简单测试。日志优先查看 Codex 的 debug 日志不要猜。版本固定确认 Codex CLI、MCP Server、插件版本之间是否兼容。回归测试修复后执行一次实际开发任务不要只验证“能启动”。7. 最佳实践与工程建议7.1 Memory 的维护规范Memory 内容要简短明确不要大段粘贴团队 Wiki。Codex 每次读取都会消耗上下文如果记忆文件过长反而会挤占代码上下文空间。使用正面表达例如“必须使用Data注解”而不是“不要忘记加Data”。正面指令更容易被模型遵循。定期检查在新的迭代开始前打开记忆文件删除不再适用的条目。7.2 MCP 的安全边界使用 MCP 时重点关注安全问题最小权限MCP Server 只开放必要的目录或数据表不要把所有文件路径都暴露给 Codex。来源可信使用第三方 MCP Server 前检查其开源仓库的 star 数、最近提交时间、issue 响应情况。拉取恶意工具到本地可能造成敏感数据泄露。敏感信息隔离生产数据库的账号密码不要直接写进 MCP 配置文件。优先使用环境变量注入。日志脱敏启用 MCP Server 后Codex 对话日志中可能包含数据库查询内容注意日志脱敏。7.3 Plugin 的团队协作如果是团队使用建议将 Plugin 模板纳入版本控制放在独立的仓库中。团队成员 clone 项目后通过统一脚本安装插件确保所有人的 Codex 行为一致。以下是一个简单的同步脚本示例#!/bin/bash # 文件路径scripts/sync-codex-plugins.sh set -e PLUGIN_SOURCE_REPOgityour-git-server:codex-plugins.git PLUGIN_DIR$HOME/.codex/plugins if [ ! -d $PLUGIN_DIR/.git ]; then git clone $PLUGIN_SOURCE_REPO $PLUGIN_DIR else git -C $PLUGIN_DIR pull fi echo Codex plugins synced from $PLUGIN_SOURCE_REPO7.4 性能与稳定性建议MCP Server 数量控制在 5 个以内过多会导致启动缓慢。尽量避免在 MCP Server 中使用本地大文件扫描。如果你使用的是老旧机器插件启用后出现卡顿优先查看内存占用。生产环境使用 Codex 时建议将 Memory、MCP、Plugin 的配置拆分为独立的 profile方便切换。8. 总结与动手建议到这里我们已经把 Codex 的三大扩展能力梳理完了。核心要点再强调一遍Memory是长期记忆告诉 Codex 项目规范和背景知识配置最简单收益最直接。MCP是工具调用协议让 Codex 能连接数据库、设计稿、文件系统等外部服务适合需要动态数据的场景。Plugin是行为扩展把团队固定的开发流程固化成模板或指令适合有标准化流程的团队。对于普通用户我建议的下一步是先打开 Codex 配置文件写下你当前项目最重要的一条技术规范比如“本项目必须使用Data注解”。然后运行一次 Codex让它写一个简单的类。确认规范生效后再去研究 MCP 和 Plugin。Codex 的学习曲线并不陡峭真正影响体验的是你如何组织扩展能力。只要按照“Memory 定基础、MCP 补数据、Plugin 定流程”的思路去搭建你的 Codex 会越来越像一个真正熟悉你项目的“资深开发”。希望这篇教程能帮你少走一些弯路。如果后面配置过程中遇到具体的报错欢迎在评论区带上你的操作系统、Codex 版本和配置文件我会尽量帮大家分析。