Como construir agentes de IA eficazes

• Equipes que implementaram com sucesso agentes baseados em LLM tendem a usar padrões simples e combináveis em vez de frameworks complexos
• É preciso entender as diferenças estruturais entre workflows e agentes, e recomenda-se sempre introduzir apenas a complexidade mínima necessária para chegar à melhor solução
• Diversos padrões de agentes, como encadeamento de prompts, roteamento, paralelização, orquestrador-workers e loop de avaliação-otimização, são usados em ambientes reais de produção, e cada padrão tem seus casos de uso, vantagens e desvantagens
• Ao implementar agentes, os princípios centrais são simplicidade, transparência e design de interface, com atenção especial ao design de ferramentas e à engenharia de prompts
• Casos em que agentes realmente geram valor em atendimento ao cliente ou em ambientes de desenvolvimento de software estão se tornando cada vez mais comuns

---

Visão geral

Ao longo do último ano, a Anthropic vem construindo agentes baseados em modelos de linguagem de grande porte (LLMs) junto com equipes de vários setores. Na prática, os casos de adoção bem-sucedida de agentes mostraram uma tendência de se apoiar mais em padrões simples e combináveis do que em frameworks complexos ou bibliotecas especializadas. Este post compartilha insights obtidos em colaborações com clientes e em experiências de desenvolvimento interno, além de conselhos práticos para construir agentes eficazes.

O que é um agente

Agentes podem ser definidos de várias formas.

• Alguns os definem como sistemas totalmente autônomos, capazes de concluir tarefas complexas de forma independente usando ferramentas externas
• Outros os entendem como implementações prescritivas que seguem workflows limitados ou processos predefinidos

A Anthropic classifica ambos como sistemas agentivos, mas faz uma distinção arquitetural importante entre workflows e agentes.

• Workflow: estrutura em que LLMs e ferramentas são orquestrados por caminhos de código previamente definidos
• Agente: estrutura em que o LLM decide dinamicamente como usar ferramentas e como conduzir o processo, mantendo o controle sobre a forma de executar a tarefa

Neste post, os dois tipos de sistema são explicados em detalhe, e os casos de uso práticos são tratados no Apêndice 1.

Quando usar agentes — e quando não usar

Ao desenvolver aplicações, é recomendável seguir o princípio da complexidade mínima, adicionando complexidade de forma gradual apenas quando necessário.

• Sistemas agentivos podem melhorar o desempenho da tarefa mesmo sacrificando parte da latência/custo
• Se a complexidade não for realmente necessária, muitas vezes uma única chamada de LLM com exemplos no prompt e integração com busca já resolve bem o problema
• Workflows são mais adequados quando previsibilidade e consistência são essenciais; agentes, quando há necessidade de flexibilidade e escala

Quando e como usar frameworks

Existem vários frameworks que facilitam a implementação de sistemas agentivos.

• LangGraph (LangChain)
• Amazon Bedrock AI Agent framework
• Rivet, Vellum etc.

Esses frameworks simplificam tarefas de baixo nível, como chamadas de LLM, definição/parsing de ferramentas e composição de cadeias de execução. Porém, abstrações excessivas podem tornar o fluxo real de prompts e respostas opaco ou aumentar a complexidade desnecessariamente.

• Recomenda-se que desenvolvedores comecem usando diretamente a API do LLM sempre que possível
• Mesmo ao usar frameworks, é importante entender com precisão como eles funcionam internamente

Exemplos de implementação podem ser vistos em anthropic-cookbook.

Blocos de construção, workflows e padrões de agentes

A Anthropic apresenta padrões de sistemas agentivos frequentemente usados em ambientes reais de operação.

Bloco de construção: LLM aumentado

O núcleo de um sistema agentivo é um LLM ampliado com recursos como busca, ferramentas e memória.

• O modelo pode por conta própria gerar consultas de busca, selecionar a ferramenta adequada e armazenar informações
• Um ponto central de implementação é adaptar esses recursos ao caso de uso e fornecer ao LLM interfaces claras e bem documentadas

Com o Model Context Protocol, lançado recentemente, ficou simples integrar várias ferramentas de terceiros.

Explicação por tipo de workflow

Encadeamento de prompts

• A tarefa é dividida em uma série de etapas, e cada chamada ao LLM processa o resultado da etapa anterior
• É possível controlar o processo adicionando validações programáticas (gates) em cada etapa
• Exemplos de aplicação: geração de textos de marketing seguida de tradução; criação de estrutura de documento → validação → redação do conteúdo

Roteamento

• A entrada é classificada e encaminhada para tarefas posteriores específicas
• É possível usar prompts e ferramentas especializados para cada categoria
• Exemplos de aplicação: encaminhamento de solicitações de clientes (reembolso, suporte técnico etc.), escolha de modelo conforme o grau de dificuldade

Paralelização

• A tarefa é dividida em unidades menores, processadas em paralelo, e os resultados são agregados
• Sectioning: cada parte é processada de forma independente
• Voting: a mesma tarefa é repetida sob várias perspectivas ou prompts, usando por exemplo votação majoritária
• Exemplos de aplicação: separação entre filtragem e resposta para perguntas de usuários, avaliação automática, revisão de código

Orquestrador-workers

• Um LLM central decompõe e distribui dinamicamente a tarefa, e vários LLMs workers processam partes separadas antes da combinação final
• É adequado para subtarefas não predefinidas e variáveis conforme a entrada
• Exemplos de aplicação: alteração de código em múltiplos arquivos, exploração de informações complexas

Loop de avaliação-otimização

• Usa um LLM para responder e outro para avaliar em um loop iterativo
• É adequado quando há critérios claros de avaliação e valor em melhorar com base em feedback
• Exemplos de aplicação: avaliação de nuances em tradução literária, exploração de informação em múltiplas rodadas

Agentes

• Com a evolução dos LLMs, surgiram em serviços reais agentes capazes de lidar com entradas complexas, raciocínio e planejamento, uso de ferramentas e recuperação de erros

• O fluxo começa com um comando ou conversa do usuário → esclarecimento da tarefa → execução autônoma → possibilidade de feedback em checkpoints intermediários → encerramento ao concluir ou ao atingir condição de parada

• Em implementações reais, o LLM itera com base no feedback do ambiente, como resultados de ferramentas ou execução de código, e o conjunto de ferramentas e sua documentação são fundamentais

• Exemplos de aplicação: agentes de programação para resolver tarefas do SWE-bench, automação de uso de computador baseada em Claude

• Escopo de aplicação: problemas abertos em que não é possível prever o caminho ou as etapas, e situações em que se precisa confiar na tomada de decisão

• Também é preciso considerar o aumento de custos e a possibilidade de erros compostos decorrentes da maior autonomia; testes em sandbox e guardrails são essenciais

Combinação e customização de padrões

• Os blocos de construção apresentados não são regras rígidas; podem ser combinados conforme diferentes situações
• O mais importante é escolher a melhor estrutura por meio de medição de resultados e melhoria iterativa, adicionando complexidade de forma gradual

Resumo e princípios recomendados

O sucesso de sistemas com LLM não depende de complexidade ou de tecnologia nova, mas de encontrar a abordagem certa para o objetivo.

• Comece com prompts simples, avalie os resultados, otimize iterativamente e expanda a complexidade por etapas

• Três princípios centrais no design de agentes

  1. Manter a simplicidade
  2. Priorizar a transparência (clareza já na etapa de planejamento)
  3. Dar importância à documentação e aos testes de ferramentas/interfaces

• Frameworks podem ajudar a começar rápido, mas, na prática, minimizar camadas de abstração e ter capacidade de implementação direta é o que determina confiabilidade e manutenção

Apêndice 1: Casos de aplicação de agentes no trabalho real

Atendimento ao cliente

A área de atendimento ao cliente é naturalmente adequada para agentes, por combinar interface de chatbot com integração de ferramentas.

• Coexistem uma interface conversacional e a necessidade de acessar dados externos e executar processos de negócio
• Ferramentas podem ser integradas a informações de clientes, histórico de pedidos, base de conhecimento etc.
• É possível automatizar tarefas como reembolsos e abertura de tickets
• Os critérios de resolução podem ser definidos com clareza

Casos bem-sucedidos validaram a eficácia dos agentes com modelos de cobrança baseados em uso, medidos por critérios de resolução bem-sucedida.

Agentes de programação

Em ambientes de desenvolvimento de software, o uso de agentes para resolver problemas automaticamente também vem aumentando bastante.

• O código pode ter seus resultados verificados por testes automatizados
• É possível fazer melhorias iterativas com base nos resultados dos testes
• A definição do problema é clara, e a qualidade do resultado pode ser medida objetivamente

Exemplo interno da Anthropic: no benchmark SWE-bench Verified, problemas reais do GitHub foram resolvidos apenas com descrições de pull requests. Além dos testes automatizados, a revisão humana continua importante para verificar se o sistema atende aos requisitos gerais.

Apêndice 2: Como fazer engenharia de prompts para ferramentas

Em todo sistema agentivo, ferramentas são um elemento central.

• LLMs como Claude conseguem interagir com serviços externos a partir da API seguindo com precisão a estrutura e a definição corretas
• A resposta pode incluir um tool use block
• As definições e especificações das ferramentas também precisam ser projetadas com tanto cuidado quanto a engenharia de prompts

Dicas para projetar o formato de ferramentas

• Garanta tokens suficientes para que o modelo não caia em “armadilhas” ao escrever

• Recomenda-se usar formatos naturais, amplamente encontrados na internet

• Minimize overhead de formatação desnecessário, como contagem de linhas de código ou escape de strings

• Assim como se investe no design de interfaces humano-computador (HCI), também é preciso caprichar na interface agente-computador (ACI)

• Para o modelo, deve ser “claro” como entender e usar a ferramenta, incluindo exemplos de uso, condições de contorno e formatos de entrada

• Os nomes e descrições de parâmetros também devem ser intuitivos, como ao escrever documentação (docstrings)

• Teste o uso real com diferentes valores de entrada e melhore iterativamente

• Projete os argumentos de modo a reduzir erros (Poka-yoke)

Ao construir o agente do SWE-bench na prática, foi investido mais tempo na otimização do design das ferramentas do que no prompt completo. Exemplo: para reduzir erros de caminho de arquivo ao sair da pasta raiz, a ferramenta foi alterada para aceitar apenas caminhos absolutos, e então passou a funcionar perfeitamente.

[GN⁺]

Comentários do Hacker News

• Achei especialmente impressionante que este texto começa deixando clara a definição de "AI agents". A definição usada aqui é "um sistema em que o LLM gerencia dinamicamente, por conta própria, o processo e o uso de ferramentas, controlando sozinho a forma como executa a tarefa". Também gostei da parte que distingue ‘agent’ de ‘workflow’ e da forma como apresenta vários padrões práticos de workflow. Quando o texto saiu pela primeira vez, eu também escrevi um resumo próprio: notas sobre building-effective-agents. E recentemente também achei interessante o texto da Anthropic sobre como construíram um sistema de pesquisa multiagente, além de haver notas adicionais sobre isso: notas sobre multi-agent research system

  • Acho que a definição de workflow usada neste texto não é precisa. Hoje em dia, muitos motores de workflow não seguem caminhos de código pré-definidos e, em muitos casos, funcionam praticamente da mesma forma que agentes. Parece que o autor redefiniu workflow com a intenção de criar essa distinção, mas na prática, na minha opinião, agent também nada mais é do que um workflow em loop que faz chamadas dinâmicas com base nas respostas do LLM. Os motores de workflow mais modernos também são muito dinâmicos

  • Um dos coautores de Building Effective Agents também fez uma palestra na AIE sobre esse texto, e a reação foi muito boa: vídeo no YouTube

  • O texto sobre pesquisa multiagente é realmente muito bom, mas não concordo com a afirmação em Building Effective AI Agents de que "construir o sistema do zero, sem framework, é melhor do ponto de vista educacional". O primeiro benefício de usar um bom framework é poder experimentar facilmente vários LLMs diferentes, inclusive de fornecedores distintos

  • Fico curioso para saber qual AI agent framework a Anthropic usa. Não me parece que eles já tenham tornado público um framework próprio

  • Obrigado pelas notas adicionais; esse tema também tem sido uma questão muito importante para mim ultimamente

• Na área de IA, meio ano parece uma eternidade. Li este texto repetidas vezes alguns meses atrás, mas agora tenho a sensação de que o desenvolvimento de agentes claramente chegou a um gargalo. Até o Gemini mais recente parece ter regredido em desempenho

  • Rodar vários agentes ao mesmo tempo custa caro, o que reduz o RoI. Por exemplo, um agente de DeepSearch para ações usa 6 agentes e custa cerca de 2 dólares por consulta. A orquestração multiagente é difícil de controlar e, quando o modelo é mais forte, a necessidade de multiagente diminui. Por outro lado, quanto mais fraco o modelo, mais aumenta o valor de negócio de uma IA estreita e especializada. Estou falando isso com base em experiência real

  • Fico curioso sobre por que você sente que os agentes regrediram. Por que eles simplesmente não conseguem criar várias cópias de si mesmos para trabalhar em paralelo 24/7, validar, melhorar e evoluir continuamente?

  • Resolver o problema de prompt injection é extremamente difícil, e isso está se tornando um gargalo sério

• Tenho curiosidade sobre como agentes lidam com task queueing, race condition e outros problemas de concorrência. Em artigos sobre construção de workflows multiagente, muitas vezes se diz que um orchestrator agent gerencia tudo, mas sempre fico me perguntando se, na prática, não é necessário um design bem mais complexo e um glue code mais inteligente. Ou será que tudo isso realmente funciona como uma “mágica automática”?

  • O padrão em agentes é que as ferramentas sejam executadas sequencialmente, então não é preciso se preocupar com problemas de concorrência. Agora vários modelos já oferecem suporte a chamadas paralelas de ferramentas, então, se o modelo pedir “execute estas três ferramentas”, o harness pode executá-las em paralelo ou em sequência e depois passar o resultado para a etapa seguinte. A Anthropic vem usando configurações multiagente de forma mais agressiva, em que um agente de nível superior delega tarefas em paralelo para agentes subordinados. Esse truque está sendo aplicado no Claude Code, e é explicado com mais detalhes em notas de engenharia reversa relacionadas (claude-trace) e também no texto sobre como funciona o Claude Research (multi-agent-research-system). Ainda estamos em uma fase muito inicial de descoberta de padrões de uso de ferramentas por LLMs, e os modelos só ficaram realmente bons em usar ferramentas nos últimos 6 meses, então ainda há muito espaço para evolução

  • Por isso, em vez de tratar tudo como JSON, passei a preferir uma direção em que o próprio LLM gera code para lidar com tool call. A biblioteca smolagents, da Huggingface, usa uma abordagem em que o LLM gera código de chamada de funções em python. Se você quiser chamadas paralelas de ferramentas, basta explicitar isso no prompt, e o LLM também precisa lidar com a sincronização. Claro, há a questão de executar código gerado pelo LLM, mas existem várias soluções para isso

  • Compartilhando um caso de uso da interface web do Codex. Eu tinha um plano de refatoração longo demais para terminar de uma vez, então usei a função “ask” para dividi-lo em várias tarefas e agrupar as que podiam ser feitas em paralelo. O LLM fez a divisão de forma parecida com a maneira como uma equipe real distribuiria o trabalho, mas como não havia pressuposto de comunicação entre as tarefas, a perda de contexto foi enorme. Mesmo tendo levado mais tempo do que fazer eu mesmo, tentei seguir com isso, mas acabei processando de forma sequencial, dando a cada tarefa em várias sessões prompts detalhados sobre objetivo, método, validação, documentação etc. Resumindo, um orchestrator agent pode servir para tarefas muito simples, mas, na prática, seu campo de aplicação é mais limitado do que parece

  • Não existe nada que funcione automaticamente como mágica. As características operacionais com as quais já precisamos nos preocupar em sistemas tradicionais também precisam ser desenvolvidas para agentes de IA. Se você olhar apenas demos de AI agent e achar que dá para “substituir o código de uma equipe que escreve código espaguete por alguns prompts limpinhos de IA”, você pode acabar se enganando. Em alguns poucos casos isso pode funcionar, mas no fim todo código existe por um motivo dentro do sistema, e se você chegar ao ponto de traduzir todo esse código para dentro do LLM, é sinal de que perdeu a direção

  • No caso de agentes de programação, um padrão emergente é usar contêineres para isolar o trabalho e usar git para revisar e fazer merge do que foi produzido. Um exemplo é o uso de contêineres e MCP em container-use, que é útil para trabalho paralelo em código. Fora isso, em outras tarefas, construtores de workflow como n8n, Zapier e CrewAI continuam sendo usados com frequência

• Este texto relembra a mensagem de começar pelo “mais simples possível” e só adicionar complexidade real quando ela for necessária. Menciona a possibilidade de construir sistemas mais estáveis, mais fáceis de depurar e mais baratos apenas com chamadas de LLM bem definidas e um pouco de glue logic simples. Em contrapartida, sistemas de agentes vistosos muitas vezes acabam causando ainda mais problemas

• Espero que a IA se torne algo que realmente ajude as pessoas de forma prática

• É bom que a Anthropic forneça esse tipo de informação técnica, mas acho que eles também deveriam oferecer uma versão em guia fácil para não especialistas. Por exemplo, mesmo que o departamento de marketing queira adotar agentes, ele precisa de um guia para conseguir definir especificações em nível básico. Há algum conteúdo relacionado no final do texto e no apêndice, mas ainda assim a discussão de “como construir” continua muito centrada na implementação

• (Dezembro de 2024 — agora, olhando para trás, parece algo de muito tempo atrás)

  • Ahhh, então agora vamos ter que voltar a usar a cabeça e escrever 100% do código à mão, como homens das cavernas em dezembro de 2024 comentário relacionado

  • Acho que este texto envelheceu muito bem. Pessoalmente, continuo usando-o como material de referência e ele não parece datado mesmo com o passar do tempo. Foi um texto que deu à Anthropic uma nova imagem como “parceira prática no desenvolvimento de ferramentas de IA”

• Na minha visão, o hype em torno de Agent já esfriou bastante neste momento

  • Agora todo mundo passou a se interessar por AI Agency

• Compartilhando a informação de que este texto já havia sido discutido na época: discussão original no HN

• Gosto do fato de que este texto adota uma abordagem realista, sem exageros nem modismos. Sou crítico da tendência de muita gente sair construindo sistemas de agent porque está na moda, sem antes pensar se aquela tarefa realmente precisa de um agent