Claude 和国产模型不是二选一：在同一个 Claude Code 里按任务分流

关于国内怎么用 AI 写代码，流传最广的说法是「要么想办法用 Claude，要么换国产模型」——这是个伪选择。Claude Code 的模型是按请求指定的，同一个客户端里可以让主任务走一个模型、子任务走另一个模型，也可以在会话中途一句 /model 切过去。真正需要判断的不是「选哪一家」，而是「哪类任务该给哪类模型」。这篇给出三种共存方式的具体配置、任务分流的判断依据，以及共存之后会冒出来的三个新问题。

一、「二选一」这个错觉是怎么来的

几乎所有教程教的都是同一个动作：

export ANTHROPIC_BASE_URL="某一家的地址"
export ANTHROPIC_AUTH_TOKEN="某一家的 Key"

这个动作叫「换」。换的语义是排他的——换了 A 就没有 B。于是大量文章顺理成章地把它写成了一道选型题。

但 Claude Code 的模型解析是按请求发生的，不是按安装发生的。它至少有四个独立的模型变量：

ANTHROPIC_MODEL                  # 主任务默认用哪个
ANTHROPIC_DEFAULT_OPUS_MODEL     # 被要求用「最高档」时用哪个
ANTHROPIC_DEFAULT_SONNET_MODEL   # 中间档
ANTHROPIC_DEFAULT_HAIKU_MODEL    # 轻量档
CLAUDE_CODE_SUBAGENT_MODEL       # 子任务用哪个

这五个变量可以指向不同的模型。 只要它们背后的端点都兼容 Anthropic 协议，客户端不关心你混了几家。

「二选一」的错觉，本质上是把「端点只能填一个」误当成了「模型只能用一个」。

二、三种共存方式

2.1 会话内切换：/model

最简单的一种。在 Claude Code 的对话里直接输入：

/model

它会列出当前可用的模型，选一个即可，不用退出会话、不用重启。适合的场景是：正在做一件事，中途发现需要换个能力档位。

前提是你的端点后面挂着多个模型。如果端点只映射了一个模型，这个菜单里就只有一项。

2.2 主任务与子任务分开路由（这条最省钱）

Claude Code 在执行复杂任务时会派生子任务去做杂活——读文件、grep、简单判断。默认情况下，这些子任务可能和主任务用同一个模型。

一次跨文件重构里，子任务的调用次数常常是主任务的好几倍。用高价模型去读文件，是最典型的浪费。

分开指定：

# 主任务：难活，用能力上限高的
export ANTHROPIC_MODEL="你的主力模型"
export ANTHROPIC_DEFAULT_OPUS_MODEL="你的主力模型"

# 杂活：读文件、搜索、简单判断
export CLAUDE_CODE_SUBAGENT_MODEL="你的轻量模型"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="你的轻量模型"

⚠️ CLAUDE_CODE_SUBAGENT_MODEL 这个变量知道的人很少，但它在重度使用下的成本差别是数倍量级的。配置前后各跑一次同样的重构任务，看用量统计就知道差多少。

2.3 多配置文件按项目切换

给不同场景各写一份配置：

~/.claude/
├── settings-a.json      # 一套端点
├── settings-b.json      # 另一套端点
└── settings-local.json  # 本地/私有部署

每份长这样：

{
  "env": {
    "ANTHROPIC_BASE_URL": "对应的端点地址",
    "ANTHROPIC_AUTH_TOKEN": "对应的 Key",
    "ANTHROPIC_MODEL": "对应的模型名",
    "API_TIMEOUT_MS": "600000"
  }
}

启动时指定：

claude --settings ~/.claude/settings-a.json

嫌麻烦可以设 alias，或者用社区的开源工具 cc-switch 做可视化管理，它内置了几十家厂商的预设。

这三种方式可以叠加：用 2.3 决定这个项目走哪套端点，用 2.2 在端点内部分流主子任务，用 2.1 临时救急。

三、什么任务该给什么模型

这是共存之后真正要回答的问题。下面这张表的依据是任务特性，不是厂商排名：

两条容易搞反的：

① 长文档不一定要用最贵的模型。 一个 1M 窗口的中档模型，在「读完整个仓库再回答」这件事上，可能比 200K 窗口的顶配模型更有用。窗口是硬约束，能力是软约束。

② 「日常编码够用」和「复杂重构够用」是两个结论。 网上很多测评说国产模型「效果也很好」，这个判断在日常编码、读代码、写文档上成立；但在长链路的复杂重构、大规模代码库理解上，和第一梯队仍有可感知的差距。别用一个场景的结论去覆盖另一个场景。

四、共存带来的三个新问题

诚实地说，混用不是白拿的，它引入了三个原本不存在的问题。

4.1 上下文窗口标记：影响最大、知道的人最少

Claude Code 对它不认识的模型 ID，一律按 200K 上下文处理。如果你切到一个 1M 窗口的模型，它会在 200K 就触发自动压缩——你损失了 5 倍上下文，而且它不报错。

你的感受会是「这模型怎么老忘事」，然后你会去怪模型。

自查：

/context

看第一行的分母。是 200k 但你用的是 1M 模型，就中招了。

修法是给模型 ID 加 [1m] 后缀。三条实测注意事项：

• [1m] 是纯客户端侧的标记，不是上游模型名。带后缀的名字直接发给厂商 API 会报「模型不存在」，这个后缀必须由中间层吃掉
• 只给确认是 1M 窗口的模型加，加之前查准官方文档
• 标错比不标更糟：不标最坏是压缩太早（难受但不崩）；标大了会一路顶到上游真实窗口才撞墙，直接 API 报错，而那时会话里已经堆了一堆东西

⚠️ 官方模型也一样，默认 200K，1M 是要显式选的。这不是第三方模型专属问题。

4.2 工具调用行为的差异

Claude Code 重度依赖 tool use（读文件、执行命令、编辑）。不同模型对工具调用的支持成熟度不同，表现出来是：

• 有的模型会漏掉 tool_use 的某些参数
• 有的在多轮工具调用后丢失上下文关联
• 流式输出的分片结构不一致，可能导致显示异常

判别方法：让它做一个需要连续三次工具调用的任务（比如「找出所有引用了某函数的文件，逐个打开，统计调用次数」）。能稳定走完的，工具调用支持就是可用的。

4.3 计费口径对不上

混用之后，你的花销分散在多个地方，且计价单位可能不同（有的按 token、有的按次、有的包月）。想知道「这个月到底花了多少」会变得麻烦。

这是聚合类服务的实际价值所在——不是便宜，是把多个口径统一成一个。

五、怎么验证切换真的生效了

切换之后必须验证，否则你可能一直在用你以为已经换掉的那个模型。

🔴 先说一个不成立的方法：问它「你是什么模型」。模型自述的身份可以被系统提示词改写，返回体里的 model 字段也是服务端自己填的，两者都证明不了背后实际调用的是什么。

有参考价值的是这几条：

① 看 /context 的分母。 不同模型窗口不同，分母会跟着变。这是最难伪造的一项。

② 看响应的行为指纹。 有的模型会输出思考过程，有的不会；同一系列的相邻版本，这个行为可能刚好不同。拿行为差异做交叉验证，比问身份可靠。

③ 看错误响应的结构。 用一个故意写错的 Key 发一次请求：

curl -s -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
  -H "x-api-key: sk-obviously-wrong" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-5-20250929","max_tokens":16,
       "messages":[{"role":"user","content":"hi"}]}' | head -c 300

正经实现会返回结构化 JSON 错误体。返回 HTML、纯文本、或者干脆返回 200 的，说明中间那层根本没在转发。

④ 看用量记录的粒度。 后台能不能分项显示输入 token / 输出 token / 缓存 token？只给一个模糊的「剩余额度」、不能逐条审计的，用量上动手脚的空间很大。

六、三条落地路径

要实现多模型共存，有三种做法，成本和维护负担差别很大：

没有普适答案。用量集中在一家的，自己开户最省；需要频繁跨家切换的，聚合层的价值才显现出来。

七、说明一下 Code2AI 是什么（以及不是什么）

写到这里该说明立场：我们做的是第三种，code2ai.codes。

先澄清一个容易混淆的点：网上有一个名字接近的产品叫 Code2.AI，那是一个把代码库压缩成 AI 可读格式的代码协作工具，和我们不是一回事，也没有关系。我们做的是 API 网关——你的 Claude Code 照常用，只是把请求发到我们这里，由我们路由到不同厂商的模型。

具体形态是本文说的「共存」：

• 一个 Key、一份包月额度，覆盖 Claude 全系、GPT 全系、Kimi、GLM、DeepSeek、Grok 六家
• 额度是共享池，不是各模型独立叠加——强模型扣得快、轻量模型扣得慢，你可以把额度全花在真正需要的模型上
• [1m] 后缀已经在模型菜单里预置好，不用自己折腾第四节那个坑。窗口没有可靠依据的模型故意没加——按第 4.1 节第三条，标错比不标更糟
• 调用记录保留 30 天，可以逐条看

它不适合谁，说在前面：

• 用量集中在单一厂商的 —— 直接去那家开户更省
• 一个月只用几次的 —— 按量计费更划算，包月的价值在可预测性不在便宜
• 需要数据完全不出自己服务器的 —— 应该走私有部署，任何聚合层都不满足这个要求

第五节那四条验证方法，建议你对任何服务商（包括我们）都跑一遍。

八、常见问题

Q：一个 Claude Code 里真的能同时用 Claude 和国产模型吗？

能。主任务和子任务可以指向不同模型（2.2 节），会话中途也能用 /model 切（2.1 节）。前提是端点后面挂着多个模型。

Q：切换模型需要重启 Claude Code 吗？

/model 不需要。改环境变量或配置文件需要重启。

Q：混用会不会导致上下文丢失？

切换模型时当前会话的上下文会带过去，但新模型的窗口可能更小，超出部分会被压缩。切到小窗口模型前留意一下 /context。

Q：ANTHROPIC_API_KEY 和 ANTHROPIC_AUTH_TOKEN 用哪个？

不同版本、不同接入方式要求不同。一个不行试另一个，或者两个都设成同一个值。这是最常见的配置失败原因之一。

Q：怎么知道子任务真的走了轻量模型？

看用量记录的分项。配置前后各跑一次同样的任务，对比轻量模型的调用次数——如果 CLAUDE_CODE_SUBAGENT_MODEL 生效了，它的调用次数会明显高于主模型。

Q：国产模型能替代 Claude 吗？

分场景。日常编码、读代码、写文档基本够用；长链路复杂重构、大规模代码库理解仍有可感知差距。所以本文的结论才是「分流」而不是「替代」。

小结

• 「用 Claude 还是用国产模型」是伪选择。Claude Code 的模型是按请求指定的，五个模型变量可以指向不同厂商
• 三种共存方式：/model 会话内切、主子任务分开路由、多配置文件切换，可以叠加
• 最省钱的一条是主子任务分流，CLAUDE_CODE_SUBAGENT_MODEL 知道的人很少但差别是数倍量级
• 分流依据是任务特性不是厂商排名：窗口是硬约束，能力是软约束
• 共存有代价：上下文窗口标记、工具调用行为差异、计费口径分散
• 切换后必须验证，而问模型「你是谁」不算验证

先去跑一次 /context，看看你现在的上下文窗口分母是多少。这一条和你用哪家模型无关，但可能比选哪家影响更大。