Skip to main content

广播群组

状态: 实验性功能
版本: 于 2026.1.9 版本新增

概述

Broadcast Groups enable multiple agents to process and respond to the same message simultaneously. This allows you to create specialized agent teams that work together in a single WhatsApp group or DM — all using one phone number. 当前范围:仅限 WhatsApp(web 渠道)。 Broadcast groups are evaluated after channel allowlists and group activation rules. 广播群组在渠道白名单和群组激活规则之后进行评估。在 WhatsApp 群组中,这意味着广播会在 OpenClaw 正常回复时发生(例如:被提及时,具体取决于你的群组设置)。

使用场景

1. 专业智能体团队

部署多个具有原子化、专注职责的智能体:
每个智能体处理相同的消息并提供其专业视角。

2. 多语言支持

3. 质量保证工作流

4. 任务自动化

配置

基本设置

  1. 添加一个顶层 broadcast 区段(与 bindings 同级)。 19. 键为 WhatsApp 对等 ID:
  • 群聊:群组 JID(例如 [email protected]
    1. 私聊:E.164 电话号码(例如 +15551234567
结果: 当 OpenClaw 在此聊天中回复时,将运行所有三个智能体。

处理策略

控制智能体如何处理消息:

并行(默认)

所有智能体同时处理:

顺序

智能体按顺序处理(后一个等待前一个完成):

完整示例

34. 工作原理

消息流程

  1. 接收消息 到达 WhatsApp 群组
  2. 广播检查:系统检查 peer ID 是否在 broadcast
  3. 如果在广播列表中
    • 所有列出的智能体处理该消息
      1. 每个代理都有自己的会话键和隔离的上下文
    • 智能体并行处理(默认)或顺序处理
  4. 如果不在广播列表中
    • 应用正常路由(第一个匹配的绑定)
注意:广播群组不会绕过渠道白名单或群组激活规则(提及/命令等)。它们只改变消息符合处理条件时_运行哪些智能体_。 45. 它们只会改变在消息符合处理条件时 运行哪些代理

会话隔离

广播群组中的每个智能体完全独立维护:
  • 会话键agent:alfred:whatsapp:group:120363... vs agent:baerbel:whatsapp:group:120363...
  • 对话历史(智能体看不到其他智能体的消息)
  • 工作空间(如果配置了则使用独立的沙箱)
  • 工具访问权限(不同的允许/拒绝列表)
  • 记忆/上下文(独立的 IDENTITY.md、SOUL.md 等)
  • 群组上下文缓冲区(用于上下文的最近群组消息)按 peer 共享,因此所有广播智能体在被触发时看到相同的上下文
这允许每个智能体拥有:
  • 不同的个性
  • 不同的工具访问权限(例如只读 vs 读写)
  • 不同的模型(例如 opus vs sonnet)
  • 不同的已安装 Skills

示例:隔离的会话

在群组 [email protected] 中,智能体为 ["alfred", "baerbel"] Alfred 的上下文:
Bärbel 的上下文:

最佳实践

1. 保持智能体专注

将每个智能体设计为具有单一、明确的职责:
Good: Each agent has one job
Bad: One generic “dev-helper” agent

2. 使用描述性名称

Make it clear what each agent does:

3. 配置不同的工具访问权限

只给智能体提供它们需要的工具:

4. 监控性能

With many agents, consider:
  • 使用 "strategy": "parallel"(默认)以提高速度
  • 将广播群组限制在 5-10 个智能体
  • 为较简单的智能体使用较快的模型

5. 优雅地处理失败

Agents fail independently. One agent’s error doesn’t block others:

兼容性

提供商

广播群组目前支持:
  • ✅ WhatsApp(已实现)
  • 🚧 Telegram(计划中)
  • 🚧 Discord(计划中)
  • 🚧 Slack(计划中)

路由

广播群组与现有路由一起工作:
  • GROUP_A:只有 alfred 响应(正常路由)
  • GROUP_B:agent1 和 agent2 都响应(广播)
优先级: broadcast 优先于 bindings

故障排除

代理未响应

检查:
  1. 智能体 ID 存在于 agents.list
  2. Peer ID 格式正确(例如 [email protected]
  3. 代理不在拒绝列表中
调试:

只有一个智能体响应

原因: Peer ID 可能在 bindings 中但不在 broadcast 中。 修复: 添加到广播配置或从绑定中移除。

性能问题

如果智能体较多时速度较慢:
  • 减少每个群组的智能体数量
  • 使用较轻的模型(sonnet 而非 opus)
  • 检查沙箱启动时间

示例

示例 1:代码审查团队

用户发送: 代码片段
响应:
  • code-formatter:“修复了缩进并添加了类型提示”
  • security-scanner:“⚠️ 第 12 行存在 SQL 注入漏洞”
  • test-coverage:“覆盖率为 45%,缺少错误情况的测试”
  • docs-checker:“函数 process_data 缺少文档字符串”

示例 2:多语言支持

API 参考

配置模式

字段

  • strategy(可选):如何处理智能体
    • "parallel"(默认):所有智能体同时处理
    • "sequential":智能体按数组顺序处理
  • [peerId]:WhatsApp 群组 JID、E.164 号码或其他 peer ID
    • 值:应处理消息的智能体 ID 数组

限制

  1. 最大智能体数: 无硬性限制,但 10 个以上智能体可能会较慢
  2. 共享上下文: 智能体看不到彼此的响应(设计如此)
  3. 消息顺序: 并行响应可能以任意顺序到达
  4. 速率限制: 所有智能体都计入 WhatsApp 速率限制

未来增强

计划中的功能:
  • 共享上下文模式(智能体可以看到彼此的响应)
  • 代理协作(代理可以相互发送信号)
  • 动态智能体选择(根据消息内容选择智能体)
  • 代理优先级(某些代理先于其他代理响应)

另请参阅