这段时间我一直在折腾一个开源的个人 AI 助理框架，名字叫 OpenClaw。之前我只接入单一模型，运行时总觉得别扭：复杂任务推理跟不上，简单对话又浪费 token，偶尔接口一抖动就直接罢工。后来我把 Claude、Qwen、DeepSeek 三个模型一起接进去，情况立刻不一样。这篇文章就是我整理出来的接入过程和避坑记录。它能做什么？简单说，让 OpenClaw 一次识别三种模型，根据任务类型自动路由，既保证质量又控制成本。适合谁看？正在用或者准备用 OpenClaw 做个人助理的开发者，哪怕是第一次接触多模型配置，也能按步骤复现。
1. 动手前先想清楚：为什么一定要一次接入三个模型
1.1 OpenClaw 加载模型的底层逻辑
OpenClaw 这类个人助理框架，本质上就是个“调度壳”。它本身不生产回答，而是把用户指令拆解后发给大模型接口，再把返回结果接上工具调用、记忆存储、对话管理这些周边功能。所以它和模型之间不是绑定关系，而是可插拔关系。理论上只要接口协议对得上，换模型就像换电池一样简单。
但这里有个关键点：不同模型的接口协议并不完全一致。Claude 走的是 Anthropic 的 Messages API，Qwen 和 DeepSeek 都兼容 OpenAI 的 Chat Completions 格式。OpenClaw 底层做了统一封装，把三套协议翻译成内部消息结构，然后根据配置里的模型名称去请求对应服务商。我们要做的，就是在配置层把路由信息写清楚，让它在每次对话时知道该找谁。
明白了这层关系，你就不会把多模型接入想成什么黑科技。它更像是给一个已经支持多输入的收音机装上三个频道预设，调台的事交给系统，选台的事交给我们。
1.2 三个模型的分工怎么划
很多人的第一反应是：我有三个模型，那就随机用，哪个回复快用哪个。这是最省事但最浪费的做法。三个模型的能力侧重点完全不同，我实际用下来是这样分的：
- Claude 当作“推理主力”。涉及代码审查、复杂逻辑拆解、长文档理解时，它的稳定性和指令跟随能力最好，但价格也最贵。
- Qwen 当作“日常助手”。润色文案、整理会议纪要、写周报、闲聊这类任务，它反应快，中文表达自然，性价比高。
- DeepSeek 当作“批量处理工具”。翻译、摘要、格式化输出、批量打标签这类结构化任务，它速度快、接口稳定，适合跑量。
这样分工之后，我在 OpenClaw 里设置的不是“谁有空谁上”，而是“什么任务找谁”。这个思路直接决定了后面的路由规则怎么写。
1.3 多模型接入的三个常见误区
误区一是“接进去就能自动最优”。很多框架确实支持多模型，但默认只是提供手动切换入口，并不会自动帮你选。如果不写路由规则，那多接入反而增加管理成本。
误区二是“API Key 越多越好”。有人把五个模型的 Key 全部塞进配置里，结果日志刷屏，排查问题时分不清是哪个服务商报的错。我的建议是先用两到三个，跑顺了再往上加。
误区三是“配置完就不用管”。模型服务商经常调整模型版本、价格和速率限制。比如原来配置的模型名还在，但服务商已经下线了旧版本。所以每次接入完，至少要跑一周观察日志，确认没有隐藏异常。
2. 准备工作：把三把钥匙一次性弄整齐
2.1 环境检查与依赖安装
在动配置文件之前，先确认机器上的环境是干净的。OpenClaw 官方要求 Node.js 18 以上，我用的是 20 LTS，跑了大半个月没有遇到兼容问题。如果你之前装过旧版本，建议先升级再继续。
安装依赖这一步，我推荐用 pnpm 而不是 npm。不是因为 pnpm 更潮，而是 OpenClaw 的依赖树比较复杂，pnpm 的硬链接机制能避免很多“幽灵依赖”问题。我刚开始用 npm 装，启动时经常报模块找不到，换成 pnpm 后一次通过。具体命令很简单：
pnpm install pnpm build如果网络比较慢，可以把 registry 切到镜像源，但注意不要影响后续拉取模型服务商依赖。装完后跑pnpm start能正常起来，说明环境没问题。
2.2 申请三个 API Key 的要点
三个模型的 Key 申请方式各不相同，我逐个说一下容易踩的细节。
Claude 的 Key 在控制台创建，开通后有一段时间的免费额度。要注意的是取 Key 时千万别关了页面再刷新，Key 只展示一次，丢了只能重新生成。另一个坑是 Claude 的 Key 分“普通 Key”和“Admin Key”，OpenClaw 这种个人助理只需要普通 Key，管理权限用不到。
Qwen 的 Key 在阿里云百炼平台创建。这个平台默认开通的是海外版还是国内版要留意，不同区域的调用地址不一样。我在配置时发现，OpenClaw 里填的 base_url 必须和区域对应，不然延迟会高得离谱。
DeepSeek 的 Key 申请最简单，注册后直接在控制台创建，没有复杂的区域区分。但它对余额比较敏感，建议在控制台开通余额告警，避免跑到一半欠费导致助理突然“失忆”。
2.3 用 .env 统一管理三个密钥
我强烈建议不要把 Key 直接写在 OpenClaw 的配置文件里。配置文件可能会被同步到 Git 仓库，一旦泄露就是所有模型一起遭殃。正确做法是放进.env文件，然后在配置里引用环境变量名。
我习惯新建一个.env文件放在项目根目录，内容长这样：
ANTHROPIC_API_KEY=sk-ant-xxxx DASHSCOPE_API_KEY=sk-xxxx DEEPSEEK_API_KEY=sk-xxxxOpenClaw 启动时会自动加载这个文件。只要配置里写成env:ANTHROPIC_API_KEY这种形式，框架就会去取对应的值。这样有另外一个好处：换机器部署时，只需要复制.env，不用动任何业务配置。
3. 核心实操：让 OpenClaw 一次认得三个模型
3.1 读懂 OpenClaw 的配置文件结构
OpenClaw 的配置集中在项目根目录下的claw.yaml里，打开后会看到几个顶层字段：app、models、tools、memory等。其中models字段是我们这次操作的主战场。
我先说一个最小的模型配置结构长什么样：
models: claude: model: claude-3-5-sonnet-latest api_key_env: ANTHROPIC_API_KEY max_tokens: 8192 temperature: 0.7这段配置的意思是：在 OpenClaw 内部注册一个代号为claude的模型，真正请求时使用claude-3-5-sonnet-latest这个版本，密钥从环境的ANTHROPIC_API_KEY变量里取，单次最大输出 8192 tokens，温度设 0.7。
这里最关键的是model字段的命名。它必须和服务商当前支持的模型版本完全一致，差一个字都会报模型不存在。我的习惯是先去官方文档查一眼最新的模型 ID，不要凭记忆填。
3.2 一次性写入三份模型配置
了解结构之后，接入三个模型就是往models节点下加内容的事。我给出一个可直接抄作业的完整配置：
models: claude: model: claude-3-5-sonnet-latest api_key_env: ANTHROPIC_API_KEY max_tokens: 8192 temperature: 0.7 base_url: https://api.anthropic.com/v1 qwen: model: qwen-plus api_key_env: DASHSCOPE_API_KEY max_tokens: 4096 temperature: 0.8 base_url: https://dashscope.aliyuncs.com/compatible-mode/v1 deepseek: model: deepseek-chat api_key_env: DEEPSEEK_API_KEY max_tokens: 4096 temperature: 0.6 base_url: https://api.deepseek.com/v1这里我有几个刻意为之的选择。Claude 的max_tokens给得高，因为它要干的是长文档分析、代码生成，输出空间不足容易截断。Qwen 和 DeepSeek 给 4096，日常对话和翻译绰绰有余，省下不必要的计费。温度方面，Claude 需要更严谨，所以 0.7 偏低；Qwen 做润色和闲聊，0.8 更有创造性；DeepSeek 做结构化输出，0.6 能减少自由发挥带来的格式漂移。
有人会问，DeepSeek 为什么不用deepseek-reasoner这个推理模型？我试过一次，它的思维链输出很长，OpenClaw 在这种场景下不好处理中间过程，容易超时。除非你要跑复杂推理，否则日常接入选deepseek-chat更稳。
3.3 设置路由规则和默认模型
只把三个模型写进配置，OpenClaw 还不会自动挑选。它需要一组路由规则，明确什么情况用哪个模型。OpenClaw 支持在配置文件里加一个routing节点，语法可以按任务关键词和模型能力来匹配。我目前的规则如下：
routing: default: qwen rules: - name: code-review match: ["代码", "debug", "重构", "review", "bug"] model: claude - name: batch-text match: ["翻译", "摘要", "总结", "标题", "标签"] model: deepseek这里有三个细节要解释。第一，默认模型我选的是 Qwen，因为它最均衡，误伤概率最小。第二，match里的关键词命中后就会走对应模型，所以关键词要按需加，不要贪多。第三，规则有顺序优先级，OpenClaw 从上到下匹配，命中第一条就停下。所以“代码”相关规则要放在“翻译”规则前面，我在实际配置时就遇到过顺序写反，导致“翻译这段代码”这种请求被 Cluade 处理而不是 DeepSeek。
如果你的 OpenClaw 版本比较新，路由规则可能还支持按max_tokens、工具调用数量这些条件判断，原理一样，都是提前在配置里声明分支逻辑。
3.4 第一次启动验证
配置写完后，先别急着正式使用。我习惯先启动一个测试会话，逐个确认三个模型都通了。OpenClaw 启动后，可以用交互面板手动输入指令，也可以直接写一段测试脚本调它的 API。
最简单的验证方法是在聊天窗口里输入下面三句话，看回复内容辨别模型身份：
- “你是哪个模型？” 如果 OpenClaw 带有系统提示词，可能不直接回答身份。这时可以问“你现在使用的是什么模型版本”，多数模型会从内部知识里回答一个名字。
- “把这句话翻译成英文：你好世界”。这句应该走到 DeepSeek 的翻译规则上。
- “帮我看看这段代码有什么问题”。这句应该走到 Claude 的代码规则上。
如果第三句没有命中 Claude，先别怀疑路由，直接在日志里看请求执行路径。一切正常的话，日志里会出现类似routing matched: code-review -> claude的记录。
4. 日志、报错与排查：接入过程中最易踩的坑
4.1 日志级别与关键信息
OpenClaw 的日志是排查问题的第一现场。默认日志级别可能只输出 warning，会把很多有效信息过滤掉。调试阶段建议把日志级别调到 debug，方式是在配置文件里写：
logging: level: debug在 debug 级别下，能看到每次请求的路由命中、请求体大小、模型返回耗时、HTTP 状态码。我最常关注的是这几行：
[ModelRouter] rule code-review matched, using model=claude [LLMClient] POST /v1/messages 200 1.834s [Tokenizer] input tokens=1234 output tokens=567看到这几行，就基本能确定三个环节：路由是否正确、请求是否成功、token 消耗是否异常。如果只开着 warning 级日志，一遇到问题就是黑盒，只能靠猜。
4.2 高频报错对照表
我把这半个月遇到的高频报错整理成了一张速查表，基本覆盖了刚接入时容易碰到的绝大部分问题：
| 报错特征 | 原因 | 处理方式 |
|---|---|---|
401 authentication_error | API Key 错误、被轮换或环境变量未加载 | 检查.env是否被正确读取，打印环境变量确认值 |
404 model_not_found | 模型 ID 填错或服务商下线了旧版本 | 去官方文档查最新模型 ID，重新填写 |
429 rate_limit_exceeded | 请求频率超出免费额度或并发限制 | 降低请求频率，检查是否多个任务同时跑同一个模型 |
400 context_length_exceeded | 输入 token 超过模型上下文窗口 | 压缩上下文，或配置里调低max_tokens |
502 upstream_error | 服务商接口临时故障 | 开启自动重试，通常延迟 3-5 秒后可恢复 |
ECONNREFUSED | base_url 写得不对或网络不通 | 手动 curl 一下接口地址，确认能连通 |
我第一次遇到404 model_not_found时，反复检查模型名拼写，最后发现是版本号少了一个后缀。这类问题最笨但也最有效的方法是：把错误信息原文复制到搜索引擎里搜，不要自己猜。
4.3 一个典型的排查顺序示例
有次我发现系统里所有走 Claude 的请求都报401，但 Qwen 和 DeepSeek 完全正常。最开始我以为 Claude 的 Key 被限流，快把控制台翻个底朝天也没找到原因。
后来一步步排查才发现，是系统在启动时自动加载了一个全局环境变量文件，把旧的ANTHROPIC_API_KEY给覆盖了。也就是说，OpenClaw 拿到的根本不是.env里那个新 Key。
这个经历告诉我一个排查顺序：先确认环境变量 → 再确认 base_url → 再确认模型名 → 最后才怀疑服务商故障。每层问题都用一个简单的 curl 测试来确认，比瞎猜快得多。
5. 稳定运行与成本控制的进阶调优
5.1 按任务类型分配模型的优先级
接入完成只是第一步，真正让多模型发挥价值的是优先级策略。OpenClaw 默认单一规则匹配，但实际任务的复杂度不是单标签能描述的。我会在路由规则之外，结合工具调用和任务规模做分级处理。
比如，普通 Qwen 能处理的请求，坚决不升级到 Claude；只有确认涉及多步逻辑推理或代码执行时，才通过规则把它引到 Claude。这个分级需要一段时间积累。我会先不加任何成本限制地跑一周，然后看日志里每个模型的调用占比，再做规则收敛。
配合行为是设置“成本上限”和“调用占比”监控。有的版本支持在配置文件里声明每日最高消耗，一旦达到阈值就不再调用对应模型。我在实际使用中会把它设为一个会用完但不会心疼的额度，比如每天 10 元以内，超过就自动切到默认模型。
5.2 用量控制与成本估算
接入三个模型后，一定要对自己的消耗量有数。我按常见单价估过一笔账：Claude 的推理成本最高，一次长文档分析可能消耗几万 token；Qwen 和 DeepSeek 便宜一个量级。
假设我每天跑 200 次对话，其中 10% 需要走 Claude、40% 走 Qwen、50% 走 DeepSeek，每次平均输入 1500 tokens、输出 500 tokens。按大致的公开单价粗算，一天的成本大约在几块钱到十几块钱之间。如果你的使用频率更高，应该从一开始就在控制台看 token 消耗曲线，心里有本账，才敢继续折腾。
控制方案可以是给不同模型分配不同的max_tokens：Claude 只用于高端任务，输出 4096 就够了，没必要留 8192。调低max_tokens会直接减少账单，因为流式输出到指定长度就会截断。
5.3 超时、重试和失败后的降级
多模型接入的优势之一是可以互相兜底。我遇到过真实情况：DeepSeek 接口在晚高峰偶发超时，如果不做降级，整个任务就失败了。在 OpenClaw 配置里，超时和重试也是可以按模型单独声明的。
我写了一组实测可用的配置：
request: timeout: 60s retries: 2 fallback_order: [claude, qwen, deepseek]意思是单次请求最长 60 秒，失败后自动重试最多 2 次，如果当前模型不可用，就按fallback_order顺序切换。我把 Claude 放在降级链最前面，是因为它的可用性最好；Qwen 第二，DeepSeek 最后兜底。
这里有个细节：重试不是越快越好。如果服务商返回429，马上重试只会加重限流。retries的间隔建议设成指数退避，第一次 2 秒，第二次 5 秒。这个值可以在框架的 request 配置里调，我实测下来对稳定性提升很大。
5.4 效果对比与模型选择建议
跑了两周之后，我的使用感受是：三个模型各有所长，但没有一个是万能选手。Claude 在复杂代码生成和长文档理解上明显强于其他两个，缺点是响应速度偏慢且贵。Qwen 的中文口语化表达最自然，适合做文案润色，但在严格遵循格式上偶尔会松。DeepSeek 在批量结构化任务上最稳定，几乎不会跑偏，但创意类回答偏保守。
所以我的建议是：不要迷信“最新模型”，要在具体任务上做 A/B 测试。测试方法很简单，固定的问题分别让三个模型回答，把结果放在一起对比，优先看是否满足格式要求，再看内容质量。多模型的价值就在这种对比中体现，而不是单纯比谁参数多。
6. 我的经验与更多玩法
6.1 我踩过的三个大坑
第一个坑是每个模型的 API 协议细节不一样。Qwen 和 DeepSeek 都兼容 OpenAI 格式，但它们在工具调用的参数上有细微差别。OpenClaw 虽然做了兼容，但遇到工具调用失败时还是要回到原文协议里排查。
第二个坑是温度参数不能“万金油”。我最初给三个模型都设成 0.7，结果 DeepSeek 在格式化输出时偶尔会在 JSON 里多加注释符，导致解析失败。后来把 DeepSeek 的温度调低到 0.6，问题立刻消失。温度不是越高越好，也不是越低越好，它跟任务类型的匹配度相关。
第三个坑是不要忽略上下文压缩策略。OpenClaw 支持把长对话内容压缩再送进模型。但如果压缩算法不匹配，可能丢掉关键信息。我在跑长对话时发现 Claude 的表现优于其他两个，因为它对长上下文的忠实度更高。所以涉及长历史对话时，最好把默认模型指向 Claude，别在意那点成本。
6.2 可以从这里继续扩展的方向
接入三个模型只是起点，后面可以做的还有很多。我会建议把日志里的 token 消耗数据接进一个小应用，生成日报表，这样能直观看到哪类任务在花钱。OpenClaw 有插件机制，写一个统计插件就能完成这件事。
另一个方向是给每个模型绑定不同的系统提示词。Claude 用代码规则提示词，Qwen 用中文表达偏好提示词，DeepSeek 用输出格式约束。这样即使是同一个用户问题，不同模型也会按最适合自己的方式回答。OpenClaw 在配置里支持system_prompt字段，按模型区分声明即可。
最后，如果你想进一步折腾，可以在三个模型之间做“投票”机制：同一问题让三个模型各答一遍，再让 Claude 做裁判总结。这种方式在写代码和内容审核场景下效果很好，虽然消耗高，但正确率有明显提升。我自己只会在处理重要决定时开启这个模式，平时还是按路由规则走。
我个人在实际操作中的体会是：多模型接入这件事，真正麻烦的不在配置代码本身，而在后续的观测和调整。第一次启动时先别追求完美元宇宙级规则，跑起来、看日志、按月迭代，比一开始就设计一个庞大体系可靠得多。这里提供的配置和排查思路，应该能让你少走很多弯路。接下来就轮到你用自己的场景去折腾了。
