38 pontos por GN⁺ 2026-03-13 | Ainda não há comentários. | Compartilhar no WhatsApp
  • Com a melhora das capacidades de raciocínio, multimodalidade e uso de ferramentas dos LLMs, surgiu uma nova categoria de sistemas: os agentes, capazes de executar fluxos de trabalho de forma autônoma em nome do usuário
  • Os agentes são compostos por três elementos centrais: modelo (LLM), ferramentas (APIs/funções externas) e instruções (diretrizes), podendo ser orquestrados como sistemas de agente único ou de múltiplos agentes
  • A adoção de agentes é adequada para fluxos de trabalho que exigem tomada de decisão complexa, sistemas de regras difíceis de manter e processamento de dados não estruturados
  • Guardrails são mecanismos de defesa em múltiplas camadas que protegem a privacidade dos dados, a segurança do conteúdo e a consistência da marca, sendo essenciais na implantação de agentes
  • Uma abordagem iterativa, começando com um único agente e expandindo gradualmente após validação com usuários reais, é a chave para uma implantação bem-sucedida

Definição de agentes

  • Agentes são sistemas que executam tarefas de forma autônoma em nome do usuário, lidando com fluxos de trabalho como resolução de problemas de atendimento ao cliente, reservas em restaurantes, commit de alterações em código e geração de relatórios
  • Aplicações que integram LLMs, mas não controlam a execução do fluxo de trabalho (chatbots simples, LLMs de turno único, classificadores de sentimento etc.) não são agentes
  • Características centrais dos agentes:
    • Usam LLMs para gerenciar a execução do fluxo de trabalho e tomar decisões, reconhecendo quando o fluxo foi concluído e ajustando proativamente suas ações quando necessário
    • Interrompem a execução em caso de falha e devolvem o controle ao usuário
    • Têm acesso a diversas ferramentas para interagir com sistemas externos e selecionam dinamicamente a ferramenta adequada conforme o estado atual do fluxo, sempre operando dentro de guardrails claros

Quando construir agentes

  • Diferentemente da automação tradicional, agentes são adequados para fluxos de trabalho em que abordagens determinísticas e baseadas em regras chegam ao seu limite
  • Exemplo de análise de fraude em pagamentos: enquanto um mecanismo tradicional baseado em regras sinaliza transações a partir de critérios pré-configurados em um modelo de checklist, um agente com LLM atua como um investigador experiente, avaliando o contexto, considerando padrões sutis e identificando atividades suspeitas mesmo sem violação explícita de regras
  • Três tipos de casos em que adotar agentes agrega valor:
    • Tomada de decisão complexa: fluxos de trabalho que exigem julgamento sutil, exceções e decisões sensíveis ao contexto (ex.: aprovação de reembolso no atendimento ao cliente)
    • Regras difíceis de manter: sistemas com conjuntos extensos e complexos de regras, cuja atualização é cara ou propensa a erros (ex.: revisão de segurança de fornecedores)
    • Cenários com alta dependência de dados não estruturados: interpretação de linguagem natural, extração de significado de documentos e interação conversacional com o usuário (ex.: processamento de sinistros de seguro residencial)
  • Se esses critérios não forem claramente atendidos, uma solução determinística pode ser suficiente

Fundamentos de design de agentes

  • Três componentes centrais

    • Modelo (Model): o LLM que impulsiona o raciocínio e a tomada de decisão do agente
    • Ferramentas (Tools): funções externas ou APIs que o agente usa para agir
    • Instruções (Instructions): diretrizes explícitas e guardrails que definem como o agente deve se comportar
  • Escolha do modelo

    • Nem toda tarefa precisa do modelo mais poderoso — buscas simples ou classificação de intenção podem ser tratadas por modelos menores e mais rápidos, enquanto tarefas mais difíceis, como decidir a aprovação de um reembolso, se beneficiam de modelos mais fortes
    • Na fase de protótipo, é eficaz estabelecer uma linha de base de desempenho com o modelo mais poderoso e depois substituí-lo por modelos menores para verificar se os resultados continuam aceitáveis
    • Princípios para escolha do modelo:
      • Configurar avaliações (evals) para estabelecer uma linha de base de desempenho
      • Focar em atingir a meta de precisão com o melhor modelo
      • Substituir por modelos menores onde possível para otimizar custo e latência
  • Definição de ferramentas

    • Ferramentas ampliam as capacidades do agente usando APIs da aplicação ou do sistema subjacente
    • Em sistemas legados sem API, é possível interagir diretamente com interfaces web e de aplicativos usando um modelo de computer-use
    • Cada ferramenta deve ter uma definição padronizada, permitindo relações flexíveis muitos-para-muitos entre ferramentas e agentes
    • Ferramentas reutilizáveis, bem documentadas e exaustivamente testadas contribuem para melhor descobribilidade, simplificam o versionamento e evitam definições duplicadas
    • Três tipos de ferramentas de que um agente precisa:
      • Dados (Data): recuperam contexto e informações necessárias para executar o fluxo de trabalho (ex.: consulta a banco de dados de transações, sistemas de CRM, leitura de PDF, busca na web)
      • Ação (Action): interagem com sistemas para adicionar informações ao banco, atualizar registros ou enviar mensagens (ex.: envio de e-mail/SMS, atualização de registro em CRM, encaminhamento de ticket de suporte para um humano)
      • Orquestração (Orchestration): o próprio agente atua como ferramenta de outros agentes (ex.: agente de reembolso, agente de pesquisa, agente de redação)
  • Estruturação das instruções

    • Instruções de alta qualidade são essenciais em qualquer app baseado em LLM, mas são especialmente importantes em agentes
    • Instruções claras reduzem ambiguidade e melhoram a tomada de decisão do agente, levando a fluxos de trabalho mais fluidos e menos erros
    • Boas práticas para instruções de agentes:
      • Aproveitar documentação existente: usar procedimentos operacionais, scripts de suporte e documentos de política já existentes para criar rotinas compatíveis com LLMs (em atendimento ao cliente, essas rotinas costumam se mapear aproximadamente a documentos individuais da base de conhecimento)
      • Prompts de decomposição de tarefas: fornecer etapas menores e mais claras a partir de recursos densos para minimizar ambiguidades
      • Definição clara de ações: especificar que cada etapa da rotina corresponda a uma ação ou saída específica (ex.: solicitar número do pedido, buscar detalhes da conta via chamada de API)
      • Captura de edge cases: antecipar variações comuns, como quando o usuário fornece informações incompletas ou faz perguntas inesperadas, e incluir etapas condicionais ou ramificações para tratar esses casos
    • Também é possível usar modelos avançados como o1 ou o3‑mini para gerar instruções automaticamente a partir de documentos existentes

Orquestração

  • Sistemas de agente único

    • Um único agente pode lidar com muitas tarefas por meio da adição gradual de ferramentas, o que simplifica o gerenciamento da complexidade, além da avaliação e manutenção
    • Toda abordagem de orquestração precisa do conceito de 'run', geralmente implementado como um loop em que o agente opera até atingir uma condição de término
    • Condições de término comuns: chamada de ferramenta, saída estruturada específica, erro ou alcance do número máximo de turnos
    • No Agents SDK, o agente é iniciado com o método Agents.run(), e o loop termina quando há uma chamada de ferramenta de saída final ou uma resposta do modelo sem chamada de ferramenta
    • Estratégia de template de prompt: em vez de vários prompts individuais, usa-se um único prompt-base flexível que recebe variáveis de política para se adaptar a diferentes contextos, simplificando bastante manutenção e avaliação
  • Quando migrar para sistemas com múltiplos agentes

    • A recomendação geral é maximizar primeiro as capacidades de um agente único
    • Embora mais agentes ofereçam uma separação conceitual intuitiva, eles trazem complexidade e overhead adicionais; em muitos casos, um único agente com ferramentas já é suficiente
    • Diretrizes práticas para dividir agentes:
      • Lógica complexa: se o prompt contiver muitas condicionais (ramificações if-then-else) e o template de prompt ficar difícil de escalar, separe cada segmento lógico em um agente distinto
      • Sobrecarga de ferramentas: o problema não é o número de ferramentas em si, mas a semelhança ou sobreposição entre elas — há implementações que gerenciam com sucesso mais de 15 ferramentas claramente distintas, enquanto outras enfrentam dificuldades mesmo com menos de 10 ferramentas redundantes
  • Padrão gerente (usar agentes como ferramentas)

    • Um LLM central, o "gerente", orquestra uma rede de agentes especializados por meio de chamadas de ferramenta
    • O gerente delega tarefas no momento certo ao agente apropriado sem perder contexto nem controle, e sintetiza os resultados em uma interação unificada
    • É adequado para fluxos de trabalho em que apenas um agente deve controlar a execução e ter acesso ao usuário
    • Exemplo: um agente de tradução chama como ferramentas agentes de espanhol, francês e italiano
  • Padrão descentralizado (handoff entre agentes)

    • Um agente faz um 'handoff' unidirecional da execução do fluxo de trabalho para outro agente
    • No Agents SDK, handoff é um tipo de ferramenta ou função: ao chamar a função de handoff, o estado mais recente da conversa é transferido e o novo agente inicia a execução imediatamente
    • É ideal quando não há necessidade de um agente único manter controle central ou sintetizar resultados, e cada agente pode assumir a execução e interagir diretamente com o usuário
    • Exemplo: um agente de triagem avalia a consulta do usuário e a direciona para agentes de suporte técnico, vendas ou gestão de pedidos
  • Grafos declarativos vs. não declarativos

    • Alguns frameworks exigem que todas as ramificações, loops e condições sejam previamente definidos de forma declarativa (declarative) como um grafo com nós (agentes) e arestas (handoffs) — isso traz clareza visual, mas se torna trabalhoso à medida que os fluxos ficam dinâmicos e complexos, além de exigir aprendizado de uma linguagem específica de domínio
    • O Agents SDK adota uma abordagem code-first, permitindo expressar a lógica do fluxo diretamente com estruturas de programação familiares, sem precisar definir o grafo completo antecipadamente, o que torna a orquestração de agentes mais dinâmica e adaptável

Guardrails

  • Papel dos guardrails

    • Ajudam a gerenciar riscos de privacidade de dados (ex.: evitar vazamento do system prompt) e riscos reputacionais (ex.: forçar comportamento do modelo alinhado à marca)
    • Um único guardrail dificilmente oferece proteção suficiente; é necessário combinar vários guardrails especializados para construir agentes mais resilientes
    • Embora sejam componentes importantes, guardrails devem ser combinados com protocolos robustos de autenticação e autorização, controle rigoroso de acesso e medidas padrão de segurança de software
  • Tipos de guardrails

    • Classificador de relevância (Relevance classifier): verifica se a resposta do agente está dentro do escopo pretendido e sinaliza consultas fora de tópico (ex.: "Qual é a altura do Empire State Building?")
    • Classificador de segurança (Safety classifier): detecta entradas inseguras, como jailbreaks e prompt injections que tentam explorar vulnerabilidades do sistema
    • Filtro de PII: evita exposição desnecessária de informações pessoalmente identificáveis (PII) na saída do modelo
    • Moderação (Moderation): sinaliza entradas nocivas ou inadequadas, como discurso de ódio, assédio e violência
    • Proteções de ferramentas (Tool safeguards): atribuem a cada ferramenta um nível de risco baixo/médio/alto com base em acesso somente leitura vs. escrita, reversibilidade, permissões de conta necessárias e impacto financeiro, acionando ações automatizadas como pausar verificações de guardrails ou escalar para humanos antes de executar funções de alto risco
    • Proteções baseadas em regras (Rules-based protections): medidas determinísticas simples, como blocklists, limites de tamanho de entrada e filtros por regex, para prevenir ameaças conhecidas, como termos proibidos ou SQL injection
    • Validação de saída (Output validation): usa prompt engineering e inspeção de conteúdo para garantir que as respostas estejam alinhadas aos valores da marca
  • Abordagem para construir guardrails

    • Começar pelos guardrails voltados aos riscos já identificados e adicionar novas camadas conforme novas vulnerabilidades forem descobertas
    • Heurísticas eficazes:
      • Focar em privacidade de dados e segurança de conteúdo
      • Adicionar novos guardrails com base em edge cases e falhas reais
      • Ajustar os guardrails à medida que o agente evolui, otimizando tanto segurança quanto experiência do usuário
    • No Agents SDK, guardrails são tratados como conceito de primeira classe (first-class concept) e, por padrão, usa-se execução otimista (optimistic execution) — o agente-base gera a saída proativamente enquanto os guardrails rodam em paralelo e disparam exceções em caso de violação de restrições
  • Planejamento de intervenção humana

    • A intervenção humana é uma salvaguarda essencial que pode melhorar o desempenho real do agente sem prejudicar a experiência do usuário
    • É especialmente importante no início da implantação, ajudando a identificar falhas, descobrir edge cases e estabelecer um ciclo robusto de avaliação
    • Dois principais gatilhos para intervenção humana:
      • Ultrapassar limiar de falha: definir limites para tentativas e ações do agente e, ao excedê-los (ex.: não conseguir entender a intenção do cliente após várias tentativas), escalar para um humano
      • Ações de alto risco: ações sensíveis, irreversíveis ou de alto impacto (ex.: cancelar pedido de usuário, aprovar grandes reembolsos, processar pagamentos) exigem supervisão humana até que a confiança no agente aumente

Conclusão

  • Agentes inauguram uma nova era da automação de fluxos de trabalho, capazes de raciocinar sobre ambiguidades, agir por meio de ferramentas e executar tarefas em várias etapas com alto grau de autonomia
  • Diferentemente de aplicações simples com LLM, agentes executam fluxos de trabalho de ponta a ponta, sendo adequados para tomada de decisão complexa, dados não estruturados e sistemas frágeis baseados em regras
  • Para construir agentes confiáveis: combine modelos competentes, ferramentas bem definidas e instruções claras e estruturadas; use padrões de orquestração compatíveis com o nível de complexidade, mas comece com um agente único e expanda para múltiplos agentes apenas quando necessário
  • Guardrails são importantes em todas as etapas, da filtragem de entrada ao uso de ferramentas e à intervenção humana, garantindo que os agentes operem de forma segura e previsível em produção
  • Uma implantação bem-sucedida não é tudo ou nada, mas sim uma abordagem iterativa de começar pequeno, validar com usuários reais e ampliar capacidades ao longo do tempo

Ainda não há comentários.

Ainda não há comentários.