我怎么搭配 Codex、Claude Code 和国产 Coding Plan

最近我在折腾一件很实际的事：同一套工作流里，怎么同时用好 Codex、Claude Code、OpenClaw、Hermes，以及一些国产 coding plan。

这不是单纯的模型评测。真正用起来以后，我发现最影响体验的不是某一次 benchmark，而是这些更日常的问题：

• 订阅额度到底能不能给第三方 agent 用？
• token 能不能放在多个终端、多个 runtime 里？
• CLI、gateway、Telegram bot、Hermes 后台任务会不会互相把登录态刷坏？
• 一旦额度用完，是停掉、降级，还是变成 API 账单？

这篇文章不是“谁吊打谁”的评测，而是一篇个人踩坑后的使用记录。

我的基本工作流

我现在主要同时使用几类工具：

• Codex CLI：日常终端里最常用的 coding agent。
• Claude Code：有些任务仍然会配合使用，尤其是 Claude 生态里已有的工作流。
• OpenClaw：更像 agent gateway，可以接 Telegram、Feishu、Weixin，也能作为长期运行的服务。
• Hermes：另一个本地 agent runtime，有自己的记忆、工具、gateway 和任务循环。
• 国产 coding plan / token plan：包括 Qwen、MiniMax、MiMo 这类模型和套餐。

我的目标不是只押一家，而是把它们分层：

• 主力交互：Codex CLI。
• 渠道和服务化：OpenClaw、Hermes。
• 长上下文、备用模型、低成本尝试：国产 coding plan。
• 特定 Claude 工作流：Claude Code。

为什么我开始重视“订阅边界”

以前很多人会自然地觉得：我买了一个 AI 订阅，就应该能给所有工具用。

但现在越来越明显：模型厂商在把不同场景拆开计量。

Anthropic 官方已经说明，从 2026 年 6 月 15 日开始，Claude 订阅计划会有单独的 Agent SDK monthly credit。它覆盖 Claude Agent SDK、claude -p、Claude Code GitHub Actions，以及基于 Agent SDK 的第三方应用。这个额度和普通 Claude usage limits 是分开的。

这个变化说明一件事：agent workload 会被单独看待。

交互式聊天、CLI 编程、SDK 调用、GitHub Action、第三方 agent，不再天然共享同一池“无限额度”。

对普通用户来说，这意味着你不能只问“模型强不强”，还要问：

• 这个订阅能不能用于第三方工具？
• 有没有单独的 agent credit？
• 额度耗尽后会不会自动产生 API 费用？
• 能不能配置到 OpenClaw、Hermes、OpenCode、Cline、Cursor 这类工具里？

Codex 的体验：目前对我的组合很顺

我现在把 Codex CLI、OpenClaw、Hermes 都接到了 openai-codex。

实际体验是：模型能力够强，尤其是 gpt-5.5 这一类 Codex 模型，在复杂项目里表现很稳。更重要的是，它能同时覆盖我这几类入口：

• 终端里跑 Codex CLI。
• OpenClaw 接 Telegram。
• Hermes 跑本地 agent。

但这里有一个很大的坑：可以共用账号，不要共用同一份 refresh token。

Codex CLI、OpenClaw、Hermes 都可以使用 openai-codex，但它们最好各自登录、各自维护凭据。

正确方式：

codex login
codex login status

hermes auth add openai-codex
hermes auth status openai-codex

openclaw models auth login --provider openai-codex
openclaw models status --json

不要把 ~/.codex/auth.json 复制给 Hermes 或 OpenClaw。OAuth refresh token 会轮换，一个客户端刷新后，另一个客户端手里的旧 token 可能就废了。

典型报错是：

Codex refresh token was already consumed by another client

看到这句，就先别怀疑模型。先怀疑：是不是多个客户端复用了同一份 refresh token。

OpenClaw 的另一个坑：别把 provider 写错

我还踩过一个 OpenClaw 的坑。

Telegram 已经配对成功，但机器人回复：

Missing API key for OpenAI on the gateway.
Use openai-codex/gpt-5.5, or set OPENAI_API_KEY, then try again.

这个不是 Telegram 坏了。根因是模型写成了：

"primary": "openai/gpt-5.5"

openai/* 走的是 API Key 路径，所以它要 OPENAI_API_KEY。

如果你用 Codex OAuth，要写：

"primary": "openai-codex/gpt-5.5"

这两个不是同一个 provider。

国产 coding plan 的优势：更像“明确的 key + 明确的额度”

和 OAuth 订阅比起来，Qwen、MiniMax、MiMo 这类 coding plan / token plan 的一个好处是：它们通常更像传统 API key。

你拿到一个 plan-specific key 或 token plan key，然后把它配置到不同工具里：

• OpenClaw
• Hermes
• Claude Code
• OpenCode
• Cline / Kilo / Roo
• 其他 OpenAI-compatible 或 Anthropic-compatible 工具

这种方式对新手反而更直观：不是“登录态能不能被第三方用”，而是“这个 key 对应哪个套餐、哪个 base URL、哪个额度”。

当然，这不等于可以把密钥到处乱放。我的理解是：

• 个人实验环境：一个 key 放多个终端，通常更容易跑通。
• 团队或生产环境：最好分 key、分项目、分机器、分权限。
• 任何 key 泄露，都要能立刻撤销和轮换。

开放不是没有边界，而是边界更像 API key 管理。

Qwen：一定要用 Coding Plan 专用 key 和 base URL

Qwen Cloud 的官方文档说得很清楚：Coding Plan 要用 plan-specific API key，格式类似 sk-sp-xxxxx。

同时 base URL 也要用 coding 专用地址：

OpenAI compatible:
https://coding-intl.dashscope.aliyuncs.com/v1

Anthropic compatible:
https://coding-intl.dashscope.aliyuncs.com/apps/anthropic

不要拿普通 sk-xxxxx key 或普通 DashScope base URL 混用。官方文档也提醒：如果用了通用 API key 和通用 base URL，可能会变成按量计费，导致意外账单。

这点对新手很重要。不是“Qwen 扣错钱”，而是你可能把 coding plan 的 key 和普通 API key 混了。

MiniMax：Token Plan Key 覆盖更广

MiniMax 官方文档把 Coding Plan 扩展成了 Token Plan。

它的核心思路是：一个 Token Plan 覆盖文本、语音、视频、音乐、图片等多种模型资源。Token Plan Key 可以使用订阅 seat 或 credits 里的资源。

这类设计对 agent 很有意思。因为未来的 agent 不一定只写代码，它可能会：

• 写文档。
• 生成图片。
• 生成语音。
• 做视频草稿。
• 同时调用多模态工具。

MiniMax 的 Token Plan 更像是给这种“多模态 agent”准备的资源池。

但注意：Token Plan Key 不等于普通 pay-as-you-go API key。不同 key 对应不同资源规则，配置时要看清楚。

MiMo：我看重的是兼容性和长上下文

MiMo 这条线，我主要看中两点：

第一，它对 agent/coding 场景很友好。OpenClaw 官方文档里也把 Xiaomi MiMo 作为 OpenAI-compatible API key provider 接入。MiMo Pro 这类模型支持很长上下文，适合长文档、长项目、代码仓库级任务。

第二，它同时有 OpenAI-compatible 和 Anthropic-compatible 的接入形态。社区资料里也能看到 MiMo V2.5 / V2.5 Pro 可以接 Claude Code、OpenCode、Codex、Cline、Kilo、Roo 这类工具。

我自己的体感是：MiMo 这种 token plan 更适合作为 OpenClaw / Hermes 的备用模型池，或者做大上下文任务的补充。

但我不会把它神化。原因也很简单：coding agent 的 token 消耗很可怕。工具调用、多轮上下文、缓存读写、长文件扫描，都会让消耗比普通聊天大很多。

所以 MiMo、Qwen、MiniMax 这类套餐，买之前一定要看：

• 是否有 coding 专用 key。
• 是否有 coding 专用 base URL。
• 缓存 token 怎么计费。
• 长上下文是否额外收费。
• 用量是按 request、token、credit，还是滚动窗口。
• 控制台能不能看清楚消耗。

我现在的搭配建议

如果你是个人用户，我会这样建议：

1. 主力 coding agent 用 Codex

Codex CLI 目前对我来说比较顺。模型能力够强，和 OpenClaw、Hermes 也能打通。

但一定要记住：

同账号可以，复制 token 不行。

Codex CLI、OpenClaw、Hermes 各自登录，各自维护凭据。

2. Claude Code 保留，但别默认当无限第三方额度

Claude Code 很好用，但随着 Agent SDK credit 独立出来，我会更谨慎地看它的使用边界。

如果是官方 Claude Code 交互式使用，按官方规则来。
如果是第三方 agent、SDK、GitHub Action、自动化跑任务，就要仔细看是不是走单独额度或 API 计费。

3. 国产 coding plan 适合做备用池和试验场

Qwen、MiniMax、MiMo 的开放度对 agent 用户很有吸引力。

它们通常不是 OAuth 登录态，而是 key + base URL 的形态。配置到多个工具里更直接，也更容易和 OpenClaw、Hermes 这类 runtime 结合。

但要做好三件事：

• 不混用普通 API key 和 coding plan key。
• 不混用普通 base URL 和 coding plan base URL。
• 不把生产密钥放进不受控环境。

最实用的一张检查表

Codex

codex login status

如果远程机器没有浏览器：

codex login --device-auth

Hermes

hermes auth status openai-codex
NO_PROXY=127.0.0.1,localhost hermes chat -q "Reply exactly: ok"

OpenClaw

openclaw config validate
openclaw models status --json
curl --noproxy 127.0.0.1 -fsS http://127.0.0.1:18789/health

本地模型实测：

timeout 180 openclaw agent --local --agent main \
  --message '请只回复两个小写字母: ok' \
  --session-id smoke-openai-codex \
  --json --timeout 150

Qwen / MiniMax / MiMo

检查三件事：

1. key 是不是套餐专用 key？
2. base URL 是不是套餐专用 base URL？
3. 控制台里是否能看到用量和剩余额度？

最后的观点

我的判断是：未来 coding agent 的使用会分成两条路。

一条是 OAuth 订阅型，比如 Codex、Claude Code 这类。它的好处是对个人用户友好，登录就能用；坏处是订阅边界、SDK 边界、第三方工具边界会越来越细。

另一条是 Token Plan / Coding Plan 型，比如 Qwen、MiniMax、MiMo。它更像传统 API key，跨工具配置更直接；坏处是你要自己管理 key、base URL、额度和账单。

我现在不会只押一种。我的方案是：

• Codex 做主力。
• OpenClaw / Hermes 做运行时和渠道。
• Claude Code 做特定场景补充。
• Qwen / MiniMax / MiMo 做国产模型池、长上下文补充和成本试验。

真正的经验不是“哪个模型最强”，而是你要知道每个模型和套餐的边界在哪里。

会配模型只是第一步。会管理 token、额度、provider、gateway，才是长期使用 agent 的关键。

参考来源

• Anthropic Help Center: Use the Claude Agent SDK with your Claude plan
• Qwen Cloud Docs: Coding Plan Overview
• MiniMax API Docs: Token Plan Overview
• OpenClaw Docs: Xiaomi MiMo Provider
• DevTk.AI: Xiaomi MiMo-V2.5 Agent Model Guide