LLM & Models 大模型与配置¶

OpenClaw 平台的核心能力之一是灵活的模型管理与多 Provider 支持。本文档记录了从 Provider 配置、模型选型、Azure OpenAI 适配到多 Agent 模型协作的完整演进历程。

产品定位¶

OpenClaw 的模型系统不仅是单一 LLM 接口，而是一个多模型编排平台：

多 Provider 支持：GitHub Copilot、Azure OpenAI、MiniMax、本地模型等
Per-Agent 模型配置：不同 Agent 可使用不同模型，匹配各自角色定位
动态切换：会话级别模型切换，支持 fallback 策略
成本分层：小模型做粗筛，大模型做精处理

核心能力¶

1. Provider 体系¶

OpenClaw 支持多种模型 Provider，通过统一接口管理：

Provider	典型模型	使用场景
github-copilot	claude-opus-4.6, gpt-5.4, gemini-3.1-pro	主力开发与推理
my-azure	gpt-5.4, gpt-5.2	企业级部署
minimax-portal	MiniMax-M2.5, MiniMax-M2.1	中文场景优化
本地模型	ollama 系列	私有化部署

2. 模型选型原则¶

基于实践总结的选型经验：

claude-opus-4.6：总协调/PM 角色，长上下文与复杂推理
gpt-5.4：架构设计、深度审查、代码生成
claude-opus-4.5：数据分析、文档理解
gemini-3.1-pro-preview：前端/多模态、UI 交互
gpt-5.2 / gpt-4o：文档整理、低成本任务

3. 多 Agent 模型配置¶

典型的多 Agent 模型分配：

{
  "agents": {
    "defaults": {
      "model": { "primary": "github-copilot/claude-opus-4.6" }
    },
    "list": [
      { "id": "prism-arch", "model": "github-copilot/gpt-5.4" },
      { "id": "prism-data", "model": "github-copilot/claude-opus-4.5" },
      { "id": "prism-ui", "model": "github-copilot/gemini-3.1-pro-preview" },
      { "id": "prism-docs", "model": "github-copilot/gpt-5.2" }
    ]
  }
}

4. Fallback 与容错¶

模型调用支持多级 fallback：

{
  "model": {
    "primary": "github-copilot/claude-opus-4.6",
    "fallbacks": ["github-copilot/gpt-5.4", "my-azure/gpt-5.2"]
  }
}

项目时间线¶

时间段	阶段	关键成果
03-10	Azure 接入	[[03-10-provider-config]] Codex 验证可用，Azure OpenAI SDK 适配方向确认
03-11	MiniMax 测试	[[03-11-minimax-testing]] MiniMax-M2.5 测试，VL-01 多模态模型发现
03-12	多模型辩论	ClawCraft 项目中 GPT-5.4 vs Gemini 多轮架构辩论
03-13	Codex Azure 适配	[[03-13-azure-sdk-adaptation]] Codex 完成 Azure provider 配置
03-15	多 Agent 配置	Hackathon 5 Agent 独立模型与 workspace 配置
03-20	流式输出	Clawline 流式 streaming 链路打通
03-21	模型协作	自动剪辑项目中 GPT-5.4 + 4o 分层协作方案
03-27	本地 TTS	Qwen3-TTS 本地服务化，语音生成能力落地

关键技术决策¶

Azure OpenAI vs 标准 OpenAI¶

决策：采用 Azure OpenAI 作为主要企业级 Provider
原因： - 企业级 SLA 与合规性 - 区域部署（如 Sweden Central） - 与 Azure DevOps 生态集成

适配要点： - Python SDK 从 OpenAI 切换为 AzureOpenAI - 环境变量：AZURE_OPENAI_API_KEY, AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_API_VERSION - model 参数实际传递的是 deployment name

多模型协作策略¶

决策：按任务复杂度分层使用模型
实践： - 5.4 负责高价值创意决策：选片、叙事、架构设计 - 4o/4.1 负责低风险结构化任务：整理候选、格式化输出、执行型工作 - Watchdog 用便宜模型巡检，复杂问题升级给主模型

模型可用性验证¶

经验：模型名可见 ≠ 实际可用

常见问题： - Provider 列表显示模型，但实际调用返回 model_not_found - 会话切换后模型状态不一致 - Token/OAuth 配置影响模型访问

解决方案： - 启动前校验模型注册状态 - 配置完整的 fallback 链 - 端到端验证而非仅配置检查

架构演进¶

第一阶段：单模型单 Provider¶

最初使用单一 Provider（如 GitHub Copilot），所有 Agent 共用同一模型。

第二阶段：Per-Agent 模型配置¶

引入多 Agent 支持后，每个 Agent 可配置独立模型，实现角色与能力匹配。

第三阶段：多模型分层协作¶

形成"小模型粗筛 + 大模型精处理"的分层架构，优化成本与效果平衡。

第四阶段：本地模型集成¶

通过 Ollama、Qwen3-TTS 等本地模型，补充语音、视觉等特殊能力。

关键经验¶

Provider 配置¶

环境变量分层：~/.bashrc 不够，需补到 systemd/profile 层
Provider 路由：显式配置 provider，不依赖自动推断
版本管理：Azure 必须显式指定 api_version

模型使用¶

先验证再使用：切换模型后做端到端测试
提示词质量：多 Agent 失败往往是提示词不够约束
上下文隔离：不同 Agent 使用独立 workspace，避免记忆污染

成本控制¶

分层处理：routine 任务用便宜模型
批量优化：减少 API 调用频次
缓存利用：相似查询复用结果

子页面¶

[[03-10-provider-config]] - Provider 配置与环境变量管理
[[03-13-azure-sdk-adaptation]] - Azure OpenAI SDK 适配详解
[[03-11-model-testing]] - 模型测试与选型实践
[[03-21-multi-model-collaboration]] - 多模型协作架构

下一步发展¶

模型监控：建立模型调用成本与性能监控
自动选型：基于任务特征自动选择最优模型
本地模型扩展：更多特殊能力模型（ASR、Vision）本地化
Provider 健康检查：自动检测 Provider 可用性并切换

OpenClaw 的模型系统从单一 LLM 接口演进为完整的多模型编排平台。核心经验是：模型能力只是基础，真正的价值在于按角色、按任务、按成本的精细化配置与协作。