OpenClaw多模型接入：Claude/Qwen/DeepSeek路由配置

发布时间：2026/10/21 4:27:08
OpenClaw多模型接入：Claude/Qwen/DeepSeek路由配置
这段时间我一直在折腾一个开源的个人 AI 助理框架名字叫 OpenClaw。之前我只接入单一模型运行时总觉得别扭复杂任务推理跟不上简单对话又浪费 token偶尔接口一抖动就直接罢工。后来我把 Claude、Qwen、DeepSeek 三个模型一起接进去情况立刻不一样。这篇文章就是我整理出来的接入过程和避坑记录。它能做什么简单说让 OpenClaw 一次识别三种模型根据任务类型自动路由既保证质量又控制成本。适合谁看正在用或者准备用 OpenClaw 做个人助理的开发者哪怕是第一次接触多模型配置也能按步骤复现。1. 动手前先想清楚为什么一定要一次接入三个模型1.1 OpenClaw 加载模型的底层逻辑OpenClaw 这类个人助理框架本质上就是个“调度壳”。它本身不生产回答而是把用户指令拆解后发给大模型接口再把返回结果接上工具调用、记忆存储、对话管理这些周边功能。所以它和模型之间不是绑定关系而是可插拔关系。理论上只要接口协议对得上换模型就像换电池一样简单。但这里有个关键点不同模型的接口协议并不完全一致。Claude 走的是 Anthropic 的 Messages APIQwen 和 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_KEYsk-ant-xxxx DASHSCOPE_API_KEYsk-xxxx DEEPSEEK_API_KEYsk-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 modelclaude [LLMClient] POST /v1/messages 200 1.834s [Tokenizer] input tokens1234 output tokens567看到这几行就基本能确定三个环节路由是否正确、请求是否成功、token 消耗是否异常。如果只开着 warning 级日志一遇到问题就是黑盒只能靠猜。4.2 高频报错对照表我把这半个月遇到的高频报错整理成了一张速查表基本覆盖了刚接入时容易碰到的绝大部分问题报错特征原因处理方式401 authentication_errorAPI Key 错误、被轮换或环境变量未加载检查.env是否被正确读取打印环境变量确认值404 model_not_found模型 ID 填错或服务商下线了旧版本去官方文档查最新模型 ID重新填写429 rate_limit_exceeded请求频率超出免费额度或并发限制降低请求频率检查是否多个任务同时跑同一个模型400 context_length_exceeded输入 token 超过模型上下文窗口压缩上下文或配置里调低max_tokens502 upstream_error服务商接口临时故障开启自动重试通常延迟 3-5 秒后可恢复ECONNREFUSEDbase_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 的推理成本最高一次长文档分析可能消耗几万 tokenQwen 和 DeepSeek 便宜一个量级。假设我每天跑 200 次对话其中 10% 需要走 Claude、40% 走 Qwen、50% 走 DeepSeek每次平均输入 1500 tokens、输出 500 tokens。按大致的公开单价粗算一天的成本大约在几块钱到十几块钱之间。如果你的使用频率更高应该从一开始就在控制台看 token 消耗曲线心里有本账才敢继续折腾。控制方案可以是给不同模型分配不同的max_tokensClaude 只用于高端任务输出 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 做裁判总结。这种方式在写代码和内容审核场景下效果很好虽然消耗高但正确率有明显提升。我自己只会在处理重要决定时开启这个模式平时还是按路由规则走。我个人在实际操作中的体会是多模型接入这件事真正麻烦的不在配置代码本身而在后续的观测和调整。第一次启动时先别追求完美元宇宙级规则跑起来、看日志、按月迭代比一开始就设计一个庞大体系可靠得多。这里提供的配置和排查思路应该能让你少走很多弯路。接下来就轮到你用自己的场景去折腾了。