多模型协作架构¶

记录 OpenClaw 中多 Agent、多模型协作的架构设计与最佳实践。

核心架构¶

分层模型策略¶

┌─────────────────────────────────────────┐
│         主模型 (claude-opus-4.6)         │
│    规划、协调、异常升级、最终决策          │
└─────────────────┬───────────────────────┘
                  │
    ┌─────────────┼─────────────┐
    │             │             │
┌───▼───┐   ┌────▼────┐   ┌───▼───┐
│ 架构   │   │ 数据    │   │ UI    │
│ gpt-5.4│   │claude-4.5│   │gemini │
└───────┘   └─────────┘   └───────┘
    │             │             │
    └─────────────┼─────────────┘
                  │
┌─────────────────▼───────────────────────┐
│        Watchdog (gpt-4o/4.1)            │
│    低成本巡检、routine 任务、预筛         │
└─────────────────────────────────────────┘

角色-模型映射¶

角色	模型	职责
PM	claude-opus-4.6	总协调、规划、汇报、异常升级
架构师	gpt-5.4	架构设计、代码审查、系统推理
数据分析	claude-opus-4.5	长上下文、文档理解、数据分析
前端	gemini-3.1-pro	多模态、UI/UX、交互探索
文档	gpt-5.2	文档整理、策略编写
Watchdog	gpt-4o/4.1	低成本巡检、routine 检查

多 Agent 协作模式¶

主代理-子代理职责边界¶

核心原则（Dad 决策 2026-03-03）：

主代理是全局规划者，不直接下场执行细节；具体查询/操作交给子代理

职责划分： - 主代理：规划、汇报、异常处理 - 子代理：具体执行、数据查询、操作落地

最佳实践：脚本化任务¶

问题：复杂任务中子代理超时或只完成部分步骤

根因：不是模型太弱，而是任务结构错误

正确模式：

Manager plans, script encodes, subagent executes.

主代理分析需求，设计执行方案
主代理编写执行脚本
子代理按脚本执行，返回结果
主代理汇总结果，决定后续

好处： - 减少上下文长度 - 降低歧义 - 提高可重复性

Workspace 隔离¶

问题：多 Agent 共用工作区，记忆/文件/任务互相污染

解决方案（Dad 决策）：每个 Agent 独立 workspace

{
  "agents": {
    "list": [
      {
        "id": "prism-arch",
        "workspace": "~/.openclaw/workspace-prism-arch",
        "agentDir": "agents/prism-arch",
        "model": "github-copilot/gpt-5.4"
      },
      {
        "id": "prism-pm",
        "workspace": "~/.openclaw/workspace",
        "agentDir": "agents/prism-pm",
        "model": "github-copilot/claude-opus-4.6"
      }
    ]
  }
}

架构意义： - 不同模型在不同角色上下文中独立演化 - 避免 memory/context 串扰 - 便于按 Agent 定制 prompt、skills、任务队列

群聊协作与防护¶

问题：Bot 互相 @ 死循环¶

2026-03-13 Hackathon 期间，多 bot 在群聊中互相触发，形成死循环。

解决方案：

行为规则：在 SOUL.md 中写入
谨慎 @ bot
可以 @ 人类
除非人类明确要求，否则不要 @ bot

配置防护：使用 groupAllowFrom 限制触发来源

{
  "channels": {
    "mattermost": {
      "accounts": {
        "prism-arch": {
          "chatmode": "oncall",
          "groupAllowFrom": ["human-user-id-1", "human-user-id-2"]
        }
      }
    }
  }
}

触发策略差异化¶

PM Agent：群里以 pm 开头即可触发

{
  "chatmode": "onchar",
  "oncharPrefixes": ["pm"]
}

其他 Agent：仅 @mention 触发

{
  "chatmode": "oncall"
}

多模型辩论¶

ClawCraft 架构辩论案例¶

在 ClawCraft 项目中，采用多模型辩论确定架构方向：

准备阶段：先读取 OpenClaw 源码和文档，建立真实 API surface
GPT-5.4 辩论：10 轮架构讨论，侧重推理与可行性
Gemini 补充：10 轮补充审查，提供不同视角
汇总成 PRD：整合多模型意见，形成产品文档

关键经验：

RAG/源码 grounding 先于架构推理

避免让模型"凭空脑补 API"，先建立真实约束。

成本优化¶

两阶段处理流水线¶

典型应用场景：会话总结、视频挑片、主题分析

数据采集 → 小模型粗处理 → 大模型精处理 → 结果持久化 → 投递
           (gpt-4.1)       (gpt-5.4)

Watchdog 模式¶

架构：便宜模型做 routine checks，主模型处理异常升级

配置：

{
  "id": "watchdog",
  "model": "github-copilot/gpt-4o",
  "purpose": "routine-monitoring"
}

触发规则： - 定时任务触发巡检 - 发现异常时升级给主 Agent - 复杂问题转交人类

常见问题¶

问题 1：子代理提示词不够明确¶

现象：子代理执行偏离预期

根因：任务描述不够约束

解决： - 明确输入、输出、边界 - 提供示例 - 限定执行范围

问题 2：多 Agent 路由失效¶

现象：消息不能正确分发到不同 Agent

根因：缺少 bindings 配置

解决：补齐 bindings 配置

问题 3：model 字段格式错误¶

现象：Agent 没按预期使用指定模型

根因：使用了对象格式而非字符串格式

错误：

{ "model": { "primary": "github-copilot/gpt-5.4" } }

正确：

{ "model": "github-copilot/gpt-5.4" }

单 Bot 维护策略¶

背景¶

2026-03-23，在调试场景下，多子 bot 协作存在结构性问题： - 调试上下文容易丢失 - 中间转述会损失细节 - 多轮排障时责任边界不清

决策¶

以后让 WebBot 一个 bot 负责整个 Clawline 产品维护

原则： - 对 LLM 工程维护来说，统一上下文 + 单一责任 bot 比多 bot 分工更适合高频调试与跨仓库联动 - 停用职责过细的 bot（如 gatewaybot、channelbot） - 将经验沉淀为 skill，供 LLM 按需加载

知识技能化¶

将长上下文拆分为按需加载的 skill： - 减少上下文污染 - 降低 token 浪费 - 保持相关性

总结¶

多模型协作的核心要点：

分层策略：不同任务用不同级别模型
职责隔离：主代理规划，子代理执行
脚本化：复杂任务编写脚本，子代理执行脚本
防护机制：群聊触发限制，避免死循环
成本优化：小模型粗筛，大模型精处理
灵活调整：调试场景可回归单 bot 模式