扩展能力：MCP 接系统，技能沉淀流程

8.1 什么时候才需要往外接

先说什么时候不需要。如果你的信息在仓库里，Codex 已经能读；如果是一次性的数据，粘贴给它就行。往外接的成本（配置、认证、维护、安全审查）只有在下面这类情况才划算：

• 信息在仓库外且经常变：线上错误日志、监控指标、issue 列表、数据库 schema
• 你需要它执行仓库外的动作：查一个内部服务、触发一次部署、写一条工单
• 同一类信息你每周都要手动粘贴好几次

判断标准是重复度：偶尔用一次，手动粘贴更省事；每周都要，就该接进来。

8.2 两种服务器形态

Codex 通过 MCP（Model Context Protocol）连接外部工具。一个 MCP 服务器对外暴露一组工具函数，接上之后 Codex 的能力就扩展到这些工具覆盖的范围。

服务器分两种形态：

添加方式有两种：用 codex mcp 子命令，或直接编辑配置文件。命令形态大致是这样（具体参数以 codex mcp --help 为准，这部分接口仍在演进）：

# 添加一个本地 STDIO 服务器：名字在前，启动命令在 -- 之后
codex mcp add <name> -- <command> <args...>

# 添加一个远程 HTTP 服务器：用 --url 指向地址
codex mcp add <name> --url https://example.com/mcp

配置文件里对应的是 [mcp_servers.<id>] 表，可以设置启动命令、参数、工作目录、启用开关、超时时间等。MCP 配置在 CLI、IDE 扩展和桌面应用之间是共享的——配一次，三个入口都能用。

需要注意的是作用域：项目级的 .codex/config.toml 只会对你标记为受信任的项目加载。这是一道刻意的防线，防止你 clone 一个陌生仓库就自动加载了它自带的 MCP 配置。

8.3 接入前必须问的三个问题

每接一个 MCP 服务器，都在扩大攻击面。接之前问清楚：

第一，这个服务器能看到什么？ 一个能读你数据库的服务器，意味着数据库内容可能进入模型上下文。生产库的真实用户数据要不要进去，这是个需要明确回答的问题，不是默认选项。

第二，这个服务器能做什么？ 只读查询和”能触发部署”是两个量级的风险。优先选只读能力，写能力单独评估。

第三，工具描述是可信的吗？ MCP 服务器的工具描述文本会进入模型上下文。一个恶意或被攻陷的服务器可以在工具描述里塞入指令，试图影响 Codex 的行为。只接你自己写的、或者你信任的组织维护的服务器，第三方服务器要看代码。

8.4 重复的提示词应该变成技能

MCP 解决的是”连到外部系统”，技能（skill）解决的是”复用一套流程”。

技能本质上是一份写好的流程说明，Codex 在遇到匹配场景时把它加载进来。判断某件事该不该变成技能，标准和第6章一致：你是不是在反复使用同一段提示词，或者反复纠正同一个流程？

典型候选：

• 发版流程：改版本号 → 生成 changelog → 打 tag → 更新文档
• 新增数据库迁移：写迁移文件 → 更新模型 → 补测试 → 检查回滚脚本
• 事故复盘：拉日志 → 定位时间线 → 写复盘文档骨架

这三个的共同点是：步骤固定、顺序重要、每次都容易漏一步。这正是流程沉淀的价值所在。Codex 也支持插件机制，可以把技能、MCP 配置打包分发给团队。

三种固化手段的分工可以这样记：

8.5 动手：把一个重复流程写成编号清单