一个被忽略的能力#

大多数开发者用 Codex CLI 的方式很直接：打开终端，输入任务，等它写完代码，结束。这种「一次性对话」的用法确实能解决很多问题，但它有一个明显的局限，每个任务都是孤立的，没有状态延续，没有和其他智能体协作的可能。

不过，Codex CLI 还藏着一个不太为人所知的身份，它能作为 MCP Server 运行。这意味着你可以把 Codex 当作一个「可编程的代码执行引擎」，让其他 AI 智能体通过标准协议调用它。配合 OpenAI Agents SDK，一个完整的多智能体协作系统就搭起来了。

这个能力听起来有点抽象，但实际应用场景非常具体。

什么是 MCP Server 模式#

MCP（Model Context Protocol）是一个开放协议，让 AI 智能体之间可以互相调用工具。当你运行 codex mcp-server 时，Codex CLI 会暴露两个核心工具：

codex()：创建一个新的 Codex 会话，传入任务描述、审批策略、沙箱模式、模型选择和工作目录。

codex-reply()：基于之前的会话 ID 继续对话，实现多轮交互。

这两个工具让 Codex 从一个「用完即走」的命令行工具，变成了一个有状态、可控制、可追踪的子进程。编排智能体（Orchestrator）可以把 Codex 当作团队里的一名开发者来调度。

单智能体模式：受控执行#

最简单的用法是让一个智能体通过 MCP 调用 Codex。你给智能体一段系统提示词，告诉它如何使用 Codex 工具，然后它就能自动完成任务。

这里有两个关键参数值得注意。approval-policy: never 表示不需要人工审批，适合自动化流水线场景。sandbox: workspace-write 限制智能体只能在工作目录内写文件，不会动到系统其他部分。

对于只读任务，比如代码审查或文档提取，可以用 sandbox: read-only 进一步收紧权限。

这种模式适合 CI/CD 流水线里的自动化代码生成、测试脚本编写等场景。不需要人盯着，智能体自己完成任务后返回结果。

多智能体编排：门控交接模式#

单个智能体能做的事有限，真正的威力在于多个智能体协作。OpenAI Cookbook 里展示了一个五智能体团队的案例，核心设计思想叫「门控交接」（Gated Hand-Off）。

这个团队由五个角色组成：

  • 项目经理（PM）：总协调人，负责任务分配和质量把关
  • 设计师：产出设计规范和线框图
  • 前端开发：实现界面
  • 后端开发：实现服务端逻辑
  • 测试员：验证最终产物

关键设计在于，PM 不会盲目地把任务往下传。每次交接后，PM 都会检查上游智能体是否真的产出了约定的交付物。比如设计师完成任务后，PM 会验证 /design/design_spec.md 这个文件是否存在，只有确认后才会把任务交给前端和后端。

这种「先验证再推进」的机制避免了一个常见问题：某个智能体以为自己完成了任务，但实际上产出不完整或格式不对，导致下游智能体拿到错误的输入。

前端和后端可以并行执行，进一步节省时间。两者都完成后，PM 再把所有产物交给测试员做最终验证。

会话延续：codex-reply 的价值#

有些任务不是一轮对话能搞定的。比如智能体生成了一段代码，发现构建失败，需要根据错误信息修改。这时候 codex-reply() 就派上用场了。

通过传入之前返回的 threadId，智能体可以在同一个会话上下文中继续对话。Codex MCP Server 会保持完整的对话历史，包括文件状态，这样后续的修改请求不需要重新描述整个上下文。

这个机制在调试场景下特别有用。智能体可以反复迭代：写代码、运行测试、看报错、修改、再测试，直到通过为止。

追踪和可观测性#

多智能体系统的一个痛点是调试困难。当五个智能体交替执行了几十轮操作后，出了问题很难追溯到底哪个环节出了错。

Agents SDK 自带的追踪功能解决了这个问题。每次 MCP 调用、每次智能体交接、每次工具执行，都会被自动记录到 OpenAI 的 Traces 面板里。你能看到：

  • 每个智能体的提示词和响应内容
  • MCP 调用的参数和耗时
  • 完整的交接链路，清楚地展示谁把控制权交给了谁
  • 沙箱内执行的 shell 命令

这对排查问题和审计行为都非常有价值。

模型选择和成本控制#

在多智能体工作流里，不是每个角色都需要最强的模型。合理的模型分配能显著降低成本：

  • 编排智能体（PM）：需要强推理能力来判断交接条件，适合用高能力模型
  • 专项开发智能体：任务范围明确，用更便宜、更快的模型就够了
  • 代码理解任务：需要深度代码分析能力的场景，可以用专门的代码模型

一个五智能体、三十轮交互的工作流会消耗不少 token。建议通过 Traces 面板监控成本，并考虑把中间结果缓存到文件里，避免跨智能体重复生成。

实际注意事项#

工作区隔离：所有智能体共享同一个 Codex MCP Server 进程，写入的是同一个文件系统。如果不同智能体需要在不同目录工作，要在调用时指定各自的工作目录。

错误处理：如果某个 Codex 会话失败了（沙箱违规、模型错误、超时），MCP Server 会返回错误响应。编排智能体需要被设计成能优雅处理失败，比如调整参数重试、跳过失败任务、或升级给人工处理。

进程限制：当前版本里，所有智能体共享一个 MCP Server 进程，真正的并行执行可能需要启动多个实例。另外，长时间运行的进程会在内存中积累会话状态，生产环境需要考虑定期重启。

流式输出：目前 Agents SDK 从 Codex MCP 接收的是完整响应，不是流式 token。对于需要实时反馈的场景，这可能是一个限制。

适用场景对比#

不同场景下，Codex 的三种接入方式各有优势：

  • codex exec（命令行单次执行）：适合一次性任务，比如 CI 脚本、定时任务、简单的代码生成
  • codex mcp-server（MCP 模式）：适合多智能体工作流，需要任务编排、状态管理和全链路追踪
  • Python SDK：适合需要精细控制线程和会话的编程场景

MCP Server 模式处在一个巧妙的位置，比命令行模式更可控，比 Python SDK 更易组合，还自带可观测性。

写在最后#

把 Codex 当作 MCP Server 来用，本质上是把一个「对话式编程助手」升级成了「团队里的可调度开发者」。这个转变带来的不只是技术上的灵活性，更是思维方式的转变，从「我让 AI 帮我写代码」到「我编排一个 AI 团队来完成项目」。

当然，多智能体系统也有它的复杂性。你需要设计合理的交接机制、处理好错误恢复、控制好成本。但如果你的工作流确实需要多个步骤、多个角色的协作，这套方案值得一试。

随着 Codex CLI 和 Agents SDK 的持续演进，这种多智能体协作模式会变得越来越成熟。现在开始探索，就是最好的时机。

参考来源：Codex CLI as an MCP Server: Building Multi-Agent Workflows with the OpenAI Agents SDK，Daniel Vaughan