O que é A2A no Zero?
Zero A2A é uma forma prática de comunicação entre agentes dentro do produto. Permite que um agente abra várias conversas isoladas, que um coordenador delegue trabalho limitado a agentes especialistas e que você digite @ no compositor de chat para trazer uma conversa existente para uma comparação, transferência ou decisão.
Isso é útil quando uma tarefa é muito ampla, barulhenta ou arriscada para uma única conversa longa. Em vez de pedir a um agente que mantenha todos os testes, fontes e decisões no mesmo contexto, você dá a cada parte do trabalho um lar claro e traz de volta apenas a evidência que importa.
Três maneiras de A2A funcionar no Zero
| O que você quer fazer | Use esta configuração | Uma boa primeira cena |
|---|---|---|
| Repetir um método com contexto limpo | Um agente, várias conversas | Testar inscrição, cobrança, permissões e mobile separadamente |
| Dar partes de uma tarefa a diferentes especialistas | Um coordenador, vários agentes especialistas ou subagentes | Dividir um lançamento entre pesquisa, QA do navegador, redação e publicação |
| Reutilizar trabalho que já existe | @ outra conversa no compositor | Comparar dois relatórios de QA ou passar pesquisa para uma tarefa de redação |
Três objetos de produto estão por trás desses padrões:
- Um agente é o trabalhador reutilizável. Ele possui instruções, fluxos de trabalho, conectores, permissões, tom, função e escolha do modelo.
- Uma conversa é uma conversa isolada com um agente. Ela mantém uma tarefa de teste, revisão ou produção em seu próprio contexto.
- Uma execução é uma resposta ativa dentro de uma conversa. Execuções fazem o trabalho e podem esperar quando o espaço de trabalho atinge seu limite de concorrência.
O detalhe importante é simples: uma nova conversa filha não herda a história completa da conversa de controle. Sua primeira mensagem deve incluir tudo o que ela precisa para fazer o trabalho.
A2A, várias conversas, subagentes, fluxos de trabalho e automações
Esses termos resolvem problemas diferentes. Use a menor configuração que dá a você a fronteira que precisa.
| Padrão de produto | O que muda | Melhor usado para |
|---|---|---|
| A2A no Zero | Como agentes e conversas coordenam trabalho | Delegação, comparação, transferências e síntese final |
| Várias conversas sob um agente | Contexto, enquanto instruções e permissões permanecem iguais | Testes paralelos, verificações de localização, lotes de pesquisa e avaliações de modelo |
| Agentes especialistas ou subagentes | Função, instruções, modelo, ferramentas ou permissões | Pesquisa, QA, redação, análise de dados e publicação controlada |
| Fluxo de trabalho | Um procedimento salvo que um agente pode repetir | Uma lista de verificação estável ou método multi-etapa |
| Automação | Um gatilho que inicia um fluxo de trabalho com um agente | Relatórios agendados, triagem baseada em eventos e verificações recorrentes |
Uma regra prática útil: divida em conversas quando o método permanece o mesmo, divida em agentes especialistas quando o método ou acesso muda, e use um fluxo de trabalho quando o procedimento deve ser repetido da mesma forma.
1. Um agente abre várias conversas limpas
Você está prestes a lançar. Inscrição, cobrança, permissões e mobile precisam de uma última passagem. Colocar todos os testes em uma única conversa longa parece conveniente, mas o estado pode se filtrar de uma jornada para a próxima. Uma atualização de cobrança pode mudar a conta antes mesmo que o teste de permissões comece.
Use uma conversa por jornada em vez disso.
Uma breve compartilhada, quatro verificações isoladas, depois um relatório final.
Recriamos este padrão no produto de staging em 25 de agosto de 2026. O mesmo agente Zero abriu quatro conversas reais para onboarding, cobrança, permissões de colegas e teste de localidade.
Cada jornada tem sua própria conversa, então a evidência permanece fácil de examinar.
Tente este prompt:
Percorra esta verificação de lançamento de staging como quatro tarefas separadas. Abra uma conversa para inscrição e onboarding, uma para atualização de cobrança, uma para convite de colegas e permissões negadas, e uma para teste de mobile e localidade. Use o mesmo agente de verificação para cada conversa. Cada trabalhador deve retornar o URL testado, papel da conta, passos numerados, capturas de tela, status de passagem/falha e etapas exatas de reprodução. Traga os resultados de volta aqui e agrupe bloqueios duplicados.
Este padrão também funciona para:
- Uma conversa por navegador ou tamanho de dispositivo
- Uma conversa por localidade ou papel da conta
- Uma conversa por solicitação de pull ou bandeira de recurso
- Uma conversa por revisor, mantendo achados separados até o final
- Uma conversa por lote de entrevistas de cliente ou conjunto de fontes de pesquisa
- Uma conversa por modelo quando você quer comparar saídas de forma justa
O que geralmente dá errado? A breve é muito curta. “Verifique cobrança” deixa o trabalhador adivinhando sobre a conta, build, resultado esperado e formato de evidência. Dê a cada conversa a mesma lista de verificação e uma conta de teste separada quando a sequência muda dados compartilhados.
2. Use @ para trazer outro chat para a tarefa
Às vezes, o trabalho útil já existe. Um chat de pesquisa tem as citações do cliente. Um chat de QA tem as capturas de tela. Uma segunda revisão chega a uma conclusão diferente. Você não precisa copiar e colar tudo.
Clique no compositor e digite @. Zero abrirá uma lista de seus chats existentes.
Comece a digitar um título para achar a lista, depois escolha o chat que precisa.
O chat selecionado aparece como um botão clicável de cor laranja.
O botão aponta para o exato chat de onboarding. A resposta será escrita no chat atual.
Então adicione um verbo. Diga ao Zero o que fazer com esse chat:
- “Compare
@Onboarding QAcom essa revisão de cobrança.” - “Continue a partir de
@Pesquisa de cliente lote 2e escreva a recomendação aqui.” - “Desafie a conclusão de maior risco em
@Revisão de segurança.” - “Transforme as capturas de tela em
@Walkthrough móvelem um relatório de bug.” - “Extraia todas as perguntas não resolvidas de
@Pesquisa de lançamento.”
Digite @, escolha o chat, então diga ao que o Zero deve fazer com ele.
A menção é uma endereço, não uma etiqueta vaga de texto. Ela aponta para o chat selecionado sem colar a conversa inteira no compositor. Isso mantém a mensagem atual legível, mas sua instrução ainda precisa de uma ação clara. “Use isso” é fraco. “Compare os passos falhados e classifique os bloqueios compartilhados” é claro.
3. Dê partes diferentes a agentes especializados ou subagentes
Use vários chats quando quiser cópias limpas do mesmo trabalhador. Use agentes especializados quando a tarefa precisa de instruções diferentes, ferramentas, modelos ou limites de permissão. Um agente especializado fazendo uma tarefa limitada para um coordenador é frequentemente chamado de subagente.
Um lançamento de produto é um bom exemplo. Um Escoteiro de Pesquisa pode verificar as evidências. Um QA de Navegador pode verificar o produto lançado. Um Escritor de Lançamento pode redigir a página. Um Operador de Publicação pode criar o draft do CMS após a aprovação das reivindicações.
O ambiente de staging tem um agente central e quatro agentes especializados nomeados, prontos para uma tarefa limitada.
O coordenador é responsável pelo resultado. Os especialistas retornam evidências e artefatos, depois um proprietário escreve o resultado final.
Aqui está um breve de lançamento prático:
Coordenar um pacote de lançamento para a Feature X. Peça ao Escoteiro de Pesquisa para verificar as evidências do cliente e as reivindicações do concorrente. Peça ao QA de Navegador para reproduzir todas as reivindicações do produto no staging e anexe capturas de tela. Peça ao Escritor de Lançamento para redigir a página apenas após a chegada das evidências. O Operador de Publicação pode criar o draft do CMS, mas não pode publicá-lo. Relate evidências faltantes e reivindicações conflitantes neste chat.
O valor vem de limites reais. Um agente de pesquisa pode permanecer somente leitura. Um agente de publicação pode ter acesso a rascunhos sem permissão para publicar. Um agente de QA pode seguir sempre a mesma lista de verificação do navegador. Os controles de permissão do Zero ajudam a manter esses limites bem definidos.
Não crie especialistas apenas para tornar o painel mais ocupado. Crie um quando o papel muda como o trabalho é feito.
4. Deixe revisores independentes discordarem, depois use um juiz
Duas revisões são úteis apenas quando o segundo revisor não está copiando o primeiro. Abra chats limpos, dê a ambos os revisores as mesmas evidências e mantenha seus primeiros relatórios separados.
Então comece um chat de julgamento e mencione ambos os relatórios em uma única solicitação.
Uma solicitação pode referenciar dois chats de QA reais e pedir ao Zero para encontrar os bloqueios compartilhados.
Por exemplo:
Compare
@Onboarding QAcom@Billing QA. Liste os bloqueios encontrados por ambos os chats, os problemas encontrados por apenas um chat e as evidências que ainda estão faltando. Em seguida, decida se o lançamento deve ser enviado. Cite a captura de tela ou passo que apoia cada bloqueio.
Este padrão funciona para revisão de design, revisão de segurança, seleção de fornecedores, escolha de arquitetura, revisão de contrato e comparação de modelos. Defina os critérios de julgamento antes das relatórios chegarem. Caso contrário, o juiz pode recompensar a escrita mais confiante em vez da evidência mais forte.
5. Passe o trabalho de um agente para o próximo
Algumas tarefas não devem ser executadas ao mesmo tempo. A pesquisa deve terminar antes do rascunho. O rascunho deve terminar antes da QA. A QA deve terminar antes da publicação.
Trate cada passagem como uma nota de entrega curta:
- Nomeie o agente receptor ou chat.
- Anexe ou refira o artefato.
- Estabeleça os critérios de aceitação.
- Indique onde o receptor deve relatar de volta.
“Diga ao escritor o que você encontrou” é difícil de verificar. Isso é melhor:
Envie o resumo de pesquisa aprovado para o Escritor de Lançamento. O rascunho deve usar apenas afirmações verificadas, manter a terminologia aprovada e marcar qualquer prova ausente com
[EVIDÊNCIA NECESSÁRIA]. Retorne o link do rascunho e as questões não resolvidas para este chat.
O chip de chat @ é útil aqui porque dá ao próximo trabalhador uma fonte precisa. Para trabalhos com muitos arquivos, passe também o link do artefato. O coordenador precisa do status, decisões e pacote final. Não precisa de cada nota copiada em seu próprio contexto.
Como os agentes de IA compartilham contexto no Zero?
Os agentes no Zero não precisam de uma conversa compartilhada gigante. O contexto se move através de breves explícitos, menções de chat @, links de artefato e resumos retornados. Cada trabalhador recebe o contexto mínimo útil, completa uma tarefa definida e envia evidências ou uma decisão de volta ao coordenador.
Este abordagem evita dois problemas comuns de múltiplos agentes. Primeiro, a história irrelevante não enche o contexto do trabalhador. Segundo, o coordenador pode ver exatamente qual fonte ou chat suporta uma afirmação.
Use esses quatro padrões de compartilhamento de contexto:
- Breve autossuficiente: melhor para um novo chat filho que deve começar limpo.
- Mencionar de chat
@: melhor quando uma conversa existente é a fonte. - Link de artefato: melhor para documentos, capturas de tela, conjuntos de dados e mudanças de código.
- Retorno estruturado: melhor quando vários trabalhadores devem relatar no mesmo formato.
Não assuma que um chat filho já sabe as decisões do chat de controle. Se um termo, restrição, conta, intervalo de datas ou formato de saída importa, coloque-o na primeira mensagem.
Mais cenários de fluxo de trabalho A2A e multi-agentes
| Cenário | Como dividir | O que retorna |
|---|---|---|
| Walkthrough de lançamento | Mesmo agente, um chat por jornada do usuário | Capturas de tela, verificações de pass/fail e bloqueadores compartilhados |
| QA de localização | Mesmo agente, um chat por local | Strings quebradas, problemas de layout e capturas de tela específicas da localidade |
| Testes de navegador e dispositivo | Mesmo agente, um chat por navegador ou viewport | Uma matriz de compatibilidade comparável com evidências |
| Revisão de solicitação de pull | Mesmo agente, um chat por PR ou ângulo de revisão | Bugs, notas de risco e recomendações de nível de linha |
| Pesquisa de cliente | Mesmo agente, um chat por lote de entrevistas | Citações, padrões, objeções e links de fonte |
| Resposta a incidentes | Coordenador mais aplicativo, API, deploy e agentes de impacto do cliente | Uma cronologia com acordos e conflitos chamados |
| Produção de conteúdo | Agentes de pesquisa, escrita, design, QA e publicação | Um rascunho revisado e uma transição de publicação controlada |
| Triagem de suporte ao cliente | Coordenador mais conta, produto, faturamento e agentes de resposta | Causa raiz, prioridade, proprietário e um rascunho de resposta |
| QA de análise de dados | Agente de análise mais um revisor independente | Junções verificadas, denominadores, fusos horários e suposições |
| Comparação de modelos | Chats limpos com o mesmo breve e diferentes modelos | Precisão, custo, latência e pontuações de formato |
A divisão correta cria uma fronteira útil. Isso pode isolar o contexto, proteger uma permissão, manter revisões independentes ou permitir que o trabalho pronto execute ao mesmo tempo.
Quando você deve usar um chat, vários chats ou vários agentes?
Use um chat quando cada próximo passo depende da resposta imediatamente anterior. Uma sessão de depuração sequencial é um bom exemplo.
Use vários chats sob um agente quando as instruções permanecem as mesmas, mas você precisa de um contexto limpo ou evidências independentes. Isso é geralmente o melhor ponto de partida para testes, lote de pesquisa e comparações justas.
Use vários agentes especialistas quando cada parte precisa de diferentes especialidades, conectores, permissões ou modelos. Deixe um coordenador responsável pela decisão final.
Use um fluxo de trabalho quando o procedimento deve ser repetível. Adicione uma automação apenas quando esse procedimento também precisa de um agendamento ou disparador de evento. Os documentos Zero dessas duas blocos de construção separadamente: fluxos de trabalho definem o método, enquanto automações decidem quando ele deve ser executado.
Segurança A2A e fronteiras de permissão
O trabalho multi-agente é mais seguro quando o acesso segue a atribuição. Dê a cada especialista apenas os conectores e permissões necessárias para sua parte. Um agente de pesquisa raramente precisa de acesso de publicação. Um agente de QA pode precisar de um login de staging, mas não de controles de faturamento de produção. Um agente de publicação pode precisar de acesso a rascunhos, mas ainda requer uma pessoa para aprovar a publicação final.
Manter escritas externas sob um único proprietário nomeado. Vários agentes podem ler um repositório, CRM ou CMS, mas um agente deve criar o ticket final, atualizar o registro, enviar a resposta ao cliente ou publicar a página. Isso evita escritas duplicadas e torna o rastro de auditoria mais fácil de seguir.
Para trabalho de alto risco, adicione uma condição de parada ao breve: “Apenas rascunho”, “Não enviar”, “Escalonar se houver conflito de evidência” ou “Pedir aprovação antes de alterar a produção”. A2A facilita a delegação; ela não remove a necessidade de uma responsabilidade clara.
Quatro regras que mantêm o trabalho A2A organizado
1. Faça a primeira mensagem de cada chat autossuficiente
Inclua o objetivo, o material de origem, as restrições, o formato de saída, o destino e a condição de parada. Um chat filho não deve precisar adivinhar o que o chat de controle já sabe.
2. Dê aos trabalhadores a mesma forma de resposta
Se quatro chats de QA retornarem quatro formatos diferentes, o coordenador passará seu tempo limpando o texto. Peça a cada trabalhador que forneça os mesmos campos: ambiente, passos, evidências, status e ação seguinte.
3. Deixe a escrita compartilhada com um único proprietário
Dois agentes corretos ainda podem fazer bagunça escrevendo duas vezes. Nomeie o agente que possui a ação final externa.
4. Divida apenas o trabalho que beneficia da divisão
Criar oito chats não significa que oito execuções ocorrerão ao mesmo tempo. A concorrência do workspace ainda se aplica, e o trabalho dependente deve esperar pela entrada necessária. Mantenha uma tarefa em um único chat quando cada próximo passo depende da resposta anterior.
Zero A2A é o mesmo que o protocolo Agent2Agent do Google?
Não se alega equivalência de protocolo aqui. Este guia descreve a coordenação de produto entre agentes e chats dentro do Zero: como o trabalho é dividido, referenciado, julgado e transferido através da interface.
O protocolo Agent2Agent aberto do Google é um padrão técnico para comunicação entre sistemas de agentes remotos, incluindo descoberta de capacidade, gerenciamento de tarefas, mensagens e artefatos. Os resultados de busca para "A2A" frequentemente se concentram nesse protocolo, então a distinção importa: Zero A2A é o fluxo de trabalho prático de produto coberto neste artigo.
Perguntas frequentes
Um chat é o mesmo que um agente?
Não. Um agente é uma configuração de trabalhador reutilizável. Um chat é uma conversa isolada com esse agente. Um agente pode possuir muitos chats.
Os chats filhos compartilham o contexto do chat de controle?
Não. Comece cada chat filho com uma breve completa. Trabalhadores podem retornar resultados ou passar artefatos limitados a outro chat, mas não devem assumir história compartilhada.
O que acontece quando eu @ um chat?
Zero insere uma referência estruturada ao chat que você selecionou. A referência identifica a conversa que você quer. Não cola a conversa completa no compositor, então adicione uma ação clara como comparar, revisar, continuar ou extrair.
O que é um subagente no Zero?
Um subagente é um agente especialista que recebe uma tarefa limitada de um coordenador. Ele pode usar instruções diferentes, ferramentas, permissões ou um modelo diferente, e então retornar seu resultado ao chat de controle.
Pode haver múltiplos chats em execução em paralelo?
Sim, quando a concorrência do workspace está disponível e as tarefas são independentes. Trabalhos adicionais podem ficar em fila quando o limite é atingido. Trabalhos com dependências devem ser executados em sequência.
Quando devo usar agentes diferentes?
Use agentes diferentes quando o trabalho precisa de instruções diferentes, fluxos de trabalho, modelos, conectores ou permissões. Use vários chats sob o mesmo agente quando você principalmente precisa de um contexto limpo.
Tente o guia de introdução em staging primeiro
Abra um novo chat no Zero e divida uma verificação de lançamento real em quatro chats limpos. Peça capturas de tela e o mesmo formato pass/fail em cada chat. Uma vez que isso funcione, substitua uma rama com um agente especialista ou mencione duas chats completas em um prompt de julgamento.
Para mais ideias, veja 20 casos de uso de agentes de IA com prompts e ferramentas exatas.
