把 Codex 变成可编程的执行引擎：用 MCP Server 搭建多智能体工作流

Sun, 07 Jun 2026 09:00:00 +0800

一个被忽略的能力

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

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

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

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 会验证 /design/design_spec.md 这个文件是否存在，只有确认后才会把任务交给前端和后端。