--- title: "LangGraph vs OpenAI Agents SDK vs PydanticAI: Qual Usar?" url: "https://python.dev.br/comparacoes/langgraph-vs-openai-agents-vs-pydanticai/" markdown_url: "https://python.dev.br/comparacoes/langgraph-vs-openai-agents-vs-pydanticai.MD" description: "Compare LangGraph, OpenAI Agents SDK e PydanticAI para agentes de IA em Python: controle, tipagem, produção, custo operacional e projetos de portfólio." date: "2026-06-04" author: "Equipe Python Brasil" --- # LangGraph vs OpenAI Agents SDK vs PydanticAI: Qual Usar? Compare LangGraph, OpenAI Agents SDK e PydanticAI para agentes de IA em Python: controle, tipagem, produção, custo operacional e projetos de portfólio. Frameworks de agentes de IA em Python amadureceram rápido. Em 2024 muita gente ainda chamava qualquer chatbot com tool calling de "agente". Em 2026, a pergunta ficou mais prática: qual ferramenta ajuda a construir um sistema que chama APIs, mantém estado, valida saída, respeita limites de segurança e pode ser operado sem virar uma demonstração frágil? Três nomes aparecem com frequência nessa discussão: **LangGraph**, **OpenAI Agents SDK** e **PydanticAI**. Todos permitem criar agentes em Python, mas eles partem de filosofias diferentes. LangGraph pensa em grafos e execução com estado. OpenAI Agents SDK foca uma experiência direta de agentes, tools, handoffs e guardrails no ecossistema OpenAI. PydanticAI aproxima agentes de uma experiência type-safe, com validação forte e dependency injection inspirada no que o ecossistema Python já faz bem. Este comparativo ajuda a escolher o caminho certo para estudo, portfólio e produção. Se você ainda está montando a base, leia antes [Python e LLMs](/blog/python-e-llms-apis-inteligencia-artificial/), [LLMOps com Python](/blog/llmops-python-producao/) e [como conseguir vaga Python com IA](/carreira/como-conseguir-vaga-python-ia/). ## Resposta rápida Use **OpenAI Agents SDK** se você quer montar um agente funcional rápido, com tools e handoffs, e o projeto já está confortável no ecossistema OpenAI. Use **PydanticAI** se a prioridade é saída estruturada, validação, tipagem, testes e integração natural com modelos Pydantic. Use **LangGraph** se o fluxo precisa de estado persistente, ciclos, ramificações, revisão humana, retomada depois de falha ou uma arquitetura mais explícita para produção. | Critério | LangGraph | OpenAI Agents SDK | PydanticAI | |---|---|---|---| | Melhor caso de uso | Fluxos complexos e duráveis | Agentes rápidos com tools e handoffs | Agentes type-safe e respostas estruturadas | | Curva de aprendizado | Maior | Menor a média | Média | | Modelo mental | Grafo com nós, arestas e estado | Agente, tool, handoff e guardrail | Agent, dependências e modelos Pydantic | | Controle de fluxo | Muito alto | Bom | Bom para fluxos mais lineares | | Tipagem/validação | Depende da implementação | Boa, mas menos central | Ponto forte | | Produção | Forte quando bem desenhado | Forte para casos alinhados ao SDK | Forte em contratos e testes | | Portfólio | Excelente para mostrar arquitetura | Excelente para demo funcional | Excelente para mostrar qualidade de software | ## O que cada ferramenta tenta resolver Antes de comparar código, vale separar os problemas. Um agente de IA real costuma precisar de pelo menos cinco capacidades: 1. receber uma tarefa em linguagem natural; 2. decidir se precisa chamar uma ferramenta; 3. executar a ferramenta com argumentos válidos; 4. interpretar o resultado; 5. devolver uma resposta útil, segura e rastreável. Em projetos pequenos, isso pode ser uma função que chama um modelo e uma API. Em projetos maiores, entram controle de acesso, estado, memória, aprovação humana, custo, logs, avaliação e fallback. A diferença entre os frameworks aparece justamente quando o projeto cresce. ## LangGraph: quando o fluxo importa O LangGraph representa o agente como um grafo. Em vez de escrever uma sequência fixa de chamadas, você define nós de processamento e transições condicionais. Isso combina bem com agentes que precisam tentar uma ferramenta, revisar o resultado, decidir se buscam mais dados e só então responder. Um desenho típico pode ter: - nó de classificação da intenção; - nó de busca em documentos; - nó de chamada de ferramenta externa; - nó de revisão de segurança; - nó de aprovação humana; - nó de resposta final. Essa estrutura é mais verbosa do que um agente simples, mas deixa o comportamento explícito. Para produção, isso ajuda muito. Você consegue inspecionar onde o fluxo parou, qual estado foi carregado, qual decisão levou a outra ferramenta e onde uma regra humana deve intervir. LangGraph brilha em cenários como: - assistente interno que consulta CRM, banco e documentos; - workflow de suporte que abre chamado apenas depois de confirmação; - agente de pesquisa que pode fazer múltiplas buscas antes de concluir; - automação que precisa pausar para aprovação humana; - sistema que deve retomar execução depois de falha. A desvantagem é a curva de aprendizado. Para um primeiro projeto, muita gente se perde tentando modelar um grafo antes de entender prompts, embeddings, ferramentas e avaliação. Por isso, LangGraph é ótimo para o segundo passo: quando você já sabe construir uma integração simples e agora precisa de controle. Leia também o tutorial de [LangGraph com Python](/blog/langgraph-agentes-ia-python/) para ver o modelo de estado, nós e transições na prática. ## OpenAI Agents SDK: caminho direto para agentes com tools O OpenAI Agents SDK é atraente porque reduz o atrito inicial. Você define um agente, passa instruções, registra ferramentas e deixa o runtime cuidar de boa parte da orquestração. Para protótipos, produtos internos e integrações alinhadas ao ecossistema OpenAI, isso encurta o caminho entre ideia e ferramenta funcionando. O SDK combina bem com projetos como: - assistente que consulta uma API específica; - triagem de mensagens com handoff para agentes especializados; - automação de atendimento interno; - geração de relatórios com algumas ferramentas controladas; - protótipo comercial que precisa validar demanda rapidamente. O ponto forte é velocidade. Um projeto de portfólio usando o SDK pode mostrar tool calling, handoffs, guardrails e interface simples sem virar um sistema enorme. O ponto de atenção é dependência de ecossistema e desenho operacional. Mesmo com SDK, você ainda precisa pensar em logs, limites de custo, entradas perigosas, timeout, retries e tratamento de erro. Um erro comum é achar que o SDK substitui arquitetura. Não substitui. Ele facilita a construção do agente, mas a aplicação continua precisando de fronteiras claras: o que o agente pode fazer, que dados pode acessar, que ações exigem confirmação e como o usuário percebe falhas. Para começar, veja o guia de [OpenAI Agents SDK em Python](/blog/openai-agents-sdk-python-multi-agentes/). ## PydanticAI: quando contrato e validação importam PydanticAI parte de uma dor muito comum: LLMs retornam texto flexível demais. Em aplicações reais, você muitas vezes não quer "uma resposta qualquer". Você quer uma estrutura validada: campos obrigatórios, tipos corretos, enumerações, listas, limites e mensagens de erro compreensíveis. Isso aproxima agentes de práticas já conhecidas em FastAPI e Pydantic. Em vez de confiar que o modelo vai devolver JSON perfeito, você define modelos, valida resultados e lida com erros como parte normal do fluxo. PydanticAI é especialmente útil para: - classificação de leads, tickets ou documentos; - extração de dados estruturados; - agentes que precisam devolver um plano validado; - sistemas em que a resposta alimenta outra API; - projetos com testes automatizados e dependency injection. A força aqui não é criar o grafo mais sofisticado, e sim reduzir ambiguidade. Se a saída do agente vira dado de negócio, validação vale muito. Isso também torna o projeto mais convincente em entrevista: você mostra que entende limites de LLMs e não trata texto gerado como verdade automática. Veja o tutorial de [PydanticAI com Python](/blog/pydanticai-agentes-ia-tipagem-forte/) e revise [Pydantic para validação de dados](/blog/pydantic-validacao-dados-python/) se a base ainda não estiver sólida. ## Comparação por tipo de projeto ### Projeto de portfólio júnior/pleno Para um projeto de portfólio, escolha o menor escopo que demonstre maturidade. Um bom exemplo seria um **assistente de triagem de vagas Python**: - recebe descrição de vaga; - extrai stack, senioridade, regime e riscos; - compara com perfil do candidato; - sugere próximos estudos; - registra limitações; - não inventa compatibilidade perfeita. Para esse projeto, **PydanticAI** é uma ótima escolha porque a saída estruturada importa. Você pode definir modelos como `VagaExtraida`, `LacunaTecnica` e `PlanoEstudo`. Depois escreva testes com descrições fictícias. Se quiser demonstrar tool calling, **OpenAI Agents SDK** também funciona bem: uma ferramenta busca links internos do seu material de estudo, outra monta checklist, outra gera mensagem de candidatura. Só mantenha ações reais desabilitadas ou exigindo confirmação. LangGraph pode ser usado, mas talvez seja excesso para o primeiro projeto. Use se você quer mostrar explicitamente etapas como classificar vaga, buscar contexto, revisar risco e gerar resposta. ### Produto interno com várias etapas Para um produto interno que consulta sistemas e pode executar ações, **LangGraph** tende a ser mais seguro. O grafo deixa claro onde o agente decide, onde chama ferramenta, onde precisa de aprovação e onde encerra. Exemplo: um assistente de suporte que pode consultar documentação, verificar status de conta, sugerir resposta e abrir chamado. Esse fluxo tem ramificações e risco operacional. Um grafo com estado ajuda a controlar. ### Extração e classificação de documentos Para extrair dados de contratos, currículos, tickets, emails ou notas fiscais, **PydanticAI** costuma ser o melhor ponto de partida. A saída precisa ser validada. Um campo faltando ou uma categoria inesperada deve virar erro controlado, não dado silenciosamente errado. ### Demo rápida para validar uma ideia Para validar uma ideia com poucas ferramentas, **OpenAI Agents SDK** é direto. Você consegue montar uma prova de conceito rapidamente, especialmente se as ferramentas forem funções Python simples e o produto ainda estiver buscando encaixe. ## O que importa mais que o framework A ferramenta não corrige um projeto mal desenhado. Antes de discutir LangGraph vs OpenAI Agents SDK vs PydanticAI, revise estes pontos: - **Escopo da ação**: o agente só responde, ou pode executar algo? - **Permissões**: quais dados e ferramentas ele pode acessar? - **Confirmação humana**: que ações precisam de aprovação? - **Observabilidade**: onde ficam logs, custo, latência e erro? - **Avaliação**: como você mede se a resposta melhorou? - **Fallback**: o que acontece quando o modelo falha? - **Segurança**: como lidar com prompt injection e dados sensíveis? Esses itens aparecem em qualquer framework. Se o projeto usa RAG, conecte também com [RAG com FastAPI e pgvector](/blog/rag-fastapi-pgvector-producao/). Se usa deploy real, revise [Docker em projetos Python](/guias/configurando-docker-python/) e [observabilidade com OpenTelemetry](/blog/opentelemetry-python-observabilidade/). ## Recomendações práticas Se você está estudando para vagas Python com IA, siga esta ordem: 1. construa uma chamada simples a LLM com entrada e saída controladas; 2. adicione uma ferramenta Python pequena; 3. registre logs, custo aproximado e erros; 4. force saída estruturada com Pydantic; 5. transforme em API com FastAPI; 6. só então escolha um framework de agentes para o fluxo completo. Para a maioria dos candidatos, o projeto que mais impressiona não é o que usa mais bibliotecas. É o que tem README claro, dados fictícios, `.env.example`, testes, limitação explícita e uma história de produto coerente. ## Veredito **Escolha OpenAI Agents SDK** quando velocidade e integração direta com ferramentas forem mais importantes que controle fino de fluxo. **Escolha PydanticAI** quando o diferencial for contrato, tipagem, validação e confiabilidade da saída. **Escolha LangGraph** quando o agente for um workflow com estado, etapas condicionais, revisão humana e necessidade de retomada. Em produção, essas escolhas não são apenas técnicas. Elas afetam manutenção, contratação, custo e risco. Comece pelo menor sistema que resolve o problema, prove que ele funciona, depois adicione complexidade apenas onde ela reduz risco real. Para continuar estudando, veja [LangGraph com Python](/blog/langgraph-agentes-ia-python/), [OpenAI Agents SDK](/blog/openai-agents-sdk-python-multi-agentes/), [PydanticAI](/blog/pydanticai-agentes-ia-tipagem-forte/) e o roteiro de [vaga Python com IA](/carreira/como-conseguir-vaga-python-ia/).