在掌握了 AGENTS.md（项目规则）与 config.toml（运行配置）之后，我们需要引入更强大的扩展机制：MCP (Model Context Protocol)。它的核心价值在于打破 AI 的封闭环境，实现与外部工具及海量实时资料的深度连接。

> 前置要求：请确保您已熟悉 配置作用域与优先级。MCP 服务通常通过 config.toml 进行挂载，清晰的配置分层将极大降低排障难度。

核心定义：什么是 MCP？

MCP 是 Codex 连接外部数字世界的标准协议。

在原生状态下，Codex 的视野受限于：

  1. 当前项目的文件内容。

    2. 2. 开发者在对话框中粘贴的文本。

    3. 通过本地命令执行获取的临时结果。

    引入 MCP 后，Codex 可以获得您显式授权的外部能力，包括但不限于：

    • 实时技术文档：如 OpenAI, React 或各类开源项目的最新官方文档。
    • 私有知识库：企业内部的 Confluence, Notion 或 Wiki 页面。
    • 协作工具链：GitHub (PR/Issue)、Linear、Jira 等任务管理系统。
    • 设计与交互：Figma 标注、浏览器实时快照及控制台日志。
    • 内部数据服务：通过受控接口访问数据库或内部 API。

    实战场景：从“手动搬运”到“自动检索”

    传统模式：

    当您要求 AI “根据公司最新的接口标准重构代码”时，您需要手动打开文档系统、复制关键字段定义、反复核对是否遗漏，最后粘贴到对话框。

    MCP 协作模式：

    您可以直接下达指令：“请通过公司文档 MCP 检索『订单创建接口』的最新 v2.0 规范，并对比当前项目的实现差异，给出重构建议。”

    此时，Codex 会自动调用 MCP Server 获取精准数据，整个过程无需人工干预，且能确保数据始终处于最新状态。

    协作边界与职责分工

    理解 MCP 与现有工具的关系，有助于构建更清晰的开发流：

    | 工具维度 | 核心职责 | 协作示例 |

    | :--- | :--- | :--- |

    | AGENTS.md | 定义项目“怎么做” | “修改接口前必须先核对 MCP 文档库中的最新规范。” |

    | MCP | 提供外部“工具/资料” | 提供查询接口文档的实时 Server 接口。 |

    | config.toml | 充当“连接插座” | 在配置文件中挂载并管理 MCP Server 的连接参数。 |

    | Skills | 定义“任务流程” | 规定“修 Bug 时先调 GitHub MCP 查 Issue，再分析代码”。 |

    核心架构术语简析

    • MCP Client：即 Codex 内部负责协议通信的客户端模块。
    • MCP Server：外部工具提供的服务端口，负责向 Codex 暴露能力。
    • Tool (工具)：Server 提供的可执行能力（如“创建 Issue”、“执行 SQL”）。
    • Resource (资源)：Server 提供的可读取资料（如“读取文档”、“查看代码快照”）。

    引入 MCP 的决策原则

    什么时候需要引入 MCP？

    • 需要实时访问频繁变动的外部文档或数据。
    • 需要频繁查询 GitHub/Jira 等系统中的任务上下文。
    • 希望 AI 具备受控的外部系统操作能力（如自动化提 PR）。

    什么时候不建议使用 MCP？

    • 临时性约束：直接在对话提示词中说明即可。
    • 项目内部规则：应优先沉淀到 AGENTS.md。
    • 个人配置偏好：应留在 config.toml。
    • 简单修改任务：过度配置 MCP 会增加系统的权限复杂度和推理成本。

    安全与风险管控 (CRITICAL)

    MCP 赋予了 AI 访问外部系统的能力，因此必须遵循严格的安全原则：

    1. 只读优先：新手建议从只读文档类 MCP 开始，避免授予写权限。

      2. 2. 权限最小化：严禁为 AI 提供生产数据库的完全写入权限或线上发布权限。

      3. 人工审计：对于涉及外部系统修改的 Tool 调用，必须配置为“需开发者显式审批”。

      4. 敏感数据隔离：确保 MCP Server 不会无意间泄露客户隐私或加密日志。

      ---

      下一篇推荐：MCP 适用场景与决策清单 —— 学习如何科学地评估您的项目是否真正需要 MCP 扩展。