Codex 进阶：配置文件、MCP 扩展与自动化集成

Codex 进阶的三个方向：用配置文件固化模型、审批策略和项目规则，避免每次重复设置；用 MCP 接入数据库、文档、API 等外部能力；用单次命令模式把 Codex 嵌进脚本和 CI，实现批量与自动化任务。

这是 Codex 系列第 ④ 篇（完结篇）。前三篇覆盖了安装、基础使用和实战流程，本文假设你已经能熟练完成日常任务。

会用 Codex 之后，下一步是让它更懂你、能力更强、能被编排。这一篇讲三件事：配置文件、MCP、自动化集成。

一、配置文件：一次设置，处处生效

前面每次都要 --model、--approval 地敲，很烦。配置文件能把这些固化下来。

全局配置

全局配置在 ~/.codex/config，作用于所有项目：

# ~/.codex/config
model = "sonnet-4"          # 默认模型
approval = "manual"          # 默认审批模式
theme = "dark"

[context]
max_tokens = 100000          # 单次会话上下文上限，控制成本

项目级配置

在项目根目录放 .codex/config，只对当前项目生效，且优先级高于全局配置：

# <项目>/.codex/config
model = "opus-4.8"           # 这个项目复杂，用更强的模型

[project]
# 告诉 Codex 项目约定，等于每次都自动带上的「系统提示」
rules = """
- 使用 TypeScript，禁止 any
- 遵循现有的 ESLint 配置，不要新增依赖
- 测试用 Vitest，新功能必须带测试
- 不要改动 src/legacy/ 目录
"""

[ignore]
# 不让 Codex 读取的路径，保护敏感文件、节省上下文
paths = ["node_modules", "dist", ".env", "secrets/"]

rules 是最有价值的一项——把「项目规矩」写一次，就不用在每轮对话里反复叮嘱了。

提示：.codex/config 建议提交到 Git，让团队共享同一套规则；但 .env、密钥务必写进 [ignore]。

二、MCP：给 Codex 接上外部能力

Codex 默认只能读写本地文件。MCP（Model Context Protocol） 让它能连接外部系统——数据库、文档、API、浏览器等。

它解决什么问题

没有 MCP 时：

你：这个 bug 和数据库里的订单状态有关
Codex：我看不到数据库，你把相关记录贴给我

接入数据库 MCP 后：

你：查一下 order_id=1234 的状态，看看为什么触发了这个 bug
Codex：（直接查询数据库）状态是 pending_refund，
      而代码在这个状态下没有处理分支，问题在 orderHandler.ts:88

配置一个 MCP Server

在配置文件里声明：

# ~/.codex/config 或项目级 config
[[mcp_servers]]
name = "postgres"
command = "npx"
args = ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]

[[mcp_servers]]
name = "filesystem-docs"
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/docs"]

重启 Codex 后，用 /mcp 查看已连接的服务：

/mcp
# postgres        ✓ connected
# filesystem-docs ✓ connected

常见的 MCP Server：数据库（Postgres / SQLite）、文件系统、Git、浏览器自动化、以及各类 SaaS API。按需接入，不用的别开——每个都会占用上下文和启动开销。

三、自动化集成：把 Codex 嵌进流程

交互模式适合人机协作，但真正的效率来自把重复任务交给单次命令模式。

写进 Shell 脚本

#!/bin/bash
# review.sh —— 提交前让 Codex 审一遍改动
git diff --cached | codex run --approval read-only \
  "审查这段 diff，指出潜在 bug、安全问题和风格违规，只报告不修改"

批量任务

# 给一批文件批量加类型注解
for file in src/utils/*.js; do
  codex run --approval auto "给 $file 补充 JSDoc 类型注解，不改逻辑"
done

注意这里用了 auto——因为任务简单、边界清晰、且有 Git 兜底，符合第②篇里说的「可以放开自动化」的条件。

接入 CI

在 CI 里让 Codex 做自动化检查（以 GitHub Actions 为例）：

# .github/workflows/ai-review.yml
- name: AI Code Review
  run: |
    git diff origin/main...HEAD | \
      codex run --approval read-only \
      "总结这个 PR 的改动风险，输出 markdown" >> $GITHUB_STEP_SUMMARY
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

成本提醒：自动化任务会持续消耗 API token。给 CI 场景选 haiku 或 sonnet，并在脚本里限制范围（只审 diff，别扫全库），避免账单失控。

与 n8n 等自动化平台结合

如果你已经在用 n8n（见自动化栏目），可以把 Codex 的单次命令包成一个节点：

定时触发
  → 拉取待处理内容
  → 执行 codex run（生成 / 分类 / 摘要）
  → 结果写回数据库 / 发通知

关键仍是那条老原则：结构化、可验证的任务适合自动化；涉及最终对客承诺、付款、不可回滚操作的，保留人工确认。

系列小结

四篇走下来，你应该已经能：

1. 安装配置 Codex 并选对模型
2. 日常使用：命令、审批模式、工作流
3. 实战：用一套 SOP 完成真实需求
4. 进阶：配置固化偏好、MCP 扩展能力、自动化编排

Codex 的价值不在于「替你写代码」，而在于成为一个你能精确控制、逐步放权、最终可编排的开发伙伴。从手动审批起步，建立信任，再按任务特性决定放开多少——这就是用好它的全部秘诀。

系列文章

• ✅ ① Codex 快速上手：安装、认证与模型选择
• ✅ ② Codex 基础使用：常用命令与日常工作流
• ✅ ③ Codex 实战：在真实项目里完成任务
• ✅ ④ Codex 进阶：配置文件、MCP 与自动化集成（本文）

延伸：Codex vs Claude Code：两款 AI 编程客户端怎么选