Pruebe un agente de IA en Agentforce Testing Center: solicite recibos de resultados

Si necesitas probar un agente de IA en Agentforce Testing Center , utilice sus evaluaciones de subagente, acción y respuesta como tres piezas de evidencia separadas, no como un veredicto de liberación. El valor predeterminado razonable es: ejecutar casos positivos y negativos en una zona de pruebas, requerir pases nuevos para la ruta y las acciones esperadas y luego verificar el efecto comercial de forma independiente antes de la promoción. Ese último recibo importa. Un agente puede elegir el subagente esperado, llamar a la acción esperada y producir una respuesta aceptable mientras el cambio de registro previsto está ausente, duplicado, aplicado al alcance incorrecto o aún esperando aprobación. Una fila de prueba verde demuestra lo que evalúa esa fila. No prueba automáticamente el resultado del destino. Esta guía convierte una prueba de Agentforce en una puerta de promoción de ocho estados. El dispositivo no almacena declaraciones, respuestas, registros de clientes ni secretos; solo mantiene los estados de aprobación/rechazo, actualidad, estado de aprobación y un veredicto de resultado recepción. El resultado del Centro de Pruebas es evidencia, no el veredicto de liberación La corriente de Salesforce unidad de configuración de prueba describe casos de prueba con una expresión, un subagente esperado, acciones esperadas y una respuesta esperada. Es unidad de resultados luego expone el subagente y las acciones reales, además de evaluaciones separadas del subagente, la acción y la respuesta. Esa separación es útil porque cada falla apunta a una reparación diferente: Fallo del subagente: la ruta seleccionó el límite de responsabilidad incorrecto. Fallo de acción: la ruta era plausible, pero faltaba la operación requerida o era diferente. Fallo de respuesta: la ruta y las llamadas pueden ser correctas, pero la respuesta no satisfizo el resultado semántico esperado. No colapse esos campos en un solo porcentaje. Supongamos que un caso de actualización de contacto pasa la evaluación de respuesta porque el agente dice que la dirección se actualizó. Si la evaluación de la acción falla, la oración no es evidencia de que se haya producido la escritura. Incluso cuando se aprueban las tres evaluaciones, una lectura del destino sigue siendo la prueba más sólida de un efecto secundario. La misma precaución se aplica a la frescura. Una ejecución aprobada para la versión 12 del agente, la revisión 4 del conjunto de pruebas y los metadatos de la acción de ayer no pueden certificar la versión 13 después de un cambio de instrucción o permiso. Vincular cada decisión de promoción a al menos: Mantenga el recibo sin contenido. Almacene identificadores, versiones, marcas de tiempo, valores booleanos y hashes opacos. No copie indicaciones, datos de clientes, credenciales ni respuestas de modelos completos en un registro de seguimiento. También existe un límite de seguridad antes de que cualquier puntuación importe. La corriente de Salesforce unidad de consideraciones y herramientas de prueba advierte que las pruebas del agente pueden modificar los datos de CRM y les indica a los operadores que realicen pruebas en una zona de pruebas. Trátelo como una condición previa estricta, no como una nota a pie de página. Utilice dispositivos dedicados, registros reversibles, identidades de prueba con privilegios mínimos y verificación de limpieza. Una prueba exitosa que afectó la producción por error no es una prueba saludable. Convierta una prueba en una puerta de ascenso a ocho estados El artefacto inspeccionable que acompaña a este artículo evalúa ocho casos sin contenido en un orden estricto. Ese orden evita que un campo verde aguas abajo oculte una falla anterior: Estado Evidencia Decisión del operador RUN INCOMPLETE El trabajo de prueba no se ha completado Esperar; no infieras el fracaso o el éxito STALE RESULT El resultado supera la antigüedad de la evidencia aceptada. Vuelva a ejecutar con las versiones previstas SUBAGENT MISMATCH Error en la evaluación del subagente Ruta de reparación, alcance o expectativa de prueba ACTION MISMATCH La evaluación de la acción falló Inspeccionar permisos, instrucciones y plan de acción. RESPONSE MISMATCH La evaluación de la respuesta falló Reparar criterios de respuesta o comportamiento de respuesta WAITING Una aprobación legítima es pendiente Notificar al propietario; preservar el contexto del currículum OUTCOME UNVERIFIED Los campos del centro de pruebas pasan, falta la prueba de destino Vuelva a leer el efecto antes de la promoción. HEALTHY La nueva ruta, la acción, la respuesta y la evidencia de resultados coinciden Permitir la decisión de promoción limitada. Ejecute el artefacto con Node.js: El resumen esperado es: El experimento importante es el último par de casos. Ambos tienen una ejecución nueva y completa y pasan las evaluaciones de subagente, acción y respuesta. effect unverified no tiene recibo de destino y resuelve OUTCOME UNVERIFIED ; healthy agrega una lectura verificada y resuelve HEALTHY . Un campo cambia el veredicto de liberación. Esa lectura debería coincidir con el resultado prometido: Para una actualización CRM, consulte el registro deseado con una identidad de prueba aislada y compare solo los campos esperados. Para un correo electrónico o una notificación, verifique la bandeja de salida de la zona de pruebas o el recibo del proveedor y haga valer exactamente un efecto aceptado. Para obtener una respuesta de conocimiento, valide las citas requeridas o los identificadores de fuentes en lugar de comparar la prosa palabra por palabra. Para una transferencia de flujo de trabajo, verifique el registro de transferencia duradera, el propietario, la fecha límite y el token de reanudación. Para una solicitud que requiere autoridad, registre WAITING ; No marque el agente bloqueado solo porque se detuvo correctamente. Intencionalmente, este no es un evaluador universal. El clasificador supone que ha asignado los campos de resultados actuales de Agentforce a su propio contrato de recibo estable. No juzga la calidad objetiva, no simula las frases de cada usuario ni demuestra que un sandbox refleja los permisos de producción. Tampoco puede decidir su línea base de tasa de aprobación aceptable. La documentación de Salesforce señala que el comportamiento generativo es probabilístico y que cada organización debe definir su propio umbral de preparación para la producción. Ejecute el simulacro y luego establezca el límite de producción. Comience con una tarea de alto valor cuyo resultado sea inspeccionable de manera determinista. No empiece con mil mensajes generados. Una suite más pequeña con expectativas confiables revelará más que una suite grande cuyas acciones esperadas fueron copiadas de una ejecución incidental. 1. Congele la identidad de la prueba. Registre la versión del agente, la revisión de la suite, la revisión de los metadatos de la acción, la revisión del conjunto de permisos y el identificador de la zona de pruebas. 2. Definir casos positivos y negativos. La guía de configuración de Salesforce recomienda ambos. Incluya una solicitud válida, una solicitud no válida, una solicitud no permitida, un caso de falta de permiso y un caso que requiere aprobación. 3. Ejecutar en una caja de arena. Sembrar registros reversibles y probar limpieza. Cancele si el entorno o la identidad son ambiguos. 4. Inspeccione las tres evaluaciones por separado. Repare el primer límite fallido. Una reescritura de respuesta no debe ocultar una acción faltante. 5. Vuelva a leer el resultado. Utilice una aserción específica de destino con una clave de idempotencia o un registro de prueba estable. 6. Repetir los casos sanos. Una sola pasada no expone descamación probabilística. Mantenga visibles el recuento de ejecuciones y el intervalo de confianza en lugar de declarar certeza. 7. Promocione solo el artefacto fijado. Si las instrucciones, acciones, permisos, configuración del modelo o expectativas de prueba cambian, el recibo anterior caducará. 8. Supervise el resultado en vivo por separado. La evaluación previa a la producción reduce el riesgo; no reemplaza la accesibilidad, el cronograma, el estado de espera, el permiso, el costo o el estado de entrega después del lanzamiento. Ese límite final es donde divergen las pruebas y la salud del agente. Las pruebas preguntan si los escenarios seleccionados se comportan de manera aceptable antes de promover un cambio. El estado operativo pregunta si el agente en ejecución sigue siendo accesible, realiza avances útiles, alcanza sus herramientas, respeta los límites de aprobación y produce el resultado esperado ahora. Necesitas ambos, pero uno no puede sustituir al otro. Sidewisp está diseñado en torno a esa capa de salud operativa: actualización de evidencia, progreso útil, acceso a herramientas, espera versus estancamiento y resultados verificados. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público y la demostración interactiva están en vivo; No se envían un adaptador Agentforce de producción, un motor de monitoreo en vivo ni un ejecutor de recuperación automatizado. El paso práctico hoy es conservar el recibo sin contenido junto a la prueba de Agentforce y rechazar la promoción cuando aún se desconoce el resultado del destino.