模型选型与成本控制

很多人第一次配置 OpenClaw 时，会把模型问题理解成“哪家最强”。但真正长期使用时，更重要的通常是下面四件事：

• 主力模型够不够稳
• fallback 链有没有准备
• 低价值任务是不是在浪费预算
• 你的 provider 是否适合当前网络环境

1. 一开始不要追求模型越多越好

更稳的方式通常是：

1. 先选一个主力模型
2. 再加一个 fallback
3. 最后再补低成本或本地模型

如果你一开始就同时接很多 provider，排查问题和控制成本都会变得更难。

2. 主力模型应该怎么选

主力模型更适合承担：

• 长任务
• 工具调用
• 稳定的日常主会话

选择主力模型时，优先看：

• 你是否已经有稳定凭据
• 当前网络环境访问是否稳定
• 工具调用和长上下文是否符合你的主要任务
• 长期成本能否承受

3. 为什么 fallback 很重要

对长期运行来说，fallback 不是锦上添花，而是系统稳定性的关键一层。

它适合解决：

• 主模型限速
• 主模型临时不可用
• 某些 provider 高峰期抖动
• 成本过高时的自动降级

如果你的 OpenClaw 已经接了真实渠道，最好不要让主模型成为单点故障。

4. 中文用户更值得单独看的 3 类 provider

Qwen OAuth

官方 Qwen provider 现在更像“快速验证和低门槛试用入口”：

• 通过设备码 OAuth 登录
• 默认 provider 是 qwen-portal
• 文档注明有每日请求额度上限

它很适合：

• 本地测试
• 快速体验 Qwen Coder / Vision
• 轻量备用入口

但如果你要长期跑真实团队工作流，更适合把它看成补充路线，而不是唯一主力。

Qianfan

Qianfan 更适合已经在百度云体系里、或者想统一走 MaaS 平台的团队。

官方接入已经支持：

openclaw onboard --auth-choice qianfan-api-key

它更适合：

• 团队已有百度云账号与结算体系
• 想把模型入口放进统一平台
• 希望接入和审计方式更企业化

Moonshot / Kimi

官方现在已经把 Moonshot API 和 Kimi Coding 明确分开：

• moonshot/...
• kimi-coding/...

它们不是同一个 provider，密钥也不能互换。

对中文用户尤其重要的一点是，官方文档已经给出：

• 国际端点：https://api.moonshot.ai/v1
• 中国端点：https://api.moonshot.cn/v1

如果你准备在国内网络环境长期运行，这类 provider 会比“只看模型榜单”更值得先核对端点和计费方式。

5. 哪些任务适合用低成本模型

不是所有任务都值得上高价模型。

更适合低成本或免费模型的通常包括：

• 心跳任务
• 定时检查
• 简单摘要
• 轻量对话
• 状态汇总

这样做的价值很直接：

• 把预算留给真正需要强模型的任务
• 降低长期运行的焦虑感

6. 本地模型值不值得上

本地模型的核心优点是：

• 零 API 成本
• 更强的数据控制
• 离线可用

但它的代价也很明确：

• 硬件门槛
• 推理速度
• 工具调用能力不一定稳定
• 模型切换和维护成本

所以更适合把本地模型理解成：

• 隐私敏感任务的补充方案
• 预算有限时的实验方案
• 某些低风险任务的离线入口

而不是默认替代所有云端模型。

7. 中文团队最容易忽略的成本，不只是单价

真正容易失控的，通常不是某个模型的标价，而是下面这些组合问题：

• 所有任务都走同一个高价主力模型
• 没有 fallback，导致故障时只能强行切更贵模型
• 长期在线群聊把低价值消息也送进高价模型
• 在国内网络环境下频繁因端点不稳重试

所以长期成本控制，本质上也是入口治理和任务分层。

8. 一条更稳的成本控制路径

建议按这个顺序配置：

1. 一个稳定主力模型
2. 一个更便宜或更稳的 fallback
3. 把轻量任务切到低成本模型
4. 如果确实需要，再补本地模型

9. 给中文用户的一套实用预算思路

如果你现在还没有精细计费体系，可以先按三层看：

主力预算

留给：

• 长任务
• 工具调用
• 需要稳定结果的主会话

维护预算

留给：

• 定时任务
• 状态汇总
• 轻量问答

试验预算

留给：

• 新 provider 测试
• 本地模型实验
• 新渠道灰度接入

这样比“所有流量统一走同一个模型”更容易长期维护。

10. 一条推荐的实践思路

更合理的组合通常是：

• 强模型负责主任务
• 低成本模型负责常规维护
• 国内 provider 或本地模型负责网络环境、预算或隐私约束下的补位

这样比“全部任务都上同一个模型”更接近长期可用状态。

2026 年 3 月 24 日的中文预算与 provider 观察

近期公开可访问的中文教程站和社区文章，在模型话题上有一个很明显的变化：
中文用户越来越少只问“哪个最好”，而更常一起问：

• 哪个 provider 当前更稳
• 哪个适合当长期主力
• 本地模型该不该一起接进来

这轮整理时重点参考了：

• OpenClaw 中文教程首页
• Qianfan Provider Guide

结合官方资料和中文外部资料，当前更值得长期保留的提醒有三条：

1. 中文团队更适合先定“默认 provider”，再谈模型组合

很多成本失控并不是因为模型单价太高，而是：

• 默认 provider 不稳
• 故障时没有明确 fallback
• 所有任务都被送进高价模型

所以比“先列一堆候选模型”更重要的，是先确定：

• 默认 provider 是谁
• fallback 走谁
• 低价值任务降到哪一层

2. 国内 provider 更应该按“组织条件”而不是“榜单热度”选

对中文团队来说，Moonshot、Qwen、Qianfan 这类 provider 是否适合长期使用，往往更取决于：

• 当前网络环境
• 团队已有账号与结算体系
• 是否需要统一平台审计

而不只是模型排行里的效果强弱。

3. 本地模型最适合承担预算和隐私约束下的补位角色

从近期中文教程和用户反馈看，更实际的配置通常是：

• 强模型做主力
• 国内 provider 做稳定或网络补位
• 本地模型做隐私任务、实验任务或低价值任务承接

这比“所有任务都混着走”更容易长期维护成本和排障边界。

下一步推荐

• 模型、配置和安全这三页分别什么时候看
• 国内云部署思路
• Providers 与 Fallback
• 本地模型与 Ollama