LangGraph vs AutoGen: comparación del seguimiento de estado — checkpoint, recuperación por timeout y decisión de framework

30 pasos: un Agent de síntesis bibliográfica, 2 horas y 40 minutos de ejecución en total.

En el paso 25, timeout de la interfaz de base de datos y caída del proceso.

Los 24 pasos anteriores se pierden. Coste de API, tiempo de espera, resúmenes ya generados — todo a cero.

No es un caso aislado. Construí flujos complejos con AutoGen: estado incontrolable, agents fuera de control, depuración que triplicó el tiempo de desarrollo. Luego pasé a LangGraph: el prototipo simple exigió más de cien líneas de definición de estado. En ambos frameworks he tropezado con problemas.

LangGraph vs AutoGen en gestión de estado: filosofías radicalmente distintas. Uno controla el flujo con una máquina de estados explícita; el otro deja que los Agents negocien libremente mediante un protocolo conversacional. Elegir el framework equivocado: el 80 % de los proyectos Agent fallan no por falta de capacidad del LLM, sino porque el camino del seguimiento de estado se desvió desde el principio.

Este artículo compara ambos frameworks en 12 dimensiones — Checkpoint, recuperación por timeout, soporte distribuido — con casos reales, árbol de decisión y código ejecutable. Al terminar deberías poder decidir: para tu proyecto, ¿cuál conviene?

La línea de vida de la gestión de estado: por qué Checkpoint es vital para un Agent

Desarrollé para un cliente un Agent de síntesis bibliográfica: 10 llamadas consecutivas a APIs de bases académicas, 200 resúmenes de artículos, informe de síntesis.

Duración estimada: 3 horas. En el paso 25 (de 30), timeout de la interfaz de base de datos y caída.

Agent tradicional sin estado — los 24 pasos anteriores se pierden. Resúmenes generados, coste de API, 2 h 40 de espera: todo a cero. Volver a ejecutar desde el inicio quema de nuevo el coste de API.

El cliente pregunta: ¿podemos continuar desde el paso 25?

Respuesta: no. El estado de un Agent tradicional solo vive en memoria; al terminar el proceso, desaparece.

Las 5 catástrofes de un Agent sin estado

Viví este problema. Con AutoGen en un flujo complejo de tickets de soporte: estado incontrolable, agents fuera de control, depuración tres veces más larga que el desarrollo. Luego LangGraph con un grafo de estados: más de cien líneas para un prototipo simple.

En resumen, un Agent sin estado tiene 5 problemas fatales:

1. Pérdida de todo el historial de conversación tras reinicio

Despliegue de nueva versión, mantenimiento del servidor, caída inesperada — cualquier terminación del proceso borra el estado. Una conversación en curso se corta al instante.

2. Imposibilidad de reanudar una tarea multietapa interrumpida

Tareas largas (síntesis bibliográfica, pipeline de datos): si fallan, hay que empezar de cero. Caída en el paso 25 de 30: los 24 anteriores se pierden.

3. Sin concurrencia multiusuario; estados que se mezclan

Un mismo Agent sirve a varios usuarios: estados entrelazados. El historial del usuario A lo sobrescribe el usuario B; contaminación de datos.

4. Sin auditoría ni reproducción de la ejecución

Problema en producción y quieres revisar cómo decidió el Agent: no hay registro. Reproducir un bug: no hay estado histórico.

5. Fallo en tarea larga = empezar de cero

Tareas de horas (procesamiento de datos, generación por lotes): coste de fallo enorme. Gasto de API, tiempo, experiencia de usuario — todo perdido.

LangGraph vs AutoGen: madurez de Checkpoint

La brecha entre LangGraph y AutoGen en Checkpoint es clara.

Dimensión	LangGraph	AutoGen
Soporte Checkpoint nativo	Instantánea automática en cada nodo	En evolución en la roadmap
Madurez en producción	⭐⭐⭐⭐⭐ (estándar de facto 2026)	⭐⭐⭐ (aún en evolución)
Estabilidad de API	Ecosistema LangChain estable	Migración v0.2 → v0.5, proyectos a reescribir

LangGraph integra Checkpoint desde el diseño. Cada nodo ejecutado guarda una instantánea de estado. Tras una caída, reanuda en el punto de interrupción sin reejecutar nodos ya completados.

La gestión de estado de AutoGen sigue evolucionando. En abril de 2024 Microsoft publicó la roadmap de Persistence; en marzo de 2025 llegó Save/Load para AgentChat.NET. Proyectos en AutoGen v0.2 actualizados a v0.5: APIs invalidadas, código a reescribir.

Checkpoint no es un extra — es la línea de vida de un Agent. En producción sin persistencia de estado, vas desnudo.

Mecanismo Checkpoint de LangGraph en profundidad

La esencia del Checkpoint: no es «guardar mensajes», es «el estado completo del grafo»

Muchos creen erróneamente que Checkpoint = «guardar historial de conversación».

No es eso.

Un Checkpoint registra una instantánea completa del estado del Graph en un paso de ejecución. Incluye:

• Valores actuales de todos los Channels (cada campo de State)
• Nodo en ejecución
• ID del checkpoint padre (cadena de versiones)
• Marca temporal y metadatos

Analogía con el historial de Git: cada ejecución de nodo produce un «commit»; puedes hacer checkout de cualquier nodo histórico. No es copia de diálogo, es instantánea de todo el workflow.

Estructura Checkpoint v4 en detalle

LangGraph usa Checkpoint v4 con 7 campos principales, según la documentación oficial de LangChain:

class Checkpoint:
    v: int                  # Número de versión (actualmente 4)
    ts: str                  # Marca temporal formato ISO
    id: str                  # UUID, identificador único de la instantánea
    channel_values: dict     # Valor actual de cada campo de State
    channel_versions: dict   # Versión de cada campo, para detección de conflictos
    versions_seen: dict      # Versiones vistas por cada nodo, evita reprocesamiento
    pending_sends: list      # Cola de mensajes pendientes de envío

Punto clave sobre channel_versions — no es un campo inútil.

LangGraph lo usa para decidir si un nodo debe reejecutarse. Base de la reanudación: al restaurar, comprueba la versión de cada Channel y salta nodos ya ejecutados.

thread_id: coordenada de «universo paralelo» para aislamiento multi-sesión

Una misma instancia de Graph puede servir un número ilimitado de hilos de conversación.

Cada hilo tiene su propia secuencia de Checkpoints, sin interferencia. Se distingue con thread_id.

Como una ranura de guardado de juego: cada thread_id es un archivo de guardado independiente. El estado del usuario A no afecta al de B.

config = {"configurable": {"thread_id": "user-001"}}
result = graph.invoke(input, config)

Cambia el thread_id y entras en otro universo paralelo.

Flujo de ejecución Super-Step

El flujo de ejecución de LangGraph se llama Super-Step. Según la documentación de LangChain:

[Lee el Checkpoint anterior]
  ↓
[Ejecuta el nodo actual, actualiza State]
  ↓
[Escribe nuevo Checkpoint (instantánea)]
  ↓
[Decide el siguiente paso: continuar / esperar / terminar]

Tras cada nodo, guarda Checkpoint automáticamente. Tras una caída, reanuda desde el punto de interrupción.

Comparación de tres backends de almacenamiento Checkpoint

Tipo de almacenamiento	Escenario	Características
MemorySaver	Desarrollo y depuración	En memoria, se pierde al reiniciar
SqliteSaver	Producción monolítica	Persistencia SQLite, ligero
PostgresSaver	Producción distribuida	PostgreSQL, soporta pause/resume y distribución

En desarrollo usa MemorySaver, cómodo para depurar. En producción PostgresSaver, con soporte distribuido nativo.

RedisSaver encaja en escenarios de alta concurrencia, con lectura/escritura rápida.

Reanudación tras interrupción en la práctica

Volvamos al caso inicial: Agent de síntesis bibliográfica de 30 pasos, fallo por timeout en el paso 25.

Con el Checkpointer de LangGraph, reanuda desde el punto de interrupción:

# Recuperación tras fallo en el paso 7
config = {"configurable": {"thread_id": "research-001"}}
recovered_state = compiled_graph.invoke({"step": 7}, config)
# Salta automáticamente los 6 primeros pasos y continúa desde el 7

Con el mismo thread_id, carga el Checkpoint más reciente y sigue ejecutando.

Los 24 pasos anteriores no se repiten. Coste de API y contenido generado se conservan.

Estado actual del seguimiento en AutoGen: el coste de una roadmap en evolución

Evolución de la roadmap de gestión de estado

La gestión de estado de AutoGen sigue evolucionando.

Según GitHub Issue #2358, en abril de 2024 Microsoft publicó la roadmap Persistence and state management. La gran migración de API de AutoGen v0.2 a v0.5 obligó a rehacer proyectos.

Lo viví en carne propia. Un proyecto en AutoGen v0.2 actualizado a v0.5: APIs invalidadas. ConversableAgent, GroupChat y otras clases centrales cambiaron interfaz. Código reescrito.

En marzo de 2025 se publicó el PR Save/Load for AgentChat.NET (#5841). Agents y teams de AgentChat pueden volver a snapshots (Issue #4100). Documentada la serialización de estado de SingleThreadedAgentRuntime (Issue #4108).

Ya hay capacidad de gestión de estado, pero la madurez no alcanza a LangGraph.

Control de terminación: cuatro mecanismos de fusible

AutoGen tiene un dolor: dos Agents debaten 50 rondas sobre «comillas simples o dobles» y queman 5 $ de API.

O una tarea nocturna sigue 8 horas porque el diálogo no termina y al día siguiente la factura explota.

AutoGen v0.4 adopta arquitectura orientada a eventos con bucle de escucha continuo. Sin condiciones de terminación, se convierte en un agujero negro de recursos.

Según la documentación oficial de AutoGen, ofrece cuatro condiciones de terminación:

Tipo de terminación	Dimensión de control	Escenario
MaxMessageTermination	Control de rondas	Limitar el total de mensajes a 10
TextMentionTermination	Control de contenido	Detectar la palabra clave TERMINATE
TimeoutTermination	Control temporal	Evitar colgados largos que ocupen conexiones
TokenUsageTermination	Control de coste	Evitar superar el presupuesto

Uso combinado:

from autogen_agentchat.conditions import (
    MaxMessageTermination,
    TimeoutTermination,
    TokenUsageTermination
)

# Condiciones de terminación combinadas
termination = (
    MaxMessageTermination(max_messages=20)
    | TimeoutTermination(timeout_seconds=3600)
    | TokenUsageTermination(max_tokens=10000)
)

Al cumplirse cualquier condición, el diálogo termina. Mecanismo de fusible contra bucles infinitos.

Protocolo conversacional vs máquina de estados: implícito vs explícito

La filosofía de diseño de AutoGen y LangGraph es completamente distinta.

AutoGen usa protocolo conversacional (Conversational Programming):

• ConversableAgent: clase base de agent conversable
• GroupChat: varios Agents en un chat grupal
• GroupChatManager: decide quién habla siguiente (round-robin, selección automática, estrategia personalizada)

El Agent es una entidad que conversa y colabora en lenguaje natural. El estado queda implícito en el flujo de diálogo, menos explícito que en LangGraph.

LangGraph usa máquina de estados (State Machine):

• State TypedDict: define explícitamente la estructura de estado
• Node: lógica de procesamiento de cada nodo
• Edge: conexiones entre nodos y ramas condicionales

Cada paso define explícitamente cómo cambia el estado y hacia dónde va el flujo.

AutoGen encaja en flujos conversacionales flexibles — no sabes quién habla después; dejas que los Agents negocien.

LangGraph encaja en control preciso — ramas condicionales claras, rutas predecibles.

Capacidad de serialización Checkpoint (AgentChat.NET)

La capacidad Checkpoint de AutoGen se implementa mediante serialización.

Según GitHub PR #5841, AgentChat.NET soporta guardar/cargar estado de Agent:

# Guardar estado en archivo
team.save_state("checkpoint.json")

# Restaurar desde archivo
team.load_state("checkpoint.json")

Es serialización en archivo, no persistencia en base de datos. Sirve en escenarios monolíticos; despliegue distribuido requiere adaptación adicional.

En observabilidad, AutoGen usa los tres pilares de OpenTelemetry: Logs, Metrics, Traces. Monitorización de flujo de eventos + depuración Replay, cómoda para localizar problemas.

Comparación central y elección técnica: 12 dimensiones cuantificadas

Elegir framework es como elegir pareja — no hay «el mejor», sino «el más adecuado para ti».

LangGraph y AutoGen representan dos rutas técnicas: orquestación de workflow con máquina de estados prioritaria vs colaboración multirol con diálogo prioritario.

Tabla comparativa en 12 dimensiones

Dimensión	LangGraph	AutoGen	Diferencia
Modelo de gestión de estado	State TypedDict explícito	Flujo conversacional implícito	LangGraph +2
Mecanismo Checkpoint	Soporte nativo, guardado automático por nodo	Roadmap en evolución, serialización	LangGraph +3
Capacidad de recuperación	Recuperación a nivel Super-Step	Rollback conversacional (en desarrollo)	LangGraph +2
Control de terminación	Aristas condicionales (Conditional Edge)	Clase TerminationCondition	Empate
Medio de persistencia	Memory/SQLite/Postgres/Redis	Serialización en archivo	LangGraph +2
Time travel	Rollback a cualquier historial	Replay	LangGraph +1
Human-in-the-Loop	interrupt() + Command(resume=)	UserProxyAgent como proxy humano	LangGraph +1
Soporte distribuido	PostgresSaver con soporte nativo	Arquitectura orientada a eventos	LangGraph +1
Flexibilidad de desarrollo	Control fino, requiere State+Edge	Impulsado por diálogo, prototipo rápido	AutoGen +1
Curva de aprendizaje	Alta, requiere entender grafo de estados	Media, requiere entender modo conversacional	AutoGen +1
Estabilidad de API	Ecosistema LangChain estable	Migración v0.2 → v0.5	LangGraph +2
Madurez en producción	⭐⭐⭐⭐⭐	⭐⭐⭐	LangGraph +2

Valoración global: LangGraph lidera en gestión de estado (+14 puntos); AutoGen en flexibilidad conversacional (+2 puntos).

No significa que LangGraph sea «mejor» — significa que encaja mejor cuando necesitas control preciso del estado. AutoGen encaja mejor cuando necesitas colaboración conversacional flexible.

Diagrama de decisión por escenario

¿Cómo elegir? Mira tus necesidades.

Análisis de requisitos
  ↓
¿Hay un flujo con ramas condicionales explícitas?
  ├─ Sí → LangGraph
  └─ No → ¿Necesitas negociación libre multiagente?
      ├─ Sí → AutoGen
      └─ No → ¿Necesitas tolerancia a fallos en tareas largas?
          ├─ Sí → LangGraph
          └─ No → ¿Es un prototipo rápido?
              ├─ Sí → AutoGen
              └─ No → LangGraph por defecto (nivel producción)

Escenarios donde LangGraph destaca

LangGraph encaja en estos casos:

1. Workflows complejos con ramas condicionales

Flujo de tickets de soporte: clasificar tipo de problema → derivar a rutas distintas → agregar resultados. Ramas claras; Conditional Edge de LangGraph controla con precisión.

2. Tareas largas que requieren control preciso del estado

Agent de síntesis bibliográfica: 10 llamadas a base de datos, 200 artículos, informe de síntesis. Tres horas de ejecución; si falla a mitad, recuperar desde Checkpoint. Recuperación Super-Step sin reejecutar nodos completados.

3. Flujos Human-in-the-Loop de nivel producción

Revisión de contratos, correos sensibles — pausa tras borrador inicial, espera confirmación humana. interrupt() + Command(resume=) de LangGraph pausan y reanudan con elegancia.

4. Escenarios que requieren depuración time travel

Reproducir bugs, pruebas A/B — volver a cualquier versión histórica, explorar ramas. La secuencia Checkpoint permite checkout en cualquier nodo.

5. Sistemas Agent de alta concurrencia distribuidos

Atención al cliente: varias instancias, estado compartido. PostgresSaver soporta distribución nativa, sin competencia de estado.

Escenarios donde AutoGen destaca

AutoGen encaja en estos casos:

1. Negociación conversacional libre multiagente

Misterio tipo escape room, debates — no sabes quién habla después; dejas que los Agents negocien. GroupChat con estrategia de selección automática, flujo flexible.

2. Desarrollo rápido de prototipos

Demo de prueba de concepto — montaje rápido sin definir State+Edge. Impulsado por diálogo, curva de entrada suave.

3. Colaboración tipo role-play

Copy + diseño + operaciones — distintos roles Agent colaboran simulando un equipo real.

4. Bucle generación de código + ejecución

Code Executor + UserProxyAgent — generar código, ejecutar, feedback, corregir. AutoGen soporta nativamente el bucle código-ejecución.

5. Escenarios con flujo conversacional flexible

Siguiente paso incierto — GroupChatManager decide quién habla, sin flujo prefijado.

Ejemplos de código: la misma necesidad en ambos frameworks

La misma necesidad, implementada en ambos frameworks para comparar.

Definición de la necesidad: Agent de síntesis bibliográfica de flujo largo

Descripción de la tarea:

• 10 llamadas consecutivas a APIs de bases académicas
• Organizar 200 resúmenes de artículos
• Generar informe de síntesis

Tiempo de ejecución: unas 3 horas

Requisito de tolerancia a fallos:

• Timeout de interfaz de base de datos en el paso 7
• Recuperar desde Checkpoint sin repetir los 6 primeros pasos

Human-in-the-Loop:

• Pausa tras generar borrador
• Tras confirmación humana, generar versión final

Implementación con LangGraph

from langgraph.checkpoint.sqlite import SqliteSaver
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from operator import add

# Definir estructura de State
class ResearchState(TypedDict):
    papers: Annotated[list, add]  # Acumular, no sobrescribir
    summaries: Annotated[list, add]
    draft: str
    final_report: str
    step: int
    human_approved: bool

# Definir funciones de nodo
def fetch_papers(state: ResearchState):
    """Llamar a API de base de datos académica"""
    step = state["step"]
    papers = call_database_api(step)  # Llamada API hipotética
    return {"papers": papers, "step": step + 1}

def summarize_papers(state: ResearchState):
    """Generar resúmenes de artículos"""
    papers = state["papers"]
    summaries = generate_summaries(papers)  # Generación hipotética
    return {"summaries": summaries}

def generate_draft(state: ResearchState):
    """Generar borrador"""
    summaries = state["summaries"]
    draft = generate_report(summaries)  # Generación hipotética
    return {"draft": draft}

def human_review(state: ResearchState):
    """Nodo de revisión humana (espera resume tras interrupt)"""
    return {"human_approved": True}

def generate_final(state: ResearchState):
    """Generar versión final"""
    draft = state["draft"]
    final_report = refine_report(draft)
    return {"final_report": final_report}

# Construir Graph
graph = StateGraph(ResearchState)

# Añadir nodos
graph.add_node("fetch", fetch_papers)
graph.add_node("summarize", summarize_papers)
graph.add_node("draft", generate_draft)
graph.add_node("review", human_review)
graph.add_node("final", generate_final)

# Definir aristas
graph.add_edge("fetch", "summarize")
graph.add_edge("summarize", "draft")
graph.add_edge("draft", "review")
graph.add_edge("review", "final")
graph.add_edge("final", END)

# Punto de entrada
graph.set_entry_point("fetch")

# Añadir Checkpointer (núcleo)
checkpointer = SqliteSaver.from_conn_string("research_checkpoints.db")
compiled_graph = graph.compile(
    checkpointer=checkpointer,
    interrupt_before=["review"]  # Pausa antes del nodo review
)

# Ejecutar tarea
config = {"configurable": {"thread_id": "research-session-001"}}
result = compiled_graph.invoke({"step": 0}, config)

# Recuperación tras fallo en el paso 7
# Mismo thread_id, salta automáticamente los 6 primeros pasos
recovered_state = compiled_graph.invoke({"step": 7}, config)

# Recuperación Human-in-the-Loop
# Pausa tras borrador, continúa tras confirmación humana
compiled_graph.invoke(
    Command(resume={"human_approved": True}),
    config
)

Características clave:

• SqliteSaver guarda State automáticamente tras cada nodo
• thread_id aísla sesiones distintas
• Al recuperar, salta nodos ya ejecutados (mediante channel_versions)
• interrupt_before implementa pausa Human-in-the-Loop

Implementación con AutoGen

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.conditions import (
    MaxMessageTermination,
    TimeoutTermination,
    TokenUsageTermination
)
from autogen_core.models import ChatCompletionClient

# Definir Agents
research_agent = AssistantAgent(
    name="researcher",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="Eres un asistente de síntesis bibliográfica.\
        Llama a bases de datos, organiza resúmenes y genera informes.\
        Al terminar di 'TERMINATE'."
)

human_agent = AssistantAgent(
    name="human_reviewer",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="Eres revisor. Tras revisar el borrador di 'APPROVED' o 'REJECT'."
)

# Condiciones de terminación (evitar bucles infinitos)
termination = (
    MaxMessageTermination(max_messages=50)
    | TimeoutTermination(timeout_seconds=10800)  # 3 horas
    | TokenUsageTermination(max_tokens=50000)
    | TextMentionTermination(text="TERMINATE")
)

# Construir Team
team = RoundRobinGroupChat(
    participants=[research_agent, human_agent],
    termination_condition=termination
)

# Ejecutar tarea
async def run_research():
    result = await team.run(
        task="Organizar 200 resúmenes bibliográficos y generar informe de síntesis"
    )
    return result

# Guardar Checkpoint (AgentChat.NET)
team.save_state("research_checkpoint.json")

# Restaurar desde Checkpoint
team.load_state("research_checkpoint.json")

# Continuar ejecución
async def resume_research():
    result = await team.run()
    return result

Características clave:

• TerminationCondition evita bucles infinitos (fusible)
• Save/Load de estado en archivo (serialización)
• Arquitectura orientada a eventos adaptable a distribución
• Protocolo conversacional: Agents colaboran en lenguaje natural

Resumen comparativo

Característica	LangGraph	AutoGen
Definición de estado	TypedDict explícito	Flujo conversacional implícito
Checkpoint	Guardado automático por nodo (base de datos)	Serialización en archivo
Mecanismo de recuperación	Super-Step salta nodos ejecutados	Rollback conversacional
Human-in-the-Loop	interrupt pausa + resume reanuda	UserProxyAgent interviene
Control de terminación	Enrutamiento por aristas condicionales	Fusible TerminationCondition
Volumen de código	~60 líneas (State+Edge)	~30 líneas (impulsado por diálogo)

LangGraph: control fino, ideal para gestión precisa del estado.

AutoGen: prototipo rápido, ideal para colaboración conversacional flexible.

Recomendaciones de despliegue en producción: del desarrollo a producción

Puntos clave de despliegue LangGraph en producción

Esquema de persistencia:

Combinación PostgresSaver + RedisSaver.

PostgreSQL como almacenamiento persistente, con soporte distribuido nativo. Redis como capa de caché, lectura/escritura rápida en alta concurrencia.

from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.checkpoint.redis import RedisSaver

# Configuración de producción
postgres_saver = PostgresSaver.from_conn_string(
    "postgresql://user:pass@host:5432/db"
)
redis_saver = RedisSaver.from_conn_string(
    "redis://host:6379/0"
)

# Uso combinado: caché Redis + persistencia Postgres
compiled_graph = graph.compile(
    checkpointer=postgres_saver
)

Observabilidad:

LangSmith tracing + integración OpenTelemetry.

LangSmith para trazado de llamadas — qué nodo es lento, qué consume más tokens. OpenTelemetry se integra con tu stack de monitorización existente.

Optimización de rendimiento:

Salida en streaming — el usuario ve el primer token al instante, latencia percibida <1 s.

Llamadas paralelas a herramientas — soporte nativo en LangGraph, varias herramientas a la vez.

Precompilación de prompts — reduce ~30 % el tiempo de inferencia del LLM.

Optimización de costes:

Estrategia	Reducción de coste	Escenario
Compresión de prompts	30-50 %	Uso general
Enrutamiento multi-proveedor	40-60 %	Failover en producción
Mecanismo de caché	50-80 %	Consultas repetidas

El enrutamiento multi-proveedor es estándar en producción. API Gateway con failover: si cae GPT-4, cambia a Claude y puede reducir costes un 40 %.

Puntos clave de despliegue AutoGen en producción

Observabilidad:

Tres pilares OpenTelemetry — Logs, Metrics, Traces.

• EventLogger + logs estructurados: localización de problemas, auditoría
• OpenTelemetry Meter: monitorización de rendimiento, planificación de capacidad
• OpenTelemetry Tracer: análisis de cadena de llamadas, optimización de latencia

from autogen_core.telemetry import (
    enable_telemetry,
    EventLogger
)

# Habilitar observabilidad
enable_telemetry(
    logger=EventLogger(),
    meter=OpenTelemetryMeter(),
    tracer=OpenTelemetryTracer()
)

Monitorización de flujo de eventos:

Técnica Replay para depuración — todo comportamiento de Agent genera flujo de eventos reproducible.

Adaptación distribuida:

Arquitectura orientada a eventos con soporte distribuido nativo. Mensajes entre Agents vía eventos, sin competencia de estado.

Control de costes:

Fusible TokenUsageTermination — termina automáticamente al alcanzar el límite de presupuesto.

from autogen_agentchat.conditions import TokenUsageTermination

# Configurar fusible de coste
termination = TokenUsageTermination(max_tokens=10000)

Análisis estructurado de logs del consumo de tokens — qué diálogos consumen más, qué Agent cuesta más.

Tabla comparativa de despliegue en producción

Dimensión	LangGraph	AutoGen
Persistencia	PostgresSaver con soporte distribuido	Serialización en archivo (requiere adaptación)
Observabilidad	LangSmith tracing	Tres pilares OpenTelemetry
Control de costes	Enrutamiento multi-proveedor	Fusible TokenUsageTermination
Optimización de rendimiento	Streaming + herramientas paralelas	Monitorización de flujo de eventos
Distribución	PostgresSaver nativo	Adaptación orientada a eventos

Lección clave: en producción hace falta AI Gateway

Tanto con LangGraph como con AutoGen, en producción debes añadir AI Gateway.

¿Por qué?

1. Failover multi-proveedor

Cambio automático si cae la API. ¿GPT-4 caído? Cambia a Claude. Elimina punto único de fallo.

2. Monitorización de costes

Qué Agent consume más, qué diálogo cuesta más — monitorización en tiempo real. Fusible automático al superar presupuesto.

3. Rate limiting

Evita throttling de la API. Cola de peticiones, reintentos automáticos.

4. Trazado de logs

Registro centralizado de todas las llamadas. Localización de problemas, auditoría.

AI Gateway no es opcional — es requisito para Agents de nivel producción.

Conclusión

LangGraph y AutoGen representan dos rutas técnicas de frameworks Agent.

LangGraph: orquestación de workflow con máquina de estados prioritaria. State+Node+Edge explícitos, cada paso controlable. Checkpoint nativo; recuperación tras caída sin reejecutar. Ideal para ramas condicionales complejas, tareas largas, despliegue distribuido.

AutoGen: colaboración multirol con diálogo prioritario. Agents negocian en lenguaje natural, flujo conversacional flexible. Condiciones de terminación como fusible contra bucles infinitos. Ideal para prototipos rápidos, negociación libre multiagente, escenarios role-play.

La elección no es «cuál es mejor», sino «cuál encaja con tu escenario».

¿Flujo con ramas condicionales explícitas? LangGraph. ¿Negociación libre multiagente? AutoGen. ¿Tarea larga con tolerancia a fallos? LangGraph. ¿Validación rápida de prototipo? AutoGen.

He tropezado con ambos. AutoGen con estado incontrolable y migración de API que obligó a reescribir. LangGraph con más de cien líneas solo para definir el grafo de estados.

Lección clave: en producción hay que añadir AI Gateway. Failover multi-proveedor, monitorización de costes, rate limiting — estas tres capacidades son la base de un Agent estable.

Siguiente paso: si tu proyecto es un workflow complejo, elige LangGraph. Si quieres montar rápido un prototipo multiagente, elige AutoGen. Luego lee «Gestión de estado en LangGraph en la práctica» (orden de serie 39) para profundizar en Checkpoint.