两个死对头的模型第一次在同一个工作流里并肩工作，Agent生态正在走向“跨厂商编排”。

今天看到一个有意思的变化：OpenAI官方发布了一个插件codex-plugin-cc，可以直接在Claude Code中调用Codex。

不是“兼容”，也不是“第三方适配”，而是官方下场，把自家能力塞进对手生态。

简单说：你现在可以在Claude Code里调用Codex做代码审查、对抗性审查，甚至直接把任务交给Codex接管。一个工作流里，可以同时调度两个不同厂商的智能体。

01 为什么说这是一次“反常识”的动作

过去AI工具链的思路是：要么All in一个平台，要么自己做一套Agent编排。

但这次不一样。OpenAI的动作，本质是在做一件事：把“模型能力”降级成“可调用工具” 。Codex不再是一个独立入口，而是变成Claude Code里的一个“函数调用能力”。

这背后其实是一个很明确的趋势：Agent生态正在走向 “跨厂商编排” 。

以前是：模型 = 产品。现在开始变成：模型 = 能力节点。

OpenAI的这一步，标志着AI开发从单模型走向多智能体协作新范式。

02 插件能力拆解：三个命令背后的工程价值

这个插件最核心的不是“能调用Codex”，而是调用方式设计得很工程化。

/codex:review —— 标准代码审查

适合PR Review、重构后回归检查、规范校验。本质上就是引入第二个模型做“独立判断”，避免单模型偏见，提高代码质量下限。

/codex:adversarial-review —— 对抗性审查

这是最有价值的一个能力。它不是简单Review，而是主动挑战你的实现假设。典型适用场景：权限系统改动、鉴权逻辑、基础设施脚本、数据迁移。

它会去问类似问题：有没有边界条件没覆盖？有没有隐式信任？有没有绕过路径？这已经接近安全测试思维了。

/codex:rescue —— 任务接管

这个设计很有意思：当Claude Code卡住时，可以把当前上下文直接交给Codex接管。适合长任务中断、推理路径错误、复杂任务重启。

本质上是多智能体的failover（容灾切换）。

此外还有配套的后台任务管理命令/codex:status和/codex:result，说明它是按“任务系统”设计的，而不是一次性调用。

03 两个模型，各有所长

为什么需要两个模型一起上？因为它们的特长刚好互补。

有开发者实测发现：Codex想得深，但慢。xhigh模式跑一个review要三到五分钟。而Claude Code干得快，但容易顺着你的思路一路写下去——包括错的方向。

实测对比也更清晰：

• 在SWE-bench Pro基准测试中，GPT-5.3-Codex得分56.8%，Claude Opus 4.6得分55.4%
• 在Terminal-Bench 2.0中，GPT-5.3-Codex得分77.3%，Claude Opus 4.6得分65.4%
• 但Claude Opus 4.6在SWE-bench Verified上达到了80.8%
• 在执行相同任务时，Claude Code消耗的token是Codex的3.2-4.2倍

结论：两者各有胜负。最好的方案不是二选一，而是让它们各司其职：

• 设计阶段：棘手问题丢给Codex xhigh，让它慢下来想，输出spec或proposal，把问题拆干净
• 实现阶段：切回Claude Code，拿着spec用Opus写，1M上下文窗口兜底
• Review阶段：交回Codex，用/codex:adversarial-review慢慢审，挑出Claude顺着思路时忽略的东西

04 真实工作流会怎么用

把这个插件放进日常开发，流程会变成：

1. 在Claude Code里写代码、搭架构
2. 提交前，后台跑/codex:review，让Codex过一遍
3. 关键逻辑改动，上/codex:adversarial-review，专门“挑刺”
4. Claude Code卡住了，/codex:rescue让Codex接管

这个流程的核心变化是：“单Agent开发” → “多Agent协作开发” ，而且是异构模型协作。

有开发者提供了一个实用技巧：在Claude Code里打开review gate，任务结束前强制等Codex审查完才放行——当然，这会烧更多token。

05 技术实现：接协议，不是接模型

从技术实现来看，这个插件的接入方式比较克制：

• 依赖本地Codex CLI，不直接嵌模型
• 通过App Server中转，统一请求入口
• 复用MCP（Model Context Protocol）能力，统一上下文传递和工具调用方式
• 不新增运行时，不起新进程体系，不重复认证

这点很关键：插件不是“接模型”，而是“接协议” 。复用现有工程体系，降低接入成本——OpenAI这套思路，其实是把“模型”降维成了可编排的工具节点。

06 对开发者意味着什么

这件事对普通开发者的实质影响，至少有这几个：

• Review会变成“多模型共识” 。过去一个模型给建议，现在两个模型交叉验证。长期来看代码质量会更稳定，但成本会上升。

• Agent不再是“单点能力” 。你可以根据任务类型选择不同的模型：设计用Codex，实现用Claude，审查两者一起上。Anthropic更擅长发散性思考和创新，OpenAI的模型则以稳定、精确著称。

• 成本结构变了。多模型协作意味着token消耗成倍增加，这是开发者需要权衡的新变量。

07 一些容易被忽略的坑

安装前注意两个前提：本地Node.js版本需要在18.18及以上；Claude Code版本需要1.0.33或更高，/plugin相关能力从该版本开始支持。

此外，多文件改动的review往往比较慢，建议用--background放后台跑，而不是前台硬等。

还有一点：Codex xhigh模式跑一个review可能长达3-5分钟，如果你的迭代频率很高，这会是工作流中的一个瓶颈。

写在最后

OpenAI把Codex接进Claude Code，本质上是在做一件事：承认未来是“多智能体协作”的。

它不是让你放弃Claude Code，而是让你在Claude Code里顺手把Codex拉进来。这背后是一条很清晰的逻辑线：当你的核心资产不再是单一模型，而是跨模型的智能体编排能力时，“送一个插件给竞品”就不再是让利，而是构建新的行业标准。

当然，这也意味着你需要重新思考：自己的开发工作流，要不要从“选一个工具”变成“配一个团队”？

👇 如果你已经在用Claude Code，不妨装上这个插件试试。欢迎在评论区聊聊：你打算怎么用Codex和Claude Code配合？

附录：快速安装指南

# 1. 添加插件市场
/plugin marketplace add openai/codex-plugin-cc

# 2. 安装插件
/plugin install codex@openai-codex

# 3. 重新加载插件
/reload-plugins

# 4. 初始化配置
/codex:setup

安装完成后，你会在命令列表里看到一组/codex:前缀的命令。需要先确保本地已安装Codex CLI：

npm install -g @openai/codex
!codex login

然后就可以开始使用了：

# 提交前跑一遍review（后台运行）
/codex:review --background

# 查看进度
/codex:status

# 获取结果
/codex:result