Actualizado el Nov 1, 2026

Pruebas y Depuración

Lo que aprenderás

• Cómo usar el botón Iniciar depuración para probar pre-acciones
• Cómo probar tu agente en una conversación en vivo
• Cómo probar un agente a través de la API y ver todos los mensajes que envió
• Cómo usar los niveles de registro y los logs para diagnosticar problemas

Antes de conectar tu agente de IA a un canal de producción, es importante probarlo a fondo. AutoTalk ofrece varias herramientas para probar y depurar agentes en diferentes niveles.

Depurar pre-acciones

Si tu agente LLM usa pre-acciones (configuradas en la pestaña Acciones), puedes probarlas sin ejecutar una conversación completa:

1. Abre el agente y ve a la pestaña Acciones.
2. Haz clic en el botón Iniciar depuración (cuya descripción emergente dice "Depurar todo").
3. AutoTalk ejecuta cada paso de pre-acción en secuencia y te muestra el resultado de cada uno, incluyendo cualquier dato producido o error encontrado.

Esto te permite verificar que cada paso funciona correctamente antes de que el agente entre en operación. Si un paso falla, puedes corregirlo y hacer clic en Iniciar depuración de nuevo de inmediato.

Probar con conversaciones en vivo

La manera más realista de probar un agente es asignarlo a un canal y enviarle mensajes como lo haría un contacto:

1. Asigna el agente a un canal de prueba (o a un número/cuenta secundaria que controles).
2. Envía mensajes a ese canal desde un teléfono personal o un navegador.
3. Observa cómo responde el agente en la bandeja de entrada de AutoTalk.
4. En la vista de conversación, busca el interruptor del bot -- este te permite habilitar o deshabilitar el agente por conversación. Úsalo para alternar entre respuestas automatizadas y manuales durante las pruebas.

Qué probar

• Preguntas comunes: Haz los tipos de preguntas que tus contactos reales hacen con más frecuencia.
• Casos extremos: Intenta preguntas ambiguas, fuera de tema o de varias partes para ver cómo las maneja el agente.
• Pruebas de límites: Pregunta sobre temas que el agente debería rechazar (para verificar que tus mensajes del sistema establecen las barreras adecuadas).
• Uso de herramientas: Si el agente tiene herramientas configuradas, activa escenarios que deberían provocar llamadas a herramientas y verifica los resultados.
• Conversaciones largas: Continúa una conversación durante muchos intercambios para verificar que el contexto se mantiene y que el agente no pierde el hilo.

Probar a través de la API (talkToAgent)

Para pruebas automatizadas y scripts de evaluación, un agente puede accionarse sin un canal real. La función talkToAgent envía un mensaje al agente, como un contacto en el canal de API del propio agente, ejecuta el agente y devuelve lo que volvió:

POST /v1/dynadata/type/agents/item/{agentId}/executeFunction/talkToAgent

{"type": "text", "body": {"text": "Quiero reservar una cita"}}

La clave de API necesita el scope automation:admin. type es obligatorio -- envíalo también para un mensaje de texto: una solicitud sin él se rechaza con 400 y {"error": "missing_fields", "fields": ["type"], "message": "Missing required argument(s): type", …}. Acepta uno de estos valores: text, image, audio, video, document, location, options, option o contacts; los mensajes image, audio, video y document necesitan un body.file. Omite contactId para empezar con un contacto de API nuevo, y pasa el data.contactId de una respuesta anterior para continuar la misma conversación.

La respuesta usa el sobre de /v1 -- success y data --, con lo que devolvió talkToAgent dentro de data. Una llamada exitosa responde 200:

{
  "success": true,
  "data": {
    "success": true,
    "contactId": "…",
    "messages": [
      {"role": "assistant", "body": {"controlType": "…"}, "type": "control"},
      {"role": "assistant", "content": "¿Qué día te viene bien?", "type": "text"}
    ],
    "outboundMessages": [
      {"role": "assistant", "messageId": "…", "type": "options", "body": {"…": "…"}},
      {"role": "assistant", "messageId": "…", "type": "text", "content": "¿Qué día te viene bien?"}
    ],
    "logs": [{"level": "info", "message": "talkToAgent started"}, "…"]
  }
}

• data.messages es el búfer de respuesta de la ejecución: lo que escribió el modelo, más entradas internas de type: "control" -- registros de llamadas a herramientas, por ejemplo -- que el contacto nunca ve. No incluye lo que enviaron las herramientas del agente. Así que, cuando una herramienta envió la respuesta y el modelo no escribió nada más después -- una ejecución que terminó en tool_reply, que es también como la termina una herramienta con Termina el turno --, messages solo tiene entradas internas; lee outboundMessages para ver lo que recibió el contacto.
• data.outboundMessages es lo que el contacto recibió de verdad durante la llamada, del más antiguo al más reciente: mensajes enviados por herramientas -- un documento o un menú de opciones de Componer Respuesta de la Conversación, por ejemplo -- y la respuesta final, cada uno una vez. Cada entrada es {role, messageId, type, content?, body?}: content es el texto o el pie, y body se conserva en todo mensaje que no es texto, así que un documento conserva su archivo y un menú sus opciones. Los mensajes internos de estado quedan fuera, y la lista tiene como máximo 50 mensajes -- 20 en un caso alternativo descrito abajo.
• Cubre esta conversación solamente. Una herramienta que avisó a otra persona -- alguien del equipo, por ejemplo -- envió ese mensaje a otra conversación, así que no está en la lista.
• outboundMessages: null significa que la lista no pudo leerse (el motivo está en logs), no que no se envió nada. Nada enviado es una lista vacía.
• La lista se lee de la conversación por tiempo, así que cualquier otra cosa que envíe al mismo contacto durante la llamada -- un segundo talkToAgent con el mismo contactId, o un workflow que reacciona al mensaje -- también aparece.
• Caso alternativo. Cuando el búfer de respuesta de la ejecución no vuelve a la llamada, messages se lee de la conversación: como máximo 20 mensajes del agente, así que sí incluye lo que enviaron las herramientas, y también las entradas internas. Eso pasa cuando otra ejecución ya estaba respondiendo a este contacto (la llamada espera los mensajes de esa ejecución), o cuando no volvió nada de la ejecución. En el segundo caso, outboundMessages sale de esa misma lectura, sin las entradas internas, así que tiene como máximo 20 mensajes en lugar de 50. En los dos casos la llamada deja de esperar en la primera lectura que encuentra algún mensaje del agente, así que, si la ejecución todavía estaba enviando en ese momento, las dos listas pueden quedar incompletas. En el primer caso, outboundMessages sale de una segunda lectura de la conversación, hecha después de esa, así que un mensaje que la ejecución envió entre las dos lecturas está en outboundMessages pero no en messages; lo que envió después de la última lectura no está en ninguna de ellas.

data.success: false significa que la función se ejecutó, pero rechazó el mensaje o falló: data.error dice el motivo, y data.logs muestra hasta dónde llegó. El estado HTTP sigue siendo 200 y el success de fuera sigue siendo true -- solo dice que la función se llamó --, así que revisa data.success:

{"success": true, "data": {"success": false, "error": "For text messages, body.text must be a non-empty string.", "logs": []}}

Una solicitud que la API rechaza, o que falla fuera del propio talkToAgent, no tiene data: responde con un estado de error y un objeto de error. Una clave sin automation:admin recibe 403 con {"error": "scope_denied", "code": "scope_denied", "message": "…", "userMessage": "…", "details": {…}}, un id de agente que no existe recibe 400 con {"error": "not_found", …}, y la mayoría de los fallos inesperados también recibe 400, con {"error": "dynadata_function_error", "code": "execution_error", "message": "…", "userMessage": "…", "details": null}. Solo un fallo fuera de la propia llamada a la función recibe 500, con {"success": false, "errorId": "…", "message": "Internal server error"}.

Usar los niveles de registro para la depuración

Cada agente tiene una configuración de Nivel de registro en su formulario de configuración. Durante las pruebas y la depuración, establécelo en un nivel de verbosidad más alto para capturar más detalles sobre lo que el agente está haciendo internamente.

Una vez que el agente esté estable y en producción, puedes reducir el nivel de registro para disminuir el ruido y el uso de almacenamiento. Consulta Ver Logs para conocer los detalles sobre dónde encontrar y leer los logs.

Problemas comunes y soluciones

Problema	Causa posible	Solución
El agente da información imprecisa	Los mensajes del sistema son muy vagos o faltan datos clave	Agrega detalles más específicos a los mensajes del sistema en la pestaña Mensajes
El agente no usa sus herramientas	Las descripciones de las herramientas son poco claras o la selección de herramienta está mal configurada	Revisa las descripciones de las herramientas en la pestaña Herramientas y asegúrate de que la selección de herramienta esté en "auto"
Las respuestas son muy largas o divagan	La temperatura es muy alta o el máximo de tokens no está definido	Reduce la temperatura en la pestaña Avanzado y establece un límite de tokens
El agente responde sobre temas que debería evitar	Faltan barreras en los mensajes del sistema	Agrega instrucciones explícitas de "no hagas" a los mensajes del sistema
Las pre-acciones fallan silenciosamente	Un paso tiene una configuración incorrecta	Usa el botón "Iniciar depuración" (descripción emergente "Depurar todo") en la pestaña Acciones para identificar el paso que falla
El agente no responde en absoluto	El agente no está asignado al canal, o el interruptor del bot está desactivado	Verifica la asignación del canal y confirma que el interruptor del bot esté habilitado en la conversación
El agente envía un menú de opciones y después más texto debajo	El modelo tomó otro turno después de la herramienta del menú	Activa Termina el turno en esa herramienta (ver Mensajes del sistema y herramientas)

Próximos pasos

• Ver logs
• Mensajes del Sistema y Herramientas