Phase 14 - Lesson 29
Runtimes de Producción: Cola, Evento, Cron
Los agentes de producción se ejecutan en seis formatos de runtime: solicitud-respuesta, streaming, ejecución durable, cola en segundo plano, orientado a eventos y programado. Elija el formato antes de elegir el framework. La observabilidad es crucial (load-bearing) en todos los formatos.
Tipo: Aprender Idiomas: Python (stdlib) Prerrequisitos: Fase 14 · 13 (LangGraph), Fase 14 · 22 (Voz) Tiempo: ~60 minutos
Objetivos de Aprendizaje
- Nombrar los seis formatos de runtime de producción y asociar cada uno a un patrón de framework / producto.
- Explicar por qué la ejecución durable (LangGraph) es importante para tareas de largo horizonte (long-horizon).
- Describir el runtime orientado a eventos y cuándo se adapta Claude Managed Agents.
- Explicar la afirmación de que la observabilidad es crucial (load-bearing) para agentes de múltiples pasos.
El Problema
Los agentes de producción fallan de formas que un notebook Jupyter no revela: tiempos de espera (timeouts) de red en el paso 37, el usuario cuelga a mitad de una llamada de voz, el job de cron muere al reiniciar la máquina, el worker en segundo plano se queda sin memoria. El formato del runtime determina qué fallas son sobrevivibles.
El Concepto
Solicitud-respuesta
- HTTP síncrono. El usuario espera a que se complete.
- Solo viable para tareas cortas (<30s).
- Stacks: Agno (Python + FastAPI), Mastra (TypeScript + Express/Hono/Fastify/Koa).
- Observabilidad: logs de acceso HTTP estándar + spans de OTel.
Streaming
- SSE o WebSocket para salida progresiva.
- LiveKit extiende esto a WebRTC para voz/video (Lección 22).
- Stacks: cualquier framework con soporte de streaming + un frontend que maneje SSE/WS.
- Observabilidad: tiempo por fragmento (chunk), latencia del primer token, latencia de cola (tail latency).
Ejecución durable
- Estado guardado en puntos de control (checkpointed) después de cada paso; se reanuda automáticamente en caso de falla.
- El modelo de actor de AutoGen v0.4 aísla las fallas a un solo agente (Lección 14).
- El principal diferenciador de LangGraph (Lección 13).
- Esencial cuando el número de pasos es desconocido y el costo de recuperación es alto.
Basado en cola / segundo plano
- El trabajo ingresa a una cola, los workers lo recogen y los resultados regresan a través de webhooks o pub/sub.
- Esencial para agentes de largo horizonte (docenas a cientos de pasos por tarea, según el anuncio de computer use de Anthropic).
- Stacks: Celery (Python), BullMQ (Node), SQS + Lambda (AWS), personalizado.
- Observabilidad: profundidad de la cola, distribución de latencia por trabajo, tamaño de la DLQ.
Orientado a eventos
- Los agentes se suscriben a disparadores (triggers): nuevo correo electrónico, PR abierta, activación de cron.
- Claude Managed Agents cubre esto de forma nativa (Lección 17).
- CrewAI Flows (Lección 15) estructura flujos de trabajo deterministas orientados a eventos.
- Observabilidad: origen del disparador, latencia desde el evento hasta el inicio, latencia del agente.
Programado
- Agentes en formato cron que se ejecutan periódicamente.
- Combínelo con ejecución durable para que una ejecución nocturna fallida se reanude en el siguiente intervalo.
- Stacks: Kubernetes CronJob + un framework durable; alojado (Render cron, Vercel cron).
Patrones de despliegue de 2026
- CrewAI Flows para producción orientada a eventos.
- Agno FastAPI sin estado (stateless) para microservicios de Python.
- Mastra adaptadores de servidor (Express, Hono, Fastify, Koa) para incrustación (embedding).
- Pipecat Cloud / LiveKit Cloud para voz gestionada (Lección 22).
- Claude Managed Agents para asíncrono de larga duración alojado.
La observabilidad es crucial (load-bearing)
Sin los spans de GenAI de OpenTelemetry (Lección 23) más un backend de Langfuse/Phoenix/Opik (Lección 24), no podrá depurar un agente de múltiples pasos que falló en el paso 40. Esto no es opcional para producción. Es la diferencia entre "depuramos rápido" y "reproducimos todo desde cero con más logs".
Dónde fallan los runtimes de producción
- Elección incorrecta de formato. Elegir solicitud-respuesta para una tarea de 5 minutos. Los usuarios cuelgan; los los workers se acumulan; los reintentos (retries) complican el problema.
- Sin DLQ. Workers de cola sin cola de descarte (dead-letter queue). Los trabajos fallidos desaparecen.
- Trabajo opaco en segundo plano. El agente en segundo plano se ejecuta sin exportación de rastreo (trace). Las fallas son invisibles hasta que el usuario las reporta.
- Omitir el estado durable. Cualquier ejecución de más de 30 segundos en la que no pueda permitirse reiniciar necesita ejecución durable.
Constrúyalo
El archivo code/main.py es una demostración de múltiples formatos de la biblioteca estándar (stdlib):
- Endpoint de solicitud-respuesta (función simple).
- Manejador de streaming (generador).
- Worker basado en cola con DLQ.
- Registro de disparadores de eventos.
- Programador en formato cron.
Ejecútelo:
python3 code/main.py
Salida: cinco rastreos (traces) que muestran el comportamiento de cada formato en la misma tarea. Misma lógica de agente, diferentes cubiertas externas. La ejecución durable (el sexto formato) se cubre intencionalmente en la Lección 13 con el checkpointing de LangGraph.
Úselo
- Solicitud-respuesta para UX tipo chat.
- Streaming para respuestas progresivas.
- Durable para tareas de largo horizonte.
- Cola para lotes / asíncrono / larga duración.
- Evento para reactividad de agentes.
- Cron para mantenimiento interno (consolidación de memoria, evaluaciones, reportes de costos).
Envíelo
El archivo outputs/skill-runtime-shape.md elige un formato de runtime para una tarea y conecta los requisitos de observabilidad.
Ejercicios
- Adapte su bucle ReAct de la Lección 01 a los seis formatos en su stack. ¿Qué formato se adapta a qué superficie de producto?
- Agregue una DLQ a la demostración basada en cola. Simule un 10% de falla en los trabajos; muestre el tamaño de la DLQ.
- Escriba un agente de evaluación activado por cron que se ejecute todas las noches contra sus 20 rastreos principales del día.
- Implemente streaming con contrapresión (backpressure): si el cliente está lento, pause el agente. ¿Cómo interactúa esto con un presupuesto de turnos (turn budget)?
- Lea los documentos de Claude Managed Agents. ¿Cuándo movería un agente de largo horizonte autoalojado a managed?
Términos Clave
| Término | Lo que dice la gente | Lo que realmente significa |
|---|---|---|
| Solicitud-respuesta | "Síncrono" | El usuario espera; solo para tareas cortas |
| Streaming | "SSE / WS" | Salida progresiva; mejor UX; latencia observable por fragmento |
| Ejecución durable | "Reanudar desde la falla" | Estado guardado en puntos de control; reinicio en el último paso |
| Basado en cola | "Trabajos en segundo plano" | Pool de productores / workers / DLQ |
| Orientado a eventos | "Basado en disparadores" | El agente reacciona a eventos externos |
| DLQ | "Cola de cartas muertas" | Estacionamiento para trabajos fallidos |
| Claude Managed Agents | "Harness alojado" | Asíncrono de larga duración alojado por Anthropic con caché + compactación |
Lectura Adicional
- LangGraph overview — detalles sobre ejecución durable
- Claude Managed Agents overview — asíncrono de larga duración alojado
- Anthropic, Introducing computer use — "docenas a cientos de pasos por tarea"
- AutoGen v0.4 (Microsoft Research) — aislamiento de fallas del modelo de actor