Padrões de projeto de sistemas de agentes

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

Invocação de ferramenta

Antes de mergulhar nos padrões de design, é importante entender a chamada de ferramentas como um recurso fundamental que pode ser usado em qualquer sistema de agente, do simples ao complexo. A chamada de ferramentas é um mecanismo que permite que um sistema de agente interaja com funções externas, fontes de dados ou serviços. Isso pode permitir:

• Pesquisas de dados em tempo real, como consultas SQL, buscas de CRM ou recuperação de índice vetorial.
• Ações como enviar um e-mail ou atualizar um registro.
• Lógica arbitrária ou transformações através de funções Python ou APIs.

O uso de chamadas de ferramentas, assim, oferece um mecanismo poderoso para tornar os LLMs “cientes” de dados externos ou APIs, independentemente do padrão de design escolhido.

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

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

Compare os padrões de design de aplicativos de IA da geração

Os padrões de design do aplicativo (agente) Gen AI são apresentados em ordem de complexidade.

Padrão de design	Quando usar	Prós	Contras
Cadeia determinística	Tarefas bem definidas As linhas de processamento estáticas, como o RAG básico Sem necessidade de decisões imediatas	Muito simples Fácil de auditar	Inflexível Requer alterações de código para se adaptar
Sistema de agente único	Consultas de complexidade moderada a complexa no mesmo domínio Algumas decisões dinâmicas sem a sobrecarga de vários agentes especializados.	Flexível Mais simples do que sistemas multiagente Bom "padrão"	Menos previsível Deve proteger contra chamadas de ferramentas repetidas ou incorretas
Sistema multiagente	Domínios grandes ou multifuncionais; múltiplos agentes "peritos"; contextos distintos de lógica ou conversação; padrões de reflexão avançados.	Altamente modular Escalar 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 - muitas vezes orquestrando várias chamadas LLM - para lidar com solicitações de entrada. O agente pode:

1. Aceite solicitações como consultas de usuários e qualquer contexto relevante, como histórico de conversas.
2. Pense na melhor forma de responder, decidindo opcionalmente se deve utilizar ferramentas para dados ou ações externas.
3. Itere se necessário, utilizando um LLM (e/ou as mesmas ferramentas) repetidamente até que um objetivo seja alcançado ou uma determinada condição seja cumprida (como receber dados válidos ou resolver um erro).
4. Integre os resultados das ferramentas na conversa.
5. Devolver uma resposta coesa como saída.

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

Mesmo que haja apenas "um" agente, ainda pode ter múltiplas chamadas LLM e de ferramentas nos bastidores (para planeamento, geração, verificação, e assim por diante), todas geridas por este fluxo único e unificado.

Exemplo: Assistente de Help Desk

• Se o usuário fizer uma pergunta simples ("Qual é a nossa política de devoluções?"), o agente pode responder diretamente do conhecimento do 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 o ID correto, continuando até que ele possa fornecer uma resposta final.

Quando usar:

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

Vantagens:

• O agente pode adaptar-se a consultas novas ou inesperadas, escolhendo quais ferramentas (se houver) chamar.
• O agente pode percorrer chamadas LLM repetidas ou invocações de ferramentas para refinar os resultados - sem a necessidade de uma configuração com múltiplos agentes.
• Esse padrão de design geralmente é o ponto ideal para casos de uso corporativos - mais simples de depurar do que configurações multiagentes, 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 ferramentas repetidas ou inválidas. (Loops infinitos podem ocorrer em qualquer cenário de chamada de ferramentas, portanto, defina limites de iteração ou tempos limites.)
• Se seu aplicativo abrange subdomínios radicalmente diferentes (finanças, devops, marketing, etc.), um único agente pode se tornar pesado ou sobrecarregado com requisitos de funcionalidade.
• Ainda precisa de instruções e restrições cuidadosamente projetadas para manter o agente focado e pertinente.

Cadeia determinística (passos codificados)

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

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

1. Certifique-se de sempre atender à solicitação do utilizador e recuperar de um índice de vetor para obter contexto relevante.
2. Combine esse contexto com a solicitação do usuário em um prompt LLM final.
3. Chame o LLM e retorne a resposta.

Exemplo: Cadeia RAG básica

Uma cadeia RAG determinística pode sempre:

1. Obtenha os principais resultados k de um índice vetorial usando a solicitação de um utilizador (recuperar).
2. Formate partes recuperadas em um modelo de prompt (aumentar).
3. Forneça esse prompt expandido ao LLM (gerar).
4. Retorne a resposta do LLM.

Quando usar:

• Para tarefas bem definidas com fluxos de trabalho previsíveis.
• Quando a coerência e a auditoria são as principais prioridades.
• Quando se pretende minimizar a latência, evitando múltiplas chamadas LLM para decisões de orquestração.

Vantagens:

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

Considerações:

• Flexibilidade limitada para lidar com solicitações diversas ou inesperadas.
• Pode tornar-se complexo e difícil de manter à medida que os ramos lógicos crescem.
• Pode exigir uma refatoração significativa para acomodar novas capacidades.

Sistema multiagente

Um sistema multiagente 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 outro LLM ou um roteador baseado em regras - direciona as solicitações para o agente apropriado ou decide quando passar de um agente para outro.

Exemplo: Assistente empresarial com agentes especializados

• Agente de suporte ao cliente: lida com pesquisas, devoluções e remessas de CRM.
• Agente do Analytics: Concentra-se em consultas SQL e resumo de dados.
• Supervisor/roteador: Escolhe qual agente é melhor para uma determinada consulta de usuário ou quando mudar.

Cada subagente pode efetuar chamadas de ferramentas dentro do seu próprio domínio (como lookup_customer_account ou run_sql_query), muitas vezes exigindo prompts exclusivos ou históricos de conversas.

Quando usar:

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

Vantagens:

• Esta abordagem modular significa que cada agente pode ser desenvolvido ou mantido por equipas separadas, especializadas num domínio restrito.
• É capaz de lidar com fluxos de trabalho empresariais grandes e complexos que um único agente pode ter dificuldade em gerir de forma coesa.
• Facilita o raciocínio avançado em várias etapas ou multiperspectivas - por exemplo, um agente gerando uma resposta, outro verificando-a.

Considerações:

• Requer uma estratégia para redeamento entre os diferentes agentes, além de carga adicional para registo, rastreamento e depuração em vários endpoints.
• Se você tiver muitos subagentes e ferramentas, pode ficar complicado decidir qual agente tem acesso a quais dados ou APIs.
• Os agentes podem trocar tarefas indefinidamente entre si sem resolução, se não forem cuidadosamente limitados.
  • Riscos de loops infinitos também existem em chamadas de ferramenta de agente único, mas configurações multi-agente adicionam uma camada extra de complexidade na depuração.

Conselhos práticos

Independentemente do padrão de design selecionado, considere as seguintes práticas recomendadas para desenvolver sistemas de agente estáveis e fáceis de manter.

1. Comece simples: Se você só precisa de uma cadeia direta, uma cadeia determinística é rápida de construir.
2. Adicione complexidade gradualmente: À medida que você precisar de consultas mais dinâmicas ou fontes de dados flexíveis, mude para um sistema de agente único com chamada de ferramentas.
3. Adote multi-agente: Somente se tiver domínios ou tarefas claramente distintos, vários contextos de conversa ou um conjunto de ferramentas extenso que seja grande demais para o prompt de um único agente.

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

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.

Orientações para o desenvolvimento

• Indicativos
  • Mantenha as instruções claras e mínimas para evitar instruções contraditórias, informações que distraiam e reduzir alucinações.
  • Forneça apenas as ferramentas e o contexto que seu agente exige, em vez de um conjunto ilimitado de APIs ou um grande contexto irrelevante.
• Registo & observabilidade
  • Implemente o registro detalhado para cada solicitação de usuário, plano de agente e chamada de ferramenta. O MLflow Tracing pode ajudar a capturar logs estruturados para depuração.
  • Armazene registros com segurança e esteja atento às informações de identificação pessoal (PII) nos dados da conversa.
• Atualizações de modelo & fixação da versão
  • Os comportamentos de LLM podem mudar quando os provedores atualizam modelos nos bastidores. Use a fixação de versão e testes de regressão frequentes para garantir que a lógica do agente permaneça robusta e estável.
  • A combinação de MLflow com Mosaic AI Agent Evaluation fornece uma maneira simplificada de versionar agentes e avaliar regularmente a qualidade e o desempenho.

Diretrizes de teste e iteração

• Tratamento de erros & lógica de retorno
  • Planeje falhas de ferramentas ou LLM. Tempos limites, respostas malformadas ou resultados vazios podem interromper um fluxo de trabalho. Inclua estratégias de repetição, lógica de recuperação, ou uma cadeia de recuperação mais simples quando os recursos avançados falharem.
• Engenharia de prompt iterativa
  • É esperado que se refine instruções e lógica de encadeamento ao longo do tempo. Versione cada alteração (usando Git e MLflow) para que possas reverter ou comparar o desempenho entre as versões.
  • Considere frameworks como DSPy para otimizar programaticamente os prompts e outros componentes dentro do seu sistema de agente.

Orientação de produção

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

Seguindo essas diretrizes, você pode mitigar muitos dos modos de falha mais comuns, como chamadas incorretas de ferramentas, desempenho de LLM à deriva ou picos de custos inesperados, e criar sistemas de agentes mais confiáveis e escaláveis.