
OpenClaw OpenRouter 配置,简单说就是让 OpenClaw 通过 OpenRouter 这个统一入口调用多个模型,而不是把每个模型供应商的 Key、接口和模型名都分散写在不同地方。它适合已经跑通 OpenClaw,想让 Agent 在 Claude、Gemini、DeepSeek、Kimi 或 OpenRouter Auto 之间切换的团队。
这件事不只是“省配置”。对做海外社媒矩阵、客服回复、内容生成和自动化任务的团队来说,不同任务对模型要求不一样。简单状态检查不需要大模型,复杂规划、代码、长上下文和多步骤推理则需要更强模型。配置好之后,团队要关注的不只是能不能跑,还要看模型能力、fallback、费用记录和执行结果是否可追踪。
Key Takeaways
- OpenClaw 官方建议新用户优先用
openclaw onboard配置 OpenRouter。 - OpenRouter 模型格式通常是
openrouter/<author>/<slug>,也可以用openrouter/openrouter/auto。 - 多模型切换要同时配置 primary、models 列表和 fallback,不要只改一个字段。
- 企业落地时要把模型选择、执行环境、账号权限和任务复盘一起设计。
先把前置条件对齐:OpenClaw OpenRouter 配置适合谁
先判断你是否真的需要 OpenRouter。如果你只是本地试用 OpenClaw、每天只问几个问题,单一模型也能先跑。如果你已经把 OpenClaw 接到 Telegram、WhatsApp、Slack 或其他消息入口,并且任务类型开始变多,就值得考虑 OpenRouter。
配置前至少准备四类东西:
- 一个可用的 OpenClaw 环境。
- 一个 OpenRouter API Key,通常以
sk-or-开头。 - 一个默认模型,例如
openrouter/~anthropic/claude-sonnet-latest或openrouter/openrouter/auto。 - 一个测试任务,用来验证 Agent 是否真的走了新模型。
对团队来说,还要多准备一个负责人。模型切换会影响费用、输出质量和任务稳定性,不建议所有人都能随意改默认模型。
| 配置项 | 用来解决什么 | 不建议怎么做 |
|---|---|---|
| API Key | 让 OpenClaw 能访问 OpenRouter | 明文贴到群聊、文档或截图里 |
| primary model | 设置默认运行模型 | 只改模型名,不确认模型是否存在 |
| fallbacks | 主模型不可用时按顺序尝试备用模型 | 把所有 fallback 都设成同一类模型 |
| usage dashboard | 查看请求、费用和 token 使用 | 只看能不能回复,不看成本 |
OpenClaw OpenRouter 配置教程:操作步骤
新用户最稳的方式是走官方向导。OpenRouter 的 OpenClaw 集成文档写明,可以用下面命令启动配置:
openclaw onboard
向导会引导你选择 OpenRouter、输入 API Key、选择模型,并配置消息渠道。如果已经有 Key,也可以用快速命令:
openclaw onboard --auth-choice apiKey --token-provider openrouter --token "$OPENROUTER_API_KEY"
如果你要手动改配置,可以把 Key 放到 ~/.openclaw/openclaw.json 的 env 里,再在 agents.defaults.model.primary 里指定 OpenRouter 模型。官方文档也说明,OpenClaw 已经内置 OpenRouter 支持,通常不需要额外配置 models.providers,只要使用正确模型格式。
一个常见配置思路是:
{
"env": {
"OPENROUTER_API_KEY": "sk-or-..."
},
"agents": {
"defaults": {
"model": {
"primary": "openrouter/~anthropic/claude-sonnet-latest",
"fallbacks": ["openrouter/~anthropic/claude-haiku-latest"]
},
"models": {
"openrouter/~anthropic/claude-sonnet-latest": {},
"openrouter/~anthropic/claude-haiku-latest": {}
}
}
}
}
改完后重启 OpenClaw gateway,再用一个短任务测试是否能正常回复。官方文档里的启动命令是:
openclaw gateway run
中间最容易出错的地方
第一类错误是 Key 没被 OpenClaw 读到。排查时先看环境变量,再看 auth profile。官方常见错误里也提到,遇到 “No API key found for provider openrouter” 时,要确认 OPENROUTER_API_KEY 是否存在,或者用 onboard 命令重新写入。
第二类错误是模型格式写错。OpenClaw 的 OpenRouter 模型格式通常是 openrouter/<author>/<slug>。如果要跟随某个模型家族的最新版本,文档示例里会在 author 前使用 ~。不要凭感觉手写模型名,最好从 OpenRouter models 页面复制 slug。
第三类错误是模型能力不匹配。OpenClaw 模型文档提到,openclaw models scan 可以检查 OpenRouter 模型目录,并可选探测工具和图片支持。做 Agent 工作流时,模型是否支持 tools、图片输入、上下文长度和响应速度,都比“看起来便宜”更重要。
如何确认操作结果
配置完成后,不要只问一句“你好”就算成功。至少做三层验收。
- 鉴权验收:运行一个简单请求,确认没有 401、403 或 missing key。
- 模型验收:让 Agent 输出当前模型来源,或者在 OpenRouter Activity Dashboard 查看请求记录。
- 任务验收:用真实任务测试,例如总结素材、生成回复、拆解发布步骤或调用工具。
如果你做的是海外社媒矩阵运营,还要把模型结果放进执行链里看。比如内容生成是否进入审核,回复建议是否有人工确认,发布任务是否有负责人,失败记录是否能复盘。Jumei 的 OpenClaw 专题页 更适合看 Agent 能力入口,而 工作方式 更适合理解任务如何进入团队流程。
下一步还能怎么优化
配置能跑以后,再考虑优化模型策略。简单任务可以用 openrouter/openrouter/auto 降低成本压力;复杂任务可以指定更强模型;关键任务可以设置 fallback,避免单一模型不可用时中断。
但不要把模型切换当成全部方案。真正影响运营结果的,是模型输出之后有没有执行环境和复盘机制。网页账号可以结合 AI 指纹浏览器 隔离登录环境;移动端 App 任务可以结合 云手机 执行;多账号分工可以放进 多账号管理 统一记录。
对于团队账号,建议把模型配置权限收口到少数负责人。普通运营可以选择任务模板,不直接修改底层模型。这样既能减少误操作,也方便追踪成本变化。
试运行时可以先选 3 类任务:低成本状态检查、中等复杂度内容草稿、高复杂度 SOP 拆解。每类任务固定跑 10 次左右,记录模型、耗时、是否调用工具、人工修改量和失败原因。这样团队不是凭感觉选模型,而是用真实任务判断哪个模型适合哪条运营流程。
常见问题
1. OpenClaw OpenRouter 配置一定要手动改 JSON 吗?
不一定。新用户优先用 openclaw onboard。只有需要精细控制 primary、fallback 或 auth profile 时,再手动编辑配置。
2. 可以直接用 OpenRouter Auto 吗?
可以。OpenRouter 官方文档把 openrouter/openrouter/auto 描述为自动路由模型。适合成本敏感或任务类型差异大的场景,但关键任务仍建议测试输出质量。
3. 为什么配置后还是提示找不到 Key?
通常是环境变量没有被当前进程读取,或者 auth profile 没写成功。先重新打开终端,再检查 OPENROUTER_API_KEY,必要时重新运行 onboard。
4. fallback 是 OpenRouter 做,还是 OpenClaw 做?
两层都可能参与。OpenRouter 有 provider 级 failover,OpenClaw 配置里也可以设置模型 fallback。企业使用时应明确自己依赖哪一层。
5. 免费模型适合生产任务吗?
不建议直接用于关键生产任务。可以用来测试,但正式任务要看稳定性、延迟、上下文、工具支持和数据策略。
6. 多模型切换会不会影响社媒自动化?
会。不同模型的输出格式、稳定性和工具调用能力可能不同。用于社媒任务前,最好先用小范围账号和低风险任务验证。
7. Jumei 适合接在哪一层?
Jumei 更适合接在执行层。OpenClaw 和 OpenRouter 负责 Agent 与模型入口,Jumei 负责账号环境、浏览器、云手机、任务分配和复盘。
8. 下一步怎么做最稳?
先选一个低风险任务,比如素材总结或回复草稿。跑通鉴权、模型记录、任务输出和人工审核后,再扩展到更多账号和平台。
总结
OpenClaw OpenRouter 配置的核心,是把模型能力从单点调用变成可切换、可回退、可监控的运行时配置。先用官方 onboard 跑通,再按任务复杂度设置 primary、fallback 和 auto model,最后用真实任务验收。
如果你的目标是海外社媒矩阵,不要只停在模型切换。更完整的做法,是把模型输出接到账号环境、任务审核、执行记录和数据复盘里。模型负责生成和推理,执行平台负责把结果变成可控的团队流程。
参考资料: