LangChain vs LangGraph: como escolher para seu projeto

LangChain vs LangGraph: qual escolher para o seu projeto?

Escolha LangChain para um ciclo de agente configurável. Use LangGraph diretamente quando precisar desenhar o processo ao redor desse ciclo. A decisão passa por quem escolhe a próxima etapa, quais informações precisam sobreviver a uma interrupção e quais responsabilidades de operação você quer assumir.

Se você está criando um assistente de atendimento que consulta pedidos e responde a perguntas, use create_agent do LangChain. Você fornece o modelo, as ferramentas e as instruções; a abstração de agente cuida do ciclo de interação entre modelo e ferramentas. Quando precisar verificar uma política ou exigir aprovação, adicione middleware: código executado ao redor dessa interação.

Se o aplicativo já usa LangChain, mantenha essa estrutura até identificar um requisito de fluxo difícil de expressar com ela. Acrescentar memória à conversa ou revisar uma chamada de ferramenta proposta pelo modelo não basta, por si só, para justificar a mudança: os agentes atuais do LangChain oferecem ambos os recursos com base no LangGraph. Documentação de agentes do LangChain.

Se o aplicativo precisa validar uma solicitação, reunir evidências, aguardar um operador, executar uma ação autorizada e conferir o resultado com os registros, considere um fluxo próprio em LangGraph. Essas etapas são regras de negócio que podem ficar explícitas no código, enquanto um agente cuida do trabalho flexível dentro de uma delas.

Os termos de uso das bibliotecas estão nas páginas de produto do LangChain e do LangGraph. A comparação de recursos segue a visão geral do runtime e a documentação do middleware de aprovação, publicadas pelos desenvolvedores. A recomendação aqui é de arquitetura, não um ranking de velocidade.

Qual é a diferença entre LangChain e LangGraph hoje?

O LangChain fornece os componentes e a abstração de agente; o LangGraph fornece o runtime de orquestração com estado que sustenta essa camada. Tratar os dois como substitutos rivais gera trabalho de migração desnecessário.

LangChain: uma camada de agentes configurável

O LangChain descreve create_agent como uma “estrutura mínima e altamente configurável para executar agentes”. Essa estrutura, chamada de harness, reúne o que cerca o modelo: instruções, ferramentas disponíveis para chamada e controles de comportamento. A mesma visão geral afirma explicitamente: “Os agentes do LangChain são construídos sobre o LangGraph.” Visão geral do LangChain.

A vantagem está em partir de uma estrutura útil. Em um assistente de atendimento sobre pedidos, você pode expor a função de consulta existente como ferramenta e adicionar regras para seu uso. Não é preciso montar o ciclo à mão antes de trabalhar no produto.

O limite aparece quando essa estrutura deixa de se encaixar no problema. Um atendimento de longa duração, com etapas de negócio bem definidas, pode ficar difícil de entender se cada transição estiver escondida em prompts, convenções de ferramentas e middleware. Essa é uma avaliação de manutenibilidade, não uma afirmação de que agentes do LangChain não podem ter ramificações ou manter estado. A biblioteca é gratuita; o acesso ao modelo e a infraestrutura escolhida continuam sendo custos separados.

LangGraph: o runtime de fluxos sob seu controle

O LangGraph se define como um “framework e runtime de orquestração de baixo nível” para agentes de longa duração que mantêm estado. Um nó representa uma unidade de trabalho; uma aresta determina para onde a execução segue; o estado reúne as informações carregadas entre essas etapas. É possível combinar lógica convencional de aplicação com decisões orientadas pelo modelo. Visão geral do LangGraph.

O LangGraph leva vantagem quando o próprio fluxo faz parte do produto. O modelo pode redigir uma resposta enquanto o código da aplicação decide se ela exige aprovação e se a ação aprovada já foi executada.

O limite está na responsabilidade que você assume. Cabe a você definir um estado que faça sentido, as transições e o comportamento em caso de falha. Um grafo com limites confusos continua sendo software confuso. O LangGraph também é uma biblioteca gratuita e pode ser usado sem LangChain, embora muitas vezes seja conveniente manter os componentes de modelos e ferramentas do LangChain.

Um meio-termo prático é colocar um agente do LangChain dentro de um processo maior. Preserve a abstração útil para o trabalho flexível com ferramentas e explicite a sequência de negócio ao redor dela apenas onde for necessário.

LangGraph vs LangChain: quem controla cada etapa?

O LangChain oferece mais conveniência dentro do ciclo do agente; o LangGraph oferece controle explícito sobre as etapas de negócio. Durabilidade e revisão humana estão presentes nos dois, mas ainda dependem de configuração adequada.

Ciclos de agente e aprovação de ferramentas: vantagem do LangChain

Um assistente que consulta um pedido, explica o status e propõe uma resposta se encaixa no ciclo entre modelo e ferramentas. Acrescentar uma revisão antes de uma ferramenta enviar a resposta também se encaixa: HumanInTheLoopMiddleware pode pausar as chamadas configuradas e aceitar aprovação, edição dos argumentos ou rejeição. Ele usa a persistência do LangGraph para preservar o estado interrompido. Documentação de intervenção humana.

Para um aplicativo que já usa LangChain, isso permite um próximo passo relativamente pontual: configurar a política de aprovação e um checkpointer persistente, depois integrar a decisão pendente ao aplicativo. O middleware não cria a caixa de entrada de revisões nem determina qual funcionário tem autorização para aprovar. Essas responsabilidades continuam na aplicação.

Etapas de negócio explícitas: vantagem do LangGraph

Escolha um grafo próprio quando a próxima etapa correta depender do registro de negócio, e não da próxima ferramenta sugerida pelo modelo. Pense em um processo de cadastro de fornecedores: reunir evidências, validar os campos obrigatórios, encaminhar uma exceção a um operador e só ativar o fornecedor após a aprovação.

Um grafo pode representar essas transições diretamente. O nó que reúne evidências ainda pode chamar um agente do LangChain. A validação e a ativação podem ser funções convencionais com resultados explícitos. A capacidade documentada do LangGraph de combinar etapas determinísticas com etapas conduzidas por agentes é a distinção útil aqui. Visão geral do LangGraph.

O critério para mudar é concreto: desça uma camada quando explicitar o estado e as transições eliminar dúvidas recorrentes sobre o que a aplicação pode fazer em seguida. Um prompt maior, mais ferramentas ou uma resposta lenta do modelo não demonstram essa necessidade por si só.

Durabilidade: mesma base, responsabilidades de projeto diferentes

Um checkpointer salva o estado do fluxo de uma thread para que a execução possa continuar depois. Um store guarda informações definidas pela aplicação e compartilhadas entre threads, como uma preferência usada em conversas separadas. Eles resolvem problemas diferentes de persistência. Documentação de persistência.

Em qualquer uma das abordagens, escolha um armazenamento adequado à falha que precisa suportar. InMemorySaver mantém os checkpoints no processo em execução e os perde quando ele reinicia. Serve para demonstrar o estado de uma conversa ou uma interrupção, mas não comprova a recuperação após a queda do worker. Um saver de produção apoiado em banco de dados, ou a persistência gerenciada pelo Agent Server, atende a esse requisito de armazenamento.

Também é preciso distinguir um checkpoint do comprovante de uma ação externa. Salvar “pronto para ativar fornecedor” não comprova que o sistema de fornecedores aceitou a ativação. Guarde o identificador externo e o resultado em um registro da aplicação que permita conferir e conciliar as informações.

Os desenvolvedores documentam esse reinício e a necessidade de efeitos colaterais idempotentes: operações que podem se repetir sem repetir seu efeito no negócio. Por exemplo, use um identificador estável de operação para que uma tarefa retomada não crie o mesmo fornecedor duas vezes. Regras de interrupção e reexecução.

LangChain vs LangGraph em Python: a mesma tarefa nos dois

Para uma consulta simples ao status de um pedido, o LangChain expressa a mesma intenção com menos código de orquestração. O grafo próprio deixa visível o caminho entre modelo e ferramentas, o que passa a fazer sentido quando esse caminho precisa mudar.

Os exemplos usam o mesmo modelo, prompt, ferramenta somente de leitura e entrada. O registro do pedido é uma fixture local explicitamente fictícia. Instale langchain[anthropic] e langgraph; uma chamada real ao modelo exige a ANTHROPIC_API_KEY da sua aplicação. O identificador do modelo usado no exemplo segue a visão geral atual do LangChain e o guia de início rápido do LangGraph, publicados pelos desenvolvedores. Os dois trechos foram verificados localmente com um modelo de respostas programadas para conferir a execução das ferramentas e o estado salvo. Isso valida a integração, não o comportamento ou o desempenho de um modelo real.

Salve esta configuração compartilhada como common.py:

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("claude-sonnet-4-6", temperature=0)
prompt = "Use lookup_order for order status. Do not invent a status."
request = {"messages": [{"role": "user", "content": "Status of order demo?"}]}
config = {"configurable": {"thread_id": "order-demo"}}

@tool
def lookup_order(order_id: str) -> str:
    """Read an order's status from a fictional local fixture."""
    return {"demo": "shipped"}.get(order_id, "unknown order")

LangChain: aproveite o ciclo pronto

Execute este código em um script separado, no mesmo diretório de common.py:

from common import model, prompt, request, config, lookup_order
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model, tools=[lookup_order], system_prompt=prompt,
    checkpointer=InMemorySaver(),
)
print(agent.invoke(request, config)["messages"][-1].content)

Esse agente já tem o runtime de grafos por baixo. Passar um checkpointer não exige substituir create_agent por um grafo escrito à mão. Configuração de agentes.

LangGraph: declare o mesmo ciclo

Execute este script alternativo no mesmo diretório do mesmo common.py:

from common import model, prompt, request, config, lookup_order
from langchain.messages import SystemMessage
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.prebuilt import ToolNode, tools_condition

bound_model = model.bind_tools([lookup_order])

def call_model(state: MessagesState):
    reply = bound_model.invoke([SystemMessage(prompt)] + state["messages"])
    return {"messages": [reply]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_node("tools", ToolNode([lookup_order]))
builder.add_edge(START, "model")
builder.add_conditional_edges("model", tools_condition)
builder.add_edge("tools", "model")
agent = builder.compile(checkpointer=InMemorySaver())
print(agent.invoke(request, config)["messages"][-1].content)

A aresta condicional encaminha uma chamada de ferramenta solicitada para tools ou encerra a execução quando o modelo produz uma resposta final. O nó de ferramentas devolve o controle ao modelo. Esse é o padrão de ciclo explícito do guia de início rápido do LangGraph, usando os auxiliares fornecidos para o nó de ferramentas.

Os dois trechos usam intencionalmente memória local ao processo e mostram apenas o caminho de leitura bem-sucedida. Nenhum deles é uma receita de deploy, uma configuração de banco de dados durável ou uma política completa de erros. Configurações iguais também não garantem que o modelo produza uma saída idêntica palavra por palavra.

Para essa tarefa, escolha LangChain. Um grafo próprio passa a ser útil quando o próximo requisito muda o processo: validação obrigatória antes da consulta, uma fila separada de exceções ou uma etapa de aprovação que precise de estado e resultados próprios.

Preços do LangSmith e custos de deploy com LangGraph

A escolha da biblioteca não determina uma tarifa de hospedagem diferente. A decisão de contratação depende dos serviços do LangSmith e do ambiente de deploy de que você precisa. Os preços e a documentação de produto abaixo foram conferidos nas páginas oficiais em 13 de outubro de 2026.

LangChain, LangGraph e LangSmith: o papel de cada um

O LangSmith é a plataforma de rastreamento, avaliação e deploy ao redor da aplicação. Um trace registra uma execução do aplicativo e pode incluir chamadas ao modelo e outras etapas. É um objeto diferente do checkpoint usado para retomar a aplicação. Preços e definições do LangSmith.

As duas bibliotecas são gratuitas. Se você hospedar qualquer uma delas em infraestrutura própria, ainda precisará prever os custos de chamadas ao modelo, processamento, armazenamento e operação. Contratar LangSmith é uma decisão separada; sua documentação de deploy informa explicitamente o suporte a aplicações LangGraph e LangChain.

Essas são as condições dos planos em langchain.com/pricing. A calculadora da página descreve a franquia do Plus como 10K traces no total: adicionar usuários não significa ganhar outra franquia para cada um. Para a configuração de observabilidade exibida, ela informa 0.005 LSU por trace adicional. Esse valor da calculadora não deve ser generalizado para todas as opções de retenção de traces.

Os traces básicos têm retenção de 14 dias; os estendidos, de 180 dias, com cobrança adicional. Retenção mais longa e serviços de avaliação são decisões de orçamento separadas, não benefícios gratuitos de escolher um grafo. Perguntas frequentes sobre preços.

Opções de deploy e seus limites

Cloud é a opção gerenciada, disponível a partir do Plus. A LangChain opera a infraestrutura. Dentro de Cloud, a página pública de preços oferece deploys Serverless e Dedicated nos tamanhos Small, Medium e Large. Ambientes de deploy.

Serverless atende a tarefas intermitentes, em segundo plano ou que toleram latência. A infraestrutura escala a zero quando está ociosa, e o Plus inclui um deploy pequeno. Dedicated atende a aplicações voltadas ao cliente que precisam de disponibilidade constante, com infraestrutura sempre ativa, escalonamento automático, backups e alta disponibilidade. Esses são os usos indicados pelo fornecedor, não medições de desempenho feitas nesta comparação. Perguntas frequentes sobre preços de deploy.

Uma limitação prática afeta o plano de migração: é possível mudar o tamanho de um deploy, mas não seu tipo após a criação. Passar de Serverless para Dedicated exige, portanto, uma transição entre deploys, e não apenas um ajuste de tamanho. Os recursos Serverless também são cobrados enquanto estão provisionados, inclusive no período ocioso anterior à redução de escala. “Escalar a zero” não significa que todo segundo sem requisições seja gratuito. Recursos da plataforma Cloud.

Hybrid mantém o plano de controle gerenciado enquanto você opera a infraestrutura dos agentes. O plano de controle é o serviço que gerencia os deploys; o plano de dados executa os agentes e os serviços de apoio. A hospedagem própria com plano de controle coloca os dois no seu ambiente. A página de preços inclui as opções híbrida e de hospedagem própria no Enterprise, com preço sob consulta. Não há um valor mensal fixo e público para o plano empresarial que possa ser usado no lugar da proposta comercial. Preços e ambientes de deploy.

O Agent Server em modo standalone é outra opção de operação, sem plano de controle e com serviços de apoio sob sua responsabilidade. A documentação exige uma licença do LangSmith, PostgreSQL e Redis. Isso é diferente de incorporar a biblioteca gratuita LangGraph ao seu aplicativo. A documentação standalone também alerta para não hospedar esse servidor em um ambiente serverless que escale a zero; o produto gerenciado Cloud Serverless tem uma configuração separada. Agent Server standalone.

A mesma carga de trabalho custa o mesmo nos dois frameworks

A página pública define US$1.00 por LSU, ou LangChain Standard Unit, e lista estas tarifas de recursos para deploy:

• Processamento do runtime: 0.0675 LSU / vCPU-hr.
• Memória do runtime: 0.0090 LSU / GiB-hr.
• Processamento do banco de dados: 0.177 LSU / vCPU-hr.
• Memória do banco de dados: 0.025 LSU / GiB-hr.

Essas tarifas se aplicam ao consumo faturável de recursos de deploys adicionais Serverless e Dedicated. Tarifas publicadas de deploy.

Tanto para um agente LangChain quanto para um aplicativo próprio em LangGraph, o cálculo mensal normalizado do Plus é US$39 × número de usuários, mais a quantidade faturável de horas de cada recurso multiplicada pela tarifa acima, além do consumo de modelos, rastreamento e outros itens aplicáveis. Desconte a franquia de deploy incluída antes de contabilizar os recursos faturáveis. Não converta requisições ou nós do grafo em horas de recursos sem medições.

Os cálculos a seguir usam os tamanhos publicados pelo fornecedor. São explicitamente valores calculados, não preços de planos anunciados. Um deploy Small Serverless adicional tem 1 vCPU e 2 GiB de recursos de runtime, o que resulta em 1 × 0.0675 + 2 × 0.0090 = US$0.0855 por hora provisionada. Um deploy Small Dedicated lista 3 vCPU e 6 GiB para o runtime, mais 1 vCPU e 4 GiB para o banco de dados, resultando em 3 × 0.0675 + 6 × 0.0090 + 1 × 0.177 + 4 × 0.025 = US$0.5335 por hora provisionada. São estimativas de recursos por tamanho, antes de escalonamento adicional ou outros serviços, com base na tabela de tamanhos e nas tarifas publicadas.

Para um único usuário do Plus, mantendo constante esse perfil de recursos Dedicated, o subtotal mensal é US$39 + US$0.5335 × horas provisionadas, antes das demais cobranças já listadas. A fórmula é idêntica para os dois frameworks. Para garantir um valor de fatura mensal, é preciso conhecer o tempo real de uso dos recursos e o escalonamento do deploy.

Com a mesma carga de trabalho, não existe um ponto em que um framework passe a custar menos que o outro. A diferença calculada é de US$0 quando o número de usuários, os recursos faturáveis, o uso de modelos e ferramentas e a política de traces são iguais. Redesenhar o fluxo pode alterar essas quantidades, mas o nome da biblioteca não dá desconto nem comprova uma conta menor de tokens.

Como migrar de LangChain para LangGraph sem reescrever tudo

Migre a parte da orquestração que precisa de controle e preserve os componentes que continuam funcionando. O custo relevante da migração está em redesenhar estado, comportamento e recuperação, não em mudar a instrução de importação.

Primeiro, separe a atualização de uma API legada da decisão de adotar um grafo próprio. O guia de migração atual recomenda langchain.agents.create_agent no lugar do construtor anterior langgraph.prebuilt.create_react_agent. Seguir essa migração não significa abandonar o LangGraph na camada inferior. Um aplicativo antigo pode aproveitar os recursos atuais do LangChain antes de precisar de orquestração sob medida. Guia de migração do LangChain.

Não troque um assistente LangChain que funciona só porque grafos parecem mais adequados à produção. Se o ciclo, o middleware e o armazenamento persistente atendem aos requisitos, um grafo próprio acrescenta trabalho de projeto sem retorno demonstrado.

A dependência tecnológica também tem camadas. Os componentes reutilizáveis de modelos e ferramentas podem permanecer enquanto o estado do grafo e o fluxo de controle mudam. A infraestrutura hospedada acrescenta restrições próprias: a persistência de Cloud é acessada pelo Agent Server, e o banco de dados hospedado não tem acesso direto. Considere esse limite de acesso em qualquer futura exportação ou mudança de hospedagem. Detalhes de persistência em Cloud.

Para outra decisão — comparar a orquestração por grafos com uma abstração de equipe de especialistas —, leia LangGraph vs CrewAI. Para avaliar opções além dessa stack, consulte a comparação de frameworks de agentes de IA.

Dúvidas de quem está escolhendo a arquitetura

Use o Checklist de auditoria de fluxos de trabalho com IA para negócios para definir a tarefa, o ponto de revisão e o responsável pela operação antes de mudar a orquestração.