Skip to main content
Status: Experimental. Adicionado na versão 2026.1.9. Somente WhatsApp (canal web).

Visão geral

Os grupos de transmissão executam vários agentes para a mesma mensagem recebida. Cada agente processa a mensagem em sua própria sessão isolada e publica sua própria resposta, permitindo que um número do WhatsApp hospede uma equipe de agentes especializados em um único chat em grupo ou mensagem direta. Os grupos de transmissão são avaliados após as listas de permissões do canal e as regras de ativação de grupos. Nos grupos do WhatsApp, as transmissões ocorrem quando o OpenClaw normalmente responderia (por exemplo, ao ser mencionado, dependendo das configurações do grupo). Elas alteram apenas quais agentes são executados, nunca se uma mensagem está qualificada para processamento. A rotina ativa de controle de qualidade do WhatsApp inclui whatsapp-broadcast-group-fanout, que verifica se uma mensagem de grupo com uma menção pode gerar respostas visíveis distintas de dois agentes configurados.

Configuração

Configuração básica

Adicione uma seção broadcast de nível superior (ao lado de bindings). As chaves são IDs de pares do WhatsApp e os valores são matrizes de IDs de agentes:
  • chats em grupo: JID do grupo (por exemplo, 120363403215116621@g.us)
  • mensagens diretas: número de telefone E.164 do remetente (por exemplo, +15551234567)
Resultado: quando o OpenClaw responderia neste chat, ele executa os três agentes. Cada ID de agente listado deve existir em agents.list: a validação da configuração informa IDs desconhecidos, e o ambiente de execução os ignora com um aviso Broadcast agent <id> not found in agents.list; skipping.

Estratégia de processamento

broadcast.strategy define como os agentes processam a mensagem:

Exemplo completo

Como funciona

Fluxo de mensagens

1

A mensagem recebida chega

Uma mensagem de grupo ou direta do WhatsApp chega.
2

Roteamento e admissão

O OpenClaw aplica listas de permissões do canal, regras de ativação de grupos e a propriedade configurada das associações ACP.
3

Verificação de transmissão

Se nenhuma associação ACP configurada for proprietária da rota, o OpenClaw verificará se o ID do par está em broadcast.
4

Se a transmissão for aplicável

  • Todos os agentes listados processam a mensagem.
  • Cada agente tem sua própria chave de sessão e contexto isolado.
  • Os agentes processam em paralelo (padrão) ou sequencialmente.
  • Os anexos de áudio são transcritos uma vez antes da distribuição, permitindo que os agentes compartilhem uma transcrição em vez de fazer chamadas STT separadas.
5

Se a transmissão não for aplicável

O OpenClaw encaminha para a rota comum ou para a rota de sessão ACP configurada selecionada durante o roteamento.
Os grupos de transmissão não ignoram as listas de permissões do canal nem as regras de ativação de grupos (menções/comandos/etc.). Eles alteram apenas quais agentes são executados quando uma mensagem está qualificada para processamento.

Isolamento de sessões

Cada agente em um grupo de transmissão mantém totalmente separados:
  • Chaves de sessão (agent:alfred:whatsapp:group:120363... em comparação com agent:baerbel:whatsapp:group:120363...)
  • Histórico da conversa (um agente não vê as respostas dos outros agentes)
  • Espaço de trabalho (sandboxes separados, se configurados)
  • Acesso a ferramentas (listas distintas de permissões e bloqueios)
  • Memória/contexto (IDENTITY.md, SOUL.md etc. separados)
Uma exceção é compartilhada intencionalmente: o buffer de contexto do grupo (mensagens recentes do grupo usadas como contexto) é compartilhado por par, portanto todos os agentes da transmissão veem o mesmo contexto quando são acionados. Ele é limpo uma vez após a conclusão da distribuição. Isso permite que cada agente tenha diferentes personalidades, modelos, Skills e acessos a ferramentas (por exemplo, somente leitura em comparação com leitura e gravação).

Exemplo: sessões isoladas

No grupo 120363403215116621@g.us com os agentes ["alfred", "baerbel"]:

Casos de uso

  • Equipes de agentes especializados: um grupo de desenvolvimento em que code-reviewer, security-auditor, test-generator e docs-checker respondem à mesma mensagem, cada um sob sua própria perspectiva.
  • Suporte multilíngue: um único chat de suporte com support-en, support-de e support-es respondendo em seus respectivos idiomas.
  • Controle de qualidade: support-agent responde enquanto qa-agent revisa e só responde quando encontra problemas.
  • Automação de tarefas: task-tracker, time-logger e report-generator processam a mesma atualização de status.

Práticas recomendadas

Dê a cada agente uma única responsabilidade clara (formatter, linter, tester) em vez de usar um agente genérico “dev-helper”.
reviewer tem acesso somente de leitura. fixer pode ler e gravar.
Com muitos agentes, prefira "strategy": "parallel" (padrão), limite os grupos de transmissão a poucos agentes e use modelos mais rápidos para agentes mais simples.
Os agentes falham de forma independente. O erro de um agente é registrado (Broadcast agent <id> failed: ...) e não bloqueia os demais.

Compatibilidade

Provedores

Atualmente, os grupos de transmissão são implementados somente para o WhatsApp (canal web). Outros canais ignoram a configuração broadcast.

Roteamento

Os grupos de transmissão funcionam em conjunto com o roteamento existente:
  • GROUP_A: somente alfred responde (roteamento normal).
  • GROUP_B: agent1 E agent2 respondem (transmissão).
Precedência: broadcast tem prioridade sobre as associações de rotas comuns. As associações ACP configuradas (bindings[].type="acp") são exclusivas: quando uma delas corresponde, o OpenClaw encaminha para a sessão ACP configurada em vez de realizar a distribuição da transmissão.

Solução de problemas

Verifique:
  1. Os IDs dos agentes existem em agents.list (a validação da configuração rejeita IDs desconhecidos).
  2. O formato do ID do par está correto (JID de grupo, como 120363403215116621@g.us, ou E.164, como +15551234567, para mensagens diretas).
  3. A mensagem passou pelos controles normais (as regras de menção/ativação ainda se aplicam).
Depuração:
Uma distribuição bem-sucedida registra Broadcasting message to <n> agents (<strategy>).
Causa: o ID do par pode estar nas associações de rotas comuns, mas não em broadcast, ou pode corresponder a uma associação ACP exclusiva configurada.Correção: adicione à configuração de transmissão os pares associados a rotas comuns ou remova/altere a associação ACP configurada caso queira a distribuição da transmissão.
Se o processamento estiver lento com muitos agentes: reduza o número de agentes por grupo, use modelos mais leves e verifique o tempo de inicialização do sandbox.

Exemplos

Um trecho de código no grupo gera quatro respostas: correções de formatação, uma constatação de segurança, uma lacuna de cobertura e uma pequena observação sobre a documentação.

Referência da API

Esquema de configuração

Campos

"parallel" | "sequential"
padrão:"\"parallel\""
Como processar os agentes. parallel executa todos os agentes simultaneamente; sequential os executa na ordem da matriz.
string[]
JID de grupo do WhatsApp ou número de telefone E.164. O valor é a matriz de IDs dos agentes que devem processar as mensagens desse par.

Limitações

  1. Máximo de agentes: não há limite rígido, mas muitos agentes (10 ou mais) podem causar lentidão.
  2. Contexto compartilhado: os agentes não veem as respostas uns dos outros (por definição).
  3. Ordem das mensagens: as respostas em paralelo podem chegar em qualquer ordem.
  4. Limites de taxa: todas as respostas vêm de uma única conta do WhatsApp, portanto a resposta de cada agente conta para os mesmos limites de taxa do WhatsApp.

Conteúdo relacionado