Padrões de design do sistema de agentes

A criação de um sistema de agentes envolve a orquestração de como as chamadas LLM, a recuperação de dados e as ações externas fluem juntas. O senhor pode pensar em padrões de design para sistemas de agentes em um continuum 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 sob o capô), até arquiteturas de vários agentes que coordenam vários agentes especializados.

Chamada de ferramentas

Antes de mergulhar nos padrões de design, é importante entender a chamada de ferramentas como uma capacidade fundamental que pode ser usada em qualquer sistema de agente, do simples ao 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 permitir:

• Pesquisas de dados em tempo real, como consultas SQL, buscas de CRM ou recuperação de índices vetoriais.
• Ações como enviar um email ou atualizar um registro.
• Lógica arbitrária ou transformações por meio de funções Python ou APIs.

Assim, a chamada de ferramenta oferece um mecanismo poderoso para tornar os LLMs "cientes" de dados externos ou APIs, independentemente do padrão de design que o senhor escolher.

Para saber mais sobre as ferramentas do agente, consulte AI agent tools.

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

Compare os padrões de design de aplicativos da gen AI

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	Tarefa bem definida - Pipeline estático, como o RAG básico - Não há necessidade de tomar decisões instantâneas	Muito simples - Fácil de auditar	Inflexível - Requer alterações no código para se adaptar
Sistema de agente único	Consultas moderadas a complexas no mesmo domínio - Algumas decisões dinâmicas sem a sobrecarga de vários agentes especializados.	Flexível - Mais simples do que multiagente - Bom "default"	Menos previsível - Deve se proteger contra chamadas de ferramentas repetidas ou incorretas
Sistema multiagente	Domínios grandes ou multifuncionais; vários agentes “especialistas”; contextos distintos de lógica ou conversação; padrões avançados de reflexão.	Altamente modular - Escalável para grandes domínios	Complexo de orquestrar - Mais difícil de rastrear e depurar

Sistema de agente único

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

1. Aceitar solicitações como consultas de usuários e qualquer contexto relevante, como o histórico de conversas.
2. Raciocine sobre a melhor forma de responder, opcionalmente decidindo se deve chamar ferramentas para dados ou ações externas.
3. Iterar, se necessário, chamando um LLM (e/ou as mesmas ferramentas) repetidamente até que um objetivo seja alcançado ou uma determinada condição seja atendida (como o recebimento de dados válidos ou a resolução de um erro).
4. Integre os resultados da ferramenta na conversa.
5. Retorne uma resposta coesa como saída.

Em muitos casos de uso, uma única rodada de raciocínio LLM (geralmente com chamadas de ferramentas) é suficiente. No entanto, agentes mais avançados podem percorrer várias etapas até chegarem ao resultado desejado.

Mesmo que haja apenas "um" agente, o senhor ainda pode ter várias LLM e chamadas de ferramentas sob o capô (para planejamento, geração, verificação e assim por diante), todas gerenciadas 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 devoluções?"), o agente poderá responder diretamente com base no conhecimento do LLM.
• Se o usuário quiser o status do pedido, o agente chama a 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:

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

Vantagens:

• O agente pode se adaptar a consultas novas ou inesperadas escolhendo quais (se houver) ferramentas chamar.
• O agente pode passar por repetidas chamadas LLM ou invocações de ferramentas para refinar os resultados, sem precisar de uma configuração totalmente multiagente.
• Esse padrão de design geralmente é o ponto ideal para casos de uso corporativos: mais simples de depurar do que configurações com 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 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 limite.)
• Se o seu aplicativo abrange subdomínios radicalmente diferentes (finanças, desenvolvimento, marketing etc.), um único agente pode se tornar pesado ou sobrecarregado com requisitos de funcionalidade.
• Você ainda precisa de instruções e restrições cuidadosamente elaboradas para manter o agente focado e relevante.

Cadeia determinística (etapas codificadas)

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 ou em que ordem . O sistema segue um fluxo de trabalho predefinido para todas as solicitações, o que o torna altamente previsível.

Comumente chamado de “Cadeia”, o fluxo é essencialmente uma cadeia fixa de etapas, como:

1. Sempre recupere a solicitação do usuário e recupere de um índice vetorial para o contexto relevante.
2. Combine esse contexto com a solicitação do usuário em um prompt final do LLM.
3. Chamar o LLM e retornar a resposta.

Exemplo: cadeia RAG básica

Uma cadeia RAG determinística pode sempre:

1. Recupere os melhores resultados de um índice vetorial usando a solicitação de entrada do usuário (recuperação).
2. Formatar os blocos recuperados em um padrão de prompt (aumentar).
3. Passe esse prompt ampliado para o LLM (gerar).
4. Retornar a resposta do LLM.

Quando usar:

• Para tarefas bem definidas com fluxo de trabalho previsível.
• Quando a consistência e a auditoria são as principais prioridades.
• Quando o senhor deseja minimizar a latência, evitando várias chamadas LLM para decisões de orquestração.

Vantagens:

• Maior previsibilidade e auditabilidade.
• Latência tipicamente mais baixa (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 se tornar complexo e difícil de manter à medida que as ramificações lógicas crescem.
• Pode exigir uma refatoração significativa para acomodar novos recursos.

Sistema multiagente

Um sistema multiagente envolve dois ou mais agentes especializados que trocam mensagens e/ou colaboram na tarefa. Cada agente tem seu próprio domínio ou experiência em tarefas, 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 corporativo com agentes especializados

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

Cada subagente pode realizar chamadas de ferramentas em seu próprio domínio (como lookup_customer_account ou run_sql_query), muitas vezes exigindo prompts exclusivos ou histórico 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 acessar o 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 ter um subconjunto.
• Você quer implementar reflexão, crítica ou colaboração de ida e volta entre agentes especializados.

Vantagens:

• Essa abordagem modular significa que cada agente pode ser desenvolvido ou mantido por equipes separadas, especializadas em um domínio restrito.
• É capaz de lidar com grandes e complexos fluxos de trabalho empresariais que um único agente poderia ter dificuldade de gerenciar de forma coesa.
• Facilita o raciocínio avançado em várias etapas ou em várias perspectivas — por exemplo, um agente gera uma resposta e outro a verifica.

Considerações:

• Requer uma estratégia de roteamento entre agentes, além de sobrecarga para registro, rastreamento e depuração em vários endpoints.
• Se o senhor tiver muitos subagentes e ferramentas, pode ser complicado decidir qual agente tem acesso a quais dados ou APIs.
• Os agentes podem fazer a tarefa indefinidamente entre si sem resolução se não forem cuidadosamente restringidos.
  • Os riscos de loop infinito também existem em chamadas de ferramentas de agente único, mas as configurações de vários agentes acrescentam outra camada de complexidade de depuração.

Conselhos práticos

Independentemente do padrão de projeto selecionado, considere as seguintes práticas recomendadas para desenvolver sistemas de agentes estáveis e sustentáveis.

1. começar simples: Se o senhor precisar apenas de uma cadeia simples, uma cadeia determinística é rápida de construir.
2. Aumente gradualmente a complexidade: À medida que o senhor precisar de consultas mais dinâmicas ou de uma fonte de dados flexível, mude para um sistema de agente único com chamadas de ferramentas.
3. Use vários agentes: Somente se o senhor tiver domínios ou tarefas claramente distintos, vários contextos de conversação ou um grande conjunto de ferramentas que seja grande demais para o prompt de um único agente.

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

O Mosaic AI Agent Framework é agnóstico em relação ao padrão que o senhor escolher, facilitando a evolução dos padrões de design à medida que seu aplicativo cresce.

Orientação de desenvolvimento

• Solicitações

  • Mantenha os avisos claros e mínimos para evitar instruções contraditórias, informações que distraiam e reduzir as alucinações.
  • Forneça apenas as ferramentas e o contexto de que seu agente precisa, em vez de um conjunto ilimitado de APIs ou um grande contexto irrelevante.

• Registrando a observabilidade do &

  • Implemente registros detalhados para cada solicitação de usuário, plano de agente e chamada de ferramenta. Ferramentas como o MLflow Tracing podem ajudar a capturar logs estruturados para depuração.
  • Armazene logs de forma segura e tenha cuidado com as informações de identificação pessoal (PII) nos dados de conversas.

• Atualizações de modelo: fixação da versão &

  • Os comportamentos do LLM podem mudar quando os provedores atualizam os modelos nos bastidores. Use a fixação de versões e testes de regressão frequentes para garantir que a lógica do seu agente permaneça robusta e estável.
  • A combinação do MLflow com o Mosaic AI Agent Evaluation oferece uma maneira simplificada de controlar a versão dos agentes e avaliar regularmente a qualidade e o desempenho.

Orientação de teste e iteração

• Tratamento de erros & lógica de fallback

  • Planeje-se para falhas na ferramenta ou no LLM. Timeouts, respostas malformadas ou resultados vazios podem interromper um fluxo de trabalho. Inclua estratégias de repetição, lógica fallback ou uma cadeia fallback mais simples quando os recursos avançados falharem.

• Engenharia rápida iterativa

  • Espere refinar as solicitações e a lógica da cadeia ao longo do tempo. Controle cada alteração (usando Git e MLflow) para que o senhor possa reverter ou comparar o desempenho entre as versões.
  • Considere estruturas como o dSpy para otimizar programaticamente os prompts e outros componentes do sistema do seu agente.

Orientação de produção

• Latência versus otimização de custos

  • Cada LLM ou chamada de ferramenta adicional aumenta o uso de tokens e o tempo de resposta. Sempre que possível, combine etapas ou armazene em cache as consultas repetidas para manter o desempenho e o custo gerenciáveis.

• Segurança e sandbox

  • Se o seu agente puder atualizar os registros ou o código de execução, sandbox essas ações ou impor a aprovação humana quando necessário. Isso é fundamental em ambientes corporativos ou regulamentados para evitar danos não intencionais.
  • A Databricks recomenda as ferramentas do Unity Catalog para execução em área restrita. Consulte Ferramentas de função do Unity Catalog versus ferramentas de código de agente. O Unity Catalog permite o isolamento da execução de código arbitrário e impede que agentes mal-intencionados enganem o agente para que ele gere e execute códigos que interfiram ou espionem outras solicitações.

Seguindo essas diretrizes, o senhor pode atenuar muitos dos modos de falha mais comuns, como chamadas incorretas de ferramentas, desempenho do LLM instável ou picos de custo inesperados, e criar sistemas de agentes mais confiáveis e dimensionáveis.