Skip to main content

廣播群組

狀態: 實驗性
版本: 在 2026.1.9 中新增

概述

廣播群組使多個代理能夠同時處理並回應相同的訊息。這使您能夠建立專門的代理團隊,在單一 WhatsApp 群組或 DM 中一起工作 — 全部使用一個電話號碼。 當前範圍:僅 WhatsApp(Web 頻道)。 廣播群組在頻道允許清單和群組啟動規則之後進行評估。在 WhatsApp 群組中,這意味著廣播發生在 OpenClaw 通常會回覆的時候(例如:在提及時,取決於您的群組設定)。

使用案例

1. 專門代理團隊

部署多個具有原子型、聚焦責任的代理:
每個代理處理相同的訊息並提供其專業視角。

2. 多語言支援

3. 品質保證工作流程

4. 任務自動化

設定

基本設定

在頂級新增 broadcast 區段(在 bindings 旁邊)。鍵是 WhatsApp peer ID:
  • 群組聊天:群組 JID(例如 [email protected]
  • DM:E.164 電話號碼(例如 +15551234567
結果: 當 OpenClaw 會在此聊天中回覆時,它將執行所有三個代理。

處理策略

控制代理處理訊息的方式:

平行(預設)

所有代理同時處理:

連續

代理依序處理(一個等待前一個完成):

完整範例

如何運作

訊息流程

  1. 傳入訊息到達 WhatsApp 群組
  2. 廣播檢查:系統檢查 peer ID 是否在 broadcast
  3. 如果在廣播清單中
    • 所有列出的代理處理訊息
    • 每個代理都有其自己的會話金鑰和隔離的上下文
    • 代理平行(預設)或連續處理
  4. 如果不在廣播清單中
    • 正常路由適用(第一個相符的綁定)
注意:廣播群組不會繞過頻道允許清單或群組啟動規則(提及/命令/等)。它們只在訊息符合處理條件時改變哪些代理執行

會話隔離

廣播群組中的每個代理保持完全獨立的:
  • 會話金鑰agent:alfred:whatsapp:group:120363... vs agent:baerbel:whatsapp:group:120363...
  • 對話歷史(代理看不到其他代理的訊息)
  • 工作區(如果設定,單獨的沙箱)
  • 工具存取(不同的允許/拒絕清單)
  • 記憶/上下文(單獨的 IDENTITY.md、SOUL.md 等)
  • 群組上下文緩衝(用於上下文的最近群組訊息)按 peer 共享,所以所有廣播代理在觸發時看到相同的上下文
這使每個代理能夠有:
  • 不同的個性
  • 不同的工具存取(例如,唯讀 vs 讀寫)
  • 不同的模型(例如,opus vs sonnet)
  • 安裝的不同技能

範例:隔離會話

在具有代理 ["alfred", "baerbel"] 的群組 [email protected] 中: Alfred 的上下文:
Bärbel 的上下文:

最佳實踐

1. 保持代理聚焦

使用單一、清晰的責任設計每個代理:
好: 每個代理有一項工作
不好: 一個通用的「dev-helper」代理

2. 使用描述性名稱

清楚說明每個代理做什麼:

3. 設定不同的工具存取

只給代理它們需要的工具:

4. 監控效能

在許多代理中,考慮:
  • 使用 "strategy": "parallel"(預設)以獲得速度
  • 將廣播群組限制為 5-10 個代理
  • 為更簡單的代理使用更快的模型

5. 優雅地處理故障

代理獨立失敗。一個代理的錯誤不會阻止其他代理:

相容性

供應商

廣播群組目前適用於:
  • ✅ WhatsApp(已實現)
  • 🚧 Telegram(計畫中)
  • 🚧 Discord(計畫中)
  • 🚧 Slack(計畫中)

路由

廣播群組與現有路由一起運作:
  • GROUP_A:僅 alfred 回應(正常路由)
  • GROUP_B:agent1 AND 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 速率限制

未來增強

計畫的功能:
  • 共享上下文模式(代理看到彼此的回應)
  • 代理協調(代理可以相互發信號)
  • 動態代理選擇(根據訊息內容選擇代理)
  • 代理優先順序(某些代理在其他代理之前回應)

另見