Codex 系统实操笔记：从两种登录到 Skill、MCP、RAG 与项目落地的完整拆解

本文由 莫潇羽@无忆研习社（www.wuyi.wiki） 撰写，转载请注明出处。

快速摘要

这篇长文要解决一件事：让一个完全没碰过 Codex 的普通人，看完之后能自己装上、能配好、能真正跑起一整套 AI 编程 Agent 工作流。 我把最近半年折腾 Codex 的实操心得整理成一份可以对着做的手册，覆盖两条登录路径（第三方 API 中转站 与 ChatGPT 官方账号）、Windows 与 macOS 全平台安装、桌面端与 CLI 双入口、界面导览、沙箱权限、计划模式与目标模式、记忆系统、Skill 技能包、插件与自动化、MCP 协议、飞书 CLI 集成、AGENTS.md 规则文件、RAG 知识库搭建，以及电商官网、主图详情页、小游戏、室内设计、手机端远控等落地项目的复盘。全篇按"先原理、再操作、后避坑"的顺序展开，把该注意的合规红线、境外服务的使用边界都圈了出来。

想看完整拆解，往下翻。

一、Codex 到底是个啥：先把定位说清楚

很多同学第一次听 Codex，会把它和 GitHub Copilot、Cursor、通义灵码这些混在一起。表面看都是"AI 帮忙写代码"，但 Codex 的定位其实要往前站一步——它不是给你补全下一行的插件，而是一个能读文件、能改文件、能跑命令、能自己判断下一步的 AI 编程 Agent。

我自己第一次真正意识到区别，是让它去改一个报错的 Python 脚本。我只丢了句"这个脚本跑不动，你看看"，它先自己 ls 了下目录、cat 了报错文件、翻了依赖版本，然后写了一段修改、跑了一遍验证，最后回来告诉我"我改了三处，跑通了"。整个过程我基本没动手。传统的 AI 编程工具是"你问一句、它答一句"，Codex 是"你说个目标、它自己一轮一轮往下推"。

Codex 现在能干哪些事

聊三类典型场景就够了：

• 写代码 / 修 bug / 重构：这是它的老本行。把一个中等规模的仓库丢给它，它可以自己读代码结构、找到问题、写补丁、跑测试。
• 写作与内容工作流：借助 Skill 技能包，Codex 可以稳定复用某一类文档写作、审核、改稿流程，例如新闻稿撰写、代码审查报告、周报归档。
• 办公与协作自动化：接上飞书 CLI、GitHub、数据库等 MCP Server 之后，Codex 能直接读文档、发消息、更新表格，跑成一个"AI 员工"的样子。

Codex 有哪些入口

现在官方给的入口大致有四个：

四个入口共用同一套账号体系、同一份配置。你在 CLI 里训练好的 AGENTS.md 规则、装好的 Skill，都能在桌面 App 里继续跑，反过来也是一样。

我推荐的学习顺序

新手别一上来就折腾 CLI。 建议先装桌面 App，跑通两三个小例子，把"计划模式 / 目标模式 / 沙箱审批"这几个心智模型建起来，再回头去啃 CLI 和 MCP。等这些消化完，你会发现 IDE 扩展只是把桌面 App 的能力搬进了你熟悉的编辑器，学习成本几乎为零。

莫潇羽个人的经验是：Codex 的学习曲线，前 30% 是工具本身，后 70% 是怎么把工具和你手里的活儿对上号。所以下面每一章我都会尽量把"怎么用"和"什么时候用"放在一起讲。

flowchart LR
    A[新手起步] --> B[装桌面 App]
    B --> C[跑通 Hello World]
    C --> D[理解沙箱与审批]
    D --> E[两种模式切换]
    E --> F[记忆 + Skill]
    F --> G[MCP + 飞书 CLI]
    G --> H[项目落地]

二、两条登录路径：中转 API 与 ChatGPT 账号，选哪个不纠结

Codex 目前主流的两种登录方式，本质上是两条不同的模型接入路径。哪一条更适合你，取决于你手上有什么、以及愿意为稳定性付多少成本。

路径 A：第三方 API 中转站 + 自定义密钥

这条路径的意思是：Codex 客户端并不直接连接海外的模型服务，而是把 API 请求先发到一个国内可访问的中转服务（也叫 API 网关、聚合平台），由中转服务再去和实际的模型对接，然后把响应转回来。对个人开发者来说，好处很直接——注册流程走国内邮箱、支付走国内渠道、密钥立即生效，不需要国际手机号，也不用绕来绕去。

具体流程大致是这样：

• 在选定的中转平台注册账号、完成实名（各平台要求不同）
• 后台创建一枚 API Key，把 Key 和平台提供的 base_url 记下来
• 打开一个"多密钥切换工具"（业内俗称 CC Switch），选择"自定义配置"
• 把 官网连接、API 请求地址、API Key 三项都填进去
• 保存 → 启用 → 打开 Codex，选择"其他方式登录"→ 粘贴 Key → 完成

配置完之后，Codex 客户端看起来和官方登录一模一样，只是背后连的是中转站的请求通道。要切换模型（比如从 GPT-5 系列切到国产大模型）也很方便，一键搞定。中转平台通常允许你在同一个 Key 下切换多款主流模型，也提供余额、令牌管理、日志查看等常见后台功能。

需要提醒一句：境外模型的调用与内容生成需遵守国内网络与内容管理相关规定，尤其是涉及企业敏感数据、合同、客户信息时，务必先评估中转平台的合规资质与数据留存政策，别把不该发出去的东西发出去。

路径 B：ChatGPT 官方账号直接登录

另一条路径是走 ChatGPT 账号做官方授权。目前 ChatGPT Plus 及以上等级的账户，可以在 Codex 里选择"使用 ChatGPT 登录"，走一次 OAuth 授权就能直接把账户接入，不需要再单独申请 API Key。这条路径的好处很直接：认证一次长期有效、和 OpenAI 生态耦合更紧、桌面端插件解锁得也更彻底。代价是它对网络稳定性和账号本身的要求更高——你需要一个能正常访问的 ChatGPT 账号，以及一条能稳定连通官方服务的网络链路。

对国内绝大多数普通个人用户来说，路径 A 的门槛更低。对已经有 ChatGPT 长期订阅、并且在正规组织内使用的用户来说，路径 B 更省心。没有绝对的对错，选一条你能长期稳定用下去的。

选路径的三个自检问题

我做过一份内部表，帮着团队里的同学快速判断：

莫潇羽@无忆研习社 的实测感受是：先用路径 A 把 Codex 跑起来，把工作流跑顺，等你确认自己愿意长期投资这套工具，再考虑升级到 ChatGPT 付费账号走路径 B。这样起步成本最低、试错成本也最低。

关于 CC Switch 这类切换工具

它本质上是一个本地的多密钥管理器——帮你在多个 API 供应商、多个 Key 之间快速切换，避免每次改 ~/.codex/config.toml 或 auth.json 都要手动改文件。功能不复杂，但对经常在几个供应商之间切换的人非常省事。

# ~/.codex/config.toml 里的核心两行
model = "gpt-5-codex"
model_provider = "openai"
openai_base_url = "https://你的中转站.com/v1"

注意：切换工具本身也是第三方软件，下载时一定要从其项目的可信来源获取，不要在陌生网盘、云盘乱下。

三、Windows 与 macOS 装机保姆级实录

Codex 的安装本身是傻瓜式的，坑基本都在装完之后的第一次登录。这一章我把桌面 App 和 CLI 两条路都过一遍，Windows 和 macOS 分开讲。

Windows 桌面端安装

Windows 版 Codex 目前主要有两种分发形态：一种是直接从官方站点下载的 .exe / .msi 安装包，另一种是通过微软商店拉起。绝大多数场景我都推荐走官方安装包，装完之后可以直接把可执行文件绑到桌面快捷方式，用起来更顺手。

流程本身很简单：

• 下载对应架构的安装包（一般是 x64；ARM 版本按需选）
• 双击运行 → 一直点"下一步"
• 默认安装路径是 C 盘，如果 C 盘紧张可以改成 D 盘，随便新建一个文件夹就行
• 安装完之后先别急着打开，桌面会出现一个 Codex 图标
• 双击图标，第一次启动稍微等 10 到 20 秒，会自动完成初始化

首次启动会看到一个登录选择界面，两个按钮：Sign in with ChatGPT 和 Use API Key。前一个是路径 B，后一个是路径 A。按第二章的判断标准选就好。

macOS 桌面端安装

Mac 版分发的是 .dmg 镜像文件，安装方式是"拖入"，把 Codex 图标拖进 Applications 目录。

在 Apple Silicon（M 系列芯片）机器上，第一次打开偶尔会遇到 "应用已损坏，无法打开" 的提示。这个多半是签名校验的问题，处理办法有两条：

• 走系统设置：打开"系统设置 → 隐私与安全性"，在最下面找到 Codex，点击"仍要打开"
• 走终端命令：sudo xattr -d com.apple.quarantine /Applications/Codex.app

命令跑一遍之后就可以正常启动了。这条命令的含义是"移除隔离标记"，属于 macOS 的常规兼容操作，不涉及任何绕过安全策略的行为。

Codex CLI 命令行安装

如果你更习惯终端，或者要在服务器、Docker 里用，那么 CLI 才是主战场。CLI 版本本质上就是一个跑在终端里的 Codex Agent——你在里面直接对话、它自己读代码库、写补丁、跑测试、把结果反馈回来，整个循环都在命令行里完成。

安装是一行 npm：

# 需要先装 Node.js，建议 LTS 版本
npm install -g @openai/codex

# 验证
codex --version
codex --help

通过 npm 安装时需要先准备好 Node.js，OpenAI 官方 npm 包目前声明的最低版本是 Node.js 16，实际使用中建议选择当前受支持的 LTS 版本。macOS 用户也可以用 brew install openai-codex 走 Homebrew。

第一次跑 codex，会在 ~/.codex 下自动生成配置目录，里面主要三个文件：

• config.toml：模型、Provider、base_url 这些都在里面
• auth.json：登录信息、Token
• logs/：运行日志，出问题第一时间到这里翻

首装最容易踩的三个坑

坑一：装完看不到插件面板。这基本是版本太旧了，先去官方仓库拉最新版本再重装。AI 工具的迭代速度很快，一个月前的版本可能就已经落后好几个大版本。

坑二：中文界面出不来。桌面 App 的语言设置藏在 Settings → General → Language，切换后需要完全退出再重启（右下角托盘的小图标也要一起退），不然改了不生效。这里说的语言切换是 App 自带的多语言开关，与网络访问无关，别被网上一些教程绕进去买什么"上网工具"，那类做法既不合规也不必要。

坑三：CLI 装完命令找不到。多半是 npm 的全局路径没进 PATH。Windows 打开一个新的 PowerShell 再试；macOS / Linux 检查一下 ~/.npmrc 里 prefix 指向哪里，把对应的 bin 目录加到 PATH 就好。

首次启动的三步验证

装完了，别急着写复杂任务，先跑一遍验证：

• 在对话框里发一句 你好，看有没有正常回复
• 让它跑一个安全命令，比如 ls 或 dir，看沙箱审批弹不弹
• 让它读一个小文件（自己新建一个 test.txt），看能不能正确定位文件路径

三步都过了，就算首装成功。莫潇羽的建议是：第一次别用生产项目试水，新建一个空目录当"练习靶场"，等你摸清脾气再挪到真正的代码库里。

四、界面导览、沙箱与权限：把 Codex 关进笼子里再放出去干活

Codex 是个"能动手"的 Agent，所以权限模型比一般 AI 工具要复杂得多。这一章把界面主要区块、沙箱机制、审批策略讲清楚，你就知道该在哪里点什么按钮。

主界面五大区块

打开桌面 App 之后，界面大致分五个区：

新手第一次打开会看到一堆职业选择题（比如"你是开发者 / 产品 / 运营 / 学生"），这一步只是帮 Codex 推荐默认插件，随便选一个继续都可以，后面都能改。

什么是沙箱

沙箱是 Codex 的"安全笼子"。默认情况下，Codex 只能读取和修改你当前打开的项目目录里的文件；跑命令要经过一次"审批弹窗"确认；访问网络会被拦截或提示。这些默认策略是为了保证 AI 不小心跑一条 rm -rf 之类的破坏性命令时，你还有机会喊停。

具体一点，沙箱模式分几档：

• read-only：只能读文件，不能改、不能执行命令。适合让它"分析代码 / 生成报告"这类场景
• workspace-write：能改工作区里的文件，不能改工作区外的文件，命令仍然要审批。日常推荐档位
• danger-full-access（业内俗称 YOLO 模式）：几乎没有限制，慎用

如果你打算让 Codex 在你不看着屏幕的时候也持续干活（比如挂着跑一整晚），可以临时把权限档位拉到最高，让它自己往下推、不再被审批弹窗打断。但开 YOLO 之前请务必做好三件事：

• 项目做好版本备份或用独立目录
• 尽量放在虚拟机、Docker 或者独立机器里跑
• 关键文件（.env、密钥、生产配置）从工作目录里移出去

审批策略：一次批准 vs 每次批准

在设置里能看到 approval_policy 相关选项，粗略分为：

• 每次都问：安全但慢，人不在电脑前会卡住
• 默认放行、危险动作再问：日常够用，平衡度最好
• 完全放行：等价于 YOLO，别在生产项目里开

我自己的做法是：日常放中间档，需要连续跑长任务时临时切到 YOLO，跑完再切回来。

AGENTS.md：给 Codex 定"上班守则"

在项目根目录放一份 AGENTS.md，可以告诉 Codex 这个项目的技术栈、代码风格、禁改的文件、必须跑的测试命令等等。它在开工前会先读这份文件，然后按里面的规则来。这份文件后面第十一章会专门讲，这里只需要记住：AGENTS.md 是最有效的"防翻车"手段，比在对话里反复叮嘱要靠谱得多。

关于界面语言与本地化

桌面 App 的中文界面是内置的多语言选项，切换即用。这里再强调一次：如果某些老教程告诉你必须借助什么"额外工具"或额外配置才能汉化，那多半是过时的做法或误传。最新的 Codex 桌面 App 直接在设置里就能切语言。涉及境外服务的访问，请优先选国内可用的中转 API 或官方允许的合规通道，不要为了汉化去做超出网络管理规定范围的操作。

五、计划模式 vs 目标模式：Codex 的两颗大脑

这一章是很多老用户都没完全搞明白的地方，但一旦你分清楚，Codex 的效率会直接翻一倍。

计划模式（Plan Mode）在解决什么问题

计划模式适合在动手前让 Codex 先分析、拆解、比较方案，它通常不会急着改文件，而是先给你路线图、风险点和需要确认的问题。翻译成人话就是：Codex 先当一次咨询顾问，把方案摊在桌上，你确认之后它才动手。

流程大致是这样：

• 你抛出一个复杂需求："帮我在这个项目里加个支付功能"
• Codex 进入 Plan 模式，先读代码、翻依赖、问一两个关键决策
• 它给出一份详细计划：改哪几个文件、加哪几张表、涉及哪些风险
• 你审查计划、指出要改的地方（"不要动数据库"、"方案二更好"）
• 确认后它才开始真正动手写代码

什么时候用 Plan 模式：跨模块的大改、涉及架构或数据库的调整、需求本身不太清晰、成本高一失误就麻烦的场景。

目标模式（Goal Mode）在解决什么问题

目标模式是 Codex CLI 在 2026 年 4 月底那次大版本更新（0.128 附近）里新加的能力，/goal 命令背后是一整套目标生命周期管理逻辑，不只是一段花哨的提示词。使用方法很直接：你交代一个目标，Codex 就自己一轮一轮往下推，直到目标达成，或者遇到明确的失败条件停下来。

Goal 模式的四要素：

• 目标：这一轮任务要做什么，用一两句话说明白
• 状态记录：让它把进度保存在 GOAL_STATUS.md，方便断点续跑
• 流程约束：先读 PRD、再读 Spec、再写代码、最后跑测试
• 范围与限制：只改哪些文件、不许动哪些文件、不许做哪些操作

状态记录与断点恢复的实操做法是：让 Codex 每次启动时先检查是否存在 status 文档，如果存在就读里面的状态再继续执行，后续所有变动也都要记录进去。

什么时候用 Goal 模式：长任务、无人值守、需要连续几个小时甚至一整晚跑的项目。业内已经有人拿它连续跑 13 到 21 小时的案例，处理复杂的重构和大规模迁移。

两种模式对比表

一个组合技

我最喜欢的用法是 Plan + Goal 串联：

• 先用 Plan 模式让它出一份完整的实施方案
• 方案确认后不要选"立即执行"，选"保持在 Plan 模式"，然后用 Shift+Tab 退出
• 再用 /goal 命令进入目标模式，把 Plan 的产物当作输入，加上 Done when（完成条件）、Stop if（停止条件）、token budget（预算上限）
• 让 Goal 模式按 Plan 的规划自动往下跑

这个组合的好处是：Plan 提供路线图，Goal 提供执行引擎，两者互补。

/goal 命令的三个关键限制词

在 Goal 模式里，有三个词特别重要，写清楚能省一半麻烦：

• Done when：明确"什么算完成"。例如"所有单元测试通过 且 docs/README.md 更新"
• Stop if：明确"什么时候必须停"。例如"发现任何数据库迁移失败 或 修改超过 500 行"
• token budget：token 预算上限，防止跑飞把额度烧光

不写这些的话，Goal 模式可能会在一个死胡同里循环，白白烧掉大量额度。

注释功能配合使用

Codex 里还有个不太起眼但很好用的功能是内联注释。你可以在代码里用特定注释标记让 Codex 关注某一段：

# @codex: 这段逻辑有性能问题，请重构
def slow_function(data):
    ...

跑起来之后 Codex 会主动关注这些标记的位置。Plan 模式 + 注释标记 + Goal 模式这套组合在中大型项目里特别好用。

六、记忆系统：让 Codex 越用越懂你

"这老师，为什么我的 Codex 越用越笨？"——这是我在群里被问最多的问题。答案往往就一个：你没开记忆系统，或者你的记忆没配对。

为什么需要记忆

Codex 每次开新对话，默认是"失忆的"。你上次告诉它"我们项目用 TypeScript"、"我讨厌 var 声明"、"接口都走 tRPC"，下次它一句都不记得。记忆系统解决的就是这个：把跨对话都要用到的偏好、事实、约束沉淀下来，下次自动带上。

记忆的三个层次

Codex 的记忆大致分三个层级，从低到高：

• 对话层记忆：单次对话内的上下文，关掉就没了
• 项目层记忆：绑定在具体项目上，通过 AGENTS.md 或项目级记忆文件持久化
• 全局层记忆：绑定在账号 / 客户端上，跨所有项目都生效

大部分人只用了第一层，觉得每次都要重新交代一遍很烦。把项目层和全局层用上之后，感受完全不一样。

项目层记忆怎么写

在项目根目录建一份 AGENTS.md（后面第十一章会展开讲），把项目相关的固定信息放进去：

# 项目上下文
- 技术栈：Next.js 14 + TypeScript + Prisma + PostgreSQL
- 代码风格：ESLint + Prettier，禁用 var，优先 const
- 测试框架：Vitest，改代码必跑 `npm test`
- 禁改文件：`prisma/migrations/**`、`.env.production`

Codex 在这个项目里工作时，会自动把这份文件读到上下文里。

全局层记忆怎么开

桌面 App 的设置里有一个 Memories 开关，打开之后 Codex 会在跨对话时主动记住一些偏好。例如你说"我以后所有代码都不要用分号结尾"，它就会把这条记下来，下次自动遵守。

目前圈子里比较成熟的做法是"插件 + MCP + Hook"三件套一起上：插件负责在对话里引导 Codex 该记什么、该问什么；MCP 提供更顺手的检索和写入通道；Stop Hook 则在每次会话结束时自动把有价值的上下文抓下来。这套组合的好处是——即使你在 Codex、Claude Code、Gemini、Cursor 之间切换，记忆也能带着走。

记忆的管理与清理

记忆多了也会有副作用——旧信息可能会污染新任务。所以要定期清理：

• 打开 Memories 面板，会看到一条条的记忆条目
• 每条前面有勾选框，可以批量删除
• 也可以直接告诉 Codex "忘掉关于 XX 项目的所有记忆"，它会主动清理

我个人的节奏是每个月清一次全局记忆，把过期的、不再准确的、误存进去的都清掉。记忆不是越多越好，越准才越好。

记忆 vs RAG 知识库

很多人会混淆记忆和 RAG。简单区分一下：

• 记忆：小、快、跨对话生效，存的是"偏好"和"事实"
• RAG 知识库：大、慢、按需检索，存的是"资料"和"文档"

记忆适合放"我讨厌 var"，RAG 适合放"公司的技术手册全文"。两者互补，不冲突。RAG 的搭建后面第十二章讲。

七、Skill 技能包：把重复流程沉淀成"专属工作流"

Skill 是 Codex 生态里被低估的能力。第一次接触会觉得它就是个"提示词模板"，但真正用起来之后你会发现：Skill 是把某一类重复工作沉淀成"标准作业流程"的最有效方式。

Skill 是什么

Skill 是 Codex 里定义"某类任务该怎么办"的一个扩展模块——你把标准动作、边界条件、期望产出写进一份 Markdown 文件，Codex 在遇到匹配场景时会把它当作工作说明书来执行。你可以把它理解为"当我遇到 XX 类任务时，我应该按什么步骤做"的操作手册。

每一个 Skill 由三样东西组成：

• 名字与描述：告诉 Codex 这个技能什么时候该触发
• 完整指令：也就是 SKILL.md 文件，里面写清操作规则
• 可选资源：模板、参考文档、辅助脚本等

一个最简单的 Skill 例子

---
name: 代码审查
description: 执行深度代码审查并提供改进建议
trigger: /review
---

# 代码审查技能

当用户请求代码审查时，执行以下步骤：

## 审查标准
1. 代码可读性
2. 性能问题
3. 安全隐患
4. 单元测试覆盖

## 输出格式
- 按严重程度分级：Critical / Major / Minor
- 每条问题给出具体行号与建议改法

保存到项目的 .agents/skills/code-review/SKILL.md，之后在对话里输 /review，Codex 就会按这份说明书走一遍代码审查。

Skill 的三种来源

Skill 更像是"你自己写"的部分——工作流本身如何组织；Plugin 更像"打包分发"的部分——把 Skill、连接器、MCP 配置一起塞进一个可安装单元，分给团队里的其他人或 Codex CLI、桌面 App、IDE 扩展等入口。目前 Codex 里 Skill 主要有三个来源：

• 官方内置：Codex 自带的通用 Skill，例如 skill-installer、skill-creator，装完就能用
• 第三方作者：社区里已经有大量优秀的开源 Skill，比如 Karpathy 系列、Superpowers、Grill Me 等
• 自己写：把你团队常做的流程写成 Skill，团队内共享

一个观察：现在写自己 Skill 的人比想象中少，因为社区里已经有非常成熟的第三方 Skill，多数场景直接装现成的就够了。写自己 Skill 更多是针对公司内部特有流程。

Skill 与插件的关系

这里很多人会混淆。用一个比喻：

• Skill 是"菜谱"——告诉 Codex 怎么做
• Plugin（插件） 是"外卖袋"——把菜谱、连接器、MCP 配置打包在一起分发

写给 Codex 的 Skill 最好先按 Agent Skills 标准写通用结构，再按需加入 Codex 扩展，这样 Codex 能稳定识别，迁移到其他支持该标准的工具也更容易。

Skill 的"按需展开"机制

Codex 走的是"按需加载"的思路——启动阶段并不会把每个 Skill 的完整说明都塞进上下文，只放一份"名字 + 简介 + 路径"的目录。等 Codex 判断某个 Skill 值得用，才会去读完整的 SKILL.md。这样上下文预算就不会被一堆不用的 Skill 占满。

为什么这个机制重要：因为它意味着你可以安装几十个 Skill 而不用担心上下文被占满。Codex 会在上下文里放入一份初始技能列表，为了避免挤占提示词的其它部分，这份列表最多使用模型上下文窗口的 2%，如果上下文窗口未知则上限为 8000 个字符。

写 Skill 的三条经验

我自己踩过的坑总结成三句话：

• description 要写得像"广告词"：Codex 判断要不要用你的 Skill，全靠这一句 description。写得越具体、触发场景越明确越好
• 别把不相关的东西塞到同一个 Skill 里：一个 Skill 只干一件事，粒度要细
• 先跑一次再优化：初稿写完就上手用，从 Codex 实际执行的问题里迭代，不要空想

一个团队级 Skill 建议

如果你所在团队要落地 Codex，可以先建一个专门的 Git 仓库 team-skills，把大家写好的 Skill 都放进去，配合 skill-installer：

# 一键从仓库安装
codex install-skill https://github.com/your-team/team-skills

莫潇羽@无忆研习社在自己内部小团队里跑这套已经半年多，收益最大的就是"新人入职一周就能跑通 80% 的日常任务"，因为很多经验都沉淀在 Skill 里了。

八、插件与自动化：让 Codex 变成 24 小时上班的助理

Skill 解决"AI 会做什么"，插件解决"AI 能接什么"，自动化解决"AI 什么时候做"。三者拼在一起，才是真正的 Agent。

插件的三大类

Codex 的插件市场里，插件粗略分三类：

• 官方插件：由 OpenAI 自己维护，例如 Web Search、Chrome 扩展、Computer Use
• 第三方作者插件：社区维护，覆盖 GitHub、Notion、Linear、Slack 等等
• 企业内部插件：企业自己开发的私有插件，通常连到内部系统

装插件的入口在 Settings → Plugins，找到需要的点安装即可。第一次装完记得重启 App，让 Skill 完整加载进上下文。

官方 Chrome 扩展

Codex 官方的 Chrome 扩展是 2026 年 5 月正式上线的，主要能力集中在浏览器侧的信息抓取：批量下载页面上的图片资源、在只读的 JS 沙盒里提取结构化数据、少占用标签页（不再随手创建一堆 Tab Group），任务跑完之后也不留残余标签。装完之后，Codex 就能"看到"你正在浏览的网页，帮你抓资料、填表单、整理内容。

自动化（Triggers / Automations）

自动化是"给 Codex 定闹钟"——把某个任务安排到固定时间自动跑，或者根据某个事件触发。常见用法：

• 每天早上 9 点：让 Codex 汇总昨天的 GitHub 提交、生成日报
• 每周五下午：跑一次单元测试覆盖率报告，发到飞书群
• 收到某封邮件时：自动生成初稿回复

自动化的配置界面很直观：选触发条件、选执行动作、写提示词，保存即可。

一个真实的自动化场景

我自己配的一个自动化：

name: 每日仓库健康检查
trigger:
  type: schedule
  cron: "0 9 * * *"  # 每天早上 9 点
action:
  - 拉取所有仓库最新提交
  - 检查测试是否通过
  - 汇总失败项目
  - 生成 Markdown 报告发到飞书群

跑了两个月下来，团队里再也没有"测试挂了三天没人发现"的情况。这就是自动化的价值：把"人容易忘"的事变成"机器不会忘"。

插件安全的三条底线

因为插件可以读文件、发消息、连外部系统，装之前一定要做几件事：

• 来源可信：只装官方或知名第三方，别装来路不明的
• 权限最小：只给它必需的权限，能只读就别给写权限
• 定期审计：三个月看一次装了哪些插件，用不上的就卸掉

莫潇羽的一个原则：能用 Skill 解决的就别装插件，能装只读插件的就别装写权限插件。

关于境外插件的合规提示

有些第三方插件会调用境外服务（比如翻译、图像生成、云函数）。在国内环境使用这类插件时，需要评估其数据传输路径是否符合当地网络与数据管理相关规定，尤其是涉及企业数据、用户数据的场景，别用个人账号乱试。

九、MCP 协议：让 Codex 接入外部世界的"USB 接口"

MCP 是 Codex 生态里最重要的一环。它决定了 Codex 能不能真正长出"手脚"，去操作你身边的系统。

MCP 是什么

MCP 全称是 Model Context Protocol，中文一般翻成"模型上下文协议"，是这两年 AI Agent 生态里最重要的一份标准。它的角色像是 AI 世界的 USB 接口——不管你用的是 Codex、ChatGPT 还是别家 Agent，只要都遵循 MCP，就能对上同一套外部工具。

在 MCP 出来之前，每个 AI 想连 GitHub 都要单独写一份对接代码，连 Notion 又要重写一份。MCP 统一之后，一个 MCP Server 可以被所有支持 MCP 的 AI 使用。这就是"USB 接口"的意思——协议统一了，插头就通用了。

Codex 里的 MCP 长什么样

在 Codex 里，MCP 主要以两种角色出现：

• Codex 作为客户端：连接外部 MCP Server（例如 GitHub、Notion、飞书、Playwright）
• Codex 作为服务端：把 Codex 本身暴露成一个 MCP Server，让其他 Agent 来调用它

通过将 Codex CLI 作为 MCP Server 接入 Agents SDK，可以轻松搭建多智能体自动化工作流。这两种角色可以同时存在。

装 MCP 前的准备：Node.js

大多数 MCP Server 是用 JavaScript / TypeScript 写的，运行时需要 Node.js。

# macOS 用 Homebrew
brew install node

# Windows 直接下载官方安装包
# 版本建议 20 或 22 LTS
node --version

Node.js 装完之后，任何一个基于 npm 分发的 MCP Server 都能用 npx 一键跑。

装一个 MCP Server 的完整流程

以官方的 Filesystem MCP 为例：

# 找到 Codex 的 MCP 配置文件
# ~/.codex/mcp.json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"]
    }
  }
}

保存后重启 Codex，它就能通过 Filesystem MCP 访问指定目录。类似的还有 server-github、server-postgres、server-slack 等等。

常用 MCP Server 清单

装完这几个，Codex 就从一个"聊天助手"变成了一个能真正干活的"AI 员工"。

MCP 的安全注意事项

MCP Server 本身有可能读写你的敏感数据，所以：

• 配置文件里的凭据（token、密码）要用环境变量或密钥管理器，别硬编码
• 限制目录范围：例如 Filesystem MCP 只暴露必要的子目录，不要暴露整个 HOME
• 写权限慎给：绝大多数场景只读就够了

境外 MCP Server 的使用同样要遵循相应的数据出境合规要求，涉及企业敏感数据时先评估再启用。

一句话总结 MCP

MCP 之于 Codex，就像 USB 之于电脑——协议本身不做事，但它让所有能做事的东西都能插上来。

十、飞书 CLI 集成：让 AI 直接管你的办公协作

如果说 MCP 是通用协议，那飞书 CLI 就是在中国办公场景下最好用的一个具体落地。它把飞书里的文档、消息、日历、多维表格等能力，包装成一套命令行接口，AI Agent 可以直接调。

飞书 CLI 是什么

飞书官方把这套能力做成了开源的 Lark CLI，AI Agent 只需要走一套统一的命令行接口，就能操作飞书里的文档、消息、日历、多维表格等常用模块，中间不用再自己写一层适配。

对于中国团队来说，这个东西的意义在于：你的日常办公 90% 的动作都可以让 AI 代跑——整理会议纪要、更新多维表格、批量发消息、生成日报周报，都不用你亲自打开飞书 App 点点点。

谁适合装飞书 CLI

三类用户适合：使用 Trae、Claude Code、Codex、Cursor 的开发者，可以直接让 AI 代你操作飞书；构建企业级 AI Agent 的团队，可以基于官方推荐最佳实践做深度集成；