Fiabilidad para la compañía agente

Los agentes autónomos presentan 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 monitoreo 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 lenguaje 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 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 degrada con gracia: desde agentes sofisticados a agentes más sencillos con contexto reducido, pasando por motores de reglas deterministas y, finalmente, hasta 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 con fallos 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. El monitoreo requiere realizar un seguimiento de los índices de éxito de pláticas, el tiempo medio entre fallos (MTBF), el tiempo medio hasta la recuperación (MTTR) y la precisión de la 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 necesitará 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 de nivel de servicio (SLO), tolerancia a fallos, ampliación y monitoreo), 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 desempeño 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 pueden desalojarse 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 de la caché sola. Ajuste la condición del viaje al extremo: un conteo de fallos consecutivos (por ejemplo, cinco) o un índice de error que cruza un umbral en un plazo continuo. 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 respuesta: Los agentes generan ocasionalmente respuestas que infringen la estructura esperada a pesar de las instrucciones de solicitud. Un agente a veces devuelve un 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 las brechas con inferencia. El Seguimiento de auditoría de Einstein Trust Layer registra cada solicitud, solicitud enmascarada, respuesta, resultado de detección de toxicidad y comentarios de usuarios para la revisión de gobernanza post-hoc. Sin embargo, no captura rastros de razonamiento paso a paso. Para la captura de razonamientos paso a paso, utilice Rastreo de sesiones Agentforce, que registra ejecuciones del motor de razonamiento. Requiera 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 detectar 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 plática 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 plática. Proactive Monitoring es un servicio de asignación de Signature Success (anteriormente Signature Support) en el Salesforce Success Plan, donde Salesforce monitorea de forma proactiva cuentas de clientes. Proactive Monitoring no es una alerta configurable de autoservicio disponible para todos los clientes. Para el monitoreo de límites del regulador de autoservicio, utilice Centro de escala para identificar operaciones de agentes que requieren muchos recursos y se aproximan a los límites. Implemente paginación en acciones de agentes recuperando grandes recopilaciones de registros. Para datos de referencia a los que se accede con frecuencia, utilice Caché de plataforma.
Desfase de datos 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 Apex por lotes. 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 estrictos 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 indexados selectivos de modo que la consulta en sí se mantenga 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 seguir funcionando con capacidad reducida en vez de fallar completamente.

Agente principal con contexto completo: Agente sofisticado con fundamentación de Data 360 completa, historial de pláticas extenso y razonamientos complejos. Máxima calidad pero con mayor uso intensivo 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 de vectores 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 puntuaje de prospectos vuelve al cálculo de puntuaje 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 plática completo (incluyendo estrategias intentadas, cualquier puntuaje de confianza que calcule para el agente y motivos de fallo) para permitir una 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 se realizó con éxito, creando visibilidad sobre patrones de fallo y efectividad de reserva.

Todos los patrones de Eventos de plataforma en esta sección asumen tipos de Eventos 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 todos los patrones de resistencia de agentes, colas de reintentos y puntos de control donde la durabilidad de la reproducción es un requisito de fiabilidad. Eventos de plataforma proporciona mensajería duradera permitiendo a los flujos de trabajo de agentes sobrevivir a fallos y recuperarse automáticamente.

Progreso de agente 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 falla el análisis de cláusulas, reproduzca 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 eventos, incluyendo el Id. de correlación, los pasos completados y el estado necesario para la continuación.
Reintentar cola con retroceso exponencial: Las solicitudes de agentes fallidas se publican en el evento AgentRetryRequested con conteo de reintentos en la carga. El suscriptor del evento 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 después de plazos de mantenimiento de la organización o 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 prospectos publica LeadCreated. El agente de puntuaje de prospectos se suscribe, puntúa y publica LeadScored. El agente de enrutamiento de prospectos 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 el flujo de trabajo completo: los agentes descendentes procesan cuando se recuperan 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 capacidad de consulta de plataforma nativa.

Mueva las 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.

Apex por lotes para operaciones de agentes masivos: Un agente que analiza más de 1.000 registros se beneficia de Apex por lotes que proporciona 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 puntuaje de prospectos que procesa importaciones nocturnas de prospectos. Análisis de opiniones de casos entre casos históricos. Pronósticos de oportunidades analizando oportunidades en curso completas.
Cadenas colocables 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 prolongado utilizan cadenas Apex colocables en cola. Cada trabajo colocable en cola obtiene 60 de tiempo de CPU y 12 MB de pila. Encadena a siguiente Colocable 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 con fallo 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 de vuelta y puede tolerar fallos.

Monitoree 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 colocan en cola en Apex Flex Queue, que alberga hasta 100 trabajos en estado Espera. Todos los tipos de Apex asíncronos, Apex por lotes, futuros, colocables en cola y programados, comparten el mismo límite diario de toda la organización (DailyAsyncApexExecutions) en ejecuciones Apex asíncronas: 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, los colocables en cola 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 de Apex asíncronos, no como una asignación separada para Colocable en cola únicamente. 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 desempeño de agentes bajo carga a escala de producción utilizando volúmenes de datos completos. Simule pláticas simultáneas que coincidan con picos de demanda. Mida la latencia de p95 y p99, identificando la degradación del desempeño bajo estrés. Validar el límite regulador de consumo permanece 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 desempeño de los agentes. Antes de ejecutar estas pruebas, obtenga la aprobación de Salesforce (al menos una semana antes para solicitudes de pruebas de desempeño). Las pruebas no aprobadas se pueden reducir 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 monitorea su disyuntor, para verificar que el disyuntor se activa. Inyecte excepciones SOQL para probar la gestión de errores. Respuestas de agentes dañadas para probar la lógica de validación. Presente 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 trabajos asíncronos a mitad de la ejecución para probar el reinicio de puntos 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.
Pruebas de estabilidad de larga duración: Ejecute cargas de trabajo de agentes de forma continua durante más de 72 horas, monitoreando fallos dependientes del tiempo. La acumulación de errores y la degradación gradual del desempeño afloran solo bajo operación sostenida. Realice un seguimiento de las tendencias de tiempo de CPU para identificar la degradación gradual durante 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 pláticas: Porcentaje de pláticas de agentes completadas sin errores ni tiempos de espera. Cuente una entrega elegante a un humano como un éxito, no un fracaso: la distribución es el nivel de reserva final por diseño. Conteo 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 puntuaje de prospectos difieren de la revisión de contratos. Alerta cuando el índice de éxito cae por debajo de SLO (normalmente 95-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 conteo de fallos. Realice un seguimiento por tipo de agente para identificar agentes menos fiables que requieren inversión de optimización.
Tiempo medio hasta la 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 y disyuntores 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 de negocio 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 la fundamentación por debajo del 95% indica problemas de alucinaciones que requieren un ajuste rápido o una mejor recuperación del contexto.
Desfases de reproducción de eventos de plataforma: Conteo 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 Id. de repetición y correlación de cada evento en un objeto personalizado.

Los agentes fiables proceden del diseño para fallos por adelantado: definiendo SLI/SLO, controlando contextos conscientes de límites reguladores y cadenas de reserva de múltiples niveles antes de construir, 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 recuperan 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 monitoreando los mismos SLI en producción para confirmar que se mantiene a lo largo del tiempo.

Las directrices de fiabilidad en el 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 de trabajo bien diseñado.