Subagentes de design que evitam mensagens duplicadas

Note

Este artigo descreve as características e o comportamento do arnês padrão. Aprenda a aceder a funcionalidades padrão nos agentes e fluxos de agentes padrão do Access.

Mensagens duplicadas vêm de lacunas de contexto. O design do agente deve ter em conta o contexto em cada etapa.

Um subagente, seja um agente de elemento subordinado ou um agente ligado, é executado na sua própria camada de orquestração dentro do plano de um agente principal. Recebe um pedido do progenitor e conclui a tarefa. O subagente produz três tipos de saída: conteúdo que mostra ao utilizador, valores que devolve através de saídas definidas e uma resposta implícita que envia ao agente que chama. O agente principal não consegue ver a interação do subagente com o utilizador e só conhece o resultado através das saídas definidas e da resposta implícita. Esta visibilidade limitada causa frequentemente mensagens duplicadas e respostas falhadas.

Sugestão

Para orientações sobre quando dividir o trabalho entre agentes e melhores práticas gerais para múltiplos agentes, consulte os padrões de orquestração multi-agente, melhores práticas e padrões multi-agente. Este artigo explica como as entradas e saídas alinham a resposta de um subagente com o contexto do agente pai.

Este artigo baseia-se no modelo de contexto descrito em Distribuição de contexto no harness padrão e nas decisões de design nas melhores práticas de Design para evitar mensagens duplicadas.

Desativar o contexto do agente principal para um agente ligado

Um subagente que recebe o contexto da conversa do progenitor pode agir com base nele. Se esse contexto contiver um pedido que o pai ainda não respondeu, o subagente pode responder, repetir algo que o pai já tratou ou assumir o papel errado. Estas ações costumam causar mensagens duplicadas.

Um agente ligado tem uma definição, Passar o histórico da conversação para este agente, que controla se este recebe o contexto da conversação do agente principal. Esta definição está ativada por predefinição. Desmarca-o para que o agente conectado funcione apenas a partir das entradas que o pai envia, e não da conversa completa.

Captura de ecrã da opção 'Passar histórico de conversas a este agente' ativada, notando que a desseleção impede a partilha de histórico entre agentes.

Um agente de elemento subordinado não tem uma definição equivalente. É executado dentro do agente principal e recebe sempre o contexto da conversação do agente principal.

Para agentes ligados que precisam de manter o contexto para a tarefa que lhes foi atribuída, e para agentes de elemento subordinado que têm contexto por predefinição, utilize uma entrada de controlo do âmbito para proteger o âmbito do subagente.

Utilizar uma entrada de controlo do âmbito

Por vezes, um subagente precisa do contexto do agente pai para completar as suas tarefas. Quando passar esse contexto, inclua uma entrada de controlo do âmbito — esta entrada indica ao subagente exatamente em que deve trabalhar, para que pedidos pendentes e sem resposta no contexto não o desviem da tarefa. Se não passar o contexto, não é necessária uma entrada de controlo do âmbito, porque o subagente tem apenas o pedido que o agente principal lhe encaminhou.

Para proteger o âmbito do subagente, adicione uma entrada nomeada scopedRequest com uma descrição como: The specific request this agent should fulfill. A camada de orquestração preenche a entrada quando chama o subagente. O agente principal identifica a parte relevante da solicitação e encaminha apenas essa parte, mesmo que o seu contexto contenha outra solicitação sem resposta.

Uma entrada de controlo do âmbito constitui uma solução robusta mesmo quando não se mantém o contexto do agente principal. A entrada dá ao criador mais controlo sobre o conteúdo do pedido enviado ao subagente.

Vinculem as instruções do subagente a essa entrada para que operem com base no pedido delimitado e ignorem tudo o resto que se assemelhe a um pedido inicial.

Instruções de exemplo para subagentes:

Fulfill the request in the scopedRequest input. 
Treat it as your initial request and ignore any other initial requests in the conversation.

Configurar entradas e saídas

Entradas e saídas são o contrato entre o progenitor e o subagente. A entrada delimita aquilo em que o subagente trabalha, e as saídas informam o agente principal sobre o que aconteceu, para que este possa orquestrar a restante conversação. O agente principal não consegue ver a interação do subagente com o utilizador, por isso este contrato é o único sinal fiável de que dispõe.

Importante

Um subagente que não devolve saídas é um sinal de alerta. Sem saídas, o agente principal não tem registo daquilo a que o subagente respondeu nem do que ficou por responder. Pode repetir uma resposta que o subagente já deu, ou eliminar a parte do pedido que o subagente não tratou.

Configure as seguintes entradas e saídas, e escreva a descrição de cada uma para a camada de orquestração principal ler:

Entrada ou saída Description Modo de utilização
scopedRequest (entrada) O pedido específico que este agente deve cumprir. O pai preenche apenas a parte relevante do pedido do utilizador. Protege o subagente de responder à pergunta errada quando o contexto do progenitor ainda contém outros pedidos por responder. Ancorar as instruções do subagente a esta entrada.
answered (saída) É verdade quando o utilizador já recebeu uma resposta ao ScopedRequest. Define-o em todos os subagentes, quer envie mensagens ao utilizador ou permaneça em silêncio. A instrução de topo, mostrada a seguir, lê-a para que o pai não responda novamente ao mesmo pedido.
scopedRequest (saída) A solicitação em que este agente trabalhou. Repita o pedido com âmbito definido para que este chegue à camada de orquestração de nível superior, que não conserva de forma fiável, no seu próprio contexto, as entradas que cria. Em turnos com múltiplas intenções que exigem mais do que um subagente, esta capacidade permite que o nível superior planeie corretamente e evite encaminhar o subagente errado para a pergunta errada.
interactionSummary (saída) Um breve resumo da resposta entregue ao utilizador. Devolva‑o quando o subagente enviar uma mensagem diretamente ao utilizador, para que o agente principal saiba o que foi comunicado e não o repita.
findings (saída) A resposta ao scopedRequest, para o agente principal entregar ao utilizador. Devolva-a quando o subagente permanecer em silêncio, para que o agente principal tenha conteúdo para transmitir.
openQuestions (saída) Qualquer parte do pedido do utilizador que permaneça sem resposta. Deve ser devolvida a partir de qualquer subagente que só consiga atender a parte do pedido, ou quando surgir um novo pedido na conversação do subagente, para que o agente principal possa concluir o restante e continuar o encadeamento de ferramentas. O subagente não deve adivinhar qual agente trata do resto.

Escolha o componente que comunica com o utilizador

Decide se o agente pai ou o subagente comunica com o utilizador. Na maior parte dos casos, deixe que o agente principal comunique com o utilizador para que possa combinar os resultados numa única resposta. Permita que o subagente comunique diretamente quando precisar de fornecer uma resposta longa ou manter uma conversa em vários turnos. Devolve informação suficiente para que o pai ou mãe possa tratar do resto da conversa com contexto.

Seja qual for o componente que comunica, adicione uma instrução de topo para que a camada de orquestração verifique as saídas de cada subagente antes de responder.

Esta instrução de topo de exemplo funciona em todos os casos, quer um subagente envie mensagem diretamente ao utilizador ou permaneça em silêncio. Edite e personalize conforme necessário.

Sempre que qualquer tópico ou agente for chamado, procure sempre a saída booleana "respondida" antes de decidir o que responder. Os tópicos e agentes têm o seu próprio canal de comunicação com o utilizador. Se 'respondido' for verdadeiro, assuma sempre que o pedido foi respondido corretamente usando pelo menos uma das variáveis de saída e verifique quais com base na descrição de saída. Não faça uma confirmação pouco natural do conteúdo respondido. Forneça apenas as saídas não respondidas e continue a conversação naturalmente com o passo seguinte.

O termo canal não se refere a um canal de integração. É um dispositivo de aviso que diz à camada de orquestração que o utilizador pode já ter visto a resposta através de outro componente.

Escreva a descrição do subagente para a camada de orquestração principal, para que saiba quando usar o subagente e como ler as suas saídas. Por exemplo:

Handles payroll questions. 
If its answered output is true, the user has already received their response and it should not be answered again.

Defina as saídas de estado Respondido e de valor em todos os subagentes, quer o subagente envie uma mensagem ao utilizador quer permaneça em silêncio, e dê ao agente principal uma única instrução para as ler. Com esta abordagem, um agente pode misturar subagentes silenciosos e subagentes que enviam mensagens diretas ao utilizador, distinguindo-se apenas pelas suas saídas. Saiba mais em Desenhar uma instrução robusta de topo para evitar mensagens repetidas.

Delegar a comunicação do utilizador ao pai

Considere encaminhar toda a comunicação do utilizador através do agente pai em vez de um subagente. Recolha o que o subagente precisa como entradas antes de começar, leia o que produziu como saídas depois de terminar e instrua-o a não enviar mensagens diretamente ao utilizador. Um subagente que nunca escreve ao utilizador não pode responder a algo a que o agente principal já tenha respondido.

Diz ao subagente para ficar em silêncio e devolver as suas conclusões. Por exemplo:

Do NOT reply or communicate with the user directly. 
Only fulfill the scopedRequest provided in the input and respond with the result.

Um subagente silencioso devolve findings e openQuestions, ambos descritos em Configurar entradas e saídas, para entregar a resposta ao agente principal e assinalar qualquer trabalho que permaneça por fazer.

Devolva uma saída openQuestions. Permite que a camada de orquestração termine o resto do pedido do utilizador e continue a encadear ferramentas quando um subagente só consegue cumprir parte do pedido.

Manter o subagente em silêncio requer uma instrução explícita. Por predefinição, um subagente pode enviar mensagens ao utilizador autonomamente enquanto estiver em execução. A definição de conclusão Após a execução não impede estas mensagens, porque apenas indica ao agente principal o que fazer quando o subagente termina.

Note

Dizer ao agente principal, "És o único agente que fala com o utilizador" não funciona. O agente pai não pode parar um subagente em execução, e o subagente ainda pode enviar mensagens ao utilizador autonomamente. Em vez disso, instrua o subagente a ficar em silêncio e depois teste para confirmar.

Alguns subagentes têm de comunicar diretamente

Um subagente que envia mensagens diretamente ao utilizador é uma escolha válida, não uma violação de uma regra, mas requer um design deliberado para evitar mensagens repetidas do pai.

Alguns casos de uso exigem que o subagente responda diretamente ao utilizador, seja para entregar uma resposta longa sem a copiar para o contexto principal, seja para manter uma conversa. Para evitar mensagens repetidas e perda de contexto, passe o contexto ao agente principal nas saídas.

Peça ao subagente para dar uma resposta longa e devolver um resumo

O subagente fornece a sua resposta completa diretamente ao utilizador e retorna apenas um breve resumo ou uma nota de que entregou a resposta. Use esta abordagem para respostas longas, como análises detalhadas, e limite a informação devolvida ao contexto do pai. O objetivo é manter o contexto do agente principal reduzido, mas suficientemente informado.

Return answered e interactionSummary, ambos descritos em Configurar entradas e saídas.

Peça ao subagente para manter uma conversa com o utilizador

O subagente troca múltiplas mensagens com o utilizador ao longo de várias etapas para completar o pedido com âmbito definido. O principal risco é que o progenitor desconheça os passos intermédios da conversa, o trabalho do subagente e quaisquer respostas dadas, ou quaisquer novos pedidos que tenham surgido. Como resultado, o progenitor não pode agir sobre novos pedidos nem responder corretamente nas etapas seguintes.

Retorne answered, scopedRequest, e interactionSummary, conforme descrito em Configurar entradas e saídas.

A instrução de topo também cobre este caso de uso.

  • Última atualização a