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 filho ou um agente ligado, corre numa camada de orquestração própria dentro do plano de um agente pai. 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.

Desative o contexto principal de um agente conectado

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 conectado tem uma configuração, Transmitir o histórico da conversa a este agente, que controla se este recebe o contexto da conversa 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 criança não tem uma configuração equivalente. Corre dentro do progenitor e recebe sempre o contexto da conversa do pai.

Para agentes conectados que precisam de manter o contexto na tarefa que lhes foi atribuída, e para agentes filhos que têm contexto por defeito, utilize um parâmetro de delimitação de âmbito para proteger o âmbito do subagente.

Usar uma entrada de definição de âmbito

Por vezes, um subagente precisa do contexto do agente pai para completar as suas tarefas. Quando passar esse contexto, inclua uma instrução de delimitação — ela diz 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 passares o contexto, não precisas de um parâmetro de delimitação 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 âmbito é um design robusto mesmo quando não se mantém o contexto 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 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 resultados, o agente principal não fica com registo do que o subagente respondeu ou do que falta. 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 interações com múltiplas intenções que exigem mais do que um subagente, esta capacidade permite ao nível superior planear corretamente e evitar encaminhar a pergunta errada para o subagente errado.
interactionSummary (saída) Um breve resumo da resposta entregue ao utilizador. Devolve-o quando o subagente enviar mensagem diretamente ao utilizador, para que o pai saiba o que foi comunicado e não repita.
findings (saída) A resposta ao ScopedRequest, para o pai entregar ao utilizador. Devolva isso quando o subagente ficar em silêncio, para que o agente principal tenha conteúdo para fornecer.
openQuestions (saída) Qualquer parte do pedido do utilizador que permaneça sem resposta. Devolva isso a partir de qualquer subagente que só consiga satisfazer parte da solicitação, ou em que surja uma nova solicitação na conversa 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 um comentário de confirmação estranho sobre o conteúdo já respondido. Forneça apenas os resultados ainda sem resposta e continue naturalmente a conversa 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 cada subagente, quer o subagente envie uma mensagem ao utilizador ou permaneça em silêncio, e dê ao pai uma instrução para os 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.

Devolve uma openQuestions saída. 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 essas mensagens, porque apenas indica ao agente principal o que fazer quando o subagente concluir.

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 contexto perdido, passe o contexto ao pai 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 principal reduzido, mas suficientemente informativo.

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.

  • Last updated on