🧠 第3章：OpenClaw 大模型配置

3.1 这一章决定了 OpenClaw 能不能真正跑起来

很多人装好 OpenClaw 之后，第一反应是：“怎么还不能用？”原因往往不是安装失败，而是模型没有配好。

必须先把一个认知说透：

这就意味着，模型配置不是一个“技术小步骤”，而是整个系统能不能落地的基础工程。模型选错了，会出现三类问题：

• 效果差：明明是自动化系统，却经常答非所问；
• 成本高：几天就把 API 预算打爆；
• 不稳定：一到高峰期就报错，老板和员工很快失去信心。

3.2 先讲清楚：大模型在 OpenClaw 里扮演什么角色

如果用企业最容易理解的话来说：

换句话说：

3.3 企业应用最关心的问题：到底该选什么模型

很多人一开始会陷入“参数崇拜”：哪个模型最贵、最新、最强，就想先上哪个。企业实践里，这种思路通常会出问题，因为企业真正需要的不是“单点最强”，而是：

• 能稳定跑；
• 成本可控；
• 中文效果好；
• 适合自己业务场景。

3.3.1 一个最实用的选型思路

3.4 三种最常见的模型接入方式

从企业实践来看，OpenClaw 大模型配置通常有三种路线：

路线 1：直接接 API（最快）

适合：想先跑起来的人，或老板要先看结果的试点团队。

• 优点：快、配置简单、效果通常比较稳定；
• 不足：长期成本可能偏高，敏感数据要审慎。

路线 2：接国内模型平台（更适合中国企业）

适合：需要中文、希望成本更友好、对国内网络环境更适配的团队。

• 优点：中文表现通常不错，费用更容易控制；
• 不足：部分高复杂任务表现可能略弱于顶级国际模型。

路线 3：接本地模型（最适合强隐私场景）

适合：医疗、法律、政府、财务等对数据外发非常敏感的组织。

• 优点：数据可不出本地；
• 不足：对硬件要求高，模型能力与运维复杂度都要自己承担。

3.5 最简单的配置方式：单模型配置

如果你是刚开始试点，最稳的办法不是一上来做复杂路由，而是先把一个模型配通。

3.5.1 单模型配置思路

OpenClaw
   ↓
一个主模型
   ↓
所有任务先都走它

这种方式优点很明显：

• 容易排查问题；
• 方便做第一轮培训；
• 员工学习门槛低。

3.5.2 示例：一个最小可用配置

{
  "env": {
    "OPENAI_API_KEY": "你的_API_KEY"
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai/gpt-4o"
      }
    }
  }
}

这段配置的意思很简单：

• 把 API Key 放到环境变量；
• 把 openai/gpt-4o 设置成默认主模型；
• 之后所有默认任务都走这个模型。

3.6 企业更推荐的方式：双模型或多模型配置

企业一旦开始长期使用，就不应该所有任务都走同一个高价模型。原因很简单：

• 简单任务不值得用最贵模型；
• 复杂任务又不能用太弱模型；
• 全部堆到一个模型上，成本和风险都太高。

3.6.1 双模型配置：最推荐的企业起步方案

最常见也最实用的方式是：

• 主力模型：负责复杂任务、正式输出；
• 轻量模型：负责简单问答、摘要、格式化任务。

3.6.2 示例配置

llm:
  primary:
    provider: anthropic
    model: claude-sonnet-4-6
    apiKey: ${ANTHROPIC_API_KEY}
  secondary:
    provider: openai
    model: gpt-4o-mini
    apiKey: ${OPENAI_API_KEY}

routing:
  simple_patterns:
    - "总结"
    - "翻译"
    - "格式化"
  simple_model: secondary
  default_model: primary

如果用更通俗的话解释，就是：

• 小任务：让便宜模型做；
• 大任务：让强模型做。

3.7 企业必须会的能力：Fallback（故障切换）

如果模型配置只做一层，一旦主模型限流、报错、宕机，整个 OpenClaw 就会“瘫掉”。所以企业环境必须考虑备用模型。

3.7.1 什么叫 Fallback

你可以把它理解成：主力模型不行时，系统自动换备用模型继续跑。

3.7.2 示例配置

{
  "llm": {
    "fallbackChain": [
      {
        "provider": "anthropic",
        "model": "claude-sonnet-4-6",
        "apiKey": "${ANTHROPIC_API_KEY}",
        "priority": 1,
        "conditions": "default"
      },
      {
        "provider": "openai",
        "model": "gpt-4o",
        "apiKey": "${OPENAI_API_KEY}",
        "priority": 2,
        "conditions": "on_error|on_rate_limit"
      },
      {
        "provider": "google",
        "model": "gemini-1.5-pro",
        "apiKey": "${GOOGLE_API_KEY}",
        "priority": 3,
        "conditions": "on_error|on_rate_limit"
      }
    ]
  }
}

企业价值非常直接：

• 不中断业务；
• 减少员工“今天怎么又不能用了”的抱怨；
• 提高系统可信度。

3.8 本地模型：不是“免费就最好”，而是“适合特定场景”

很多老板一听“本地模型不花 API 钱”，就很兴奋。但企业决策不能只看调用费用，还要看：

• 显卡成本；
• 部署和维护成本；
• 模型效果是否够用；
• 是否真的有数据合规要求。

3.8.1 什么时候适合本地模型

• 内部敏感资料很多，不适合外发；
• 企业已经有 GPU 服务器；
• 场景偏固定、要求可控；
• 不追求最顶级文本质量，但追求稳和私有化。

3.8.2 Ollama 方式示例

curl -fsSL https://ollama.ai/install.sh | sh
ollama pull llama3.3:70b

{
  "llm": {
    "provider": "ollama",
    "model": "llama3.3:70b",
    "baseUrl": "http://localhost:11434",
    "maxTokens": 4096
  }
}

3.9 企业选择大模型的分工思路

企业在模型配置里最容易犯的错误，就是把重点放在“选哪个最强”，而不是“不同任务应该由谁来做”。

推荐分工思路

3.10 大模型的成本控制

很多 OpenClaw 项目不是死于技术，而是死于账单。企业真正需要的不是“效果最好”，而是“效果够用 + 费用可控”。

3.10.1 三种最实用的控成本办法

1. 任务分级：简单任务不用贵模型；
2. 预算封顶：设置日预算和月预算；
3. 把高频任务模板化：减少无效上下文和重复调用。

3.10.2 预算配置示例

{
  "agents": {
    "defaults": {
      "budget": {
        "maxTokensPerDay": 500000,
        "maxCostPerDay": 5.0
      }
    }
  }
}

这段配置的意义是：即使系统被频繁调用，也不会无限烧钱。

3.10.3 企业应用大模型的成本策略

3.11 企业最常见的模型配置错误

错误 1：一上来就全公司统一用最贵模型

后果：试点阶段就把预算烧光，老板很快失去兴趣。

错误 2：只看便宜，不看任务成功率

后果：员工天天抱怨“这个系统不靠谱”。

错误 3：没有备用模型

后果：高峰期一限流，全系统停摆。

错误 4：不设预算

后果：几天收到一张意想不到的 API 账单。

错误 5：把敏感数据直接发给外部模型

后果：有合规和隐私风险，尤其在法律、医疗、财务类业务里。

3.12 一个适合企业试点的推荐方案

如果你现在就要给企业上一个“先跑起来、再逐步优化”的模型配置方案，我建议这么做：

第一阶段：单模型试点

• 选一个稳定模型；
• 接通一个渠道；
• 只跑日报、会议纪要、客服 FAQ 这种高频简单任务。

第二阶段：双模型分工

• 主模型处理复杂任务；
• 轻模型处理摘要、格式化、普通问答。

第三阶段：加入 Fallback 和预算控制

• 防止故障；
• 防止超预算；
• 为规模化做准备。

3.14 本章结论