Skip to main content
Usa esta receta cuando un flujo de soporte deba:
  • heredar el enrutamiento y los valores predeterminados de prompts de un preset del panel
  • devolver una salida estructurada estricta
  • pausar los casos de riesgo para que los revise una persona
  • mantener visibles en los registros los fallos del gateway en lugar de ocultarlos en el código del agente

1. Empieza con un preset

Crea un preset como support-triage que defina:
  • el modelo enrutado predeterminado o el destino del router
  • las preferencias de proveedor
  • el prompt del sistema de soporte
  • los parámetros de decodificación estables
Así, el código del agente se centra en controlar el flujo de trabajo en vez de duplicar las políticas de solicitud.

2. Define un contrato acotado de clasificación

Mantén el formato de la primera salida lo bastante pequeño para que el equipo de operaciones pueda revisarlo rápidamente.

3. Crea el agente basado en el preset

El SDK resuelve preset: "support-triage" en el formato de alias del gateway @support-triage.

4. Configura el adaptador conectado al gateway

Usa valores predeterminados del adaptador para los elementos que deben mantenerse fijos en cada ejecución de clasificación:

5. Ejecuta el flujo con reintentos limitados

Si la ejecución se pausa para revisión, reanúdala de forma explícita:

6. Trata los fallos del gateway como eventos operativos

No ocultes los fallos ignorándolos dentro de la cadena de callbacks del agente. En su lugar, captura AgentGatewayError de forma explícita:
Después:
  1. permite que el runtime guarde el estado failed de la ejecución y los pasos
  2. En rutas de recuperación posteriores, consulta loaded.run.errorDetails o loaded.steps[n].errorDetails cuando la excepción original ya no esté en memoria
  3. consulta los detalles de la solicitud para revisar:
    • la aplicación de guardrails
    • los detalles del enrutamiento
    • la ejecución de plugins
    • los ID de solicitud y los datos del proveedor
Esto es especialmente importante cuando:
  • una guardrail bloquea la solicitud
  • la lista de modelos permitidos del preset rechaza el modelo solicitado
  • las credenciales del proveedor o los filtros de habilitación eliminan el conjunto de candidatos enrutados
  • response healing no consigue recuperar un JSON que cumpla el esquema

7. Qué verificar

Después de una ejecución correcta y otra de riesgo intencionado, confirma lo siguiente:
  • la vista de detalles de la solicitud muestra el destino definido por el preset
  • los casos de alto riesgo se pausan en waiting_for_human
  • los pasos de modelo reintentados persisten modelAttempts
  • los fallos de guardrails o del preset siguen visibles en los detalles de la solicitud y no quedan ocultos en las excepciones del agente

Guías relacionadas

Última modificación el 2 de octubre de 2026