Documentation Index
Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Status: 实验性。已在 2026.1.9 中添加。
概览
Broadcast Groups 允许多个智能体同时处理并回复同一条消息。这样你可以创建专门的智能体团队,让它们在同一个 WhatsApp 群组或私信中协作,且全部使用同一个电话号码。 当前范围:仅 WhatsApp(Web 渠道)。 Broadcast groups 会在渠道允许列表和群组激活规则之后评估。在 WhatsApp 群组中,这意味着当 OpenClaw 通常会回复时(例如:被提及时,取决于你的群组设置),就会进行广播。使用场景
1. 专门的智能体团队
1. 专门的智能体团队
部署多个职责原子化且聚焦的智能体:每个智能体都会处理同一条消息,并提供自己的专业视角。
2. 多语言支持
2. 多语言支持
3. 质量保证工作流
3. 质量保证工作流
4. 任务自动化
4. 任务自动化
配置
基本设置
添加一个顶层broadcast 部分(与 bindings 同级)。键是 WhatsApp 对端 ID:
- 群组聊天:群组 JID(例如
120363403215116621@g.us) - 私信:E.164 电话号码(例如
+15551234567)
处理策略
控制智能体如何处理消息:- parallel(默认)
- sequential
所有智能体同时处理:
完整示例
工作原理
消息流程
Broadcast groups 不会绕过渠道允许列表或群组激活规则(提及/命令等)。它们只会在消息符合处理条件时改变_运行哪些智能体_。
会话隔离
Broadcast group 中的每个智能体都会维护完全独立的:- 会话键(
agent:alfred:whatsapp:group:120363...与agent:baerbel:whatsapp:group:120363...) - 对话历史(智能体看不到其他智能体的消息)
- 工作区(如果已配置,则使用独立沙箱)
- 工具访问权限(不同的允许/拒绝列表)
- 记忆/上下文(独立的 IDENTITY.md、SOUL.md 等)
- 群组上下文缓冲区(用于上下文的近期群组消息)按对端共享,因此所有广播智能体被触发时都会看到相同上下文
- 不同的性格
- 不同的工具访问权限(例如,只读与读写)
- 不同的模型(例如,opus 与 sonnet)
- 安装不同的 Skills
示例:隔离会话
在群组120363403215116621@g.us 中,智能体为 ["alfred", "baerbel"]:
- Alfred 的上下文
- Bärbel 的上下文
最佳实践
1. 让智能体保持聚焦
1. 让智能体保持聚焦
为每个智能体设计单一且清晰的职责:✅ 好: 每个智能体只有一项工作。❌ 不好: 一个通用的 “dev-helper” 智能体。
2. 使用描述性名称
2. 使用描述性名称
清楚说明每个智能体的作用:
3. 配置不同的工具访问权限
3. 配置不同的工具访问权限
只给智能体提供它们需要的工具:
reviewer 是只读的。fixer 可以读取和写入。4. 监控性能
4. 监控性能
当有很多智能体时,请考虑:
- 使用
"strategy": "parallel"(默认)以提升速度 - 将 broadcast groups 限制为 5-10 个智能体
- 为更简单的智能体使用更快的模型
5. 优雅处理失败
5. 优雅处理失败
智能体会独立失败。一个智能体的错误不会阻塞其他智能体:
兼容性
提供商
Broadcast groups 目前适用于:- ✅ WhatsApp(已实现)
- 🚧 Telegram(计划中)
- 🚧 Discord(计划中)
- 🚧 Slack(计划中)
路由
Broadcast groups 可与现有路由配合使用:GROUP_A:只有 alfred 回复(正常路由)。GROUP_B:agent1 和 agent2 都会回复(广播)。
优先级:
broadcast 优先于 bindings。故障排除
智能体没有回复
智能体没有回复
检查:
- 智能体 ID 存在于
agents.list中。 - 对端 ID 格式正确(例如
120363403215116621@g.us)。 - 智能体不在拒绝列表中。
只有一个智能体回复
只有一个智能体回复
原因: 对端 ID 可能在
bindings 中,但不在 broadcast 中。修复: 添加到 broadcast 配置,或从 bindings 中移除。性能问题
性能问题
如果多个智能体导致速度变慢:
- 减少每个群组的智能体数量。
- 使用更轻量的模型(使用 sonnet 而不是 opus)。
- 检查沙箱启动时间。
示例
示例 1:代码审查团队
示例 1:代码审查团队
- code-formatter:“已修复缩进并添加类型提示”
- security-scanner:“⚠️ 第 12 行存在 SQL 注入漏洞”
- test-coverage:“覆盖率为 45%,缺少错误情况测试”
- docs-checker:“函数
process_data缺少文档字符串”
示例 2:多语言支持
示例 2:多语言支持
API 参考
配置模式
字段
如何处理智能体。
parallel 会同时运行所有智能体;sequential 会按数组顺序运行它们。WhatsApp 群组 JID、E.164 号码或其他对端 ID。值是应处理消息的智能体 ID 数组。
限制
- 最大智能体数: 没有硬性限制,但 10 个以上智能体可能会变慢。
- 共享上下文: 智能体看不到彼此的回复(设计如此)。
- 消息顺序: 并行回复可能以任意顺序到达。
- 速率限制: 所有智能体都会计入 WhatsApp 速率限制。
未来增强
计划功能:- 共享上下文模式(智能体看到彼此的回复)
- 智能体协调(智能体可以互相发信号)
- 动态智能体选择(根据消息内容选择智能体)
- 智能体优先级(某些智能体先于其他智能体回复)