Codex App Windows 版高级教程(五):Automations + Plugins,让 Codex 自己干活、把能力打包分享

上一篇我们聊了 Skills 和 MCP——教 Codex 学本事、连外脑。但有一个问题还没解决：每次都要你手动发 Prompt，Codex 才动。

你想让它每天早上自动扫一遍最近的提交，找找有没有明显的 bug？想让它每周自动优化一下你写的 Skills，变得越来越好用？想让它定时帮你生成代码变更摘要，你回来看结果就行？

这就是 Automations 要干的事——给 Codex 设一个闹钟，让它按时自己干活，干完了把结果放在 App 里等你审阅就行。

至于 Plugins，3月27号 openAI 宣布在 codex app 里面开放plugins功能。

我电脑里面启动codex后确实会出现这样的提示

只是我的windows版本界面出来后又会出现skills，之前闪现的那个plugins按钮没了，不知道怎么回事，我猜测是没完全放开吧或者是UI界面统一的问题，毕竟我的版本都是最新的了，后面再说。

那它是用来解决的是另一个问题：你花了半天配好了 Skills + MCP + 各种设置，新来的同事问你”你怎么配的”——你总不能每次都手把手教一遍吧？Plugins 就是把你配好的东西打成一个安装包，别人一键装好就能用。

这篇文章把这两个功能从零讲透。

Automations：给 Codex 设定时任务

先理解它在干什么

最直白的解释：Automations 就是 Codex 版的”定时任务”。你设定一个时间表和一个 Prompt，Codex 到点了自己跑，就是会放在 App 侧边栏。

跟你在服务器上设 cron job 是一回事，只不过执行者从一段脚本变成了一个 AI Agent。

几个关键点先说清楚：

在 Git 仓库里，Automation 可以运行在本地项目或后台 worktree；非 Git 项目则直接运行在项目目录。

选 worktree 模式的好处是它在一个独立的文件副本里干活，不会影响你正在写的代码。如果你选了本地项目模式或者项目本身不是 Git 仓库，要小心一点，因为它可能会改到你正在编辑的文件。

怎么创建一个 Automation

打开 Codex App，侧边栏里找到 Automations 面板，点创建。你需要填两样东西：

时间表（Schedule）： 多久跑一次。可以选每天、每周、自定义间隔。

Prompt： 每次跑的时候执行什么任务。就是你平时手动给 Codex 发的那种 Prompt，写在这里之后它会自动执行。

就这么简单。没有配置文件，没有 TOML，没有 JSON——在 App 界面上点几下就完了。

到点给我自动执行了，但是这里我想强调一下，如果你的任务很复杂的话，它会在对话框里面就行执行很久，然后会把上下文很快占满，这个时候就会自动压缩背景，这个过程很痛苦，因为我好几次自动压缩都是很久很久都不行，这个问题不知道官方什么时候能更好的解决一下。

任务完成后再线程里面可以看到它得到的结果，以后你每天上班前就可以获取到最新的AI技术热门信息了。

还有你也可以通过定时任务模板来创建你的任务，点击use_template

实战一：每天自动扫描最近提交，找 bug

这是 Automations 最实用的场景之一。你每天提交代码，但不可能每次都仔细做 Code Review。设一个每天跑的 Automation，让 Codex 帮你兜底。

创建 Automation，时间表设为每天一次，Prompt 写：

查看最近 24 小时内我提交到 origin/main 的代码改动。针对每个改动，重点检查：1. 有没有空指针风险2. 有没有吞掉异常（catch 了但没 log 也没 throw）3. SQL 有没有注入风险（MyBatis 里用 ${} 而不是 #{}）4. @Transactional 注解有没有用在 private 方法上（事务不会生效）如果没发现问题，直接归档，不用报告。如果发现了问题，列出文件路径、行号和修复建议。

每天早上你打开 Codex App，看一眼对应目录的线程——有问题就处理，没问题就是绿灯，心里踏实。

实战二：每天自动生成代码变更摘要

团队里其他人改了什么代码，你不可能每天去翻 Git log。设一个Automation 帮你生成每日摘要。

Prompt：

查看最近 24 小时内 origin/main 上的所有提交。生成一份简报，格式要求：- 按功能模块分组（不要按提交者分组）- 每个模块写一段话说明改了什么、为什么改- 如果有关联的 PR，附上 PR 链接- 跳过纯格式化、纯注释的提交最后用一句话总结今天最重要的变更。

这个对 Team Lead 来说特别有用——不用自己翻代码，每天看一份自动生成的简报就够了。

实战三：自动优化你的 Skills

这个玩法很有意思——让 Codex 自己改进自己的 Skills。

上一篇我们聊了怎么写 Skills。但 Skills 写好之后不是一成不变的，用着用着你会发现有些指令写得不够清楚、有些场景没覆盖到。手动去改太麻烦了，让 Automation 自动帮你优化。

Prompt：

扫描最近一天 ~/.codex/sessions 里的会话记录。如果发现：- 某个 Skill 被调用后效果不好（用户做了大量修正或重试）- 有重复出现的任务模式还没有对应的 Skill那就：- 更新有问题的 Skill（只改个人级的，不动项目级的）- 如果有值得做成 Skill 的新模式，创建一个新 Skill不要为了改而改——只有真正有改进空间的时候才动手。改完之后告诉我改了什么、为什么改。

这个 Automation 跑一段时间之后，你的 Skills 会越来越准确、越来越好用，因为它在根据你的实际使用情况持续迭代。

有个注意点：~/.codex/sessions/这个目录通常在当前工作区之外。

如果你的 Automations 默认权限模式是 workspace-write，访问这个路径很可能会被拦截；如果默认模式是 full access，权限会更大，但风险也会明显升高。

更稳妥的做法不是直接假设它一定能访问，而是先在普通线程里手动跑通，再决定是否调整默认权限、工作区范围或 rules。关于rules下面会说。

实战四：Automation + Skill 组合——自动修复你自己引入的 bug

这个是官方推荐的高级玩法。分两步：

第一步：先创建一个 Skill。

在你的个人级 Skills 目录创建 .agents/skills/recent-code-bugfix/SKILL.md：

---name: recent-code-bugfixdescription: 查找并修复当前作者最近一周内引入的 bug。当 Prompt 为空或要求检查最近提交的问题时触发。---# 最近代码 Bug 修复## 工作流程### 1. 确定范围- 用 git log --since=1.week --author=<当前用户> 找到最近一周的提交- 只关注这些提交涉及的文件### 2. 找到具体的问题- 优先找能复现的失败（测试不过、lint 报错、运行时异常）- 确认问题确实是你自己的提交引入的，不是历史遗留问题- 如果没找到问题，直接报告"没有发现问题"然后结束### 3. 修复- 只改必要的代码，不做额外的重构或美化- 保持和项目现有代码风格一致### 4. 验证- 跑相关的单元测试确认修复有效- 如果没法跑测试，说明原因和验证方式### 5. 报告- 说清楚 bug 的根因、修复了什么、怎么验证的- 明确指出是哪个提交引入的问题

第二步：创建 Automation 调用这个 Skill。

时间表设为每天一次，Prompt 写：

检查我最近 24 小时的提交，执行 $recent-code-bugfix

这样每天 Codex 会自动检查你今天提交的代码有没有引入新 bug，找到了就自动修，注意这个最好是在worktree里面工作，这样你可以方便的合到local里面去，而不用担心它乱修复BUG。

Automations 的安全边界

这块必须说清楚，因为 Automation 是无人值守的——没有人盯着它干活。

Automation 固定以默认沙箱设置运行，输入框下方的 permissions selector 只影响当前线程；Automations 继承的是全局默认权限设置。默认值可以在 config.toml 里配置。

在沙箱下，如果工具调用需要修改工作空间外的文件、访问网络、或者操作电脑上的应用，这个调用会直接失败——不会弹窗问你要不要放行，因为没人盯着。

这意味着 Automation 会按你的默认权限配置运行。对于代码审查、生成摘要这类分析任务，默认权限通常已经够用；但如果任务需要访问工作区外文件、联网或调用系统能力，就要额外关注权限边界。比如可以靠 Rules来开口子。

Rules 是 Codex 的命令审批机制，可以选择性地允许特定命令在沙箱外运行。规则文件放在 

~/.codex/rules/ 目录下，用 Starlark 语言写（语法接近 Python）。你可以给每条命令设三种策略：allow（允许在沙箱外运行）、prompt（每次要确认）、forbidden（禁止执行）。

举个例子，你想让 Automation 能跑 git log 和 git diff 但不能跑 git push，在 ~/.codex/rules/default.rules 里这么写：

prefix_rule(    pattern = ["git", "log"],    decision = "allow",)prefix_rule(    pattern = ["git", "diff"],    decision = "allow",)prefix_rule(    pattern = ["git", "push"],    decision = "forbidden",    justification = "Automation 不应该直接 push 代码",)

多条规则匹配同一个命令时，Codex 取最严格的那条（forbidden > prompt > allow）。写完之后可以用 codex execpolicy check 命令验证规则是否按预期生效。

所以整个安全模型是这样的：

沙箱负责兜底（默认拦截所有越权操作），Rules 负责开口子（精确放行你信任的命令）。对 Automation 这种无人值守的场景来说，这个组合比单纯选一个”完全访问”模式安全得多。

另一个注意点：Automation 频繁跑会创建大量 Worktree。 如果你选的是 worktree 模式，每次跑都是一个新的 worktree，时间长了会占磁盘空间。记得定期归档不需要的 Automation 运行记录。

先手动测，再设定时

这个建议很重要：不要一上来就设定时任务。先把 Prompt 在普通对话里手动跑一遍，确认效果没问题了，再复制到 Automation 里。

需要确认的事情：Prompt 写得够不够清晰？Codex 有没有按你的预期执行？用了哪些工具，表现正常吗？输出的内容是你想要的格式吗？沙箱模式对不对，会不会被权限拦截？

手动跑通了，再设定时，省得白跑半天发现 Prompt 有问题。

Plugins：把你的配置打成安装包

先搞懂 Plugin 和 Skill 的关系

很多人看到 Plugins 第一反应是”这不就是 Skill 吗”。不完全是。

Skill 是单个技能。一个 SKILL.md 文件，教 Codex 怎么做某一件事。

Plugin 是技能包。它可以把多个 Skills + MCP 配置 + App 集成打包成一个可安装的单元。

打个比方：Skill 就像一门课程（比如”Java 代码审查”），Plugin 就像一个课程包（把”代码审查”+”单元测试”+”Sentry 错误监控”打包在一起，叫”Java 后端开发套件”）。

什么时候用 Skill？你在一个项目里迭代、自己用、或者还在试验阶段。

什么时候用 Plugin？你想把同样的 Skills 和配置分享给团队里的其他人，或者跨多个项目复用。

简单说：先用 Skill 迭代，成熟了再打包成 Plugin 分发。

有一点要提前说：Codex App 的 UI 目前把 Skills 和 Plugins 混在同一个页面展示，也或许是我的windows还没灰度到。英文界面侧边栏应该写的是”Plugins”，但是我的页面标题写的是”Skills”；读者朋友如果你们的出现了plugins，可以直接尝试plugins功能。

Plugin 的文件结构

一个 Plugin 的核心就是一个文件夹，里面有一个必须的 plugin.json 清单文件：

my-plugin/├── .codex-plugin/│   └── plugin.json        # 必须的：插件清单├── skills/                 # 可选：打包的 Skills│   └── java-review/│       └── SKILL.md├── .mcp.json               # 可选：MCP Server 配置├── .app.json               # 可选：App 集成配置└── assets/                 # 可选：图标、截图    ├── icon.png    └── logo.png

plugin.json 是唯一必须的文件，其他都是可选的。但一个有实际价值的 Plugin 至少要包含一个 Skill 或一个 MCP 配置。

这是我用cli来创建的Gmail的插件，目录如上

如果某个 Codex Plugin 包含 Gmail app 集成，Codex 可能会在安装或首次使用时引导你到 ChatGPT 完成该 app 的登录授权。

然后我在ChatGPT里面提问：

查一下我最近 24 小时里最重要的 5 封Gmail 邮件

它给的回复是刚刚cli过来的插件验证是给codex app 用的，

但是我这个codex app 确显示连接不了，我个人观察可能是跟我上面说的我的灰度没到有关。

先说明一下：后面部分主要讲 Plugins 的官方机制、目录结构和配置方式。

由于我当前这台 Windows 版 Codex App 还没有独立的 Plugins 入口，我这边暂时也没法完整实测 plugin marketplace、安装入口和启用流程。所以下面这部分更适合看成“官方设计 + 配置示例 + 本地准备思路”，而不是我当前环境下已经完整跑通的点击教程。等后面版本正常了再尝试这个。

实战五：用 $plugin-creator 创建你的第一个 Plugin

和 Skill 一样，Codex 自带了一个创建器。官方内置了 Plugin Creator 能力，当前文档常见的调用写法是在 Prompt 里输入：

$plugin-creator

它会引导你完成整个创建过程：Plugin 叫什么名字、包含哪些 Skills、需不需要 MCP 配置。创建完之后还会帮你生成本地 Marketplace 配置，让你能在 Plugin 目录里看到自己的插件。

这是最快的上手方式。

实战六：手动创建一个 Java 后端开发套件 Plugin

如果你跟着上一篇文章配了 java-review 和 java-unit-test 两个 Skills，现在我们把它们打包成一个 Plugin，方便团队里其他人一键安装。

第一步：创建 Plugin 文件夹结构。

# 在你想存放 Plugin 的地方创建mkdir -p java-backend-kit\.codex-pluginmkdir -p java-backend-kit\skills\java-reviewmkdir -p java-backend-kit\skills\java-unit-test

第二步：写 plugin.json 清单。

创建 java-backend-kit/.codex-plugin/plugin.json：

{"name": "java-backend-kit","version": "1.0.0","description": "Java 后端开发工具包：包含代码审查和单元测试两个 Skill，适用于 Spring Boot + MyBatis + Redis 技术栈。","author": {"name": "你的名字","email": "your@email.com"  },"keywords": ["java", "spring-boot", "mybatis", "code-review", "unit-test"],"skills": "./skills/","interface": {"displayName": "Java 后端开发套件","shortDescription": "代码审查 + 单元测试，Spring Boot 团队专用","longDescription": "包含 Java 代码审查（SQL 注入、事务、缓存一致性检查）和单元测试生成（JUnit 5 + Mockito + AssertJ）两个 Skill。","developerName": "你的名字","category": "Development","capabilities": ["Read"]  }}

第三步：把你之前写好的 Skills 复制进来。

把上一篇文章里写的 java-review/SKILL.md 和 java-unit-test/SKILL.md 复制到 Plugin 对应的 skills/ 目录下。

第四步：注册到本地 Marketplace，让 Codex 能看到它。

创建 ~/.agents/plugins/marketplace.json（个人级 Marketplace）：

{"name": "my-plugins","interface": {"displayName": "我的插件"  },"plugins": [    {"name": "java-backend-kit","source": {"source": "local","path": "./java-backend-kit"      },"policy": {"installation": "AVAILABLE","authentication": "ON_INSTALL"      },"category": "Development"    }  ]}

注意 source.path 是相对于 Marketplace 文件所在目录的路径。如果你的 Plugin 文件夹放在别的地方，路径要相应调整。

第五步：把 Plugin 文件夹放到 Marketplace 能找到的位置。

# 把 Plugin 复制到个人目录mkdir -p "$HOME\.codex\plugins"Copy-Item -Recurse java-backend-kit "$HOME\.codex\plugins\java-backend-kit"

然后更新 marketplace.json 里的路径：

"path": "./.codex/plugins/java-backend-kit"

第六步：重启 Codex App。

打开插件相关入口，你应该能看到”我的插件”这个 Marketplace，里面有你刚创建的”Java 后端开发套件”。点安装就行。

安装之后，团队里的其他人只要把你的 java-backend-kit 文件夹和 marketplace.json 复制过去，也能一键安装——不用手动建 Skills 文件夹、不用记每个 SKILL.md 怎么写。

实战七：Plugin 里打包 MCP 配置

Plugin 不只能打包 Skills，还能打包 MCP Server 配置。比如你想让团队里每个人都用上 Context7（查技术文档）和腾讯云 CLS（查线上日志），但不想让大家各自去配 config.toml。

在 Plugin 根目录创建 .mcp.json：

{"servers": {"context7": {"command": "npx","args": ["-y", "@upstash/context7-mcp"]    },"cls": {"command": "npx","args": ["-y", "cls-mcp-server@latest"],"env": {"TENCENTCLOUD_SECRET_ID": "","TENCENTCLOUD_SECRET_KEY": "","CLS_REGION": "ap-guangzhou"      }    }  }}

然后在 plugin.json 里加一行：

{"name": "java-backend-kit","version": "1.1.0","description": "Java 后端开发工具包，现在包含 MCP 配置","skills": "./skills/","mcpServers": "./.mcp.json"}

安装这个 Plugin 之后，Context7 和腾讯云 CLS 的 MCP Server 就自动配好了。CLS 的 SecretId 和 SecretKey 需要用户自己填——安装时 Codex 会提示。如果你们团队用阿里云，把 CLS 换成阿里云可观测 MCP Server 就行，思路一样。

两种 Marketplace：团队共享 vs 个人使用

团队共享（Repo Marketplace）：

把 Marketplace 文件放在项目仓库里，这样所有 clone 这个仓库的人都能看到：

你的项目/└── .agents/    └── plugins/        └── marketplace.json     # 团队共享的 Plugin 列表

路径是 $REPO_ROOT/.agents/plugins/marketplace.json。这个文件可以提交到 Git，团队成员拉代码就自动有了。

个人使用（Personal Marketplace）：

放在用户目录下，只有你自己能看到：

C:\Users\你的用户名\└── .agents\    └── plugins\        └── marketplace.json     # 你自己的 Plugin 列表

路径是 ~/.agents/plugins/marketplace.json。

一个 Marketplace 可以包含多个 Plugin。你不用每个 Plugin 建一个 Marketplace——一个 marketplace.json 文件的 plugins 数组里可以列多个 Plugin。

安装官方 Plugin

除了自己做 Plugin，Codex 还有一个官方的 Plugin 目录，里面已经有一批现成的官方插件可直接安装。

在 App 里，侧边栏找到”Plugins”（中文界面显示为”技能”）点进去就是 Plugin 目录。目前有 Gmail、Google Drive、Slack、Figma、Notion 等常用工具的集成。

CLI 也已支持 Plugins，官方当前明确写出的相关浏览命令是 /plugins，插件能力本身已在 CLI 中可用。

安装官方 Plugin 比手动配 MCP 方便得多——点一下安装，认证一下账号，就能用了。比如装了 Gmail Plugin 之后，你可以直接说”帮我总结今天未读的邮件”，Codex 会通过 Plugin 去读你的 Gmail。

Plugin 卸载和管理

卸载： 在 Plugin 目录里找到已安装的 Plugin，点”Uninstall”就行。卸载 Plugin 会移除它包含的 Skills 和 MCP 配置，但如果 Plugin 里包含了 App 集成（比如 Gmail 的授权），那个 App 连接不会被自动删除——需要你手动管理。

启用/禁用： 不想卸载但暂时不用？Codex 会在 config.toml 里记录每个 Plugin 的开关状态，你可以单独关掉某个 Plugin。

Automations + Plugins 的完整流程

把这两个功能串起来，一个完整的进阶流程是这样的：

第一步：写 Skill（上一篇的内容）。 先在项目里写几个实用的 Skill，比如代码审查、单元测试。

第二步：设 Automation（本篇）。 把高频的 Skill 设成定时自动运行，比如每天自动审查提交、自动修 bug。

第三步：打包 Plugin（本篇）。 等 Skills 和 MCP 配置都稳定了，打包成 Plugin，分享给团队。

第四步：团队统一安装。 新同事加入，一键安装 Plugin，Skills、MCP 配置和相关集成可以一起下发——不用从头配。

这就是从”一个人用好 Codex”到”整个团队用好 Codex”的路径。

我的使用边界

适合用 Automation 的场景： 每天/每周定期检查的任务（代码审查、安全扫描），信息摘要类任务（代码变更摘要、PR 汇总），持续改进类任务（自动优化 Skills），配合 Skill 做定期维护（自动修 bug、自动清理 TODO）。

不适合用 Automation 的场景： 需要实时交互的任务（需要你边看边改的场景），需要完全访问权限的高风险操作（数据库迁移、生产环境部署），App 不会一直开着的情况（Automation 需要 App 在运行中）。

适合做成 Plugin 的场景： 多个项目要复用同样的 Skills 和 MCP 配置，团队里多个人要用同样的设置，你的 Skills 已经稳定不再频繁修改。

不适合做成 Plugin 的场景： 还在迭代的 Skill（先用本地 Skill，稳定了再打包），只有你一个人用的个人配置（Skill 就够了，不用打包）。

完整文件结构一览

# 个人级C:\Users\你的用户名\├── .codex\│   ├── config.toml                    # 全局配置 + MCP 配置│   └── plugins\                        # 个人级 Plugin 存放│       └── java-backend-kit\│           ├── .codex-plugin\│           │   └── plugin.json│           ├── skills\│           │   ├── java-review\│           │   │   └── SKILL.md│           │   └── java-unit-test\│           │       └── SKILL.md│           └── .mcp.json└── .agents\    ├── skills\                         # 个人级 Skill（不需要打包的）    │   └── recent-code-bugfix\    │       └── SKILL.md    └── plugins\        └── marketplace.json            # 个人级 Marketplace# 项目级（团队共享）D:\Projects\your-project\├── .agents\│   ├── skills\                         # 项目级 Skill│   └── plugins\│       └── marketplace.json            # 团队 Marketplace├── .codex\│   └── config.toml                     # 项目级配置└── AGENTS.md                           # 项目全局规则

写在最后

Automations 和 Plugins，本质上解决的是两个不同维度的效率问题。

Automations 解决的是时间维度的效率——不用你手动触发，Codex 自己按时干活。Plugins 解决的是协作维度的效率——不用你手动教每个人怎么配，一键安装就能用。

我建议的上手路径：先手动跑一个你每天都会做的任务（比如代码审查），确认 Prompt 效果没问题。然后把这个 Prompt 设成每天自动跑的 Automation，5 分钟搞定。等你的 Skills 积累到 3-5 个、都跑稳了，打包成一个 Plugin。最后分享给团队，让所有人都用上你调教好的 Codex。

说实话，Plugins 目前还在早期阶段——官方的 Plugin 目录还没有开放自助发布，自定义 Plugin 只能通过本地 Marketplace 分发。但这个方向是对的：从个人技能到团队标准化，从手动操作到自动执行，这就是 AI Agent 融入团队工作流的完整路径。

到这里，Codex App Windows 版高级教程系列就全部写完了。从 AGENTS.md、config.toml、Worktrees，到 Subagents、Skills + MCP、Automations + Plugins——7 大功能全覆盖。

觉得有用的话，点个赞或者收藏一下，后面有新功能更新我会继续写。