O que "Meta Muse para reprodução de bugs" realmente significa
Eu construo agentes de IA na eesel, e a parte desse trabalho que ninguém mostra em uma demo é depurar a partir da descrição que outra pessoa faz de um problema. Um relatório de bug vale o que valem as evidências anexadas, e foi assim que li a documentação da Meta para este post: seguindo a captura de tela do cliente por cada produto para ver onde ela sobrevive.
Primeiro, os nomes. "Meta Muse" pode significar quatro produtos diferentes, e três deles têm um papel na triagem de relatórios de bug:
| Produto | O que é | Papel na reprodução de bugs |
|---|---|---|
| Muse | O agente pessoal de consumo da Meta, lançado em 8 de setembro de 2026 | Nenhum. Funciona para indivíduos, não para sua equipe de suporte |
| Meta Business Agent | A IA de negócios voltada ao cliente da Meta no WhatsApp, Messenger e Instagram | Recebe o relatório do bug e transfere para uma pessoa |
| API Muse Spark | O modelo da Meta, que você chama do seu próprio código | Lê a captura de tela ou gravação e escreve os passos de reprodução |
| Muse Code | O harness de agente de programação da Meta, rodando o Muse Spark | Tenta a reprodução na sua base de código e escreve um teste que falha |
Cada estação funciona. O que nenhuma tem é um ticket: aquilo que reúne em um só lugar o relatório, a captura de tela, as anotações do engenheiro e a resposta ao cliente. Essa parte você conecta sozinho, e é onde os relatórios de bug costumam se perder.
O que um relatório de bug reproduzível precisa ter
Antes de olhar as ferramentas da Meta, ajuda ser específico sobre o objetivo. Um engenheiro só consegue reproduzir um bug se receber os passos, o que o cliente esperava versus o que aconteceu, o dispositivo e o SO, a versão do app, uma captura de tela ou gravação e com que frequência acontece. Se faltar um, o ticket volta ao suporte com uma pergunta (o clássico ciclo de suporte técnico), e o suporte precisa voltar a um cliente que já seguiu em frente.
O exemplo de ferramenta de ticket da própria Meta mostra o quanto o padrão fica longe. A ferramenta create_support_ticket no guia do agente de atendimento ao cliente da Meta tem quatro campos: category, summary, order_id e customer_phone. É um bom formato para "meu pacote chegou danificado". Para "o app fecha quando envio uma foto", falta a maior parte do que um engenheiro precisa. Fiz o mesmo ponto sobre categorias no meu texto sobre triagem de tickets.
Um desenvolvedor do Shopify resumiu sem rodeios o custo de pular isso:
"You're not unlucky with the queue, tier one is macro-driven and a bug report that doesn't come with a clean reproduction gets closed with a help doc every time."
Nada disso é culpa da Meta. O guia foi escrito para suporte de varejo, e a Meta não publicou um guia de suporte técnico ou de triagem de bugs para o Business Agent. Mas significa que os campos ficam por sua conta.
Etapa 1: coletar o relatório com o Meta Business Agent
O Business Agent é a porta de entrada. Ele responde no WhatsApp e pode executar ações por meio de conectores, que são ferramentas HTTP que você define sobre sua própria API. Para coletar um relatório de bug, você escreveria uma ferramenta (vamos chamá-la de report_bug) com os campos acima e descreveria bem cada um. A referência de ferramentas conectoras da Meta diz para "define the body schema with explicit field types, descriptions, and required fields", porque "the agent uses this schema to extract the correct values from the conversation". Marque app_version e device como obrigatórios e o agente passa a ter motivo para pedi-los.
Duas outras linhas do guia da Meta valem ser copiadas. Primeira: "Enumerate the escalation triggers rather than describing them." Os próprios exemplos do guia já incluem "Technical faults" como caso a escalar. Segunda, do guia de pós-compra: "Telling the agent to escalate does nothing on its own. Configure the handoff policy in agent settings and implement thread control." Isso é higiene padrão de escalonamento com IA, e vale em dobro aqui, porque um suposto bug é um caso em que o agente não deve adivinhar.
O problema da captura de tela
É aqui que fica interessante. Um cliente que reporta um bug no WhatsApp quase sempre envia uma captura de tela, às vezes uma gravação de tela, e muitas vezes uma mensagem de voz explicando o que tocou. Então fui ver o que o Business Agent faz com elas.
A Meta não diz. Em cerca de 20 páginas para desenvolvedores do Business Agent, nenhuma documenta se o agente lê, descreve, ignora ou transfere imagens, vídeos, mensagens de voz ou documentos de clientes. Os sinais mais próximos apontam todos para texto. O user_msg do endpoint Agent test é "The text content of the test message", sem campo para mídia, então você nem consegue testar um cenário com captura de tela pela API. O agente pode enviar imagens, por meio de uma skill de UI, e aceita imagens como arquivos de conhecimento que você envia. Nenhum dos dois diz o que acontece com uma imagem que um cliente envia.
Levar o arquivo até o seu sistema de tickets também é mais difícil do que parece:
- As ferramentas conectoras não carregam arquivos. O corpo da requisição "currently only supports
application/json", os tipos de parâmetro são string, integer, number e boolean, e nenhuma das macros de execução (USER_MESSAGE,WHATSAPP_CONVERSATION_ID,WHATSAPP_MESSAGE_IDe as demais) é um ID ou URL de mídia (Connector tools). Sua ferramentareport_bugpode enviar os passos, não a captura de tela. - O resumo de transferência é apenas texto. Quando uma conversa passa para o seu helpdesk,
conversation_contexttraz "an AI-generated summary of the conversation so far" sem IDs de mídia, e a Meta diz: "Treatsummary.textas human-readable prose, not structured data" (Conversation context). Nem está documentado se o resumo chega a mencionar uma captura de tela, o que o torna um resumo de ticket mais fraco do que parece. - Os webhooks standby carregam a mídia. Enquanto o Business Agent é dono da conversa, seu app pode receber todas as mensagens do cliente no campo
standby. A Meta diz que mensagens de imagem, documento, áudio e vídeo "are delivered in standby using the same schema as standard incoming message webhooks" (Standby webhooks). O standby vem "off by default" e a empresa precisa conceder acesso (Standby partners). Expliquei o que o standby faz com um helpdesk no meu post Meta Muse for Zendesk.
O problema está nesses dois últimos pontos. O resumo só é enviado quando "The receiving responder is not receiving standby events", e "for a given conversation you receive exactly one" dos dois. Se você ativa o standby para guardar as capturas, abre mão do resumo de IA. Se confia no resumo, não tem forma documentada de obter anexos enviados antes da transferência.
Para relatórios de bug, eu escolheria o standby sempre. Um resumo pode ser reconstruído a partir das mensagens que você guardou. Uma captura de tela que você não salvou não pode ser reconstruída de jeito nenhum.
O relógio da mídia do WhatsApp
Depois que você tem um ID de mídia, ele não dura. Estes são os limites da documentação de mídia da WhatsApp Cloud API da Meta:
| Limite | Valor |
|---|---|
URL de download de GET /MEDIA_ID | Expira em 5 minutos |
| ID de mídia recebido em um webhook | Pode ser baixado por 7 dias |
| Tamanho de imagem | 5 MB (JPEG, PNG) |
| Tamanho de vídeo | 16 MB (MP4, 3GPP, somente H.264) |
| Tamanho de áudio | 16 MB (AAC, AMR, MP3, M4A, OGG/Opus) |
| Arquivo de cliente acima de 100 MB | Rejeitado com o erro 131052 |
Mensagens de voz são fáceis de identificar: o webhook de áudio tem um sinalizador voice que é true para "a recording made with the WhatsApp client voice recording feature". Gravações de tela não têm tipo próprio e chegam como video comum.
A janela de 7 dias é a que machuca. Um bug reportado numa sexta e triado na semana seguinte pode perder sua única captura de tela. Baixe cada arquivo quando o webhook chegar e anexe ao ticket, usando o ID da conversa como chave. É o passo pouco glamouroso que toda automação de suporte por WhatsApp precisa e que a maioria pula.
Etapa 2: transformar a captura de tela em passos de reprodução com a API Muse Spark
É nesta etapa que a Meta tem mais a oferecer. A API Muse Spark aceita imagens, vídeo e áudio, e a Meta publicou uma receita muito próxima desse trabalho exato.
A receita é o cookbook Error screenshot fix da Meta, que roda o muse-spark-1.3 dentro do agente de programação OpenCode. O passo 2 é "Give it the bug report plus a screenshot, and get repro steps". O exemplo é um bug de layout real no cal.com: um rodapé sobrepondo um campo de texto na tela de onboarding.
A partir dessa captura de tela e da base de código, o modelo devolveu cinco passos numerados, incluindo redimensionar a janela para pouca largura e pouca altura, e apontou o arquivo do componente e a linha.
A Meta observa que "The mention of both narrow width and short height is the part most readers miss". É exatamente o detalhe que um cliente nunca anota, e exatamente por isso as capturas de tela importam. O cookbook também documenta dois modos de falha que vale deixar à vista. "The Screenshot Names The Wrong Component" quando a captura não tem a moldura do navegador, resolvido incluindo a URL. E "The Model Fixes The Symptom, Not The Root Cause" quando há só uma captura, resolvido anexando uma segunda de uma tela relacionada. Ambos são um argumento para pedir mais uma captura ao cliente antes de escalar.
Veja o que a API aceita para os três tipos de evidência que um relatório de bug do WhatsApp traz:
| Evidência | Suporte da API Muse Spark | Limites que vale conhecer |
|---|---|---|
| Captura de tela | JPEG, PNG, GIF, WebP, ICO (Image understanding) | Até 50 por requisição, 50 MB inline; uma imagem de ~1280 px custa cerca de 1.300 a 1.500 tokens |
| Gravação de tela | Somente MP4, gravações sem áudio permitidas (Video and audio understanding) | Sem duração máxima, taxa de quadros ou custo em tokens de vídeo publicados |
| Mensagem de voz | O áudio na 1.3 "is currently not fully supported"; use a 1.2 ou o Muse Voice Transcribe | O Transcribe aceita só WAV mono, 10 minutos e 32 MB por arquivo |
Duas lacunas específicas do WhatsApp. As mensagens de voz chegam como OGG/Opus, e nem a entrada de áudio do modelo (MP3 ou WAV) nem o Muse Voice Transcribe (WAV mono de 16 bits) aceita esse formato, então é preciso converter antes; a documentação da Meta traz um comando de ffmpeg. E no vídeo, a Meta não publica nenhum limite além do formato, então teste com suas próprias gravações antes de confiar.
Para receber os passos em um formato que seu sistema de tickets consiga usar, defina response_format com um esquema JSON. A Meta diz "decoding itself is constrained, so the output is guaranteed to conform" (Structured output), e um array plano steps[] de {action, expected, observed} (a mesma ideia do JSON mode em outros lugares) cabe bem dentro do limite de 10 níveis de aninhamento. O alerta do próprio cookbook de gráficos da Meta vale aqui também: ele "guarantees the shape, not that the model read the chart correctly". Um JSON de reprodução limpo ainda pode estar errado.
Uma regra que você não pode pular: use o nível padrão. Os Termos de Serviço da Meta dizem "You must not submit sensitive, confidential, or personal information to the Discounted Services", e acrescentam que código que você precisa manter confidencial também não pode ir para lá. Capturas de tela de clientes estão cheias de nomes, e-mails e números de conta, e estão entre os dados de suporte mais sensíveis que você tem. Então os relatórios de bug vão para o muse-spark-1.3 padrão, a $1.25 de entrada e $4.25 de saída por 1 M de tokens, onde "your prompts and completions are not used to train Meta models" (Pricing and rate limits).
Etapa 3: reproduzir em código com o Muse Code
A última etapa é a prova: um teste que falha por causa do bug. É nisso que agentes de programação são bons, e o próprio cookbook do Muse Code da Meta traz um exemplo. O jogo de exemplo, Bastion Breaker, vem com "one planted rule bug", e sua suíte de testes o mostra logo de cara: test_enemy_shot_does_not_destroy_bricks FAILED. A correção roda em um subagente dentro de um worktree git próprio, então a branch principal fica intocada até você revisar. Cobri o harness na minha análise do Muse Code.
O padrão a aproveitar: entregue ao Muse Code o JSON de reprodução da Etapa 2 e peça primeiro um teste que falha, depois uma correção. Um teste que falha um engenheiro consegue verificar em um minuto. Uma correção sem ele é um palpite com um diff anexado, o mesmo conselho que eu daria para depurar com o Claude Code ou qualquer outro agente.
Desenvolvedores que já trabalham assim relatam a mesma coisa:
"In many cases it will have figured out the bug. In many cases it will have produced a small, clean, deterministic reproducer. In my daily work I see these cases. It does help that the bugs that are filed contain a test case and some analysis by the agent."
Duas ressalvas da documentação do Muse Code. Seu sandbox está ligado desde a primeira execução e falha de forma fechada, que é o que você quer quando o agente executa código com base no relatório de bug de um desconhecido. E o Muse Code não tem limite de gasto: ele cobra os mesmos tokens do Muse Spark, três agentes observadores em segundo plano rodam por padrão, e o único freio documentado, --max-model-steps, só existe no modo headless. O detalhamento dos preços do Muse Code tem os pormenores.
Quanto custa reproduzir bugs no stack da Meta
Cada estação tem seu próprio medidor:
| Peça | O que faz | Custo |
|---|---|---|
| Meta Business Agent | Recebe o relatório e transfere | $2.00 por 1 M de tokens, cerca de 4 a 5 centavos por mensagem (preços do WhatsApp) |
| Respostas humanas após a transferência | Sua equipe acompanha o cliente | 1.000 mensagens de serviço grátis por número ao mês, depois por mensagem a partir de 1º de out. de 2026 |
| API Muse Spark | De captura de tela ou gravação a passos de reprodução | $1.25 de entrada / $4.25 de saída por 1 M de tokens, $0.15 de entrada em cache |
| Muse Voice Transcribe | De mensagem de voz a texto | $0.18 por hora de áudio, cobrado por segundo |
| Muse Code | Teste que falha e correção | Mesmas tarifas de tokens do Muse Spark, sem limite de gasto |
| Seu código de ligação | Webhook standby, download de mídia, criação do ticket | Sua própria hospedagem |
A captura de tela em si é barata, cerca de um quinto de centavo de entrada nas tarifas padrão. A linha cara é a segunda. Relatórios de bug são os tickets com mais idas e vindas ("qual versão?", "pode enviar outra captura?"), e a partir de 1º de outubro cada uma dessas respostas humanas é cobrada depois de passar dos 1.000 gratuitos. Meu post sobre os preços da API do WhatsApp Business tem o histórico completo de tarifas.
Onde o stack da Meta fica devendo na reprodução de bugs
Sendo justo, as peças individuais são boas. O cookbook Error screenshot fix é um dos melhores passo a passo de reprodução de bugs que li de um fornecedor de modelos, e um teste que falha em um worktree isolado é a saída certa para a última etapa. Os limites estão nas junções entre as peças:
- O tratamento que o Business Agent dá à mídia do cliente não está documentado. Planeje como se ele não pudesse ver a captura de tela.
- Não há caminho de arquivos até o seu ticket. As ferramentas conectoras só enviam JSON, então as capturas passam pelos webhooks standby e pelo seu próprio código de download.
- Standby ou resumo, não os dois. Você escolhe entre guardar as evidências e ter o resumo da Meta.
- Uma janela de mídia de 7 dias. Triagem lenta perde anexos.
- Uma IA por número. "An active authorized-agent integration blocks Meta Business Agent" (visão geral), então você não pode rodar o Business Agent e outra IA de suporte no mesmo número. A posição mais ampla da Meta está em sua política sobre IA de terceiros.
- Três produtos, três cobranças, três conjuntos de logs. Nada liga a conversa do WhatsApp, o JSON de reprodução e a execução do teste a um só ticket, a menos que você construa isso.
A parte que a Meta não toca: o ticket
A lição que eu tiraria disso vem mais da própria fila de suporte da eesel do que da documentação da Meta. Um dos relatórios mais técnicos que o colega de helpdesk da eesel já tratou foi a falha de hardware de um engenheiro de campo: um problema em um estágio (stage) que gerava os códigos de erro 6001, 3174 e 5169 em uma rede EtherCAT. O agente fez seis buscas nos manuais em PDF do cliente, leu dois por inteiro e redigiu uma resposta com testes de isolamento passo a passo. Nada disso é mágica. Funcionou porque o relatório, os manuais e a resposta estavam todos no mesmo ticket.
Essa é a lacuna real em uma configuração centrada na Meta. Cada etapa acima pode funcionar, e mesmo assim o relatório chega ao seu helpdesk como um resumo em prosa sem captura de tela, enquanto o JSON de reprodução fica em um log e o teste que falha em outro. Equipes de suporte nas ligações de vendas da eesel descrevem o mesmo desejo com outras palavras: uma IA que saiba "when to pull a real person in" e que fique quieta em vez de adivinhar quando não tem certeza. Um suposto bug é exatamente esse caso. Ele precisa de evidências preservadas, da transferência para um humano certa e de um ticket de engenharia sobre o qual alguém possa agir. Esse é o cerne de tratar escalonamentos com IA, e é a parte que a Meta deixa por sua conta.
Veja como isso aparece da cadeira do cliente:
"support responded me by asking build version, my os version, device type - me screenshot all the requested details + manually wrote down in response email so someone can also copy-paste somewhere directly from my email - support responds by asking me to clear my iphone cache(sending me a guide for Android's App data cleaning process)"
Esse é o lado do cliente de um ticket em que as evidências e a conversa foram separadas. Ninguém nesse ciclo foi descuidado. Os detalhes só não estavam onde a próxima pessoa olhou.
Experimente a eesel para relatórios de bug vindos do suporte
A eesel começa pela ponta do ticket no revezamento. É um colega de helpdesk com IA que trabalha dentro do Zendesk, Freshdesk e Jira Service Management. Também pode responder no WhatsApp e tem uma integração dedicada com o Jira Service Management.
Para um relatório de bug, a cadeia é esta, e cada passo está na documentação:
- Ele lê as evidências. No Zendesk e no Freshdesk ele "reads up to five images or PDFs per turn" (documentação do Zendesk), então a captura de tela faz parte do que ele analisa. Para ser claro sobre o limite: "Videos, zip files and other formats are ignored", então uma gravação de tela ainda precisa de um olhar humano.
- Ele pede o que falta. Você escreve a regra em linguagem simples ("peça a versão do app, o dispositivo e os passos antes de escalar um bug") e ela vale a partir do próximo ticket.
- Ele verifica se há duplicata. No Jira Service Management ele pode executar Search Issues com JQL "so your agent can find related or duplicate issues" (documentação do JSM), o que poupa a engenharia de reproduzir o mesmo bug duas vezes. Se o Jira é o seu centro, meu guia do Jira AI agent e o post Meta Muse for JSM cobrem a ligação.
- Ele cria a issue para aprovação. Create Issue define projeto, resumo, descrição, responsável e labels, e você pode configurar como needs-approval para que uma pessoa aprove cada ticket de engenharia (Actions and approvals).
Mais um limite, com honestidade: a eesel não consegue anexar arquivos a uma issue do Jira, então a captura de tela fica no ticket do helpdesk e a issue do Jira aponta de volta para ele. Ela também não tem integração pronta com Linear ou GitHub Issues; se é lá que seus engenheiros vivem, o caminho é o Network Access, que permite ao colega chamar uma API REST que você autorize.
Se seus engenheiros preferem não abrir mais um painel, a CLI da eesel executa o mesmo colega a partir de um terminal. Todo comando imprime JSON, então um engenheiro, ou um agente de programação como o Claude Code ou o Codex, pode consultar eesel activity para ver quais relatórios de bug o colega escalou e por quê, aprovar issues pendentes do Jira com eesel approvals approve e ajustar as regras de escalonamento com eesel automations enable sem sair do repositório. É o mesmo terminal onde o teste que falha roda, um bom lugar para as duas metades de um relatório de bug se encontrarem. Há também uma API de agente de atendimento ao cliente se você quiser integrá-lo às suas próprias ferramentas.
Por causa da regra da Meta de uma IA por número, você rodaria a eesel ou o Business Agent como IA em um determinado número de WhatsApp, não os dois. Para um leque maior de opções, veja minha lista das melhores IAs para suporte por WhatsApp. Se você é uma equipe pequena em que um desenvolvedor lê todos os relatórios de bug do WhatsApp, o Business Agent mais um webhook standby e a receita Error screenshot fix é uma construção razoável. Se os relatórios chegam por WhatsApp e e-mail e precisam chegar ao Jira com as evidências anexadas, rodar onde o ticket vive dá menos para manter. Os preços são um plano mensal fixo de créditos, a partir de $299 por 500 créditos, em que um ticket ou chat é um crédito, não importa quantas respostas leve. Você pode rodá-lo primeiro nos seus tickets antigos para ver como ele teria tratado os relatórios de bug do mês passado.
Experimente a eesel grátis com 100 créditos, sem cartão.
Perguntas frequentes
Posso usar o Meta Muse para reprodução de bugs?
O Meta Business Agent consegue ler a captura de tela de um cliente?
O Meta Business Agent consegue enviar um relatório de bug para o Jira?
Por quanto tempo as capturas de tela de relatórios de bug do WhatsApp ficam disponíveis?
A API Muse Spark consegue transformar uma gravação de tela em passos de reprodução?
Quanto custa o Meta Muse para reprodução de bugs?
Posso usar o nível barato para colaboradores do Muse Spark em relatórios de bug?
Qual é uma boa alternativa à Meta para relatórios de bug vindos do suporte?
Article by
Kira
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
