---
title: Frameworks de agentes de IA comparados: qual camada cada um resolve
description: LangGraph, CrewAI, o OpenAI Agents SDK, o Vercel AI SDK e o Mastra competem menos do que parece. O stack em que eles vivem, e a camada que nenhum deles cobre.
date: 2026-08-11
author: Victor Villalobos
locale: pt
source: https://www.zavu.dev/pt/blog/ai-agent-frameworks
tags: AI Agents, Comparação, Tutorial
---

# Frameworks de agentes de IA comparados: qual camada cada um resolve

"Qual framework de agentes eu uso" quase sempre é a segunda pergunta. A primeira é "em qual camada do problema eu estou realmente travado", e quando você responde isso a lista curta se monta sozinha.

Porque essas ferramentas não competem tão de frente quanto os posts de comparação sugerem. LangGraph e Vercel AI SDK se sobrepõem em talvez um terço da superfície. CrewAI resolve um problema que o Vercel AI SDK nem tenta. E existe uma camada que nenhum deles toca, que é justamente a que decide se o seu agente vai ter usuários.

## O stack

Todo agente em produção tem seis camadas. A maioria dos frameworks resolve uma ou duas, e são honestos quanto a isso.

| Camada | A pergunta que responde | Quem resolve |
|---|---|---|
| **1. Acesso ao modelo** | Como eu chamo um modelo, e como troco de provider depois | SDKs de providers, AI gateways |
| **2. Orquestração** | Quem decide o próximo passo, e como vários agentes passam trabalho entre si | LangGraph, OpenAI Agents SDK, CrewAI, Mastra, Vercel AI SDK |
| **3. Conhecimento** | Como ele responde a partir dos meus documentos | LlamaIndex, bancos vetoriais, RAG embutido |
| **4. Runtime** | Onde isso roda quando eu fecho o notebook | Sua cloud, plataformas serverless |
| **5. Canais** | Como um humano começa uma conversa com ele | Quase ninguém |
| **6. Observabilidade** | O que ele fez, e por que errou | LangSmith, Langfuse, Braintrust |

As guerras de framework acontecem na camada 2. A camada 5 é onde os projetos morrem.

## Os frameworks de orquestração

**LangGraph** modela o agente como um grafo de estados: nós são passos, arestas são transições, e o estado é explícito. É mais cerimônia do que um loop para um agente simples, e é exatamente a coisa certa quando você precisa de ciclos, checkpoints, aprovação humana no meio, ou retomar uma execução que parou três dias atrás. A combinação com o LangSmith para tracing é a história de debug mais madura do grupo. Python e TypeScript.

**O OpenAI Agents SDK** é a menor coisa que ainda é um framework de agentes: agentes, handoffs entre agentes, guardrails e tracing. Pouquíssimo para aprender, com opinião voltada aos modelos da OpenAI mas sem ficar preso a eles. Se a sua arquitetura é "um agente que às vezes passa para um agente especialista", esse é o menor volume de código que você vai escrever. Python e TypeScript.

**CrewAI** é construído em torno de papéis. Você define agentes como cargos com objetivos e história, coloca num crew e dá uma tarefa ao crew. Ele é genuinamente bom no que se propõe, que é dividir um trabalho entre vários especialistas. Encaixa estranho para um único agente de suporte atendendo um cliente, que é a maioria dos agentes em produção. Python.

**O Vercel AI SDK** é um toolkit TypeScript-first onde o loop é uma chamada com tools e uma condição de parada, não um grafo. A abstração de providers dele é a mais limpa do grupo: trocar OpenAI por Anthropic é um import. Streaming e os bindings de React são os melhores que existem, o que importa se o agente tem UI web e não importa nada se ele mora no WhatsApp. TypeScript.

**Mastra** é a opção TypeScript mais completa de fábrica: agentes, workflows, RAG, evals e um playground local num pacote só. Bom quando você quer estrutura sem montar cinco bibliotecas.

**Pydantic AI** traz saída estruturada tipada e validada para agentes em Python, que é o instinto certo se as suas tools devolvem dados que precisam estar corretos e não apenas plausíveis.

**LlamaIndex** começou como biblioteca de retrieval e ganhou workflows de agentes. Se o trabalho do seu agente é sobretudo "responder com precisão a partir de um corpus grande de documentos", começar por aqui em vez de parafusar RAG num framework de orquestração costuma dar menos trabalho.

**Nenhum framework** merece uma linha nessa tabela. Um loop com tool calls tem umas trinta linhas, mostradas por inteiro em [como criar um agente de IA](/pt/blog/how-to-build-an-ai-agent). Para um único agente com quatro tools, o SDK cru do provider é com frequência a decisão de engenharia correta, e você adota um framework no dia em que precisar de grafos ou handoffs.

## Escolhendo um

| Se o seu problema é | Comece com |
|---|---|
| Um agente só, um punhado de tools, TypeScript | Vercel AI SDK, ou nenhum framework |
| Um agente só, um punhado de tools, Python | OpenAI Agents SDK, ou nenhum framework |
| Trabalho longo que pausa esperando aprovação humana | LangGraph |
| Vários especialistas colaborando numa tarefa | CrewAI |
| Responder com precisão a partir de um corpus grande | LlamaIndex |
| Você quer um pacote com agentes, RAG e evals | Mastra |
| As saídas das tools precisam ser type-safe | Pydantic AI |
| Você não consegue explicar por que ele respondeu aquilo | Adicione LangSmith ou Langfuse, seja qual for a sua escolha |

Repare que nenhuma dessas linhas diz "e é assim que os clientes chegam até ele".

## A camada 5, e por que ela está vazia

Todos os frameworks acima pressupõem alguém chamando. Você embrulha o agente num endpoint HTTP, e alguma coisa chama.

Numa demo, essa alguma coisa é um widget de chat. Em produção precisa ser onde os seus clientes já estão: WhatsApp, SMS, email, uma ligação. Isso não é um wrapper. Cada um é uma integração própria com regras próprias:

- **WhatsApp**: verificação do Meta Business, um webhook com verificação de assinatura, aprovação de template antes de conseguir iniciar uma conversa, e uma janela de 24 horas a partir da última mensagem do cliente dentro da qual você pode responder livremente. Fora dela, só templates aprovados.
- **SMS**: registro A2P 10DLC nos Estados Unidos antes de as operadoras entregarem, regras de sender por país em todo lugar, e contagem de segmentos que muda quando alguém manda um emoji.
- **Email**: DKIM, SPF e DMARC, um domínio de envio cuja reputação você destrói em uma semana, mais tratamento de threading e anexos no caminho de volta.
- **Voz**: um pipeline de mídia onde reconhecimento de fala, modelo e síntese precisam terminar em cerca de um segundo, ou quem ligou acha que a ligação caiu.
- **Telegram, Instagram, Messenger**: mais três modelos de identidade, mais três formatos de webhook.

Construir isso uma vez é um trimestre de engenharia. Construir para quatro canais é quase um ano. E não diferencia nada: nenhum cliente jamais escolheu um produto porque os registros DKIM dele estavam bem configurados.

Essa é a camada que a Zavu resolve, e por isso vale ser preciso: **a Zavu não compete com o LangGraph nem com o Vercel AI SDK.** Ela é as camadas 4 e 5, mais as camadas 1, 2, 3 e 6 opcionalmente, se você quiser.

## Duas formas de combinar

### Você fica com o seu framework, a Zavu leva as mensagens

Seu agente fica exatamente como está, no framework que você já escolheu. A Zavu entrega a mensagem que chega e envia a resposta.

Esse adapter você não escreve na mão. Instale as skills e o CLI uma vez, e depois diga o que quer:

```bash
npx skills add zavudev/zavu-skills
npx zavudev@latest login
```

> Envolva o meu agente LangGraph existente para ele responder no WhatsApp. As mensagens que chegam devem alimentar o grafo, e a resposta final deve voltar pelo mesmo canal. Deploye e teste.

As skills carregam as regras de canal que o seu coding agent nunca viu: a janela de 24 horas, a verificação de assinatura, quais eventos existem. O que ele escreve fica assim:

```ts
import { defineFunction } from "@zavudev/functions"
import { generateText } from "ai"
import { openai } from "@ai-sdk/openai"
import Zavudev from "@zavudev/sdk"

const zavu = new Zavudev({ apiKey: process.env.ZAVU_API_KEY })

export default defineFunction({
  on: ["message.inbound"],
  handler: async (event) => {
    const { text } = await generateText({
      model: openai("gpt-4o-mini"),
      prompt: event.data.text,
      tools: myTools,
    })

    await zavu.messages.send({ to: event.data.from, text })
  },
})
```

O Vercel AI SDK está rodando o seu loop. A Zavu cuida do webhook, da assinatura, do canal, da janela de 24 horas e da entrega. Declare `ai` e `@ai-sdk/openai` no `package.json` e eles são instalados no build. O `ZAVU_API_KEY` é provisionado automaticamente quando a function é criada, então o callback não precisa de configuração.

O mesmo formato funciona com LangGraph, CrewAI ou um SDK de provider puro, e funciona a partir da sua própria infraestrutura também: aponte um [webhook](/pt/blog/whatsapp-business-api-integration) para o seu servidor em vez de rodar dentro de uma Zavu Function.

### Você pula a camada 2 também

Se o seu agente é um prompt mais tools e não um grafo, dá para declarar e deixar o runtime cuidar do loop. De novo, você descreve:

> Construa um agente de suporte para uma loja online. Uma tool que busque um pedido por ID na nossa API. Duas frases no máximo por resposta, nunca inventar data de entrega.

E revisa o que volta:

```ts
import { defineAgent, defineTool } from "@zavudev/functions"

defineAgent({
  senderId: process.env.SENDER_ID!,
  name: "Nora",
  provider: "zavu",
  model: "openai/gpt-4o-mini",
  prompt: "Você é a Nora, suporte de uma loja online. No máximo duas frases.",
})

defineTool({
  name: "lookup_order",
  description: "Get the status of a customer order. Use when they ask where their package is.",
  parameters: {
    type: "object",
    properties: { orderId: { type: "string" } },
    required: ["orderId"],
  },
  handler: async ({ orderId }) => {
    const res = await fetch(`https://api.example.com/orders/${orderId}`)
    return res.json()
  },
})
```

`npx zavudev deploy` e ele já está respondendo em todos os canais que o sender tiver.

O trade-off é real e vale dizer com todas as letras. Você abre mão de controle de fluxo em forma de grafo e de handoff entre vários agentes. Ganha o loop, o estado de conversa por contato, retrieval sobre knowledge base, registros de execução e todos os canais, sem escrever nada disso. O campo `provider` aceita `openai`, `anthropic`, `google` e `mistral` com a sua própria chave, então isso não é lock-in de modelo.

**Quando a opção dois está errada:** você precisa de um passo de aprovação humana no meio de uma execução, de vários agentes negociando, ou de um workflow que pausa por dois dias e retoma. Use LangGraph e a opção um.

## A pergunta que realmente prevê o resultado

Depois de tudo isso, a escolha de framework raramente é o que determina se um agente funciona. Seis meses vendo eles irem para produção, o padrão é consistente: agentes vivem ou morrem pelas tools e pelo canal.

Tools boas com um framework medíocre ganham de um grafo lindo com descrições de tool vagas. E um agente no WhatsApp com um loop simples recebe dez vezes o uso de um agente com orquestração multi-agente perfeita atrás de um widget que ninguém abre.

Escolha o framework numa tarde. Gaste a semana nas tools e em estar onde os seus clientes já estão.

## Continue lendo

- [Como criar um agente de IA](/pt/blog/how-to-build-an-ai-agent): o loop do zero e depois deployado.
- [O que é um agente de IA](/pt/blog/what-is-an-ai-agent): a definição e as quatro partes.
- [Agente de IA vs chatbot](/pt/blog/ai-agent-vs-chatbot): a decisão anterior à do framework.
- [Crie agentes de IA com o seu coding agent](/pt/blog/build-ai-agents-with-your-coding-agent): o fluxo de CLI e skills.
- [Agentes de IA no WhatsApp com Next.js](/pt/blog/whatsapp-ai-agents-nextjs), [NestJS](/pt/blog/whatsapp-ai-agents-nestjs) ou [FastAPI](/pt/blog/whatsapp-ai-agents-fastapi): a camada 5, framework por framework.