Depurador de Conversas
O que ele faz
Depurar manualmente uma conversa longa de um agente é tedioso. O Debugger automatiza a parte que você faria manualmente: ler cada turno, encontrar onde o problema começou e explicar o que deu errado em termos da configuração do agente.
É uma análise assistida por IA — o modelo lê a conversa e produz um veredito estruturado. Você fornece o Id da conversa e, opcionalmente, uma instrução (por exemplo, “por que o agente não enviou o e-mail?”); o Debugger retorna sua análise como um objeto estruturado.
O Resultado da Análise
| Campo | Significado |
|---|---|
rootCause |
Uma breve declaração do que realmente deu errado — não o sintoma, a causa subjacente. |
problemAtSequence |
O número de sequência da mensagem onde o problema se originou. Clique para ir até esse turno na transcrição e ver a troca responsável. |
evidence |
A citação específica, chamada de ferramenta, contexto ausente ou fragmento de prompt montado que sustenta o diagnóstico. |
recommendations |
Uma lista curta de correções concretas — por exemplo, adicionar uma ferramenta, editar um prompt, expandir uma configuração de campo de contexto. |
severity |
low, medium ou high — o quão grave é o problema encontrado, não o quanto o analisador está certo. Não existe pontuação de confiança. |
stopReason |
O motivo de parada do modelo para a execução do agente analisada (end_turn, max_tokens, stop_sequence). A interface exibe isso para que você identifique respostas truncadas imediatamente. |
creditsUsed |
Créditos consumidos pela chamada de análise. |
rawAnalysis |
Se o JSON estruturado não pôde ser interpretado, a saída bruta do modelo é retornada aqui como alternativa. |
error |
Preenchido para falhas que não são exceções — limite de créditos atingido, restrições de licença, problemas de configuração. |
O Que o Debugger Inspeciona
Para a conversa em análise, o Debugger vê os mesmos dados que orientaram a execução original, além das saídas dessa execução:
- O prompt de sistema montado do agente — persona, instruções, esquema e diretrizes de idioma
- As ferramentas que o agente tinha disponíveis, com categorias, níveis e canais
- A configuração dos campos de contexto e o contexto de registro efetivamente carregado
- Cada mensagem de usuário e de assistente em sequência
- Cada chamada de ferramenta — nome da ferramenta, entrada, saída (ou erro)
- O uso de tokens e o motivo de parada de cada turno do agente
- Sua instrução opcional em linguagem natural (por exemplo, “por que a resposta está vazia?”)
Esse é o panorama completo que o Debugger precisa para chegar a uma conclusão útil — nada fica escondido em uma caixa-preta.
Como Ele Difere de Ferramentas Relacionadas
- Pré-visualização de Execução do Agente mostra o que um agente vai carregar na próxima conversa. Gratuita e somente leitura. Use-a para verificar a configuração antes que qualquer conversa aconteça.
- Transcrição de Conversas mostra as mensagens brutas e as chamadas de ferramentas. Gratuita, sem análise.
- Depurador de Conversas aplica análise de IA à transcrição e retorna um diagnóstico. Consome créditos, mas produz uma declaração real de causa raiz e recomendações.
Use a Transcript quando você conseguir ler uma conversa curta mentalmente; use o Debugger quando a conversa for longa, o sintoma for sutil ou você quiser uma segunda opinião.
Como Funciona uma Execução
-
Abra a conversa
Seja pela lista de conversas da guia REDA AI Admin, seja diretamente por um link do Salesforce para o registro de Conversation subjacente.
-
Clique em Debug Conversation
A interface do Debugger carrega a transcrição e o histórico de ferramentas.
-
Adicione uma instrução
Se você tiver uma pergunta específica (“por que não chamou
send_email?”, “por que a resposta veio no idioma errado?”), digite-a. Sem uma instrução, o Debugger procura qualquer problema óbvio ao longo da conversa. -
Execute a análise
A plataforma envia o contexto da conversa para o modelo e aguarda a resposta estruturada.
-
Leia o resultado
Causa raiz, sequência do problema, evidências, recomendações e severidade são exibidos ao lado da transcrição, para que você possa verificar a análise em relação à troca real.
-
Aplique as recomendações
As correções costumam ser feitas na definição do agente, em um Prompt personalizado, em uma configuração de campo de contexto ou em uma ferramenta. Execute novamente uma conversa semelhante após a correção para confirmar.
Severidade e stopReason
A análise traz uma severidade — high, medium ou low — que descreve o quão grave é o problema encontrado, não o quanto o Debugger está certo dele. Não existe uma pontuação de confiança separada. high aponta para um problema de configuração claro que vale corrigir agora; medium, algo que merece atenção; low normalmente significa que a conversa foi um caso extremo, e não um bug.
Junto com ela você recebe Problem at sequence — o número da mensagem em que, segundo a análise, as coisas deram errado, para ir direto àquele turno da transcrição — e Evidence, o trecho em que a conclusão se apoia. Leia a evidência antes de agir sobre a recomendação: é o que permite discordar do Debugger quando ele erra.
Preste atenção separada ao stopReason:
end_turn— o modelo terminou de forma limpa. O diagnóstico é sobre conteúdo, não sobre infraestrutura.max_tokens— a resposta foi truncada pelo orçamento de resposta. Costuma ser a causa real quando o agente “não responde”. Aumente o orçamento de saída do agente ou simplifique o prompt.stop_sequence— o modelo atingiu uma parada configurada. Menos comum; geralmente esperado.
A interface exibe o stopReason diretamente, para que você reconheça o truncamento antes de ler o restante da análise.
stopReason informa como max_tokens.
Custo em Créditos e Tempo
Cada análise é uma chamada de modelo. O custo em créditos escala com a extensão da conversa e o tamanho do contexto montado que o Debugger vê. A plataforma reporta os créditos efetivamente consumidos.
Conversas longas com muitas chamadas de ferramentas custam mais créditos e demoram mais para serem analisadas, porque mais transcrição é enviada ao modelo.
O Que o Debugger Não Faz
- Não corrige nada automaticamente. A saída é um diagnóstico com recomendações; você aplica as correções manualmente na definição do agente, nos prompts, nas ferramentas ou nos campos de contexto.
- Não executa a conversa novamente. A análise é feita sobre a transcrição já existente. Para validar uma correção, execute uma conversa semelhante e (opcionalmente) depure essa também.
- Não garante uma única causa raiz. Algumas conversas têm vários problemas; o Debugger escolhe a causa raiz mais provável, mas deve ser combinado com o seu julgamento.
- Não substitui o Registro de incidentes. Falhas graves (exceções Apex, erros de callout) são registradas no Registro de incidentes. O Debugger é para problemas comportamentais em que a conversa foi concluída, mas o resultado ficou errado.
Boas Práticas
Comece com uma instrução. Uma execução vazia do Debugger produz uma análise genérica. Dizer ao Debugger o que te incomodou na conversa foca o diagnóstico.
Leia o stopReason primeiro. Se a resposta foi truncada, corrigir o orçamento costuma ser uma mudança de um único caractere, não uma reescrita do prompt.
Verifique a citação de evidência. O Debugger nomeia a sequência responsável e cita evidências. Clique para ir até esse turno antes de aceitar a recomendação; às vezes o modelo interpreta errado.
Aplique uma recomendação por vez. Aplique a recomendação mais acionável, execute uma conversa semelhante e depois itere. Várias mudanças simultâneas confundem a relação causa-efeito.
Combine com a Runtime Preview depois das correções. Depois de ajustar o agente, abra a Runtime Preview para confirmar que a correção realmente mudou o que o agente vê.
Perguntas frequentes
Não. Ele produz um diagnóstico com recomendações concretas. Você aplica as correções manualmente — geralmente pequenos ajustes em um prompt, uma ferramenta ou uma configuração de campo de contexto.
Sim. As execuções assíncronas produzem registros de conversa e mensagem idênticos aos das execuções síncronas; o Debugger os inspeciona da mesma forma. Veja Processamento assíncrono de agentes.
Ocasionalmente o modelo retorna um texto que não pode ser interpretado no formato JSON esperado. Quando isso acontece, o texto bruto é retornado em rawAnalysis como alternativa para que a análise não se perca. Executar novamente geralmente produz uma resposta estruturada limpa.
Sim. Todo canal produz os mesmos registros de conversa e mensagem. O Debugger lê esses registros diretamente, então o canal não importa.
Execute novamente com uma instrução mais específica informando ao Debugger o que estava errado. Severidade low geralmente significa que o analisador não conseguiu identificar o problema sem mais contexto. Uma instrução direcionada costuma elevar a severidade se o bug for real.
Falhas graves são registradas no Registro de incidentes. Para esses casos, use a ferramenta de depuração de incidentes. O Depurador de Conversas trata os casos em que a conversa foi executada, mas o resultado ficou errado.
As recomendações do Debugger apontam para coisas que você pode alterar — prompts, contexto, ferramentas. Se a análise disser “o modelo se comportou corretamente dada a configuração”, isso é uma dica direta de que você precisa mudar a configuração, não culpar o modelo.
Próximos passos
Leia Transcrições de conversas para entender a estrutura de registros subjacente que o Debugger lê, ou Debug with AI on Incidents para o mesmo padrão aplicado a falhas graves.