Agentes IA e Automação: RAG, Workflows e Guias

Dois meses e meio após o GPT-5.5, a OpenAI lançou o GPT-5.6 e a maior mudança não é desempenho: o carro-chefe único vira 3 modelos (Luna/Terra/Sol). O intermediário Terra entrega qualidade equivalente à do GPT-5.5 por muito menos: era metade do preço no lançamento e, com o corte de 30 de julho de 2026, passou a 40% do preço unitário ($2/$12). O Sol mantém $5/$30 e eleva o SWE-Bench Pro de 58.6 para 64.6% (valores da OpenAI). Comparamos especificações, benchmarks e custo real (de $1,100 para $440 por mês no exemplo), e mostramos para qual modelo você deve migrar.

Comparação entre o Claude Fable 5, então topo de linha da Anthropic, e o GPT-5.6 Sol, então flagship da OpenAI pela metade do preço. O Fable 5 domina a codificação de produção real (SWE-Bench Pro 80.0% vs 64.6% do Sol na tabela da OpenAI) e a autonomia de longa duração, com a migração de 50 milhões de linhas da Stripe em 1 dia. O Sol lidera operação de terminal (TerminalBench 88.8%), capacidade agentiva geral e eficiência de tokens, custando cerca de metade ($5/$30 vs $10/$50). Veja como escolher por custo, taxa de sucesso e caso de uso.

Uma comparação detalhada dos dois gigantes da programação com IA em julho de 2026, Claude Opus 4.8 (28 de maio) e o topo de linha do GPT-5.6, o Sol (9 de julho). Suas forças são quase opostas: o Sol lidera na operação de terminal e na capacidade agêntica geral (TerminalBench 2.1 88.8% vs Opus 78.9%, Agents' Last Exam 53.6, Coding Agent Index 80), enquanto o Opus 4.8 lidera na programação de nível de produção (SWE-bench Pro 69.2% vs Sol 64.6%) e coloca a honestidade em primeiro plano (deixa passar falhas no próprio código cerca de 4 vezes menos; só em 3.7% dos casos deixa de avisar sobre falhas importantes). O GPQA Diamond e o FrontierMath, tidos como não divulgados, estão na tabela de avaliação da OpenAI com o Sol à frente (como no GraphWalks 1M), e no SWE-bench Pro até a própria tabela da OpenAI coloca o Opus à frente; então, na fortaleza da programação, o Opus leva vantagem. Cobrimos a tabela de especificações, os detalhes dos benchmarks, o problema dos benchmarks não divulgados, o custo real ($25 vs $30 de preço unitário vs +54% de eficiência de tokens), um mapa de forças e fraquezas, escolhas por caso de uso e uma estratégia de dois fornecedores.

A OpenAI disponibilizou o GPT-5.6 de forma geral em 9 de julho de 2026, substituindo a antiga estrutura "padrão + Pro" por uma linha de três modelos: Luna (rápido e barato, $0.20/$1.20), Terra (equilibrado, $2/$12, equivalente ao GPT-5.5 por 40% do preço unitário do Sol) e Sol (carro-chefe, $5/$30) — preços após a revisão de 30 de julho de 2026. O Sol assume o primeiro lugar no Agents' Last Exam (53.6) e no Coding Agent Index (80), e seus 88.8% no TerminalBench 2.1 superam o Claude Fable 5 (83.1%) — mas na programação de nível de produção do SWE-Bench Pro, o Claude Fable 5 lidera com folga, 80.0% contra 64.6% do Sol. Este artigo cobre as diferenças entre os três modelos, os preços, os benchmarks, os novos recursos (Programmatic Tool Calling, ChatGPT Work e o modelo de voz full-duplex GPT-Live), a disponibilidade por plano do ChatGPT, a comparação com o Claude (Fable 5 / Opus 4.8) e como escolher conforme o uso — tudo baseado no anúncio oficial da OpenAI e em benchmarks independentes.

Você construiu sobre a OpenAI, depois quis testar o Claude e comparar o Gemini — e perdeu horas com os SDKs, formatos e tratamentos de erro diferentes por provedor. Um LLM gateway (AI gateway / LLM proxy) é um relay que você encaixa entre a sua aplicação e os provedores: ele expõe uma única API compatível com OpenAI para alcançar todos os modelos e assume as tarefas transversais — fallback, controle de custos, chaves virtuais, cache, rate limiting e observabilidade. Este guia cobre por que você precisa de um, o que um gateway realmente é, os três tipos (proxy self-hosted = LiteLLM / hospedado = OpenRouter / SDK = Vercel AI SDK), como escolher entre LiteLLM, OpenRouter e o Vercel AI SDK, o código de configuração mínima que só troca o endpoint, e os limites — um salto de latência, o gateway como novo ponto de falha, taxas (o OpenRouter cobra 5,5% sobre compras), perda de recursos e privacidade.

Depois de construir um agente de IA, você sempre esbarra no mesmo muro: "Certo, mas será que funciona de verdade?" O mecanismo que decide se uma mudança de prompt ou modelo deixou as coisas melhores ou piores com dados em vez de intuição são os evals. LLMs produzem uma saída diferente a cada vez para a mesma entrada, então testes unitários de correspondência exata não se encaixam. Este artigo se concentra nos passos para criar e rodar evals na prática, cobrindo cinco formas de medir a qualidade (① correspondência com o gabarito ② verificações baseadas em regras ③ LLM-as-judge ④ teste de regressão ⑤ monitoramento em produção), avaliação específica de agentes (taxa de sucesso da tarefa, chamadas de ferramenta corretas, trajetória, custo), como começar pequeno a partir de 20 exemplos de falha, armadilhas comuns e ferramentas principais (Anthropic Console/Evals, OpenAI Evals, LangSmith, Langfuse, Ragas) — escrito para quem põe a mão na massa.

A eterna pergunta da automação: "agentes de IA ou RPA?" A resposta não é um ou outro — escolha pelo papel, e o padrão vencedor de 2026 é um híbrido dos dois. O RPA são "mãos" determinísticas que executam um procedimento fixo de forma rápida e precisa (mas quebram quando a tela/especificação muda); um agente de IA é um "cérebro" probabilístico que lê a situação e decide (forte diante de ambiguidade e exceções, mas não idêntico a cada vez). Este artigo cobre a diferença de princípio de funcionamento, uma tabela comparativa (o trade-off entre reprodutibilidade e resistência à mudança), como escolher (o eixo é "dá para escrever tudo como regras?" — sim → RPA, julgamento que você não consegue escrever → agente de IA), a tendência de 2026 (os líderes de RPA UiPath, Automation Anywhere, Blue Prism tornando-se agênticos — convergência; a pergunta já não é "qual dos dois", mas "onde deve morar o raciocínio" = orquestração primeiro) e a resposta prática: um híbrido em que o cérebro (agente de IA) cuida do julgamento/orquestração e as mãos (RPA) executam a parte determinística — não coloque um agente onde se exige determinismo e combine o julgamento delegado com guardrails e aprovação humana. Com base nas informações oficiais dos fornecedores, com um FAQ.

Dá para entregar a operação da AWS à IA? Em 2026 você pode delegar bastante. A própria AWS oferece o Amazon Q Developer e o Agent Toolkit for AWS (maio de 2026 — mais de 40 skills de agente + um AWS MCP Server gerenciado + plugins), então a IA vai da geração de IaC até a operação de recursos. Este guia enquadra o "delegar" em três níveis (① geração de código/IaC, ② operação/investigação orientada a leitura, ③ um agente autônomo que opera a AWS de verdade), cobre as principais ferramentas (Amazon Q Developer, Agent Toolkit, AWS MCP Server, Terraform MCP, Bedrock AgentCore) — incluindo a rota traga o seu próprio de dar ao Claude Code ou ao Codex a AWS CLI para rodar "aws" pelo shell — as vantagens (IaC rápido, triagem automatizada, ideias de otimização de custos, conhecimento democratizado) e, então, o ponto que importa, as desvantagens (proliferação de permissões IAM, excesso de privilégio como amplificador do raio de destruição de erros/injeção de prompt, permissões que sobrevivem à tarefa, custos fora de controle — com incidentes reais de exclusão de bancos de dados de produção em 2025-26), com base em fontes oficiais da AWS e de fornecedores de segurança. A virada essencial: a pergunta não é "dá para fazer?", mas "como delegar sem que a coisa saia do controle ou a fatura exploda" — e o fato de a própria AWS ter embutido guardrails de IAM, auditoria via CloudTrail e sandbox no Agent Toolkit revela o formato da resposta. Inclui os cinco princípios (IAM de menor privilégio, aprovação humana para operações destrutivas, observabilidade, credenciais JIT de curta duração, sandbox) e um FAQ.

O primeiro obstáculo ao colocar um agente de IA em trabalho real é "em qual framework construí-lo". Da ótica do desenvolvedor e de quem seleciona a tecnologia, este artigo compara seis frameworks principais — LangGraph, CrewAI, AutoGen (integrado ao Microsoft Agent Framework, GA em abril de 2026), OpenAI Agents SDK, Google ADK e Claude Agent SDK — por abordagem de orquestração (grafo dirigido / crew baseada em papéis / GroupChat conversacional / handoffs / árvore hierárquica / laço autônomo de ferramentas), linguagem, curva de aprendizado, controle, maturidade em produção, custo de tokens e caso de uso ideal. A ressalva central: o framework "mais rápido de prototipar" (CrewAI) pode ser o mais caro em produção — cerca de 3× os tokens (41k contra 18,5k do LangGraph em um benchmark) e não determinístico, o que o torna inadequado para finanças e saúde. Também explica como 2026 trouxe interoperabilidade via MCP (ferramentas) e A2A (agente a agente), de modo que agentes de frameworks diferentes agora trabalham juntos e o lock-in diminuiu. Inclui um guia de seleção por caso de uso e FAQ.

Em "Como construir um sistema multiagente" dissemos para instrumentar cada handoff antes de adicionar agentes; a tecnologia que sustenta essa instrumentação em produção é a observabilidade de IA. Ela torna visível o que LLMs e agentes realmente fazem em produção (qual modelo com qual prompt, quais ferramentas e buscas, o que foi retornado, quanto tempo e quanto custou) para que você possa rastrear até a causa. A diferença decisiva em relação ao monitoramento comum: a IA pode retornar 200 OK em 50ms e ainda alucinar com confiança, então a maioria das falhas de IA são falhas de qualidade (alucinação, recuperação fraca, respostas inseguras, tarefas incompletas, uso ruim de ferramentas, regressões após mudar o prompt), não falhas de infraestrutura. A observabilidade se apoia em três pilares: traces (uma requisição como árvore de spans mostrando chamadas de LLM, ferramentas, recuperação, cadeias de raciocínio; a estrela da observação de IA), métricas (latência, custo, tokens, taxa de erro, throughput) e logs (detalhe por evento). O padrão da indústria, as convenções GenAI do OpenTelemetry, captura prompts, respostas, uso de tokens e chamadas de ferramentas/agentes em um esquema neutro alimentável no Datadog/Grafana. A distinção mais confundida é observabilidade vs avaliação (evals): a observabilidade mostra o que aconteceu (fácil de medir, mas não diz se a resposta está correta), enquanto as evals medem se a resposta é boa (precisão, groundedness, segurança) e exigem avaliação explícita. Como custo e latência são fáceis de medir mas a qualidade da resposta não, as ferramentas de 2026 combinam exibição de traces com pontuação de saídas e alertas de degradação. As métricas se dividem em operacionais (custo, latência, tokens, taxa de erro) e de qualidade (alucinação, groundedness/fidelidade que é a mais crítica para RAG, segurança, conclusão da tarefa), com detecção de alucinação via LLM-as-a-judge, similaridade semântica e scores de groundedness. Principais ferramentas: LangSmith (LangChain), Langfuse (open-source self-host), Arize Phoenix (depuração de RAG), MLflow (ciclo de vida), AgentOps (agentes) e OpenTelemetry (o padrão). Comece capturando traces (compatível com OpenTelemetry), visualize métricas operacionais e depois conecte as evals antes de subir para produção. Para sistemas multiagente a observação é essencial, pois as falhas se escondem em cadeias de múltiplos passos visíveis apenas em um trace da sessão completa. Observar mais avaliar é o que torna a IA de nível de produção. Figuras e características são citadas de materiais públicos, direcionais.

A continuação prática de "O que é um sistema multi-agente?". A regra central: construir primeiro com um único agente e adicionar agentes de forma mínima só ao bater num limite (um estudo do Google Research viu todas as configurações multi-agente renderem 39–70% pior numa tarefa estritamente sequencial, e a Anthropic relata que sistemas multi-agente usam cerca de 15 vezes mais tokens que um chat). A forma básica é o padrão supervisor: subagentes no Claude Agent SDK, agents as tools no OpenAI Agents SDK. Além dos 5 passos (decompor, definir workers, projetar o supervisor, transferências, medir), traz código mínimo para os dois SDKs segundo a documentação oficial (um supervisor mais um pesquisador e um revisor), como restringir as ferramentas de cada papel, limites em três camadas (maxTurns, max_turns, gasto), quando usar handoffs, boas e más divisões de papéis e falhas reais da Anthropic (50 subagentes para uma consulta simples, pesquisa duplicada) com soluções.

Agora que os agentes de IA se tornaram comuns, o próximo desafio é como fazê-los colaborar entre si. Se o MCP conecta um agente às suas ferramentas, o A2A (Agent2Agent) conecta um agente a outro agente — um padrão aberto para que IAs construídas com fornecedores e frameworks diferentes se descubram, se comuniquem e cooperem por meio de uma convenção comum. O Google o lançou em abril de 2025, doou-o à Linux Foundation em junho daquele ano, e ele chegou à v1.0 em 2026. Este guia para iniciantes cobre o que é o A2A (a analogia da etiqueta de uma parceria de negócios), por que é necessário (agentes especializados revezam o trabalho — um agente de planejamento, um de reserva de hotel, um de pagamento), como se diferencia do MCP (o MCP é vertical, agente ↔ ferramentas; o A2A é horizontal, agente ↔ agente; empilhar os dois é a configuração padrão de duas camadas), como funciona (um Agent Card — um JSON "cartão de visita" em /.well-known/agent-card.json — é usado para descobrir capacidades, depois uma Task carrega a solicitação por estados como working, input-required e completed, e um Artifact retorna o resultado, tudo sobre HTTP, Server-Sent Events e JSON-RPC 2.0, com os agentes mantendo seus detalhes internos ocultos), e qual é a situação atual e a implementação (em abril de 2026, 150+ organizações apoiadoras, 22.000+ estrelas no GitHub, SDKs em cinco linguagens — Python, JavaScript, Java, Go, .NET — com Microsoft, Salesforce, SAP e ServiceNow envolvidos). O mnemônico: conectar a ferramentas = MCP, conectar a pares = A2A.