Fiabilidad para la empresa agente

Los agentes autónomos introducen patrones de ejecución no deterministas fundamentalmente diferentes de la automatización tradicional de Salesforce. Aunque Salesforce Flow y Apex siguen rutas predecibles que producen resultados repetibles bajo condiciones controladas, los agentes razonan problemas de forma dinámica. Por ejemplo, la misma pregunta formulada dos veces puede tomar diferentes rutas de ejecución, consumir diferentes recursos y producir diferentes resultados. Este no determinismo crea retos de fiabilidad que los enfoques tradicionales de pruebas y supervisión no abordan.

Los modos de fallo de fiabilidad de agentes son categóricamente diferentes de los fallos de Salesforce Flow o Apex. Los servicios de inferencia de modelo de idiomas grande (LLM) representan dependencias externas con características de disponibilidad separadas de Salesforce Platform. Los agentes generan respuestas que ocasionalmente infringen la estructura esperada a pesar de las instrucciones de solicitud. La preparación de contexto de agente consume límites reguladores de forma impredecible. La recuperación de datos sin límites afecta a los agentes de forma más grave porque los agentes pueden solicitar un contexto abierto mientras que las consultas deterministas tienen un control de ámbito explícito.

La arquitectura de agentes fiable requiere una cadena de reserva de múltiples niveles que se degrade correctamente, desde agentes sofisticados a agentes más sencillos con contexto reducido, pasando por motores de reglas deterministas y finalmente traspasos humanos a través de OmniCanal. Eventos de plataforma potencia colas de reintento duraderas con patrones de puntos de control, permitiendo que los flujos de trabajo fallidos se reanuden desde el último paso correcto. Los disyuntores realizan un seguimiento del estado del servicio LLM en Caché de plataforma para el estado en tiempo real, respaldado por Tipos de metadatos personalizados para umbrales y configuración, enrutando a patrones de reserva después de fallos consecutivos. La supervisión requiere el seguimiento de índices de éxito de conversación, tiempo medio entre fallos (MTBF), tiempo medio hasta la recuperación (MTTR) y precisión de fundamentación. Agentforce Observability proporciona rastreos de sesión, mediciones de estado y latencia, así como índices de distribución y desviación, pero aún tendrá que instrumentar mediciones de fiabilidad como MTBF, MTTR y precisión de fundamentación usted mismo.

Este documento trata lo que cambia cuando los agentes están en la imagen. Para consultar los patrones de fiabilidad fundamentales que se aplican a todas las soluciones de Salesforce (diseño de objetos a nivel de servicio (SLO), tolerancia a fallos, escala y supervisión), consulte el pilar Fiabilidad.

Los agentes Agentforce fallan de formas diferentes a Salesforce Flow o Apex. Comprender estos modos de fallo es lo que da forma a la arquitectura de fiabilidad.

Indisponibilidad del servicio LLM: Los extremos de inferencia LLM experimentan picos de latencia ocasionales o problemas de disponibilidad. Agentforce figura como producto supervisado en trust.salesforce.com junto con Analytics y otros servicios de Salesforce. Sin embargo, la latencia de inferencia LLM granular y las mediciones de rendimiento por solicitud no se exponen allí. Implemente disyuntores utilizando Caché de plataforma para estado en tiempo real de baja latencia, respaldado por Tipos de metadatos personalizados para umbrales y configuración, para realizar un seguimiento del estado del servicio LLM. Caché de plataforma es el mejor esfuerzo: las entradas se pueden desalojar antes de su tiempo de vida útil (TTL), de modo que persiste el estado abierto/disparado en un establecimiento duradero, como un Objeto personalizado, en vez del caché solo. Ajuste la condición del viaje al extremo: un recuento de fallos consecutivos (por ejemplo, cinco) o un índice de error que cruza un umbral en una ventana móvil. Cuando el circuito se desencadene, ábralo y enrute a patrones de reserva, como solicitudes más sencillas, respuestas en caché o traspaso humano, hasta que una solicitud de prueba satisfactoria indique recuperación.
Fallos de validación de respuestas: Los agentes generan ocasionalmente respuestas que infringen la estructura esperada a pesar de las instrucciones de solicitud. Un agente a veces devuelve JSON incorrecto, omite campos obligatorios o incluye tipos de datos inesperados. Caché de plataforma puede almacenar esquemas de respuesta validados, lo que permite una validación rápida. Cuando falle la validación, reinténtelo con solicitudes refinadas, incluyendo el error de validación y un ejemplo de estructura correcta. Establezca un número máximo de reintentos (3 a 5) para evitar bucles de reintento infinitos.
Detección de alucinaciones: Cuando los datos de fundamentación están incompletos, los agentes producen información plausible pero incorrecta. A diferencia de las consultas deterministas que devuelven “no encontrado”, los agentes rellenan los espacios con inferencia. El Seguimiento de auditoría de capa de Einstein Trust registra cada solicitud, solicitud enmascarada, respuesta, resultado de detección de toxicidad y comentarios de usuarios para una revisión de gobernanza post-hoc. Sin embargo, no captura rastros de razonamiento paso a paso. Para la captura de razonamiento paso a paso, utilice Rastreo de sesiones Agentforce, que registra ejecuciones del motor de razonamiento. Requerir a los agentes citar orígenes de recuperación de generación aumentada (RAG) de Data 360 (anteriormente Data Cloud). Haga referencia cruzada a reclamaciones de agentes con orígenes recuperados para capturar desviaciones de hechos antes de la ejecución de acciones. Una comprobación en línea agrega poca latencia, ya que se ejecuta en orígenes que ya están en contexto. Una comprobación que necesita un recorrido de ida y vuelta separado, como una segunda llamada de modelo o un servicio externo, cuesta más. Reserve estas comprobaciones para escrituras de alto impacto, incluyendo actualizaciones financieras o de pedidos, y ejecútelas de forma asíncrona durante la conversación en tiempo real.
Límite regulador de picos: La preparación de contexto de agente consume consultas de lenguaje de consulta de objetos de Salesforce (SOQL), tiempo de CPU y memoria de pila de forma impredecible basándose en flujo de conversación. Proactive Monitoring es un servicio de asignación de Signature Success (anteriormente Signature Support) en el Salesforce Success Plan, donde Salesforce supervisa de forma proactiva cuentas de clientes. Proactive Monitoring no es una alerta configurable de autoservicio disponible para todos los clientes. Para la supervisión de límites reguladores de autoservicio, utilice Centro de escala para identificar operaciones de agentes que requieren muchos recursos que se acercan a los límites. Implemente paginación en acciones de agentes recuperando grandes colecciones de registros. Para datos de referencia a los que se accede con frecuencia, utilice Caché de plataforma.
Datos sesgados en contexto de agente: Los agentes que recuperan contexto para cuentas con más de 10.000 oportunidades, o casos con historiales de actividad comparablemente grandes, encuentran los mismos retos de sesgo de datos que Batch Apex. A diferencia de las consultas deterministas donde controla el ámbito, el razonamiento de agentes puede solicitar “todo el historial” de forma impredecible. Para evitar esto, diseñe acciones de agentes con límites rígidos razonables (por ejemplo, un límite del orden de 200 secundarios por principal) e implemente estrategias de muestreo cuando se superen los límites. El límite limita la cantidad de datos que entran en el contexto del agente. Emparejarlo con filtros selectivos e indexados de modo que la consulta en sí permanezca barata, ya que un filtro no indexado o agregado en un principal sesgado explora el conjunto secundario completo antes de que se aplique el límite.

Diseñe cadenas de reserva de múltiples niveles, permitiendo a los agentes continuar funcionando con capacidad reducida en vez de fallar completamente.

Agente principal con contexto completo: Agente sofisticado con una fundamentación completa de Data 360, un historial de conversaciones amplio y un razonamiento complejo. Máxima calidad pero con mayor consumo de recursos y mayor riesgo de fallo.
Agente secundario con contexto reducido: Agente más sencillo utilizando contexto condensado (por ejemplo, los últimos 30 días frente a todo el historial, los 5 resultados de búsqueda vectorial principales frente a los 20 principales). Contexto más pequeño significa menos tokens, inferencia más rápida y una menor posibilidad de fallo, pero solo si el contexto reducido aún cubre los datos que necesita la tarea.
Motor de reglas determinista: Lógica tradicional de Salesforce Flow o Apex que gestiona escenarios comunes cuando falla el razonamiento de los agentes. Las reglas no pueden adaptarse a nuevas situaciones, pero gestionan de forma fiable patrones conocidos. El agente de validación de pedidos vuelve a las reglas de validación estándar, mientras que el agente de puntuación de candidatos vuelve al cálculo de puntuación basado en reglas.
Transferencia humana a través de OmniCanal: Enrute a cola humana cuando se agoten las opciones automatizadas. Configure el enrutamiento basado en habilidades para asegurarse de que las distribuciones alcanzan la experiencia apropiada. Pase el contexto de conversación completo, incluyendo estrategias intentadas, cualquier puntuación de confianza que calcule para el agente y motivos de fallo, para activar la intervención humana eficiente.

Implemente lógica de reserva en la orquestación de Salesforce Flow o Apex desencadenada por Eventos de plataforma. Cada nivel registra qué estrategia tuvo éxito, creando visibilidad en patrones de fallo y eficacia de reserva.

Todos los patrones de Evento de plataforma en esta sección asumen tipos de Evento de plataforma de gran volumen, que proporcionan el plazo de retención de reproducción de 72 horas. Los eventos de plataforma de volumen estándar se mantienen solo durante 24 horas. Utilice tipos de eventos de gran volumen para toda la resiliencia de agentes, colas de reintento y patrones de puntos de control donde la durabilidad de la reproducción es un requisito de fiabilidad. Eventos de plataforma proporciona mensajería duradera que permite a los flujos de trabajo de agentes sobrevivir a fallos y recuperarse automáticamente.

Progreso de agentes de punto de control: Los flujos de trabajo de agentes de múltiples pasos publican eventos de puntos de control después de cada paso correcto. El agente de procesamiento de contratos completa la extracción de documentos, publica el evento ContractParsed con datos extraídos y luego continúa con el análisis de cláusulas. Si el análisis de cláusulas falla, vuelva a reproducir el evento ContractParsed para reanudar desde los datos extraídos sin volver a analizar. Esto funciona cuando la carga del punto de control transporta esos datos y el suscriptor es idempotente, porque la reproducción vuelve a entregar eventos en vez de reanudar un flujo de trabajo a mitad de paso. Almacene el estado del punto de control en la carga de evento, incluyendo el Id. de correlación, los pasos completados y el estado necesario para la continuación.
Cola de reintento con retroceso exponencial: Las solicitudes de agentes fallidas se publican en el evento AgentRetryRequested con recuento de reintentos en la carga. El suscriptor de eventos procesa reintentos con retrasos de retroceso exponenciales (por ejemplo, 30 segundos, 2 minutos, 8 minutos, 30 minutos). Después de un máximo de reintentos (normalmente 5), enrute a operaciones de alerta y cola de letra muerta. Los eventos de plataforma de gran volumen mantienen un plazo de reproducción de 72 horas. Utilice el tipo de evento de gran volumen para colas de reintento de agentes de modo que los suscriptores puedan ponerse al día tras los plazos de mantenimiento de la organización o el tiempo de inactividad de implementación. Los eventos de plataforma de volumen estándar se mantienen solo durante 24 horas.
Orquestación dirigida por eventos: Diseñe flujos de trabajo de agentes como cadenas de eventos acopladas libremente. La creación de candidatos publica LeadCreated. El agente de puntuación de candidatos se suscribe, puntúa y publica LeadScored. El agente de enrutamiento de candidatos se suscribe a LeadScored y se asigna a la cola apropiada. Cada agente puede fallar y reintentarlo de forma independiente. Un fallo de agente único no bloquea todo el flujo de trabajo: los agentes descendentes procesan cuando se recuperan las dependencias.
Seguimiento de Id. de correlación: Incluya un Id. de correlación como un campo personalizado en todas las cargas de eventos relacionados. Reproduzca eventos utilizando la API Pub/Sub de replayId, un identificador opaco no contiguo, para reconstruir el historial de flujos de trabajo en el plazo de retención de 72 horas. Para activar la depuración basada en Id. de correlación, implemente un patrón del lado del suscriptor que registre eventos entrantes con su replayId e Id. de correlación en un objeto personalizado, activando la trazabilidad de eventos cruzados. Este patrón de registro es una implementación personalizada que crea usted mismo, no una función de consulta de plataforma nativa.

Mueva operaciones de agentes que superan los límites síncronos a un contexto asíncrono, lo que permite límites reguladores más altos y tiempos de espera más largos.

Lote Apex para operaciones de agentes masivos: Un agente que analiza más de 1.000 registros se beneficia de Batch Apex proporcionando 200 consultas SOQL, 150 declaraciones DML (hasta 10.000 filas DML) y 60.000 milisegundos (60 segundos) de tiempo de CPU por método de ejecución. Agente de puntuación de candidatos que procesa importaciones de candidatos nocturnas. Análisis de opiniones de casos entre casos históricos. Previsiones de oportunidades analizando oportunidades en curso completas.
Cadenas en cola para flujos de trabajo de múltiples pasos: Los flujos de trabajo de agentes complejos que requieren múltiples llamadas de API externas, análisis de conjuntos de datos de gran tamaño o tiempo de procesamiento ampliado utilizan cadenas Apex en cola. Cada trabajo en cola obtiene 60 de tiempo de CPU y 12 MB de pila. Encadena a siguiente En cola para flujos de trabajo que superan los límites de un solo trabajo. Realice un seguimiento del progreso en Objetos personalizados de modo que un trabajo fallido pueda reanudarse desde el último paso completado.
@future para transferencias asíncronas sencillas: Las operaciones de agentes ligeras, como el envío de notificaciones, el registro en sistemas externos o actualizaciones no urgentes, utilizan métodos @future. El patrón de disparo y olvido se ajusta cuando un flujo de trabajo no necesita resultados y puede tolerar fallos.

Supervise la capacidad de procesamiento asíncrono a través de la página Trabajos Apex (Configuración → Trabajos Apex) y la cola flexible Apex. Un máximo de 5 trabajos por lotes simultáneos limita el procesamiento de agentes paralelos; los trabajos adicionales se incluyen en la cola flexible de Apex, que alberga hasta 100 trabajos en estado Espera. Todos los tipos asíncronos de Apex, Batch, Future, Queueable y Apex programado comparten el mismo límite diario de toda la organización (DailyAsyncApexExecutions) en ejecuciones asíncronas de Apex: el mayor de 250 000 o 200 veces el número de licencias de usuario. Cuando ejecuta sondeos de agentes de alta frecuencia o reintenta colas de suscriptores, las colas pueden agotar rápidamente esta cuota. Para evitar esto, ponga en lote o acelere estas colas para permanecer dentro del límite, que se aplica en toda la organización en todos los tipos Apex asíncronos, no como una asignación separada para Cola por separado. Alerta cuando el consumo se acerca a estos límites de modo que los equipos puedan gestionar la capacidad de forma proactiva.

Valide la resiliencia de los agentes antes de la producción a través de estrategias de prueba que abordan el comportamiento no determinista.

Pruebas de carga en Sandbox de copia completa: Pruebe el rendimiento de agentes bajo carga a escala de producción utilizando volúmenes de datos completos. Simule conversaciones simultáneas que coincidan con picos de demanda. Mida la latencia de p95 y p99, identificando la degradación del rendimiento bajo tensión. Valide que el límite regulador de consumo permanezca por debajo de umbrales en carga máxima. Las pruebas de carga en un entorno sandbox de copia parcial con datos reducidos proporcionan una confianza engañosa, ya que el volumen de datos afecta directamente al rendimiento de los agentes. Antes de ejecutar estas pruebas, obtenga la aprobación de Salesforce (al menos una semana antes para solicitudes de pruebas de rendimiento). Las pruebas no aprobadas se pueden acelerar o bloquear.
Inyección de fallo: Introduzca deliberadamente fallos para validar mecanismos de recuperación. Simule fallos de inferencia LLM en la capa de servicio que supervisa su disyuntor, para verificar que el disyuntor se activa. Introduzca excepciones de SOQL para probar la gestión de errores. Respuestas de agentes dañadas para probar la lógica de validación. Introduzca el sesgo de datos (cuentas con más de 10.000 hijos) para probar la lógica de paginación. Establezca tiempos de espera agresivos para probar estrategias de gestión de tiempos de espera y reintento.
Ingeniería del caos: Desactive aleatoriamente suscriptores de eventos de plataforma para probar la recuperación de repeticiones. Termine los trabajos asíncronos a mitad de la ejecución para probar el reinicio del punto de control. Introduzca la latencia variable en sistemas externos para probar estrategias de tiempo de espera progresivo. Los experimentos de Caos validan la resiliencia en combinaciones de fallos realistas. Programe días de caos regulares en entornos de organización, manteniendo la resiliencia a medida que evolucionan los agentes.
Ensayos de estabilidad de larga duración: Ejecute cargas de trabajo de agentes de forma continua durante más de 72 horas, supervisando fallos dependientes del tiempo. La acumulación de errores y la degradación gradual del rendimiento afloran solo bajo operación sostenida. Realice un seguimiento de las tendencias de tiempo de CPU para identificar la degradación gradual a lo largo de la ejecución.

Defina indicadores de nivel de servicio (SLI) que permiten la medición de fiabilidad objetiva. Establezca SLO antes de los agentes de construcción, no después de fallos de producción.

Índice de éxito de conversaciones: Porcentaje de conversaciones de agentes completadas sin errores o tiempos de espera. Cuente un traspaso elegante a un humano como un éxito, no un fracaso: la distribución es el nivel de reserva final por diseño. Recuento de distribuciones fallidas o no intencionadas en la medición: es una señal de fiabilidad útil, pero un proxy imperfecto para la experiencia del usuario, ya que un cierre de sesión educado puede enmascarar un problema no resuelto. Realice un seguimiento separado por tipo de agente y caso de uso ya que los criterios de éxito de puntuación de candidatos difieren de la revisión de contratos. Alerta cuando el índice de éxito cae por debajo de SLO (normalmente 95 a 99%).
Tiempo medio entre fallos (MTBF): Tiempo operativo medio entre fallos de agentes. MTBF más alto indica menos fallos y mejor fiabilidad. Calcule como total de horas operativas de agentes divididas por recuento de fallos. Realice un seguimiento por tipo de agente para identificar agentes menos fiables que requieren inversión de optimización.
Tiempo medio de recuperación (MTTR): Tiempo medio desde la detección del fallo hasta la restauración del servicio. La recuperación automatizada a través de la reproducción de eventos de plataforma e interruptores restaura el servicio mucho más rápido y con menos errores manuales que la intervención práctica. Un MTTR más bajo reduce la repercusión comercial por incidente.
Precisión de fundamentación: Porcentaje de respuestas de agentes correctas de hecho basándose en validación de datos de origen. Muestre respuestas de agentes aleatorios para validar reclamaciones en orígenes de Data 360. La precisión de fundamentación por debajo del 95% indica problemas de alucinaciones que requieren un rápido refinamiento o una mejor recuperación del contexto.
Desfases de reproducción de eventos de plataforma: Recuento de eventos perdidos o no entregados, por ejemplo, un suscriptor sin conexión más allá del plazo de retención. Cero brechas es una señal positiva de una arquitectura dirigida por eventos saludable. Las brechas indican problemas de suscriptor, fallos de publicación de eventos o restricciones de capacidad. Realice un seguimiento de estas brechas con el patrón de registro del lado del suscriptor descrito anteriormente y registre el replayId y el Id. de correlación de cada evento en un objeto personalizado.

Los agentes fiables proceden del diseño para fallos de antemano: definiendo SLI/SLO, controlando el contexto de límite regulador y cadenas de reserva de múltiples niveles antes de la creación, no atornillándolas después. Disyuntores de capa y reintento basado en eventos de plataforma y lógica de punto de control de modo que los flujos de trabajo se recuperen automáticamente, con traspaso humano como último recurso. Valide ese diseño a través de pruebas sistemáticas de carga, inyección de fallos y caos, luego siga supervisando los mismos SLI en producción para confirmar que se mantiene con el tiempo.

Las directrices de fiabilidad del pilar principal Fiabilidad se aplican a agentes con consideraciones específicas de plataforma tratadas aquí. Las arquitecturas de agentes exitosas equilibran la capacidad autónoma con la supervisión apropiada, permitiendo la recuperación automática de fallos transitorios mientras se distribuyen cuando la confianza disminuye o surgen casos extremos.

Comparta sus comentarios sobre el Marco bien diseñado.