Confiabilidade para a empresa agente

Os agentes autônomos apresentam padrões de execução não deterministas fundamentalmente diferentes da automação tradicional do Salesforce. Enquanto o Salesforce Flow e o Apex seguem caminhos previsíveis que produzem resultados repetíveis em condições controladas, os agentes explicam os problemas dinamicamente. Por exemplo, a mesma pergunta feita duas vezes pode seguir caminhos de execução diferentes, consumir recursos diferentes e produzir resultados diferentes. Esse não determinismo cria desafios de confiabilidade que as abordagens tradicionais de teste e monitoramento não abordam.

Os modos de falha de confiabilidade do agente são categoricamente diferentes das falhas do Salesforce Flow ou do Apex. Os serviços de inferência de modelo de idioma grande (LLM) representam dependências externas com características de disponibilidade separadas da Salesforce Platform. Os agentes geram respostas que ocasionalmente violam a estrutura esperada, apesar das instruções de prompt. A preparação de contexto do agente consome os limites do controlador de modo imprevisível. A recuperação de dados sem limite afeta os agentes mais severamente porque os agentes podem solicitar contexto de término aberto, enquanto as consultas determinísticas têm controle de escopo explícito.

Uma arquitetura de agente confiável exige uma cadeia de fallback de vários níveis que se degrada de modo simples: de agentes sofisticados a agentes mais simples com contexto reduzido, a mecanismos de regras deterministas e, por fim, a transferência humana por meio do Omni-Channel. Os Eventos de plataforma aprimoram filas de novas tentativas duráveis com padrões de ponto de verificação, permitindo que fluxos de trabalho com falha sejam retomados da última etapa bem-sucedida. Os interruptores de circuito rastreiam a integridade do serviço LLM no Cache da plataforma para status em tempo real, com o suporte de Tipos de metadados personalizados para limites e configuração, roteando para padrões de fallback após falhas consecutivas. O monitoramento exige rastrear as taxas de sucesso da conversa, o tempo médio entre falhas (MTBF), o tempo médio até a recuperação (MTTR) e a precisão de fundamentação. A Agentforce Observability fornece rastreamentos de sessão, métricas de integridade e latência, e taxas de escalação e desvio, mas você ainda precisará instrumentar métricas de confiabilidade como MTBF, MTTR e precisão de fundamentação.

Este documento abrange as alterações quando os agentes estão no cenário. Para obter padrões de confiabilidade fundamentais aplicáveis a todas as soluções do Salesforce (design de objeto de nível de serviço (SLO), tolerância a falhas, escalação e monitoramento), consulte o pilar Confiabilidade.

Agentes Agentforce falham de maneiras diferentes do Salesforce Flow ou do Apex. É entender esses modos de falha que moldam a arquitetura de confiabilidade.

Indisponibilidade do serviço LLM: Os pontos de extremidade de inferência do LLM enfrentam picos de latência ocasionais ou problemas de disponibilidade. Agentforce é listado como um produto monitorado em trust.salesforce.com junto com o Analytics e outros serviços do Salesforce. No entanto, a latência de inferência de LLM granular e as métricas de desempenho por solicitação não são expostas lá. Implemente os disruptores de circuito usando o Cache da plataforma para o estado em tempo real de baixa latência, com suporte em Tipos de metadados personalizados para limites e configuração, para rastrear a integridade do serviço do LLM. O Cache da plataforma é o melhor esforço: as entradas podem ser expulsas antes de seu tempo de ativação (TTL), portanto, mantenha o estado aberto/descartado em um repositório durável, como um Objeto personalizado, em vez de apenas no cache. Ajuste a condição da viagem para o ponto de extremidade: uma contagem de falhas consecutivas (por exemplo, cinco) ou uma taxa de erro que ultrapassa um limite em uma janela dinâmica. Quando o circuito viaja, abra-o e encaminhe para padrões de fallback, como avisos mais simples, respostas em cache ou transferência humana, até que uma solicitação de teste bem-sucedida indique a recuperação.
Falhas de validação de resposta: Os agentes ocasionalmente geram respostas que violam a estrutura esperada, apesar das instruções de prompt. Às vezes, um agente retorna JSON malformado, omite campos obrigatórios ou inclui tipos de dados inesperados. O Cache da plataforma pode armazenar esquemas de resposta validados, habilitando a validação rápida. Quando a validação falha, tente novamente com avisos refinados, incluindo o erro de validação e um exemplo de estrutura correta. Defina um número máximo de novas tentativas (3 a 5) para evitar loops infinitos de novas tentativas.
Detecção de alucinação: Quando os dados de fundamentação estão incompletos, os agentes produzem informações plausíveis, mas incorretas. Diferentemente de consultas determinísticas que retornam “não encontrado”, os agentes preenchem lacunas com inferência. A Trilha de auditoria da Camada de Trust do Einstein registra cada aviso, aviso mascarado, resposta, resultado da detecção de toxicidade e feedback do usuário para revisão de governança pós-hoc. No entanto, ele não captura rastreamentos de raciocínio passo a passo. Para captura de raciocínio passo a passo, use o Rastreamento de sessão do Agentforce, que registra as execuções do mecanismo de raciocínio. Exija que os agentes citem fontes de recuperação de geração aumentada por recuperação (RAG) do Data 360 (antigo Data Cloud). Reivindicações de agente de referência cruzada contra origens recuperadas para capturar desvios fatos antes da execução da ação. Uma verificação em linha adiciona pouca latência, pois é executada em fontes que já estão no contexto. Uma verificação que precisa de uma viagem de ida e volta separada, como uma segunda chamada de modelo ou um serviço externo, custa mais. Reserve essas verificações para gravações de alto impacto, incluindo atualizações financeiras ou de pedido, e execute-as de modo assíncrono durante a conversa em tempo real.
Governor limit picos: A preparação de contexto do agente consome consultas de linguagem de consulta de objeto (SOQL) do Salesforce, tempo de CPU e memória de heap de modo imprevisível com base no fluxo de conversa. O Proactive Monitoring é um serviço de direitos do Signature Success (antigo Suporte de assinatura) no Plano Salesforce Success, em que o Salesforce monitora proativamente as contas dos clientes. O Proactive Monitoring não é um alerta configurável por autoatendimento disponível a todos os clientes. Para monitoramento de limite do regulador de autoatendimento, use o Centro de escala para identificar operações de agente com uso intensivo de recursos que se aproximam dos limites. Implemente a paginação em ações do agente recuperando grandes coleções de registros. Para dados de referência acessados com frequência, use o Cache da plataforma.
Dados discrepantes no contexto do agente: Os agentes que recuperam contexto para contas com mais de 10 mil oportunidades, ou casos com históricos de atividades comparáveis, encontram os mesmos desafios de distorção de dados que o Apex em lote. Diferentemente de consultas determinísticas em que você controla o escopo, o raciocínio do agente pode solicitar “todo o histórico” de modo imprevisível. Para evitar isso, projete ações do agente com limites rígidos sensíveis (por exemplo, um limite na ordem de 200 filhos por pai) e implemente estratégias de amostragem quando os limites forem excedidos. O limite define quantos dados entram no contexto do agente. Combine-o com filtros seletivos indexados para que a consulta em si fique barata, pois um filtro não indexado ou agregado em um pai discrepante verifica o conjunto filho completo antes da aplicação do limite.

Projete cadeias de fallback de vários níveis, permitindo que os agentes continuem funcionando com capacidade reduzida em vez de falhar completamente.

Agente principal com contexto completo: Agente sofisticado com a fundamentação completa do Data 360, amplo histórico de conversas e raciocínio complexo. Qualidade mais alta, mas com maior uso de recursos e maior risco de falha.
Agente secundário com contexto reduzido: Agente mais simples usando contexto condensado (por exemplo, últimos 30 dias vs. todo o histórico, os cinco principais resultados da pesquisa do vetor versus os 20 principais). O contexto menor significa menos tokens, inferência mais rápida e menor probabilidade de falha, mas somente se o contexto reduzido ainda abranger os dados de que a tarefa precisa.
Mecanismo de regras deterministas: Fluxo do Salesforce tradicional ou lógica do Apex que lida com cenários comuns quando o raciocínio do agente falha. As regras não podem se adaptar a novas situações, mas lidam com padrões conhecidos com confiança. O agente de validação de pedido volta para regras de validação padrão, enquanto o agente de pontuação de lead volta para o cálculo de pontuação baseado em regra.
Envio humano via Omni-Channel: Roteie para a fila humana quando as opções automatizadas estiverem esgotadas. Configure o roteamento baseado em habilidades para garantir que os escalonamentos alcancem o conhecimento adequado. Passe todo o contexto da conversa, incluindo tentativas de estratégias, quaisquer pontuações de confiança que você calcular para o agente e motivos de falha, para habilitar uma intervenção humana eficiente.

Implemente a lógica de fallback na orquestração do Salesforce Flow ou do Apex acionada por Eventos de plataforma. Cada nível registra qual estratégia foi bem-sucedida, criando visibilidade dos padrões de falha e da eficácia de fallback.

Todos os padrões de Evento de plataforma nesta seção presumem tipos de Evento de plataforma de alto volume, que fornecem a janela de retenção de repetição de 72 horas. Eventos de plataforma de volume padrão são retidos por apenas 24 horas. Use tipos de evento de alto volume para todos os padrões de resistência do agente, fila de nova tentativa e ponto de verificação em que a durabilidade de repetição é um requisito de confiabilidade. Os Eventos de plataforma fornecem mensagens duráveis que permitem que os fluxos de trabalho do agente sobrevivam a falhas e se recuperem automaticamente.

Progresso do agente do ponto de verificação: Fluxos de trabalho de agente de várias etapas publicam eventos de ponto de verificação após cada etapa bem-sucedida. O agente de processamento de contrato conclui a extração de documento, publica o evento ContractParsed com os dados extraídos e avança para a análise da cláusula. Se a análise de cláusula falhar, reproduza o evento ContractParsed para retomar dos dados extraídos sem analisar novamente. Isso funciona quando a carga útil do ponto de verificação carrega esses dados e o assinante é idempotente, pois a reprodução reenvia eventos em vez de retomar um fluxo de trabalho no meio da etapa. Armazene o estado do ponto de verificação na carga útil do evento, incluindo ID de correlação, etapas concluídas e estado necessário para continuação.
Fila de repetição com recuo exponencial: Solicitações de agente com falha são publicadas no evento AgentRetryRequested com contagem de novas tentativas na carga útil. O assinante do evento processa novas tentativas com atrasos exponenciais em pendências (por exemplo, 30 segundos, 2 minutos, 8 minutos, 30 minutos). Após o máximo de novas tentativas (geralmente 5), encaminhe para a fila de falhas e operações de alerta. Os eventos de plataforma de alto volume preservam uma janela de repetição de 72 horas. Use o tipo de evento de alto volume para filas de nova tentativa do agente para que os assinantes possam acompanhar as janelas de manutenção da organização ou o tempo de inatividade da implementação. Eventos de plataforma de volume padrão são retidos por apenas 24 horas.
Orquestração acionada por evento: Projete fluxos de trabalho do agente como cadeias de eventos soltas. A criação de lead publica LeadCreated. O agente de pontuação de lead assina, pontua e publica LeadScored. O agente de roteamento de lead assina LeadScored e atribui à fila apropriada. Cada agente pode falhar e tentar novamente de modo independente. Uma falha de um único agente não bloqueia todo o fluxo de trabalho – os agentes a jusante processam quando as dependências são recuperadas.
Rastreamento de ID de correlação: Inclua um ID de correlação como um campo personalizado em todas as cargas úteis de evento relacionadas. Repita eventos usando a API Pub/Sub by replayId, um identificador opaco e não contíguo, para reconstruir o histórico de fluxo de trabalho dentro da janela de retenção de 72 horas. Para habilitar a depuração baseada em ID de correlação, implemente um padrão no lado do assinante que registra eventos recebidos com seu replayId e ID de correlação em um objeto personalizado, habilitando o rastreamento entre eventos. Esse padrão de registro é uma implementação personalizada que você mesmo cria, não uma funcionalidade de consulta de plataforma nativa.

Mova operações de agente que excedem limites síncronos para um contexto assíncrono, o que permite limites de controlador maiores e tempos limite mais longos.

Apex em lote para operações de agente em massa: Um agente que analisa mais de 1.000 registros se beneficia do Apex em lote que fornece 200 consultas SOQL, 150 instruções DML (até 10.000 linhas DML) e 60.000 milissegundos (60 segundos) de tempo de CPU por método de execução. Agente de pontuação de lead processando importações de leads noturnas. Análise de sentimento do caso em casos históricos. Previsões de oportunidade analisando pipelines completos.
Cadeias enfileiráveis para fluxos de trabalho em várias etapas: Fluxos de trabalho de agente complexos que exigem várias chamadas de API externas, análise de conjunto de dados grande ou tempo de processamento estendido usam cadeias do Apex enfileiráveis. Cada trabalho enfileirável obtém 60 CPU de tempo e 12 MB de heap. Encadeie para o próximo enfileirável para fluxos de trabalho que excedem os limites de trabalho único. Acompanhe o progresso em Objetos personalizados para que um trabalho com falha possa ser retomado na última etapa concluída.
@future para transferências assíncronas simples: Operações de agente leves, como envio de notificações, registro em sistemas externos ou atualizações não urgentes, usam métodos @future. O padrão de foco e esquecimento é adequado quando um fluxo de trabalho não precisa de resultados de volta e pode tolerar falha.

Monitore a capacidade de processamento assíncrono por meio da página Trabalhos do Apex (Configuração → Trabalhos do Apex) e da Fila Flex do Apex. Um máximo de 5 trabalhos em lote simultâneos limita o processamento de agente paralelo; fila de trabalhos adicionais na Fila flexível do Apex, que contém até 100 trabalhos no status de Espera. Todos os tipos de Apex assíncronos, Lote, Futuro, Enfileirável e Agendado do Apex compartilham o mesmo limite diário em toda a organização (DailyAsyncApexExecutions) em execuções assíncronas do Apex: maior que 250 mil ou 200 vezes o número de licenças de usuário. Quando você executa a pesquisa de agente de alta frequência ou tenta novamente as filas do assinante, o Filas pode rapidamente esgotar essa cota. Para evitar isso, coloque essas filas em lote ou no limite para permanecer dentro do limite, o que se aplica em toda a organização em todos os tipos assíncronos do Apex, não como uma alocação separada apenas para o Queueable. Alerte quando o consumo se aproximar desses limites para que as equipes possam gerenciar a capacidade de modo proativo.

Valide a resiliência do agente antes da produção por meio de estratégias de teste que lidam com o comportamento não determinista.

Teste de carregamento no Full Copy Sandbox: Teste o desempenho do agente sob a carga em escala de produção usando volumes de dados completos. Simule conversas simultâneas que correspondem à demanda máxima. Meça a latência p95 e p99, identificando a degradação do desempenho sob estresse. Validar o consumo do limite do regulador permanece abaixo dos limites na carga máxima. O carregamento de testes em um sandbox de Cópia parcial com dados reduzidos proporciona confiança enganosa, pois o volume de dados afeta diretamente o desempenho do agente. Antes de executar esses testes, obtenha a aprovação da Salesforce (pelo menos uma semana antes para solicitações de teste de desempenho). Testes não aprovados podem ser limitados ou bloqueados.
Injeção de falha: Introduza intencionalmente falhas para validar mecanismos de recuperação. Simule falhas de inferência do LLM na camada de serviço que seu disjuntor monitora para verificar se o disjuntor é ativado. Injecte exceções SOQL para testar o tratamento de erros. Respostas corrompidas do agente para testar a lógica de validação. Apresente o desvio de dados (contas com mais de 10.000 filhos) para testar a lógica de paginação. Defina tempos limite agressivos para testar a manipulação de tempo limite e tentar estratégias novamente.
Engenharia de caos: Desabilite aleatoriamente os assinantes de Evento de plataforma para testar a recuperação de reprodução. Encerre trabalhos assíncronos no meio da execução para testar a reinicialização do ponto de verificação. Apresente a latência variável a sistemas externos para testar estratégias de tempo limite progressivo. Experimentos de caos validam a resiliência em combinações de falha realistas. Agende dias de caos regulares em ambientes de preparação, mantendo a resiliência à medida que os agentes evoluem.
Testes de estabilidade de longa duração: Execute cargas de trabalho do agente continuamente por mais de 72 horas, monitorando falhas dependentes de tempo. Erros acumulados e degradação gradual do desempenho só surgem em operação sustentada. Acompanhe tendências de tempo de CPU para identificar degradação gradual ao longo da execução.

Defina indicadores de nível de serviço (SLIs) habilitando a medição de confiabilidade do objeto. Estabeleça SLOs antes de criar agentes, não após falhas de produção.

Taxa de sucesso da conversa: Percentual de conversas do agente concluídas sem erros ou tempos limite. Conta uma transferência agradável para um ser humano como um sucesso, não como uma falha: a escalação é o nível de fallback final por design. Conte escalonamentos com falha ou inadvertidos com base na métrica – é um sinal de confiabilidade útil, mas um proxy imperfeito para a experiência do usuário, pois um logout educado pode mascarar um problema não resolvido. Acompanhe separadamente por tipo de agente e caso de uso, pois os critérios de sucesso da pontuação de lead diferem da revisão do contrato. Alerte quando a taxa de sucesso cair abaixo do SLO (geralmente de 95 a 99%).
Tempo médio entre falhas (MTBF): Tempo médio de operação entre falhas do agente. MTBF maior indica menos falhas e maior confiabilidade. Calcule como o total de horas operacionais do agente dividido pela contagem de falhas. Acompanhe por tipo de agente para identificar os agentes menos confiáveis que exigem investimento na otimização.
Tempo médio até a recuperação (MTTR): Tempo médio da detecção de falha até a restauração do serviço. A recuperação automatizada por meio de repetição de evento de plataforma e quebradores de circuito restaura o serviço com muito mais rapidez e com menos erro manual do que a intervenção prática. MTTR inferior reduz o impacto dos negócios por incidente.
Precisão de aterrissagem: Percentual de respostas do agente factualmente corretas com base na validação dos dados de origem. Amostras de respostas aleatórias do agente para validar declarações em fontes do Data 360. A precisão da fundamentação abaixo de 95% indica problemas de alucinação que exigem refinamento imediato ou melhor recuperação de contexto.
Falhas de repetição de evento de plataforma: Contagem de eventos perdidos ou não entregues, por exemplo, um assinante offline além da janela de retenção. Lacunas zero são um sinal positivo de uma arquitetura orientada por evento saudável. Lacunas indicam problemas do assinante, falhas na publicação de eventos ou restrições de capacidade. Acompanhe essas lacunas com o padrão de registro no lado do assinante descrito acima e registre o replayId e o ID de correlação de cada evento em um objeto personalizado.

Agentes confiáveis vêm de projetar antecipadamente para falhas: definir SLIs/SLOs, manipulação de contexto sensível ao limite do regulador e cadeias de fallback de vários níveis antes de criá-las, em vez de aprimorá-las posteriormente. Interruptores de circuito de camada e lógica de ponto de verificação baseada em evento de plataforma para que os fluxos de trabalho sejam recuperados automaticamente, com transferência humana como último recurso. Valide esse projeto por meio de carregamento sistemático, injeção de falhas e teste de caos e, em seguida, continue monitorando os mesmos SLIs em produção para confirmar que ele se mantém com o tempo.

A orientação de confiabilidade no principal pilar de Confiabilidade se aplica a agentes com considerações específicas da plataforma abordadas aqui. Arquiteturas de agente bem-sucedidas equilibram a funcionalidade autônoma com a supervisão adequada, permitindo a auto-recuperação de falhas temporárias enquanto escalam quando a confiança diminui ou casos de ponta aparecem.

Compartilhe seu feedback sobre o Framework bem-construído.