LangGraph vs AutoGen em rastreamento de estado: checkpoints, recuperação de timeout e decisão técnica

Um Agent para organizar literatura científica em 30 etapas rodou por 2 horas e 40 minutos.

Na etapa 25, a interface do banco de dados estourou o tempo limite e quebrou.

As 24 etapas anteriores foram perdidas. Custo de chamadas de API, tempo de espera e resumos de artigos já gerados: tudo voltou a zero.

Isso não é um caso isolado. Eu já usei AutoGen para fluxos de trabalho complexos: estado incontrolável, Agents saindo do rumo e investigação de problema consumindo três vezes mais tempo de desenvolvimento. Depois migrei para LangGraph; até um protótipo simples exigiu mais de cem linhas só para definir estado. Já tropecei nos dois frameworks.

No gerenciamento de estado de LangGraph vs AutoGen, a filosofia de projeto é completamente diferente. Um controla o fluxo com uma máquina de estados explícita; o outro usa um protocolo conversacional para permitir que Agents negociem livremente. Escolher o framework errado faz com que 80% dos projetos de Agent fracassem não porque o modelo grande é incapaz, mas porque o rastreamento de estado já começou pelo caminho errado.

Este artigo compara os dois frameworks em 12 dimensões, incluindo mecanismo de Checkpoint, recuperação de timeout e suporte distribuído. Também inclui um caso real, uma árvore de decisão e código executável. Ao terminar a leitura, você deve conseguir julgar rapidamente qual deles faz sentido para o seu projeto.

A linha de vida ou morte do gerenciamento de estado: por que Checkpoint é a linha de vida de um Agent

Eu desenvolvi para um cliente um Agent de organização de literatura científica. Ele chamava uma API de banco de dados acadêmico 10 vezes seguidas, organizava resumos de 200 artigos e gerava um relatório de revisão.

O tempo estimado de execução era de 3 horas. Na etapa 25, de um total de 30, a interface do banco de dados deu timeout e o processo quebrou.

Um Agent tradicional é sem estado: as 24 etapas anteriores foram desperdiçadas. Os resumos já gerados, o custo das chamadas de API e as 2 horas e 40 minutos de espera foram zerados. Para rodar de novo, seria preciso começar do início e queimar o custo de API outra vez.

O cliente perguntou: dá para continuar a partir da etapa 25?

A resposta: não. O estado de um Agent tradicional existe apenas na memória. Se o processo interrompe, ele desaparece.

Os 5 grandes desastres de um Agent tradicional sem estado

Eu já caí nessa. Na época, usei AutoGen para montar um fluxo complexo de atendimento pós-venda. O estado ficava fora de controle, os Agents se desviavam e investigar problemas custou três vezes mais tempo de desenvolvimento. Depois usei LangGraph para definir um grafo de estado; um protótipo simples já passou de cem linhas.

Resumindo, um Agent tradicional sem estado tem 5 problemas fatais:

1. Todo o histórico de conversa se perde após reiniciar o serviço

Deploy de uma nova versão, manutenção do servidor, falha inesperada: qualquer encerramento de processo limpa o estado. A conversa em andamento do usuário cai imediatamente.

2. Não há recuperação após interrupção em uma tarefa de múltiplas rodadas

Quando uma tarefa longa, como organização de literatura científica ou pipeline de processamento de dados, falha, só resta rodar tudo desde o começo. Se uma tarefa de 30 etapas quebra na etapa 25, as primeiras 24 etapas foram em vão.

3. Não há suporte seguro a múltiplos usuários concorrentes; estados interferem entre si

Uma mesma instância de Agent atende vários usuários, e os estados se misturam. O histórico do usuário A pode ser sobrescrito pela operação do usuário B, causando contaminação de dados.

4. Não é possível auditar nem reproduzir o processo histórico de execução

Se algo dá errado em produção, como rever a decisão que o Agent tomou naquele momento? Não há registro. Como reproduzir um bug? Não há estado histórico.

5. Uma tarefa longa que falha precisa recomeçar inteira

Em tarefas de várias horas, como processamento de dados ou geração em lote, o custo de falha é altíssimo. Custos de API, tempo e experiência do usuário são todos perdidos.

LangGraph vs AutoGen: comparação de maturidade em Checkpoint

A diferença entre as capacidades de Checkpoint do LangGraph e do AutoGen é clara.

Dimensão	LangGraph	AutoGen
Suporte nativo a Checkpoint	Salva snapshot automaticamente em cada nó	Em evolução no roadmap
Maturidade em produção	⭐⭐⭐⭐⭐, padrão de fato em 2026	⭐⭐⭐, ainda evoluindo
Estabilidade da API	Ecossistema LangChain estável	Grande migração de v0.2 para v0.5, projetos obrigados a refatorar

Desde o projeto inicial, LangGraph já embute o mecanismo de Checkpoint. Ao terminar a execução de cada nó, ele salva automaticamente um snapshot do State. Após uma falha, retoma do ponto de interrupção e não reexecuta nós já concluídos.

O gerenciamento de estado do AutoGen ainda está evoluindo. Em abril de 2024, a Microsoft publicou um roadmap de persistência. Só em março de 2025 surgiu a capacidade de Save/Load no AgentChat.NET. Projetos escritos com AutoGen v0.2 perderam compatibilidade ao migrar para v0.5, exigindo reescrita de código.

Checkpoint não é um recurso bonito para enfeitar a arquitetura. É a linha de vida de um Agent. Em produção, não ter persistência de estado é operar sem proteção.

Análise profunda do mecanismo de Checkpoint do LangGraph

A essência do Checkpoint: não é “salvar mensagens”, é “salvar o estado completo do grafo”

Muita gente entende Checkpoint de forma errada, como se fosse apenas “salvar o histórico de conversa”.

Não é.

Checkpoint salva o snapshot completo de estado do Graph em uma etapa específica de execução. Isso inclui:

• O valor atual de todos os Channels, isto é, de cada campo do State
• O nó em que a execução está atualmente
• O ID do checkpoint pai, formando uma cadeia de versões
• Timestamp e metadados

Uma boa analogia é o histórico de commits do Git: cada execução de nó gera um “commit”, e você pode fazer checkout para qualquer nó histórico e rodar novamente. Isso não é backup de conversa; é o snapshot de estado de todo o workflow.

Estrutura de dados do Checkpoint v4

O LangGraph usa atualmente o Checkpoint v4, que contém 7 campos centrais. Segundo a definição da documentação oficial do LangChain:

class Checkpoint:
    v: int                  # número da versão, atualmente 4
    ts: str                  # timestamp em formato ISO
    id: str                  # UUID, identificador único do snapshot
    channel_values: dict     # valor atual de cada campo no State
    channel_versions: dict   # versão de cada campo, usada para detectar conflitos
    versions_seen: dict      # registra versões vistas por cada nó para evitar processamento repetido
    pending_sends: list      # fila de mensagens pendentes de envio

O ponto mais importante é channel_versions: ele não é um campo descartável.

O LangGraph usa números de versão para decidir se “um determinado nó precisa ser executado novamente”. Essa é a base da retomada a partir de interrupções: na recuperação, ele verifica o número de versão de cada Channel e pula os nós que já foram executados.

thread_id: a “coordenada de universo paralelo” para isolar múltiplas conversas

Uma mesma instância de Graph pode atender incontáveis threads de conversa.

Cada thread tem sua própria sequência de Checkpoints, sem interferência. A separação é feita por thread_id.

Pense em slots de salvamento de um jogo: cada thread_id é um arquivo de save independente. O estado da conversa do usuário A não afeta o usuário B.

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

Trocar o thread_id é entrar em outro universo paralelo.

Fluxo de execução Super-Step

O fluxo de execução do LangGraph se chama Super-Step. Segundo a documentação oficial do LangChain, ele funciona assim:

[Ler o Checkpoint anterior]
  ↓
[Executar o nó atual e atualizar o State]
  ↓
[Gravar um novo Checkpoint, isto é, o snapshot]
  ↓
[Decidir a próxima etapa: continuar, esperar ou encerrar]

Ao fim da execução de cada nó, o Checkpoint é salvo automaticamente. Depois de uma falha, a execução retoma do ponto de interrupção.

Comparação entre três backends de armazenamento de Checkpoint

Tipo de armazenamento	Cenário adequado	Características
MemorySaver	Desenvolvimento e depuração	Armazenamento em memória; perde dados ao reiniciar
SqliteSaver	Produção em máquina única	Persistência em SQLite, leve
PostgresSaver	Produção distribuída	PostgreSQL, com suporte a pause/resume e distribuição

Na fase de desenvolvimento, MemorySaver facilita a depuração. Em produção, PostgresSaver é mais indicado, pois oferece suporte natural a implantação distribuída.

RedisSaver é adequado para cenários de alta concorrência, com leitura e escrita rápidas.

Retomada prática a partir de uma interrupção

Voltando ao caso inicial: um Agent de organização de literatura científica com 30 etapas falha por timeout na etapa 25.

Com o Checkpointer do LangGraph, a recuperação acontece a partir do ponto interrompido:

# Recuperação após falha na etapa 7
config = {"configurable": {"thread_id": "research-001"}}
recovered_state = compiled_graph.invoke({"step": 7}, config)
# Pula automaticamente as 6 primeiras etapas e continua da etapa 7

Com o mesmo thread_id, ele carrega o Checkpoint mais recente e continua a execução.

As 24 primeiras etapas não serão executadas de novo. O custo de API e o conteúdo gerado são preservados.

Estado atual do rastreamento de estado no AutoGen: o preço de um roadmap em evolução

Histórico da evolução do roadmap de gerenciamento de estado

O gerenciamento de estado do AutoGen ainda está em evolução.

Segundo o GitHub Issue #2358, a Microsoft publicou em abril de 2024 o roadmap de persistence and state management. A migração da API do AutoGen v0.2 para v0.5 foi grande, e vários projetos precisaram voltar à bancada.

Eu também passei por isso. Um projeto escrito com AutoGen v0.2 perdeu compatibilidade ao atualizar para v0.5. Classes centrais como ConversableAgent e GroupChat mudaram de interface. O código precisou ser reescrito.

Em março de 2025, saiu o PR Save/Load for AgentChat.NET (#5841). Agents e teams do AgentChat passaram a poder voltar para snapshots (Issue #4100). A serialização de estado do SingleThreadedAgentRuntime foi documentada (Issue #4108).

A capacidade de gerenciamento de estado já existe, mas a maturidade ainda não chega ao nível do LangGraph.

Controle por condições de término: quatro tipos de disjuntor

O AutoGen tem uma dor clássica: dois Agents discutem “aspas simples ou aspas duplas” por 50 rodadas e queimam US$ 5 em custo de API.

Ou uma tarefa automática noturna continua rodando por 8 horas porque a conversa nunca terminou, e no dia seguinte a conta explode.

O AutoGen v0.4 usa uma arquitetura orientada a eventos, na qual o loop de mensagens continua escutando. Sem condições de término, isso vira um buraco negro de recursos.

Segundo a documentação oficial do AutoGen, há quatro tipos de condição de término:

Tipo de término	Dimensão de controle	Cenário adequado
MaxMessageTermination	Controle de rodadas	Limita o total de mensagens a no máximo 10
TextMentionTermination	Controle de conteúdo	Detecta a palavra-chave “TERMINATE”
TimeoutTermination	Controle de tempo	Evita processos longos pendurados ocupando conexão
TokenUsageTermination	Controle de custo	Evita estouro de orçamento

Uso combinado:

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

# Combinação de condições de término
termination = (
    MaxMessageTermination(max_messages=20)
    | TimeoutTermination(timeout_seconds=3600)
    | TokenUsageTermination(max_tokens=10000)
)

Quando qualquer condição é atingida, a conversa termina. O disjuntor evita loops infinitos.

Protocolo conversacional vs máquina de estados: diferenças filosóficas entre implícito e explícito

As filosofias de projeto de AutoGen e LangGraph são totalmente diferentes.

AutoGen usa um protocolo conversacional, ou Conversational Programming:

• ConversableAgent: classe base de um Agent conversável
• GroupChat: vários Agents colocados em um chat em grupo
• GroupChatManager: decide quem fala a seguir, por rodízio, escolha automática ou estratégia personalizada

O Agent é uma entidade que conversa e colabora por linguagem natural. O estado fica implicitamente embutido no fluxo de conversa, sem o mesmo gerenciamento explícito do LangGraph.

LangGraph usa máquina de estados, ou State Machine:

• State TypedDict: definição explícita da estrutura de estado
• Node: lógica de processamento de cada nó
• Edge: conexão e ramificações condicionais entre nós

Em cada passo da execução, como o estado muda e para onde o fluxo segue são definidos explicitamente.

AutoGen é adequado para fluxos conversacionais flexíveis, quando não se sabe quem deve falar no próximo passo e você quer deixar os Agents negociarem livremente.

LangGraph é adequado para controle preciso, quando as ramificações condicionais são claras e o caminho do fluxo é previsível.

Capacidade de serialização de Checkpoint no AgentChat.NET

A capacidade de Checkpoint do AutoGen é implementada por serialização.

Segundo o GitHub PR #5841, o AgentChat.NET suporta salvar e carregar o estado dos Agents:

# Salvar estado em arquivo
team.save_state("checkpoint.json")

# Recuperar a partir do arquivo
team.load_state("checkpoint.json")

Isso é serialização em arquivo, não persistência em banco de dados. Funciona para cenários de máquina única; implantação distribuída exige adaptação extra.

Em observabilidade, AutoGen usa os três pilares do OpenTelemetry: Logs, Metrics e Traces. Monitoramento de fluxo de eventos somado a replay facilita a localização de problemas.

Comparação central e escolha técnica: avaliação quantitativa em 12 dimensões

Escolher um framework é como escolher alguém para casar: não existe o melhor em abstrato, existe o mais adequado para você.

LangGraph e AutoGen representam duas grandes linhas técnicas em frameworks de Agent: orquestração de workflow com prioridade para máquina de estados e colaboração multi-papel com prioridade para conversa.

Tabela de comparação quantitativa em 12 dimensões

Dimensão	LangGraph	AutoGen	Diferença de pontuação
Modelo de gerenciamento de estado	State TypedDict explícito	Fluxo conversacional implícito	LangGraph +2
Mecanismo de Checkpoint	Suporte nativo, salvamento automático em cada nó	Roadmap em evolução, dependente de serialização	LangGraph +3
Capacidade de recuperação	Recuperação no nível de Super-Step	Rollback de conversa, ainda em desenvolvimento	LangGraph +2
Controle de término	Conditional Edge	Classe TerminationCondition	Empate
Meio de persistência	Memory/SQLite/Postgres/Redis	Serialização em arquivo	LangGraph +2
Viagem no tempo	Suporta rollback para qualquer histórico	Replay	LangGraph +1
Human-in-the-Loop	interrupt() + Command(resume=)	Proxy humano com UserProxyAgent	LangGraph +1
Suporte distribuído	PostgresSaver com suporte natural	Arquitetura orientada a eventos adaptável ao distribuído	LangGraph +1
Flexibilidade de desenvolvimento	Controle fino, exige definir State + Edge	Orientado a conversa, prototipagem rápida	AutoGen +1
Curva de aprendizado	Alta, exige entender grafo de estados	Média, exige entender padrão conversacional	AutoGen +1
Estabilidade da API	Ecossistema LangChain estável	Grande migração de v0.2 para v0.5	LangGraph +2
Maturidade em produção	⭐⭐⭐⭐⭐	⭐⭐⭐	LangGraph +2

Resumo da pontuação: LangGraph lidera em gerenciamento de estado (+14 pontos), enquanto AutoGen tem vantagem em flexibilidade conversacional (+2 pontos).

Isso não quer dizer que LangGraph seja melhor em tudo. Quer dizer que LangGraph é mais adequado quando você precisa de controle preciso de estado. AutoGen é mais adequado quando você precisa de colaboração flexível por fluxo de conversa.

Fluxograma de decisão por cenário

Como escolher? Olhe para a sua necessidade.

Análise da necessidade
  ↓
Há um fluxo claro com ramificações condicionais?
  ├─ Sim → LangGraph
  └─ Não → Precisa de negociação livre entre múltiplos Agents?
      ├─ Sim → AutoGen
      └─ Não → Precisa de tolerância a falhas em tarefa longa?
          ├─ Sim → LangGraph
          └─ Não → É um protótipo rápido?
              ├─ Sim → AutoGen
              └─ Não → LangGraph por padrão, para nível de produção

Cenários em que LangGraph se destaca

LangGraph é adequado para estes cenários:

1. Workflows complexos com ramificações condicionais

Fluxo de atendimento pós-venda: identificar o tipo de problema → direcionar para rotas diferentes → consolidar o resultado. Quando as condições são claras, o Conditional Edge do LangGraph oferece controle preciso.

2. Tarefas longas que exigem controle preciso de estado

Agent de organização de literatura científica: 10 chamadas consecutivas ao banco de dados, organização de 200 artigos e geração de revisão. A execução leva 3 horas e precisa recuperar de Checkpoint se quebrar no meio. A recuperação no nível de Super-Step do LangGraph evita repetir nós já concluídos.

3. Fluxos de revisão Human-in-the-Loop em produção

Revisão de contrato, auditoria de e-mails sensíveis: gerar um rascunho, pausar e aguardar confirmação humana. O interrupt() + Command(resume=) do LangGraph permite pausar e retomar com elegância.

4. Cenários que exigem depuração por viagem no tempo

Reprodução de bugs, testes A/B: voltar para uma versão histórica qualquer e explorar ramificações. A sequência de Checkpoints do LangGraph permite checkout para qualquer nó.

5. Sistemas de Agent distribuídos e de alta concorrência

Sistema de atendimento: múltiplas instâncias implantadas com estado compartilhado. PostgresSaver dá suporte distribuído naturalmente e evita competição por estado.

Cenários em que AutoGen se destaca

AutoGen é adequado para estes cenários:

1. Conversa e negociação livre entre múltiplos Agents

Raciocínio em estilo jogo de mistério ou debate: quando não está claro quem deve falar em seguida, deixe os Agents negociarem. A estratégia de escolha automática do GroupChat oferece fluxo conversacional flexível.

2. Desenvolvimento rápido de protótipos

Demo de prova de conceito: montagem rápida, sem definir State + Edge. A abordagem orientada a conversa é mais fácil de começar.

3. Colaboração baseada em papéis

Discussão entre redação, design e operação: Agents com papéis diferentes colaboram e simulam uma conversa de equipe real.

4. Loop fechado de geração e execução de código

Code Executor + UserProxyAgent: gerar código, executar, receber feedback e corrigir. AutoGen oferece suporte nativo a esse ciclo de execução de código.

5. Cenários que precisam de fluxo conversacional flexível

Quando o próximo passo é incerto, o GroupChatManager decide quem fala sem exigir um fluxo pré-definido.

Exemplo prático de código: a mesma necessidade implementada nos dois frameworks

Vamos usar a mesma necessidade para comparar as diferenças de implementação entre os dois frameworks.

Definição da necessidade: Agent de organização de literatura científica em fluxo longo

Descrição da tarefa:

• Chamar uma API de banco de dados acadêmico 10 vezes seguidas
• Organizar resumos de 200 artigos
• Gerar um relatório de revisão

Tempo de execução: cerca de 3 horas

Requisito de tolerância a falhas:

• A interface do banco de dados falha por timeout na etapa 7
• É preciso recuperar a partir de Checkpoint sem repetir as 6 primeiras etapas

Human-in-the-Loop:

• Pausar após gerar o rascunho
• Aguardar confirmação humana antes de gerar a versão final

Implementação com LangGraph

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

# Definição da estrutura de State
class ResearchState(TypedDict):
    papers: Annotated[list, add]  # acumula, sem sobrescrever
    summaries: Annotated[list, add]
    draft: str
    final_report: str
    step: int
    human_approved: bool

# Definição das funções dos nós
def fetch_papers(state: ResearchState):
    """Chama a API do banco de dados acadêmico"""
    step = state["step"]
    papers = call_database_api(step)  # chamada de API hipotética
    return {"papers": papers, "step": step + 1}

def summarize_papers(state: ResearchState):
    """Gera resumos dos artigos"""
    papers = state["papers"]
    summaries = generate_summaries(papers)  # geração hipotética de resumos
    return {"summaries": summaries}

def generate_draft(state: ResearchState):
    """Gera o rascunho"""
    summaries = state["summaries"]
    draft = generate_report(summaries)  # geração hipotética de relatório
    return {"draft": draft}

def human_review(state: ResearchState):
    """Nó de revisão humana, aguarda resume após interrupt"""
    return {"human_approved": True}

def generate_final(state: ResearchState):
    """Gera a versão final"""
    draft = state["draft"]
    final_report = refine_report(draft)
    return {"final_report": final_report}

# Construção do Graph
graph = StateGraph(ResearchState)

# Adição dos nós
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)

# Definição das edges
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)

# Configuração do ponto de entrada
graph.set_entry_point("fetch")

# Adição do Checkpointer, parte central da solução
checkpointer = SqliteSaver.from_conn_string("research_checkpoints.db")
compiled_graph = graph.compile(
    checkpointer=checkpointer,
    interrupt_before=["review"]  # pausa antes do nó review
)

# Execução da tarefa
config = {"configurable": {"thread_id": "research-session-001"}}
result = compiled_graph.invoke({"step": 0}, config)

# Recuperação após falha na etapa 7
# Com o mesmo thread_id, pula automaticamente as 6 primeiras etapas
recovered_state = compiled_graph.invoke({"step": 7}, config)

# Retomada do Human-in-the-Loop
# Depois da pausa após o rascunho, continua após confirmação humana
compiled_graph.invoke(
    Command(resume={"human_approved": True}),
    config
)

Características principais:

• SqliteSaver salva automaticamente o State depois da execução de cada nó
• thread_id isola diferentes conversas
• Na recuperação, nós já executados são pulados automaticamente por meio de channel_versions
• interrupt_before implementa pausa Human-in-the-Loop

Implementação com 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

# Definição dos Agents
research_agent = AssistantAgent(
    name="researcher",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="Você é um assistente de organização de literatura científica.\
        Chame o banco de dados, organize resumos e gere o relatório.\
        Ao terminar, diga 'TERMINATE'."
)

human_agent = AssistantAgent(
    name="human_reviewer",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="Você é a pessoa revisora. Após revisar o rascunho, diga 'APPROVED' ou 'REJECT'."
)

# Configuração das condições de término para evitar loop infinito
termination = (
    MaxMessageTermination(max_messages=50)
    | TimeoutTermination(timeout_seconds=10800)  # 3 horas
    | TokenUsageTermination(max_tokens=50000)
    | TextMentionTermination(text="TERMINATE")
)

# Construção do Team
team = RoundRobinGroupChat(
    participants=[research_agent, human_agent],
    termination_condition=termination
)

# Execução da tarefa
async def run_research():
    result = await team.run(
        task="Organize resumos de 200 artigos e gere um relatório de revisão"
    )
    return result

# Salvamento do Checkpoint no AgentChat.NET
team.save_state("research_checkpoint.json")

# Recuperação a partir do Checkpoint
team.load_state("research_checkpoint.json")

# Continuação da execução
async def resume_research():
    result = await team.run()
    return result

Características principais:

• TerminationCondition evita loops infinitos como mecanismo de disjuntor
• Save/Load salva estado em arquivo por serialização
• Arquitetura orientada a eventos pode ser adaptada a ambientes distribuídos
• Protocolo conversacional: Agents colaboram por linguagem natural

Resumo comparativo dos dois

Característica	LangGraph	AutoGen
Definição de estado	TypedDict explícito	Fluxo conversacional implícito
Checkpoint	Salvamento automático por nó em banco de dados	Serialização em arquivo
Mecanismo de recuperação	Pula nós já executados no nível de Super-Step	Rollback de conversa
Human-in-the-Loop	Pausa com interrupt + retomada com resume	Intervenção via UserProxyAgent
Controle de término	Roteamento por edges condicionais	Disjuntor por TerminationCondition
Quantidade de código	Cerca de 60 linhas, com definição de State + Edge	Cerca de 30 linhas, orientado a conversa

LangGraph: controle granular, adequado para gerenciamento preciso de estado.

AutoGen: prototipagem rápida, adequado para colaboração conversacional flexível.

Recomendações de implantação em produção: o caminho completo do desenvolvimento à produção

Pontos-chave para implantar LangGraph em produção

Solução de persistência:

Combinação de PostgresSaver + RedisSaver.

PostgreSQL faz o armazenamento persistente e oferece suporte natural a implantação distribuída. Redis atua como camada de cache e acelera leitura e escrita em cenários de alta concorrência.

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

# Configuração de produção
postgres_saver = PostgresSaver.from_conn_string(
    "postgresql://user:pass@host:5432/db"
)
redis_saver = RedisSaver.from_conn_string(
    "redis://host:6379/0"
)

# Uso combinado: cache com Redis + persistência com Postgres
compiled_graph = graph.compile(
    checkpointer=postgres_saver
)

Observabilidade:

LangSmith tracing + integração com OpenTelemetry.

LangSmith mostra o rastreamento da cadeia de chamadas: qual nó está lento, qual consome mais tokens. OpenTelemetry conecta isso ao sistema de monitoramento existente.

Otimização de desempenho:

Saída em streaming: o usuário vê o primeiro token imediatamente, com percepção de latência menor que 1 segundo.

Chamadas paralelas de Tool: LangGraph oferece suporte nativo para executar várias ferramentas ao mesmo tempo.

Pré-compilação de prompts: reduz o tempo de inferência do LLM em cerca de 30%.

Otimização de custo:

Estratégia	Redução de custo	Cenário adequado
Compressão de prompt	30-50%	Cenários gerais
Roteamento multi-provider	40-60%	Failover em produção
Mecanismo de cache	50-80%	Consultas repetidas

Roteamento multi-provider é configuração básica de produção. Um API Gateway implementa failover: se GPT-4 cair, troca automaticamente para Claude, e ainda pode reduzir custo em 40%.

Pontos-chave para implantar AutoGen em produção

Observabilidade:

Os três pilares do OpenTelemetry: Logs, Metrics e Traces.

• EventLogger + logs estruturados: localização de problemas e trilha de auditoria
• OpenTelemetry Meter: monitoramento de desempenho e planejamento de capacidade
• OpenTelemetry Tracer: análise da cadeia de chamadas e otimização de latência

from autogen_core.telemetry import (
    enable_telemetry,
    EventLogger
)

# Ativar observabilidade
enable_telemetry(
    logger=EventLogger(),
    meter=OpenTelemetryMeter(),
    tracer=OpenTelemetryTracer()
)

Monitoramento de fluxo de eventos:

Tecnologia de replay para depuração: todas as ações dos Agents geram um fluxo de eventos que pode ser reproduzido para reconstruir o problema.

Adaptação distribuída:

A arquitetura orientada a eventos tem afinidade natural com distribuição. Mensagens entre Agents passam por eventos, sem competição por estado.

Controle de custo:

TokenUsageTermination como disjuntor: ao atingir o limite de orçamento, a execução termina automaticamente.

from autogen_agentchat.conditions import TokenUsageTermination

# Configuração do disjuntor de custo
termination = TokenUsageTermination(max_tokens=10000)

Logs estruturados ajudam a analisar consumo de tokens: quais conversas consomem mais e qual Agent custa mais.

Tabela de comparação de implantação em produção

Dimensão	LangGraph	AutoGen
Persistência	PostgresSaver com suporte distribuído	Serialização em arquivo, exige adaptação
Observabilidade	LangSmith tracing	Três pilares do OpenTelemetry
Controle de custo	Roteamento multi-provider	Disjuntor TokenUsageTermination
Otimização de desempenho	Streaming + Tools paralelas	Monitoramento de fluxo de eventos
Distribuído	PostgresSaver com suporte natural	Adaptação orientada a eventos

Lição central: produção precisa obrigatoriamente de AI Gateway

Não importa se você escolhe LangGraph ou AutoGen: em produção, é obrigatório adicionar um AI Gateway.

Por quê?

1. Failover entre múltiplos providers

Se uma API cai, há troca automática. GPT-4 ficou indisponível? Troque para Claude. Isso elimina ponto único de falha.

2. Monitoramento de custo

Qual Agent consome mais? Qual conversa custa mais? Monitoramento em tempo real. Quando o orçamento estoura, o disjuntor entra.

3. Rate limiting

Evita que a API seja limitada. As requisições entram em fila e podem ser retentadas automaticamente.

4. Rastreamento de logs

Todas as chamadas são registradas de forma centralizada. Isso facilita diagnóstico, auditoria e rastreabilidade.

AI Gateway não é opcional. É um item obrigatório para Agents em nível de produção.

Conclusão

LangGraph e AutoGen representam duas grandes linhas técnicas em frameworks de Agent.

LangGraph: orquestração de workflow com prioridade para máquina de estados. Define explicitamente State + Node + Edge, com cada passo controlável. Tem suporte nativo a Checkpoint e se recupera de falhas sem repetir execução. É adequado para ramificações condicionais complexas, tarefas longas e implantação distribuída.

AutoGen: colaboração multi-papel com prioridade para conversa. Agents negociam por linguagem natural em um fluxo conversacional flexível. Condições de término funcionam como disjuntor contra loops infinitos. É adequado para protótipos rápidos, negociação livre entre múltiplos Agents e cenários de interpretação de papéis.

A escolha não é “qual é melhor”, mas “qual é mais adequado ao seu cenário”.

Há um fluxo com ramificações condicionais claras? LangGraph. Precisa de negociação livre entre múltiplos Agents? AutoGen. A tarefa longa precisa de tolerância a falhas? LangGraph. Quer validar um protótipo rápido? AutoGen.

Eu já tropecei nos dois frameworks. No AutoGen, estado incontrolável e migração de API exigiram reescrita. No LangGraph, definir o grafo de estado tomou mais de cem linhas.

A lição central: produção precisa de AI Gateway. Failover entre múltiplos providers, monitoramento de custo e rate limiting são a base para Agents estáveis.

Próximo passo: se o seu projeto é um workflow complexo, escolha LangGraph. Se você quer montar rapidamente um protótipo multi-Agent, escolha AutoGen. Depois leia “Prática de gerenciamento de estado com LangGraph” (número 39 da série) para se aprofundar na prática do mecanismo de Checkpoint.