第五部分：多智能体与高级路由

单个智能体已经很强大，但 OpenClaw 的真正差异化能力在于：你可以在同一个网关中运行多个完全隔离的智能体，通过确定性路由规则将不同渠道、不同用户、不同群组的消息分发给不同的智能体处理。本部分深入讲解多智能体架构、路由机制和智能体间通信。

第 16 章：多智能体架构

16.1 核心理念："每个智能体是一个完全隔离的大脑"

OpenClaw 的多智能体设计不是简单的"多个对话窗口"——每个智能体都是一个完全独立的运行实例，拥有自己的：

组件	独立性	说明
工作区	独立目录	各自的文件、人格定义、技能
认证凭据	独立存储	各自的 API Key / OAuth Token
会话存储	独立文件	各自的对话历史
模型配置	独立选择	可以使用不同模型
沙箱策略	独立配置	不同隔离级别
工具权限	独立策略	不同工具集

关键安全原则：认证凭据不在智能体之间共享。永远不要跨智能体复用 agentDir。如果确实需要共享凭据，手动复制 auth-profiles.json 文件。

16.2 智能体文件结构

每个智能体的运行时数据组织如下：

~/.openclaw/
├── agents/
│   ├── main/                          # 主智能体
│   │   ├── agent/
│   │   │   ├── auth-profiles.json     # 认证凭据
│   │   │   └── auth.json              # 运行时缓存
│   │   └── sessions/
│   │       ├── sessions.json          # 会话索引
│   │       ├── main.jsonl             # 主会话记录
│   │       └── ...
│   ├── work-bot/                      # 工作机器人
│   │   ├── agent/
│   │   │   └── auth-profiles.json
│   │   └── sessions/
│   │       └── ...
│   └── family-bot/                    # 家庭机器人
│       ├── agent/
│       │   └── auth-profiles.json
│       └── sessions/
│           └── ...
├── workspace/                         # 主智能体工作区
├── workspace-work/                    # 工作机器人工作区
└── workspace-family/                  # 家庭机器人工作区

16.3 定义多智能体

在 ~/.openclaw/openclaw.json 中通过 agents.list 定义多个智能体：

json5

{
  agents: {
    // 所有智能体的默认配置
    defaults: {
      model: {
        primary: "anthropic/claude-sonnet-4-5-20250929"
      }
    },

    // 智能体列表
    list: [
      {
        id: "personal",
        workspace: "~/.openclaw/workspace",
        model: {
          primary: "anthropic/claude-opus-4-6"  // 覆盖默认模型
        },
        tools: {
          profile: "full"                        // 完整工具权限
        }
      },
      {
        id: "work-bot",
        workspace: "~/.openclaw/workspace-work",
        model: {
          primary: "openai/gpt-5.1-codex"
        },
        tools: {
          profile: "coding",
          deny: ["message"]                      // 禁止跨渠道消息
        },
        sandbox: {
          mode: "all",
          workspaceAccess: "ro"                   // 只读工作区
        }
      },
      {
        id: "family-bot",
        workspace: "~/.openclaw/workspace-family",
        model: {
          primary: "minimax/MiniMax-M2.1"         // 使用低成本模型
        },
        tools: {
          profile: "messaging"                     // 仅消息工具
        }
      }
    ]
  }
}

16.4 每智能体独立配置详解

模型配置

每个智能体可以使用不同的模型，包括主模型和故障转移链：

json5

{
  id: "researcher",
  model: {
    primary: "anthropic/claude-opus-4-6",         // 最强模型
    fallbacks: ["openai/gpt-5.1-codex"]           // 后备
  }
}

工具策略

不同智能体拥有不同的工具权限——这是实现安全隔离的核心：

json5

// 个人助手：全部权限
{
  id: "personal",
  tools: { profile: "full" }
}

// 工作机器人：编码 + 自定义限制
{
  id: "work-bot",
  tools: {
    profile: "coding",
    allow: ["group:fs", "group:runtime", "web_search"],
    deny: ["message", "browser"]
  }
}

// 公开机器人：最小权限
{
  id: "public-bot",
  tools: {
    profile: "minimal",
    deny: ["exec", "group:fs"]  // 禁止执行和文件操作
  }
}

沙箱策略

每个智能体可以拥有独立的沙箱配置：

json5

{
  id: "untrusted-bot",
  sandbox: {
    mode: "all",                    // 所有会话都沙箱化
    scope: "session",               // 每会话隔离
    workspaceAccess: "none",        // 无工作区访问
    tools: {
      deny: ["browser", "canvas"]   // 沙箱内额外限制
    }
  }
}

提权配置

json5

{
  id: "ops-bot",
  tools: {
    elevated: {
      enabled: true,
      allowFrom: {
        telegram: ["admin-user-id"]  // 仅特定管理员可提权
      }
    }
  }
}

16.5 智能体管理 CLI

bash

# 添加新智能体
openclaw agents add researcher

# 列出所有智能体及其绑定关系
openclaw agents list --bindings

# 查看特定智能体状态
openclaw agent --agent work-bot status

16.6 多网关部署

大多数情况下，单个网关足以处理多个智能体。但如果确实需要运行多个网关实例（例如主网关 + 救援机器人），需要确保完全隔离：

隔离项	说明
配置文件	通过 `OPENCLAW_CONFIG_PATH` 或 `--profile` 区分
状态目录	通过 `OPENCLAW_STATE_DIR` 区分
工作区	不同的 `agents.defaults.workspace`
端口	基础端口至少间隔 20（衍生端口：浏览器 +2，Canvas +4，CDP +9~+108）

推荐方式：使用 Profile

bash

# 主网关
openclaw --profile main gateway --port 18789

# 救援网关
openclaw --profile rescue gateway --port 19001

# 检查各实例状态
openclaw --profile main status
openclaw --profile rescue status

Profile 会自动管理状态目录和配置路径，避免手动隔离的复杂性。

第 17 章：消息路由规则

路由是多智能体系统的"交通指挥官"——决定每条入站消息由哪个智能体处理、回复发送到哪里。

17.1 核心路由原则

OpenClaw 的路由是确定性的：回复始终发回消息来源的渠道。模型无法选择回复目标——宿主配置决定一切。

入站消息 → 渠道识别 → 绑定匹配 → 智能体选择 → 会话路由 → 处理 → 回复到来源渠道

17.2 会话键（Session Key）架构

每条消息都被路由到一个特定的会话，会话键按以下规则生成：

消息类型	会话键格式	示例
私聊	`agent:<agentId>:<mainKey>`	`agent:personal:main`
群组	`agent:<agentId>:<channel>:group:<id>`	`agent:work-bot:whatsapp:group:120363...@g.us`
频道	`agent:<agentId>:<channel>:channel:<id>`	`agent:personal:discord:channel:123456`
Slack 线程	`...：thread:<threadId>`	`agent:work-bot:slack:channel:C01:thread:ts123`
Telegram 论坛	`...:topic:<topicId>`	`agent:personal:telegram:group:123:topic:456`
定时任务	`cron:<jobId>`	`cron:daily-report`
Webhook	`hook:<uuid>`	`hook:abc-123`
节点	`node-<nodeId>`	`node-iphone-01`

特殊值："global" 自动映射为 "main"，"unknown" 保留用于无法确定来源的消息。

17.3 智能体选择层级

当一条消息到达时，OpenClaw 按以下优先级依次匹配，第一个匹配即胜出：

优先级从高到低：

1. Peer 匹配         ← 最具体：精确匹配对方的 ID（私聊/群组/频道）
2. Guild 匹配        ← Discord 特有：按服务器 ID 匹配
3. Team 匹配         ← Slack 特有：按工作区 ID 匹配
4. Account 匹配      ← 按账号 ID 匹配（多账号场景）
5. Channel 匹配      ← 按渠道匹配（任意账号）
6. 默认智能体        ← 兜底：配置中的默认智能体

黄金规则："Peer bindings always win"——Peer 绑定永远优先，务必将它们放在配置的最上面。

17.4 绑定（Bindings）配置

绑定是路由规则的核心配置单元，定义了"什么条件的消息交给哪个智能体"：

json5

{
  agents: {
    list: [
      { id: "personal" },
      { id: "work-bot" },
      { id: "family-bot" }
    ]
  },

  bindings: [
    // 规则 1：特定 WhatsApp 群组 → work-bot
    {
      channel: "whatsapp",
      peer: "120363403215116621@g.us",  // 群组 JID
      agent: "work-bot"
    },

    // 规则 2：特定 Telegram 用户 → family-bot
    {
      channel: "telegram",
      peer: "987654321",               // Telegram 用户 ID
      agent: "family-bot"
    },

    // 规则 3：所有 Discord 消息 → work-bot
    {
      channel: "discord",
      agent: "work-bot"
    },

    // 规则 4：特定 WhatsApp 账号的所有消息 → personal
    {
      channel: "whatsapp",
      accountId: "my-phone-account",
      agent: "personal"
    }

    // 未匹配的消息 → 默认智能体（agents.list 的第一个）
  ]
}

17.5 实战路由场景

场景一：同一 WhatsApp 号码，不同联系人路由到不同智能体

你用同一个手机号同时服务个人和工作场景：

json5

{
  bindings: [
    // 老板的私聊 → 工作智能体
    { channel: "whatsapp", peer: "+8613900001111", agent: "work-bot" },

    // 家人群组 → 家庭智能体
    { channel: "whatsapp", peer: "120363...@g.us", agent: "family-bot" },

    // 其他 WhatsApp 消息 → 个人智能体
    { channel: "whatsapp", agent: "personal" }
  ]
}

场景二：不同渠道使用不同模型

WhatsApp 用低成本快速模型保持响应速度，Telegram 用强模型处理复杂任务：

json5

{
  agents: {
    list: [
      {
        id: "fast-agent",
        model: { primary: "minimax/MiniMax-M2.1" }
      },
      {
        id: "power-agent",
        model: { primary: "anthropic/claude-opus-4-6" }
      }
    ]
  },
  bindings: [
    { channel: "whatsapp", agent: "fast-agent" },
    { channel: "telegram", agent: "power-agent" }
  ]
}

场景三：特定群组绑定专属智能体 + 提及门控

技术讨论群使用专属的编码智能体，必须 @ 提及才响应：

json5

{
  agents: {
    list: [
      {
        id: "code-bot",
        model: { primary: "openai/gpt-5.1-codex" },
        tools: { profile: "coding" },
        groupChat: {
          historyLimit: 50,
          mentionPatterns: ["@?codebot", "\\+?15555550123"]
        }
      }
    ]
  },
  bindings: [
    {
      channel: "whatsapp",
      peer: "120363...@g.us",            // 技术群组 JID
      agent: "code-bot"
    }
  ],
  channels: {
    whatsapp: {
      groups: {
        "120363...@g.us": {
          requireMention: true             // 必须 @ 提及才响应
        }
      }
    }
  }
}

场景四：多用户安全隔离

多个用户共享同一个机器人，但对话完全隔离：

json5

{
  session: {
    dmScope: "per-channel-peer"          // 按渠道+发送者隔离会话
  },
  channels: {
    whatsapp: {
      dmPolicy: "allowlist",             // 仅允许白名单用户
      allowFrom: [
        "+8613800001111",
        "+8613800002222",
        "+8613800003333"
      ]
    }
  }
}

17.6 多账号支持

单个 OpenClaw 网关可以管理同一平台的多个账号。通过 accountId 区分不同登录实例：

json5

{
  channels: {
    whatsapp: {
      accounts: [
        {
          id: "personal-phone",
          // WhatsApp 配对配置...
        },
        {
          id: "work-phone",
          // 另一个 WhatsApp 号码的配置...
        }
      ]
    }
  },
  bindings: [
    // 个人号的消息 → 个人智能体
    { channel: "whatsapp", accountId: "personal-phone", agent: "personal" },

    // 工作号的消息 → 工作智能体
    { channel: "whatsapp", accountId: "work-phone", agent: "work-bot" }
  ]
}

这样，一台服务器可以同时处理多个手机号/账号的消息，路由到不同的智能体，且会话不会混淆。

17.7 群组消息处理

群组消息的处理比私聊更复杂，涉及激活模式、上下文管理和成员归属。

激活模式

模式	行为	配置
Mention（默认）	必须 @ 提及才响应	`requireMention: true`
Always	每条消息都响应（不相关时返回 `NO_REPLY`）	`requireMention: false`

提及识别方式

智能体通过以下方式识别是否被提及：

WhatsApp 原生 @-mention
正则模式匹配机器人名称/号码
消息中包含机器人的 E.164 号码

json5

{
  groupChat: {
    mentionPatterns: [
      "@?小智",           // 匹配 "小智" 或 "@小智"
      "\\+?8613800138000"  // 匹配手机号
    ]
  }
}

群组上下文注入

智能体收到群组消息时，会获得最近的待处理消息作为上下文（默认上限 50 条）：

[Chat messages since your last reply - for context]
[from: Alice (+8613800001111)] 大家觉得这个方案怎么样？
[from: Bob (+8613800002222)] 我觉得可以，但有几个细节需要讨论
[Current message - respond to this]
[from: Charlie (+8613800003333)] @小智 帮我分析一下这个方案的优缺点

每条消息末尾附带 [from: 发送者名 (+号码)] 用于身份识别。

群组策略

json5

{
  channels: {
    whatsapp: {
      groups: {
        "*": {                          // 对所有群组生效
          requireMention: true,
          groupPolicy: "allowlist"       // open | disabled | allowlist
        },
        "120363...@g.us": {             // 对特定群组覆盖
          requireMention: false          // 这个群不需要 @ 提及
        }
      }
    }
  }
}

会话隔离

每个群组维护独立会话（agent:<agentId>:whatsapp:group:<jid>）。这意味着：

/verbose on 或 /think high 仅在该群组生效
私聊会话完全独立
心跳（Heartbeat）跳过群组线程

运行时命令（仅群主/白名单用户）

/activation mention    # 切换到提及模式
/activation always     # 切换到始终响应模式
/status                # 查看当前激活设置

17.8 广播组（Broadcast Groups）

广播组是一个实验性功能——让多个智能体同时处理同一条消息。

典型场景

场景	说明
专业团队	代码审查、文档、安全审计、测试各由不同智能体处理
多语言支持	同一消息同时路由到中文、英文、日文智能体
质量保证	主智能体回复的同时，QA 智能体并行检查
任务自动化	任务追踪、时间记录、报告生成协同执行

配置

json5

{
  broadcast: {
    // WhatsApp 群组 → 多个智能体并行处理
    "120363403215116621@g.us": ["code-reviewer", "doc-writer", "security-auditor"],

    // 特定私聊 → 多个智能体并行处理
    "+15551234567": ["assistant", "task-tracker"]
  }
}

处理策略

策略	行为
Parallel（默认）	所有智能体同时运行
Sequential	按数组顺序依次执行

隔离保证

广播组中的每个智能体完全独立：

各自的会话键和对话历史
各自的工作区环境
各自的工具权限和沙箱
各自的记忆文件
智能体之间看不到彼此的回复

唯一共享的是群组上下文缓冲区——最近的消息对所有广播智能体可见。

路由优先级

广播组评估发生在渠道白名单和群组激活规则之后，且优先于标准绑定路由。它只影响"哪些智能体运行"，不影响"何时运行"。

当前限制

目前仅支持 WhatsApp
建议智能体数量不超过 5-10 个
并行响应到达顺序不确定
所有智能体共享 WhatsApp 速率限制
Telegram、Discord、Slack 计划在未来版本支持

17.9 配对（Pairing）：渠道访问控制

配对是 OpenClaw 的渠道级安全门——控制谁可以和你的机器人聊天。

DM 配对流程

当渠道使用 dmPolicy: "pairing" 时：

未知用户发消息 → 机器人返回 8 位配对码 → 你审批 → 用户获得访问权

配对码规格：

8 位大写字母
排除易混淆字符（0/O、1/I）
1 小时后过期
每渠道最多 3 个待处理请求

管理命令

bash

# 查看待审批请求
openclaw pairing list telegram
openclaw pairing list whatsapp

# 审批
openclaw pairing approve telegram ABCDEFGH

# 支持的渠道
# Telegram, WhatsApp, Signal, iMessage, Discord, Slack

凭据存储

~/.openclaw/credentials/
├── telegram-pairing.json       # 待处理请求
├── telegram-allowFrom.json     # 已审批联系人
├── whatsapp-pairing.json
├── whatsapp-allowFrom.json
└── ...

这些文件控制机器人的访问权限，应视为敏感文件。

设备节点配对

iOS/Android/macOS 设备使用独立的配对机制：

bash

openclaw devices list              # 查看设备
openclaw devices approve <id>      # 审批设备
openclaw devices reject <id>       # 拒绝设备

设备配对状态存储在 ~/.openclaw/devices/pending.json 和 paired.json。

第 18 章：子智能体与智能体间通信

OpenClaw 不仅支持多个独立智能体，还支持智能体之间的协作通信——主智能体可以派遣子智能体执行后台任务，不同智能体之间可以互相发送消息。

18.1 子智能体（Sub-Agents）

子智能体让主智能体能够在不阻塞当前对话的情况下启动后台任务。

核心概念

主智能体对话中...
    ↓
用户："帮我调研竞品 A、B、C 的定价策略"
    ↓
主智能体调用 sessions_spawn → 立即返回（不等待）
    ↓
"已启动后台调研，我可以继续回答其他问题。"
    ↓
子智能体在隔离会话中独立运行...
    ↓
完成后自动将结果发送回主对话

生命周期四阶段

1. 派遣阶段（Spawn）

主智能体调用 sessions_spawn，立即收到：

json

{ "status": "accepted", "runId": "xxx", "childSessionKey": "agent:main:subagent:uuid" }

无需等待——主对话可以继续。

2. 隔离执行

子智能体在独立会话 agent:<agentId>:subagent:<uuid> 中运行，使用专用的 subagent 队列通道（默认 8 并发），不占用主流量。

3. 结果通报

任务完成后，子智能体自动将结果以自然语言摘要形式发回请求者的聊天，包含：

最终回复内容
运行状态（ok / error / timeout / unknown）
运行时长
Token 用量和估算成本
会话标识符和记录位置

通报保留线程路由（Slack 线程、Telegram 话题、Matrix 线程）。

4. 自动归档

60 分钟后（可配置），子会话自动归档，记录保存为 *.deleted.<timestamp> 格式。

sessions_spawn 参数

参数	类型	说明
`task`	string	必填，任务描述
`label`	string	可选，人类可读标识
`agentId`	string	覆盖目标智能体（需授权）
`model`	string	覆盖模型
`thinking`	string	覆盖思考级别
`runTimeoutSeconds`	number	超时后中止
`cleanup`	`"delete"` / `"keep"`	通报后是否归档

模型解析优先级

1. 显式 model 参数
2. 每智能体子智能体配置
3. 全局子智能体默认配置
4. 目标智能体的常规模型选择

成本优化

为后台任务使用更便宜的模型：

json5

{
  agents: {
    defaults: {
      subagents: {
        model: "minimax/MiniMax-M2.1",   // 低成本后台模型
        thinking: "low",                  // 减少思考开销
        maxConcurrent: 8                  // 最大并发数
      }
    }
  }
}

每智能体也可以单独覆盖子智能体配置。

子智能体工具策略

子智能体获得完整工具权限，但默认拒绝以下工具：

被拒绝的工具	原因
`sessions_list` / `sessions_history` / `sessions_send`	防止会话横向访问
`sessions_spawn`	防止嵌套派遣
`gateway` / `agents_list`	防止系统级操作
`memory_search` / `memory_get`	防止记忆泄露
`cron` / `session_status`	防止系统状态操纵
`whatsapp_login`	防止认证操作

可通过配置自定义子智能体的工具限制，不影响主智能体。

跨智能体派遣

默认情况下，子智能体只能在自身智能体下派遣。启用跨智能体派遣：

json5

{
  agents: {
    list: [
      {
        id: "coordinator",
        subagents: {
          allowAgents: ["researcher", "coder", "writer"]  // 允许派遣到这些智能体
          // 使用 ["*"] 允许派遣到任何智能体
        }
      }
    ]
  }
}

子智能体的认证解析：优先使用目标智能体的认证存储，主智能体的 Profile 作为后备。

子智能体系统提示

子智能体收到精简版系统提示：

包含：工具描述、工作区配置
不包含：人格/身份部分（SOUL.md、IDENTITY.md）
仅注入 AGENTS.md 和 TOOLS.md

管理命令

在聊天中使用 /subagents 命令管理：

命令	说明
`/subagents list`	查看所有子智能体及状态
`/subagents stop <id\|#\|all>`	终止特定或全部子智能体
`/subagents log <id\|#> [limit] [tools]`	查看子智能体记录
`/subagents info <id\|#>`	查看详细元数据
`/subagents send <id\|#> <message>`	向运行中的子智能体发送消息

支持按索引号、运行 ID 前缀、会话键或 "last" 引用子智能体。

终止行为

操作	效果
聊天中 `/stop`	中止主会话和所有派遣的子智能体
`/subagents stop <id>`	仅终止特定子智能体
`runTimeoutSeconds`	超时后自动中止（不触发自动归档）

关键限制

不支持嵌套派遣：子智能体不能再派遣子智能体
通报是尽力而为：网关重启时，待通报的结果会丢失
归档计时器重启丢失：网关重启后，自动归档计时器不会恢复
共享网关资源：通过 maxConcurrent 管理并发

18.2 会话工具套件

除了子智能体，OpenClaw 还提供一套会话管理工具用于智能体间通信：

sessions_list：列出会话

枚举所有会话的 JSON 数据，支持过滤：

过滤条件	说明
`kind`	`main` / `group` / `cron` / `hook` / `node` / `other`
活跃窗口	按时间范围过滤
消息包含	可选包含最近消息

返回的元数据包含：渠道、显示名、Token 用量、交付上下文。

sessions_history：查看历史

获取特定会话的对话记录：

sessions_history(sessionId: "agent:work-bot:main", limit: 50, includeTools: false)

支持过滤工具消息和限制消息数量。

sessions_send：跨会话消息

向另一个会话发送消息，支持同步和异步模式：

模式	说明
同步	等待目标会话回复（最多 5 轮自动 Ping-Pong）
异步（fire-and-forget）	发送后立即返回

可选将回复交付到目标渠道。

安全限制：

发送策略强制执行基于渠道的阻止规则
沙箱化智能体默认只能看到自己派遣的会话
群主可通过 /send on|off|inherit 控制运行时覆盖

18.3 agent-send：CLI 直接触发

openclaw agent 命令可以在不经过聊天的情况下直接触发智能体运行：

bash

# 向主会话发送消息
openclaw agent --message "分析最新的日志文件" --session-id main

# 指定智能体和接收者
openclaw agent --agent work-bot --to "+8613800001111" --message "项目进度如何？"

# 使用特定模型和思考级别
openclaw agent --message "深度分析" --thinking high --model anthropic/claude-opus-4-6

# 交付结果到渠道
openclaw agent --message "生成日报" --deliver --channel telegram --reply-to "chat-id-123"

# JSON 格式输出（含元数据）
openclaw agent --message "检查状态" --json

# 本地模式（不经过网关）
openclaw agent --message "本地测试" --local

# 设置超时
openclaw agent --message "长任务" --timeout 300

会话目标选择（三选一）：

参数	行为
`--to <dest>`	从接收者推导会话键
`--session-id <id>`	复用已有会话
`--agent <id>`	使用指定智能体的主会话

回退行为：如果网关不可达，CLI 自动回退到嵌入式本地运行（需要模型 API Key）。

18.4 llm-task：轻量级 LLM 委派

llm-task 是一个可选插件，用于在工作流中执行结构化的 LLM 操作——不需要完整的智能体运行时，只需要一次快速的 JSON 输入/输出。

与子智能体的区别

	子智能体	llm-task
运行时	完整智能体（工具、技能、上下文）	裸模型调用（仅 JSON）
工具访问	有（受限制）	无
输出格式	自然语言	严格 JSON
适用场景	复杂后台任务	分类、提取、格式化
成本	较高	较低

启用

json5

{
  plugins: {
    entries: {
      "llm-task": {
        enabled: true,
        config: {
          defaultModel: "anthropic/claude-sonnet-4-5-20250929",
          maxTokens: 800,
          timeoutMs: 30000,
          allowedModels: [
            "anthropic/claude-sonnet-4-5-20250929",
            "minimax/MiniMax-M2.1"
          ]
        }
      }
    }
  }
}

工具参数

参数	类型	说明
`prompt`	string	必填，提示词
`input`	any	可选，输入数据
`schema`	JSON Schema	可选，输出验证 Schema
`provider` / `model`	string	可选，覆盖默认
`temperature`	number	可选，温度参数
`maxTokens`	number	可选，最大 Token 数
`timeoutMs`	number	可选，超时

使用示例

在 Lobster 工作流中分类邮件：

yaml

steps:
  - name: categorize
    command: llm-task
    args:
      prompt: "Categorize this email as urgent/normal/spam"
      input: "$search.json"
      schema:
        type: object
        properties:
          category:
            type: string
            enum: ["urgent", "normal", "spam"]
          reason:
            type: string
        required: ["category", "reason"]

输出在 details.json 中返回解析后的 JSON，自动按 Schema 验证。

安全建议：llm-task 的输出限制为 JSON 格式，不暴露工具给模型。但如果没有 Schema 验证，应将输出视为不可信数据。

18.5 多智能体协作模式总结

根据你的需求，选择合适的协作方式：

需求	推荐方式	说明
后台并行任务	`sessions_spawn`（子智能体）	不阻塞主对话，自动通报结果
向另一个会话发消息	`sessions_send`	同步或异步，支持 Ping-Pong
从外部触发智能体	`openclaw agent` CLI	脚本、CI/CD、自动化集成
工作流中的轻量 LLM	`llm-task` 插件	结构化 JSON，无工具开销
同一消息多智能体并行	广播组（Broadcast）	实验性，目前仅 WhatsApp
完全独立的智能体	多智能体 + 路由绑定	各自独立运行，按规则分流

18.6 多智能体调试

检查绑定关系

bash

openclaw agents list --bindings

检查沙箱容器

bash

docker ps --filter "name=openclaw-sbx-"

网关日志过滤

在网关日志中查找路由、沙箱和工具相关的条目：

bash

# 日志路径
# /tmp/openclaw/openclaw-YYYY-MM-DD.log

# 关注关键词
# routing, sandbox, tools, agent-select, binding-match

沙箱策略诊断

bash

openclaw sandbox explain

查看实际生效的执行策略，包括工具过滤层级和沙箱配置。

小结：第五部分覆盖了 OpenClaw 最具差异化的能力——多智能体并行运行与确定性路由。你学会了如何定义多个隔离智能体、配置路由绑定规则、处理群组消息、使用广播组、管理配对安全，以及通过子智能体和会话工具实现智能体间协作。下一部分将深入安全模型与沙箱化，帮助你为生产环境做好防护。

第五部分：多智能体与高级路由 ​

第 16 章：多智能体架构 ​

16.1 核心理念："每个智能体是一个完全隔离的大脑" ​

16.2 智能体文件结构 ​

16.3 定义多智能体 ​

16.4 每智能体独立配置详解 ​

模型配置 ​

工具策略 ​

沙箱策略 ​

提权配置 ​

16.5 智能体管理 CLI ​

16.6 多网关部署 ​

第 17 章：消息路由规则 ​

17.1 核心路由原则 ​

17.2 会话键（Session Key）架构 ​

17.3 智能体选择层级 ​

17.4 绑定（Bindings）配置 ​

17.5 实战路由场景 ​

场景一：同一 WhatsApp 号码，不同联系人路由到不同智能体 ​

场景二：不同渠道使用不同模型 ​

场景三：特定群组绑定专属智能体 + 提及门控 ​

场景四：多用户安全隔离 ​

17.6 多账号支持 ​

17.7 群组消息处理 ​

激活模式 ​

提及识别方式 ​

群组上下文注入 ​

群组策略 ​

会话隔离 ​

运行时命令（仅群主/白名单用户） ​

17.8 广播组（Broadcast Groups） ​

典型场景 ​

配置 ​

处理策略 ​

隔离保证 ​

路由优先级 ​

当前限制 ​

17.9 配对（Pairing）：渠道访问控制 ​

DM 配对流程 ​

管理命令 ​

凭据存储 ​

设备节点配对 ​

第 18 章：子智能体与智能体间通信 ​

18.1 子智能体（Sub-Agents） ​

核心概念 ​

生命周期四阶段 ​

sessions_spawn 参数 ​

模型解析优先级 ​

成本优化 ​

子智能体工具策略 ​

跨智能体派遣 ​

子智能体系统提示 ​

管理命令 ​

终止行为 ​

关键限制 ​

18.2 会话工具套件 ​

sessions_list：列出会话 ​

sessions_history：查看历史 ​

sessions_send：跨会话消息 ​

18.3 agent-send：CLI 直接触发 ​

18.4 llm-task：轻量级 LLM 委派 ​

与子智能体的区别 ​

启用 ​

工具参数 ​

使用示例 ​

18.5 多智能体协作模式总结 ​

18.6 多智能体调试 ​

检查绑定关系 ​

检查沙箱容器 ​

网关日志过滤 ​

沙箱策略诊断 ​

第五部分：多智能体与高级路由

第 16 章：多智能体架构

16.1 核心理念："每个智能体是一个完全隔离的大脑"

16.2 智能体文件结构

16.3 定义多智能体

16.4 每智能体独立配置详解

模型配置

工具策略

沙箱策略

提权配置

16.5 智能体管理 CLI

16.6 多网关部署

第 17 章：消息路由规则

17.1 核心路由原则

17.2 会话键（Session Key）架构

17.3 智能体选择层级

17.4 绑定（Bindings）配置

17.5 实战路由场景

场景一：同一 WhatsApp 号码，不同联系人路由到不同智能体

场景二：不同渠道使用不同模型

场景三：特定群组绑定专属智能体 + 提及门控

场景四：多用户安全隔离

17.6 多账号支持

17.7 群组消息处理

激活模式

提及识别方式

群组上下文注入

群组策略

会话隔离

运行时命令（仅群主/白名单用户）

17.8 广播组（Broadcast Groups）

典型场景

配置

处理策略

隔离保证

路由优先级

当前限制

17.9 配对（Pairing）：渠道访问控制

DM 配对流程

管理命令

凭据存储

设备节点配对

第 18 章：子智能体与智能体间通信

18.1 子智能体（Sub-Agents）

核心概念

生命周期四阶段

sessions_spawn 参数

模型解析优先级

成本优化

子智能体工具策略

跨智能体派遣

子智能体系统提示

管理命令

终止行为

关键限制

18.2 会话工具套件

sessions_list：列出会话

sessions_history：查看历史

sessions_send：跨会话消息

18.3 agent-send：CLI 直接触发

18.4 llm-task：轻量级 LLM 委派

与子智能体的区别

启用

工具参数

使用示例

18.5 多智能体协作模式总结

18.6 多智能体调试

检查绑定关系

检查沙箱容器

网关日志过滤

沙箱策略诊断