多 CLI 联动：Claude / Codex / Gemini 协同工作指南
一句话：本地三家主流 AI CLI（Claude / Codex / Gemini）可以联动，且有多种玩法——从最简单的 Shell 管道，到工程化的 MCP 互调。本文给出全景对比、4 种玩法、1 个真实案例评析，以及选型决策树。
目录
- 0. 为什么要关心多 CLI 联动
- 1. 三家 CLI 能力对比
- 2. 联动的三个层级
- 3. 四种实用玩法
- 4. 经典案例评析：Claude + Codex 双模型协作
- 5. 选型决策指南
- 6. 工程坑清单
- 7. 与本知识库其他章节的关联
0. 为什么要关心多 CLI 联动
0.1 单一 CLI 的天花板
每家 CLI 都有自己的强项和盲区：
| 模型 | 强项 | 盲区 |
|---|---|---|
| Claude | 长任务规划、代码审查、Agent 编排 | 多模态稍弱、搜索弱 |
| Codex | 代码生成、refactor、bug 修复 | 通用对话、长上下文偏弱 |
| Gemini | 多模态（图/视频）、超长上下文 1M+、Google 搜索 | 代码生成相对弱 |
💡 核心洞察：单一模型 = 单一视角 = 单一盲区。多 CLI 联动让你能”取长补短”。
0.2 联动带来的三种价值
| 价值 | 说明 |
|---|---|
| 互补能力 | 让每家干自己最擅长的（角色分工） |
| 交叉验证 | N-version programming 思想：三家都说对，可信度指数级上升 |
| 降本增效 | 简单任务用便宜模型、关键决策用贵模型 |
1. 三家 CLI 能力对比
1.1 联动相关基础能力
| 能力 | Claude | Codex CLI | Gemini CLI |
|---|---|---|---|
| 非交互模式（一次性调用） | ✅ claude -p "xxx" | ✅ codex exec "xxx" | ✅ gemini -p "xxx" |
| 读 stdin | ✅ | ✅ | ✅ |
| 输出 JSON | ✅ --output-format json | ✅ --json | ✅ |
| 工具调用（MCP） | ✅ 原生 | ✅ 支持 | ✅ 支持 |
| 自定义 System Prompt | ✅ | ✅ | ✅ |
🎯 关键事实：三家都有”非交互模式 + MCP 协议”，这是联动的两大基石。
1.2 强项分工（业界共识）
┌──────────────────────────────────┐
│ 📋 长任务规划 / Agent 编排 │ → Claude
├──────────────────────────────────┤
│ 💻 代码生成 / refactor │ → Codex
├──────────────────────────────────┤
│ 🖼️ 多模态 / 超长上下文 / 搜索 │ → Gemini
└──────────────────────────────────┘
2. 联动的三个层级
| 层级 | 你说的”联动”是什么 | 难度 | 工程量 |
|---|---|---|---|
| L1：人工接力 | 在 A 里问，复制答案到 B 继续 | 0 | 不算联动 |
| L2：脚本编排 | 用 Shell / Python 让 A 的输出自动喂给 B | ⭐⭐ | 几十行脚本 |
| L3：Agent 互调 | A 运行中把 B 当工具调用、实时协作 | ⭐⭐⭐⭐ | 写 MCP Server |
三家 CLI 都支持 L2（基于 stdin/stdout 管道）。L3 也可以，但需要工程接线。
3. 四种实用玩法
3.1 玩法 A：Shell 管道接力（L2，最简单）
思路：把 A 的输出当 B 的输入，像 Unix 管道一样串起来。
典型场景：用 Gemini 做”网页抓取+总结”（搜索强），喂给 Claude 做”代码实现”。
#!/bin/bash
# research-and-code.sh
TOPIC="$1"
# Step 1: Gemini 研究主题
RESEARCH=$(gemini -p "研究这个主题并给出要点：$TOPIC")
# Step 2: Claude 基于研究写代码
echo "$RESEARCH" | claude -p "根据以上调研，写一个 Python 实现"| ✅ 优点 | ❌ 缺点 |
|---|---|
| 简单、可调试 | 单向流水线 |
| 每个 CLI 干自己最擅长的 | 不能来回交流 |
| 出错容易定位 | 只能一次性任务 |
3.2 玩法 B：MCP 互相当”工具”（L3，进阶）
思路：把 Codex / Gemini 注册成 Claude 的 MCP 工具，让 Claude 自己判断什么时候调用。
配置示例（最简版，用 codex 自带的 mcp-server 模式）：
# 把 codex 注册为 Claude 的 MCP server
claude mcp add codex -s project -- codex mcp-server自定义 MCP Server 示意（让 Gemini 也能被 Claude 调用，伪代码）：
# gemini-mcp-server（伪代码，实际需用官方 SDK）
注册工具：
name: ask_gemini
description: "Ask Gemini (better at search & long context)"
input: { question: string }
工具实现：
接收问题 → 用安全的子进程调用方式启动 gemini CLI
（生产环境务必用 execFile 而不是 exec，
避免 shell 注入；输入严格白名单校验）
捕获 stdout → 作为工具返回⚠️ 安全提醒：写 MCP Server 调外部 CLI 时，绝不要用 shell 字符串拼接调用命令，必须用
execFile/ 参数数组形式。否则会有命令注入漏洞——这是 AI 工具滥用最常见的攻击面。
效果：Claude 在做任务时，遇到”需要实时搜索”自动调 Gemini，遇到”代码 review”自动调 Codex。
| ✅ 优点 | ❌ 缺点 |
|---|---|
| 真正的 Agent 协作 | 工程量大 |
| 动态决策不固定 | 要写 MCP Server |
| 最接近”双脑协同” | 调试复杂 |
3.3 玩法 C：三方投票 / 对比（L2，强力）
思路：同一个问题问三家，交叉验证结果。
#!/bin/bash
# three-way-compare.sh
QUESTION="$1"
{
echo "=== Claude ==="
claude -p "$QUESTION" &
echo "=== Codex ==="
codex exec "$QUESTION" &
echo "=== Gemini ==="
gemini -p "$QUESTION" &
wait
} > answers.md
# 让 Claude 当裁判汇总
claude -p "请对比并总结以下三份答案的差异：$(cat answers.md)"注：这里用
&让三家并行调用（async思想），不要串行——速度差 3 倍。
适用场景：
- 重要决策前”三方会审”
- 不确定哪个模型更准时做 cross-check
- 评测不同模型在你的场景里的表现
💎 真实收益：不同模型的错误模式不一样——三个都答对，可信度指数级上升。这是 Eval 测评体系 中”模型对比”的低成本实现。
3.4 玩法 D：角色分工流水线（L2，最常用）
思路：按每家强项做固定分工。
#!/bin/bash
# role-division.sh
TASK="$1"
# Gemini：长上下文 + 搜索 → 做 Research
RESEARCH=$(gemini -p "研究：$TASK")
# Codex：OpenAI 系，代码生成强 → 写代码
CODE=$(echo "$RESEARCH" | codex exec "基于调研，写代码实现")
# Claude：推理 + 审查强 → Review
echo "$CODE" | claude -p "Review 这段代码，指出潜在问题和优化建议"| ✅ 优点 | ❌ 缺点 |
|---|---|
| 实用、工程量适中 | 流程固定，不灵活 |
| 各取所长 | 简单任务也走全流程 → 慢 |
4. 经典案例评析：Claude + Codex 双模型协作
4.1 原方案完整解读
社区流行一种用法——在项目 CLAUDE.md 中加入指令，让 Claude 强制每次任务都和 Codex 协作。
核心机制图：
┌─────────────────────────────────────────────┐
│ Claude (主控 / 有 CLAUDE.md 指令) │
│ │
│ 收到用户需求 │
│ ↓ │
│ ① 初步分析 → 调 codex 完善需求 │
│ ↓ │
│ ② 编码前 → 调 codex 索要"参考原型" │
│ ↓ │
│ ③ Claude 自己重写代码（不抄 codex） │
│ ↓ │
│ ④ 编完 → 调 codex review │
│ ↓ │
│ ⑤ 不一致 → 来回争辩，直到达成共识 │
└─────────────────────────────────────────────┘
↑↓ MCP
┌─────────────────────────────────────────────┐
│ Codex CLI (作为 MCP Server) │
│ 只输出 unified diff patch（不直接改文件） │
└─────────────────────────────────────────────┘
MCP 注册命令：
claude mcp add codex -s user -- codex -m gpt-5.1-codex \
-c model_reasoning_effort="xhigh" mcp-server📖 完整指令文本来自 2026-05-04 与用户交流，可在 2026-05-04_Agent知识体系闭环.md 找到原文。
4.2 亮点 ✅
① 强制”双模型对账”
N-version programming 思想用在 AI 上很有创意。两家都觉得对的概率 ≈ 真的对。
② 让 Codex 只输出 patch，不改文件
这是最聪明的一招：
- 保留 Claude 的”执行权 + 责任主体”
- 防止两家”抢方向盘”
- 让 codex 成为真正的顾问而不是第二个司机
这就是 unified diff patch 在 AI 协作里的教科书级用法。
③ 强制”批判性吸收”
原指令第 4 条：“尽信书则不如无书……必须不断争辩”——直击 LLM 最大的毛病：讨好用户、附和别人。
④ 职责分工明确
- 需求分析：Claude（规划强）+ Codex 完善
- 代码原型：Codex（OpenAI 代码训练量大）
- 代码生产：Claude 重写（自己审过的才能写）
- Review：Codex（独立第三方眼光）
⑤ MCP 协议本来就是设计来干这个的
不是 hack，是 MCP 的”教科书级正用”。
4.3 坑（7 条）⚠️
坑 1：模型号不存在 / 拼写不一致
原方案一会写 gpt-5.2-codex 一会写 gpt-5.1-codex，自相矛盾。
且 gpt-5.x-codex 在 2026-05 时点 OpenAI 并不存在这个 SKU。
修法：先 codex --list-models 看实际可用模型。
坑 2：xhigh 不是标准选项
Codex 标准 reasoning effort 是 low / medium / high。xhigh 在某些社区配置里能用，官方不一定支持。
修法：用文档支持的值，参数被忽略时回落到默认。
坑 3：强制流程过死
“务必执行” 1~3 条 → 每次任务都要：
- 调 codex 完善需求（多 1 次 API）
- 调 codex 出原型（多 1 次）
- 编完调 codex review（多 1 次）
单次任务成本：
原版：1 次 Claude 调用
双模型版：1 次 Claude + 3 次 Codex (+反复争辩)
≈ 总成本 5~10 倍、总延迟 3~5 倍
后果：
- “改个变量名”也走全流程 → 浪费
- 探索性任务一上来就 review → 卡死创造力
修法：加触发条件——复杂任务才走全流程。
坑 4：「来回争辩直到一致」容易死循环
没有”裁判”机制、没有”放弃 / 升级到人”的退出路径。
修法：加”最多 N 轮，仍不一致则升级给用户决策”。
坑 5：项目特定指令未隔离
原方案第 8 条提到 reverse_meta/ 目录——这是他自己项目的特殊路径。你照抄会让 Claude 找不存在的目录。
修法：剥离项目特定项，做成项目级 CLAUDE.md 而不是用户级。
坑 6：没有失败兜底
如果 codex 服务挂了 / API 限流 → 整个流水线停。
修法：加 try-catch 跳过失败步骤。
坑 7：MCP 作用域是 user 级别
claude mcp add codex -s user ... ← 所有项目都启用但指令只在某个 CLAUDE.md 里。其它项目的 codex MCP 也会被加载，浪费上下文。
修法：用 -s project（项目级）。
4.4 综合评分
| 维度 | 分数 | 理由 |
|---|---|---|
| 思路创新性 | 9/10 | ”双模型对账 + 强制争辩”是真东西 |
| 技术正确性 | 6/10 | MCP 用法对，模型号 / xhigh 有误 |
| 工程严谨性 | 5/10 | 缺退出条件、缺触发条件、缺兜底 |
| 文档清晰度 | 6/10 | 项目特定指令未说明 |
| 成本意识 | 4/10 | 强制每次走全流程，太贵 |
| 实战可用性 | 6/10 | 思路对，需打磨 |
| 综合 | 7/10 | 思路 9 分、执行 5 分 |
💡 结论：这是一个**“原型阶段”的好想法，不是成品**。直接照抄会踩坑。
4.5 改进版配置
## Codex 协作策略（仅在复杂任务时启用）
### 触发条件（满足任一）
- 用户明确说"用 codex review"
- 任务涉及 200 行以上代码改动
- 任务涉及架构决策、安全敏感代码
- 用户明确说"重要 / 关键 / 生产环境"
### 简单任务（默认）
- 直接由 Claude 完成，不调 codex
- 节省成本和延迟
### 复杂任务流程
1. 初步分析后 → 调 codex 完善需求（1 次）
2. Claude 写代码
3. 完成后 → 调 codex review（1 次，输出 patch 建议）
4. Claude 决定是否采纳
### 争辩规则
- 最多 2 轮争辩
- 仍不一致 → 把双方观点呈现给用户决策
- 不要陷入死循环
### 模型配置
- codex 模型：先用 `codex --list-models` 确认
- 推理强度：用文档支持的值（low/medium/high）
### 兜底
- codex 调用失败 → 跳过该步骤，继续主流程
- codex 返回明显错误 → 记录但不阻塞
### MCP 作用域
- 用 `-s project`，不要 `-s user`5. 选型决策指南
你的需求是 →
├─ 只是好奇技术可行性
│ └─ 不用任何联动，分别用即可（切换成本 < 搭建成本）
│
├─ 想做"三方对比 / 重要决策会审"
│ └─ 玩法 C（投票），50 行 bash 立刻有价值
│
├─ 想"让 Claude 当主控、按需调其它"
│ └─ 玩法 B（MCP 互调），最接近真 Agent 协作
│
├─ 想"固定流水线分工"
│ └─ 玩法 D（角色分工），实用、工程量适中
│
└─ 一次性任务（调研 + 编码）
└─ 玩法 A（Shell 管道），写完就跑
6. 工程坑清单
真要联动时会遇到的坑（建议提前知道）：
| 坑 | 说明 | 缓解 |
|---|---|---|
| API Key 管理 | 三家 key 都要配 | 用 .envrc + direnv 隔离 |
| Rate Limit | 并行调用容易被限流 | 加 retry + 指数退避 |
| 输出格式不统一 | 三家 JSON schema 不同 | 写 parser 适配层 |
| 成本暴涨 | 三家同时跑 = 三倍成本 | 仅重要任务用三方 |
| 延迟累加 | 串行调用延迟翻倍 | 能并行就用 async |
| 安全风险 | 模型互调可能滥用工具 | 限工具权限、用 execFile 而非 exec、禁危险命令 |
| 调试困难 | 多方协作错误难定位 | 全程记录每次调用的输入输出 |
| 版本漂移 | CLI 升级可能改命令格式 | 锁定版本，重要场景用 docker |
7. 与本知识库其他章节的关联
| 关联点 | 文档 | 关系 |
|---|---|---|
| 程序员术语速查 | 程序员黑话速查 | 本文用到的 MCP / patch / async 等术语都在那里有解释 |
| Harness 工程 | Harness工程与Agent解剖 | 多 CLI 联动是 Harness 在”多模型”维度的扩展 |
| Agent 发展轨迹 | Agent发展轨迹四阶段 | 多 Agent 协作是第四阶段 Harness Engineering 的高级形态 |
| Eval 体系 | Eval测评体系 | 玩法 C（三方投票）是 Eval 的低成本实现 |
| Shell 基础 | Shell与终端基础知识总结 | 管道、stdin/stdout 是联动基础 |
| Skill 工程 | SKILL.md | 未来可写 Skill 自动选择 CLI |
| 各家模型特点 | 各家LLM模型特点速查 | 选 CLI 之前先认识各家模型(Claude/GPT/Gemini)的核心定位 |
| API 选型方法论 | LLM-API选型方法论 | 三方协同的成本估算与提供商选择 |
附：来源与时间线
- 2026-05-04：用户分享一段流行的 “Claude + Codex 协作” CLAUDE.md 配置
- 2026-05-05：本文落地，整合三家 CLI 盘点 + 4 种玩法 + 案例评析
创建时间: 2026-05-05