Padrões de projeto de sistemas de agentes

A criação de um sistema de agente envolve a orquestração de como as chamadas LLM, a recuperação de dados e as ações externas fluem juntas. Você pode pensar em padrões de design para sistemas de agente em um contínuo de complexidade e autonomia: desde cadeias determinísticas, até sistemas de agente único que podem tomar decisões dinâmicas (e podem envolver várias chamadas LLM sob o capô), até arquiteturas de vários agentes que coordenam vários agentes especializados.

Ferramenta de chamado

Antes de se aprofundar em padrões de design, é importante entender a chamada de ferramenta como uma funcionalidade fundamental que pode ser usada em qualquer sistema de agente, de simples a complexo. A chamada de ferramenta é um mecanismo que permite que um sistema de agente interaja com funções externas, fontes de dados ou serviços. Isso pode habilitar:

• Pesquisas de dados dinâmicos, como consultas SQL, buscas de CRM ou recuperação de índice de vetor.
• Ações como enviar um email ou atualizar um registro.
• Lógica arbitrária ou transformações por meio de funções ou APIs do Python.

O uso de ferramentas, portanto, fornece um mecanismo poderoso para permitir que as LLMs acessem dados externos ou APIs, não importando o padrão de design que seja escolhido.

Para saber mais sobre ferramentas para agentes, consulte ferramentas para agentes de IA.

As seções abaixo discutem três padrões de design de sistemas de agentes, cada um dos quais pode alavancar o uso de ferramentas em diferentes graus.

Comparar padrões de design de IA generativa para aplicativos

Os padrões de design do aplicativo de IA de geração (agente) são apresentados em ordem de complexidade.

Padrão de design	Quando usar	Vantagens	Desvantagens
Cadeia determinística	Tarefas bem definidas Pipelines estáticos, como RAG básico Não há necessidade de decisões em tempo real	Muito simples Fácil de auditar	Inflexíveis Requer alterações de código para adaptar
Sistema de agente único	Consultas de moderadas a complexas no mesmo domínio Algumas decisões dinâmicas sem a sobrecarga de vários agentes especializados.	Flexível Mais simples que multiagente Bom "opção padrão"	Menos previsível Deve se proteger contra chamadas de ferramenta repetidas ou incorretas
Sistema de vários agentes	Domínios grandes ou multifuncionais; vários agentes "especialistas"; lógica distinta ou contextos de conversa; padrões de reflexão avançados.	Altamente modular Escalonável para grandes domínios	Complexo de orquestrar Mais difícil de rastrear e depurar

Sistema de agente único

Um sistema de agente único apresenta um fluxo coordenado de lógica - geralmente orquestrando várias chamadas LLM - para lidar com solicitações de entrada. O agente pode:

1. Aceite solicitações como consultas de usuário e qualquer contexto relevante, como histórico de conversa.
2. Raciocine sobre a melhor maneira de responder, decidindo opcionalmente se deve chamar ferramentas para dados externos ou ações.
3. Repita se necessário, chamando uma LLM (e/ou as mesmas ferramentas) repetidamente até que um objetivo seja atingido ou uma condição seja satisfeita (como receber dados válidos ou resolver um erro).
4. Integrar os resultados das ferramentas à conversa.
5. Retornar uma resposta coesa como saída.

Em muitos casos de uso, uma única iteração de raciocínio LLM (frequentemente com uso de ferramentas) é suficiente. No entanto, agentes mais avançados podem percorrer várias etapas até chegarem a um resultado desejado.

Embora haja apenas "um" agente, você ainda pode ter várias chamadas de LLM e ferramentas nos bastidores (para planejamento, geração, verificação e assim por diante), tudo gerenciado por esse fluxo único e unificado.

Exemplo: Assistente de suporte técnico

• Se o usuário fizer uma pergunta simples ("Qual é a nossa política de retorno?"), o agente poderá responder diretamente do conhecimento da LLM.
• Se o usuário quiser o status do pedido, o agente chamará uma função lookup_order(customer_id, order_id). Se essa ferramenta responder com "número de pedido inválido", o agente poderá tentar novamente ou solicitar ao usuário a ID correta, continuando até que possa fornecer uma resposta final.

Quando usar:

• Você espera consultas de usuário variadas, mas ainda dentro de um domínio coeso ou área do produto.
• Determinadas consultas ou condições podem justificar o uso da ferramenta, como decidir quando buscar dados do cliente.
• Você deseja mais flexibilidade do que uma cadeia determinística, mas não exige agentes especializados separados para tarefas diferentes.

Vantagens:

• O agente pode se adaptar a consultas novas ou inesperadas escolhendo quais (se houver) ferramentas para chamar.
• O agente pode executar um loop por meio de chamadas LLM repetidas ou invocações de ferramentas para refinar resultados sem precisar de uma configuração totalmente multi-agente.
• Esse padrão de design geralmente é o ponto ideal para casos de uso da empresa – mais simples de depurar do que as configurações de vários agentes, ao mesmo tempo em que permite lógica dinâmica e autonomia limitada.

Considerações:

• Em comparação com uma cadeia codificada, você deve se proteger contra chamadas de ferramenta repetidas ou inválidas. (Loops infinitos podem ocorrer em qualquer cenário de chamada de ferramenta, portanto, defina limites de iteração ou tempos limite.)
• Se o aplicativo abranger subdomínios radicalmente diferentes (finanças, devops, marketing, etc.), um único agente poderá ficar dificultoso ou sobrecarregado com as requisições de funcionalidades.
• Você ainda precisa de prompts e restrições cuidadosamente projetados para manter o agente focado e relevante.

Cadeia determinística (etapas codificadas em código)

Nesse padrão, o desenvolvedor define quais componentes são chamados, em que ordem e com quais parâmetros. Não há nenhuma tomada de decisão dinâmica sobre quais ferramentas chamar ou em que ordem. O sistema segue um fluxo de trabalho predefinido para todas as solicitações, tornando-o altamente previsível.

Normalmente chamado de "Cadeia", o fluxo é essencialmente uma cadeia fixa de etapas, como:

1. Sempre recupere a solicitação do usuário e recupere o contexto relevante a partir de um índice de vetor.
2. Combine esse contexto com a solicitação do usuário em um prompt de LLM final.
3. Chame a LLM e retorne a resposta.

Exemplo: Cadeia básica de RAG

Uma cadeia determinística de RAG pode sempre:

1. Recupere os resultados top-k de um índice de vetor usando a solicitação de um usuário de entrada (recuperar).
2. Formatar partes recuperadas em um modelo de prompt (aumento).
3. Passe esse prompt aumentado para a LLM (gerar).
4. Retorne a resposta da LLM.

Quando usar:

• Para tarefas bem definidas com fluxos de trabalho previsíveis.
• Quando consistência e auditoria são prioridades principais.
• Quando você quiser minimizar a latência, evite várias chamadas LLM para decisões de orquestração.

Vantagens:

• Maior previsibilidade e auditabilidade.
• Normalmente, latência mais reduzida (menos chamadas ao LLM na orquestração).
• Mais fácil de testar e validar.

Considerações:

• Flexibilidade limitada para lidar com solicitações diversas ou inesperadas.
• Pode se tornar complexo e difícil de manter à medida que as ramificações lógicas se expandem.
• Pode exigir refatoração significativa para acomodar novos recursos.

Sistema de vários agentes

Um sistema de vários agentes envolve dois ou mais agentes especializados que trocam mensagens e/ou colaboram em tarefas. Cada agente tem seu próprio domínio ou experiência de tarefa, contexto e conjuntos de ferramentas potencialmente distintos. Um "coordenador" separado - que pode ser outra LLM ou um roteador baseado em regras - direciona solicitações para o agente apropriado ou decide quando transferir de um agente para outro.

Exemplo: Assistente empresarial com agentes especializados

• Agente de suporte ao cliente: Manipula pesquisas de CRM, retornos e envio.
• Agente de análise: Concentra-se em consultas SQL e resumo de dados.
• Supervisor/roteador: Escolhe qual agente é melhor para uma determinada consulta de usuário ou quando alternar.

Cada subagente pode executar chamadas de ferramenta dentro de seu próprio domínio (como lookup_customer_account ou run_sql_query) muitas vezes exigindo prompts exclusivos ou históricos de conversa.

Quando usar:

• Você tem áreas problemáticas distintas ou conjuntos de habilidades, como um agente de codificação ou um agente financeiro.
• Cada agente precisa de acesso ao histórico de conversas ou indicadores específicos do domínio.
• Você tem tantas ferramentas que encaixar todas elas no esquema de um agente é impraticável; cada agente pode ter um subconjunto.
• Você deseja implementar a reflexão, a crítica ou a colaboração entre agentes especializados.

Vantagens:

• Essa abordagem modular significa que cada agente pode ser desenvolvido ou mantido por equipes separadas, especializadas em um domínio estreito.
• Pode lidar com fluxos de trabalho empresariais grandes e complexos que um único agente pode ter dificuldades para gerenciar de forma coesa.
• Facilita o raciocínio avançado de várias etapas ou de várias perspectivas , por exemplo, um agente gerando uma resposta, outro verificando-o.

Considerações:

• Requer uma estratégia para roteamento entre agentes, além de sobrecarga para registro em log, rastreamento e depuração em vários pontos de extremidade.
• Se você tiver muitos sub-agentes e ferramentas, pode ser complicado decidir qual agente tem acesso a quais dados ou APIs.
• Os agentes podem passar tarefas indefinidamente entre eles sem resolução, se não forem devidamente restringidas.
  • Os riscos de loop infinito também existem no uso de ferramentas por um único agente, mas as configurações com vários agentes adicionam outra camada de complexidade de depuração.

Conselhos práticos

Independentemente de qual padrão de design você selecionar, considere as práticas recomendadas a seguir para desenvolver sistemas de agente estáveis e mantenedíveis.

1. Inicie simples: Se você precisar apenas de uma cadeia simples, uma cadeia determinística será rápida de criar.
2. Adicione gradualmente a complexidade: À medida que você precisa de consultas mais dinâmicas ou fontes de dados flexíveis, mova para um sistema de agente único com chamada de ferramenta.
3. Adote múltiplos agentes: Somente se você tiver domínios ou tarefas claramente distintos, vários contextos de conversa ou um conjunto de ferramentas grande demais para o prompt de um único agente.

Se o caso de uso começar pequeno - como uma cadeia de RAG simples - comece com uma cadeia codificada. À medida que os requisitos evoluem, você pode adicionar lógica de chamada de ferramentas para tomada de decisão dinâmica ou até mesmo segmentar tarefas entre vários agentes especializados. Na prática, muitos sistemas de agente do mundo real combinam padrões. Por exemplo, use uma cadeia principalmente determinística, mas permita que o LLM chame dinamicamente determinadas APIs em uma única etapa, se necessário.

O Mosaic AI Agent Framework é independente de qualquer padrão que você escolher, facilitando a evolução dos padrões de design à medida que seu aplicativo cresce.

Diretrizes de desenvolvimento

• Solicitações
  • Mantenha as solicitações claras e mínimas para evitar instruções contraditórias, informações distrativas e reduzir alucinações.
  • Forneça apenas as ferramentas e o contexto que seu agente requer, em vez de um conjunto não associado de APIs ou um contexto irrelevante grande.
• Registro em log e observabilidade
  • Implemente logs detalhados para cada solicitação de usuário, plano do agente e chamada de ferramenta. O Rastreamento do MLflow pode ajudar na captura de logs estruturados para debug.
  • Armazene logs com segurança e esteja atento às PII (informações de identificação pessoal) nos dados da conversa.
• Atualizações de modelo e fixação de versão
  • Os comportamentos de LLM podem mudar quando os provedores atualizam modelos nos bastidores. Use testes de fixação de versão e regressão frequentes para garantir que a lógica do agente permaneça robusta e estável.
  • A combinação do MLflow com a Avaliação do Agente de IA do Mosaico fornece uma maneira simplificada de controle de versão de agentes e avaliação regular de qualidade e desempenho.

Diretrizes de teste e iteração

• Tratamento de erros e lógica de fallback
  • Planeje para falhas de ferramentas ou LLM. Tempos limite, respostas malformadas ou resultados vazios podem interromper um fluxo de trabalho. Inclua estratégias de repetição, lógica de fallback ou uma cadeia de fallback mais simples quando os recursos avançados falham.
• Engenharia iterativa de prompt
  • Espere refinar os prompts e a lógica encadeada ao longo do tempo. Versione cada alteração (usando Git e MLflow) para que possa reverter ou comparar o desempenho entre as versões.
  • Considere frameworks como DSPy para otimizar programaticamente prompts e outros componentes em seu sistema de agentes.

Diretrizes de produção

• Latência versus otimização de custo
  • Cada LLM adicional ou chamada de ferramentas aumenta o uso de tokens e o tempo de resposta. Sempre que possível, combine etapas ou armazene consultas repetidas em cache para manter o desempenho e o custo gerenciáveis.
• Segurança e área restrita
  • Se o agente puder atualizar registros ou executar código, isole essas ações ou exija aprovação humana, quando necessário. Isso é fundamental em ambientes corporativos ou regulamentados para evitar danos não intencionais.
  • O Databricks recomenda ferramentas do Catálogo do Unity para execução em área restrita. Consulte ferramentas de função do Unity Catalog vs. ferramentas de código do agente. O Catálogo do Unity permite o isolamento da execução arbitrária de código e impede que atores mal-intencionados enganem o agente para gerar e executar código que interfere ou escuta em outras solicitações.

Seguindo essas diretrizes, você pode atenuar muitos dos modos de falha mais comuns, como chamadas incorretas de ferramenta, desempenho de LLM em descompasso ou picos de custos inesperados e criar sistemas de agente mais confiáveis e escalonáveis.