返回博客列表

Claude Code / Codex / OpenCode / Gemini CLI 共存方案

2026年3月19日 | Ruichen Zhou | 约 6 分钟阅读
AI CLI Claude Code Codex 开发工具

这篇文章记录一套四个 AI CLI 工具的共存方案，重点是配置隔离、模型入口统一、历史记录可见性，以及各工具的职责边界。

环境信息如下：

  • Claude Code：主力交互式开发，负责改代码、写博客和项目级任务。
  • Codex CLI：负责批量任务、脚本化执行，以及 codex exec 这类非交互工作流。
  • OpenCode + oh-my-opencode：负责多 agent 协作和复杂排障。
  • Gemini CLI：保留用于兼容测试，不再承担高权限主任务。
  • CC-Switch：不属于这四个 CLI，但负责统一查看历史和切换模型。
  • 本地 metapi 代理：负责收口模型入口，减少多套 provider、模型名和认证方式的漂移。

第一个问题：它们互相不知道对方的存在

多工具并存时，首要问题不是模型能力，而是上下文、配置和历史记录互不共享。

每个工具都有自己的配置体系、认证方式和历史记录。Codex 看 ~/.codex/config.toml，OpenCode 有自己的配置目录和本地数据库，Claude Code 和 Gemini CLI 也各记各的。CC-Switch 试图把这些东西统一起来，但统一的是一层视图，不是底层事实。

这个问题在 OpenCode 上最明显。CC-Switch 能看到 Claude Code、Codex 和 Gemini CLI 的聊天记录，但就是找不到 OpenCode 的本地历史。更别扭的是，OpenCode 的历史其实明明就在本地，数据库文件就在 ~/.local/share/opencode/opencode.db。也就是说，问题不是没有记录，而是统一层还没有把这套格式真正接上。

踩过的坑

一次实际故障中，我在 CC-Switch 里给 Codex 调模型设置，这套设置没有同步到 OpenCode。继续排查时，Codex 还把 oh-my-opencode 的多 agent 配置清空了，最终只能从备份恢复。这个问题说明，跨工具修改配置前，必须先确认配置边界，不能默认一个 agent 理解另一个 agent 的配置目录和约定。

另一个典型问题是模型名校验。OpenCode 启动时有一次直接报：

Agent Sisyphus (Ultraworker)'s configured model vps/kimi-k2.5 is not valid

这类问题表面上像是一个字符串写错了，实际上往往是三层命名没对齐：UI 里显示的模型名、代理里的路由名、agent 配置里引用的 provider/model 标识，可能根本不是一回事。

CC-Switch 和 Codex 之间也有类似问题。我在 CC-Switch 里给 Codex 加了 GPT-5.4，但 Codex CLI 里看不到。后来确认，至少在我这套环境里，CC-Switch 不是 Codex 的 single source of truth。真正生效的，还是 ~/.codex/config.toml 里那份配置。

这些问题指向同一个结论：多工具并存时，最容易坏掉的不是模型能力，而是配置同步。

我最后怎么分工的

后来我不再问“哪个最强”，而是直接给每个工具划边界：

  • Claude Code：主力交互式开发，改代码、写博客、做项目级任务。
  • Codex CLI：批量任务、脚本化执行、codex exec 这种非交互工作流。
  • OpenCode + oh-my-opencode：多 agent 协作，只在复杂排障时打开。
  • Gemini CLI：保留，但降级，不再承担高权限主任务。
  • CC-Switch：查历史、切模型、做入口层管理，但不再假定它是所有配置的唯一真相。

这样分工之后，排查路径、权限边界和配置责任都更明确了。工具没有变少，但每个工具该做什么、不该碰什么，已经可以单独判断。

本地代理这层绕不开

在多工具环境里，本地代理层很难绕开。

如果每个 CLI 都各配一套 provider、模型名和认证方式，那么每增加一个模型，实际上就是在改四份配置。问题不在于多填几个字符串，而在于出故障时，很难判断到底是哪一层在生效。

Codex 这边我现在至少收口到了本地 metapi 代理，真正生效的配置长这样：

model_provider = "newapi"
model = "gpt-5.4"
model_reasoning_effort = "xhigh"

[model_providers.newapi]
base_url = "http://127.0.0.1:15721/v1"
wire_api = "responses"

这层的价值不是“统一一切”，而是“把最容易漂移的那层先收住”。模型入口统一了，后端怎么换、路由怎么调、走哪家 provider，至少可以在代理层集中处理，不用每个 CLI 都重新解释一遍。

当然它也不是万能的。OpenCode 还是有自己的配置体系，认证方式和 Codex 也不一样，有的走 OAuth，有的走 API Key。代理解决不了所有分裂，但至少可以先明确排查应该从哪一层开始。

这套方案的核心不是让所有工具完全统一，而是明确哪一层配置生效、哪个入口负责什么。多装几个 AI CLI 本身不是问题，真正需要控制的是配置边界、权限边界和排查路径。只要这三件事清楚，工具可以共存，问题也更容易定位。

评论