Subagentes de projeto que evitam mensagens duplicadas

Note

Este artigo descreve características e comportamentos do arnês padrão. Aprenda como acessar recursos padrão em agentes e fluxos de agentes padrão do Access.

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

Um subagente, seja um agente filho ou um agente conectado, roda em sua própria camada de orquestração dentro do plano de um agente pai. Ele recebe um pedido do pai e completa a tarefa. O subagente produz três tipos de saída: conteúdo que mostra ao usuário, valores que retorna por meio de saídas definidas e uma resposta implícita que envia ao agente chamador. O pai não pode ver a troca do subagente com o usuário e só aprende o resultado por meio das saídas definidas e da resposta implícita. Essa visibilidade limitada geralmente causa mensagens duplicadas e respostas perdidas.

Tip

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

Este artigo se baseia 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 pai para um agente conectado

Um subagente que recebe o contexto da conversa dos pais pode agir com base nele. Se esse contexto contiver uma solicitação que o pai ainda não respondeu, o subagente pode respondê-la, repetir algo que o pai já resolveu ou assumir o papel errado. Essas ações geralmente causam mensagens duplicadas.

Um agente conectado tem uma configuração, Passar histórico de conversas para esse agente, que controla se ele recebe o contexto da conversa do pai. Essa configuração é habilitada por padrão. Desmarque para que o agente conectado funcione apenas com as entradas enviadas pelo pai, não pela conversa completa.

Captura de tela da opção 'Passar histórico de conversas para este agente' ativada, observando que desmarcar impede o compartilhamento de histórico entre agentes.

Um agente filho não tem configuração equivalente. É executado dentro do elemento pai e sempre recebe o contexto da conversa do pai.

Para agentes conectados que precisam manter o contexto do trabalho que lhes foi atribuído, e para agentes filhos que têm contexto por padrão, use uma entrada de escopo para proteger o escopo do subagente.

Use uma entrada para definição de escopo

Às vezes, um subagente precisa do contexto do agente pai para completar suas tarefas. Quando você passar esse contexto, inclua uma instrução de escopo — ela diz ao subagente exatamente em que trabalhar, para que solicitações pendentes e sem resposta no contexto não o tirem do foco da tarefa. Se você não passar o contexto, não precisa de uma entrada de escopo porque o subagente tem apenas a solicitação que o pai encaminhou para ele.

Para proteger o escopo 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 pai identifica a parte relevante da solicitação e passa apenas essa parte, mesmo que seu contexto contenha outra solicitação não respondida.

Um input com escopo é uma solução robusta mesmo quando você não mantém o contexto principal. A entrada dá ao criador mais controle sobre o conteúdo da solicitação enviada ao subagente.

Vincule as instruções do subagente a essa entrada para que ele trabalhe com base na solicitação delimitada e ignore qualquer outro conteúdo que pareça uma solicitação 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 pai e o subagente. A entrada delimita o escopo em que o subagente atua, e as saídas informam ao agente principal o que aconteceu para que ele possa orquestrar o restante da conversa. O agente principal não consegue ver a interação do subagente com o usuário, então esse contrato é o único sinal confiável de que ele dispõe.

Importante

Um subagente que não retorna saídas é um sinal de alerta. Sem saídas, o pai não tem registro do que o subagente respondeu ou do que resta. Ele pode repetir uma resposta que o subagente já deu ou eliminar a parte do pedido que o subagente não atendeu.

Configure as entradas e saídas a seguir e redija a descrição de cada uma para ser lida pela camada de orquestração principal:

Entrada ou saída Description Como usar
scopedRequest (entrada) O pedido específico que esse agente deve atender. O pai preenche apenas a parte relevante da solicitação do usuário. Ele protege o subagente de responder à pergunta errada quando o contexto do pai ainda contém outros pedidos sem resposta. Ancore as instruções do subagente a essa entrada.
answered (saída) Verdade quando o usuário já recebeu uma resposta para o scopedRequest. Defina isso em todos os subagentes, quer enviem mensagens ao usuário, quer permaneçam em silêncio. A instrução de nível superior, mostrada a seguir, lê para que o pai não responda novamente ao mesmo pedido.
scopedRequest (saída) A solicitação em que este agente trabalhou. Repita a solicitação delimitada por escopo para que ela alcance a camada de orquestração de mais alto nível, que não preserva de forma confiável as entradas que ela cria no próprio contexto. Em interações com múltiplas intenções que exigem mais de um subagente, essa capacidade permite que o nível superior planeje corretamente e evite encaminhar o subagente errado para a pergunta errada.
interactionSummary (saída) Um breve resumo da resposta entregue ao usuário. Devolva quando o subagente enviar mensagem direta ao usuário, assim o pai sabe o que foi comunicado e não repite.
findings (saída) A resposta à scopedRequest, para que o pai a entregue ao usuário. Devolva quando o subagente ficar em silêncio, assim o pai tem o conteúdo para entregar.
openQuestions (saída) Qualquer parte do pedido do usuário que permanece sem resposta. Retorne isso de qualquer subagente que possa atender apenas parte da solicitação ou em que tenha surgido 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 cuida do restante.

Escolha qual componente se comunica com o usuário

Decida se o agente pai ou o subagente se comunica com o usuário. Na maioria dos casos, deixe o agente pai se comunicar com o usuário para que ele possa combinar os resultados em uma única resposta. Deixe o subagente se comunicar diretamente quando precisar fornecer uma resposta longa ou ter uma conversa com múltiplas voltas. Dê informações suficientes para que o pai ou mãe possa lidar com o resto da conversa com contexto.

Qualquer componente que se comunice, adicione uma instrução de nível superior para que a camada de orquestração verifique as saídas de cada subagente antes de responder.

Esta instrução de nível superior de exemplo funciona em todos os casos, quer um subagente envie mensagens diretamente ao usuário, quer permaneça em silêncio. Edite e personalize conforme necessário.

Sempre que qualquer tópico ou agente for chamado, sempre procure a saída booleana 'respondida' antes de decidir o que responder. Tópicos e agentes têm seu próprio canal de comunicação com o usuário. Se 'respondido' for verdadeiro, sempre assuma que a solicitação foi respondida adequadamente usando pelo menos uma das variáveis de saída e verifique quais delas com base na descrição de saída. Não faça um reconhecimento constrangedor do conteúdo já respondido. Apenas forneça as respostas não respondidas e continue a conversa naturalmente com o próximo passo.

O termo canal não se refere a um canal de integração. É um mecanismo de sinalização que indica à camada de orquestração que o usuário talvez já tenha visto a resposta por meio 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 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 o status de resposta e as saídas de valor em todos os subagentes, independentemente de o subagente enviar uma mensagem ao usuário ou permanecer em silêncio, e forneça ao agente pai uma instrução para lê-las. Com essa abordagem, um agente pode misturar subagentes silenciosos e subagentes que enviam mensagens diretamente ao usuário, distinguidos apenas por suas saídas. Saiba mais em Projetar uma instrução robusta de alto nível para evitar mensagens repetidas.

Delegue a comunicação do usuário ao pai

Considere encaminhar toda a comunicação do usuário por meio do agente pai em vez de um subagente. Colete o que o subagente precisa como entradas antes de começar, leia o que ele produziu como saídas após terminar e instrua a não enviar mensagens diretamente ao usuário. Um subagente que nunca escreve para o usuário não pode responder a algo que o agente principal já respondeu.

Diga ao subagente para permanecer em silêncio e retornar seus resultados. 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 retorna findings e openQuestions, ambos descritos em Configure entradas e saídas, para passar sua resposta ao agente pai e sinalizar qualquer trabalho que ainda reste.

Retorne uma openQuestions saída. Permite que a camada de orquestração termine o restante da solicitação do usuário e continue a encadear ferramentas quando um subagente pode cumprir apenas parte do pedido.

Manter o subagente em silêncio requer uma instrução explícita. Por padrão, um subagente pode enviar mensagem ao usuário sozinho enquanto ele está em execução. A configuração Após a execução de conclusão não impede essas mensagens porque só informa ao pai o que fazer quando o subagente termina.

Note

Dizer ao agente principal: "Você é o único agente que fala com o usuário" não funciona. O agente pai não pode interromper um subagente em execução, e o subagente ainda pode enviar mensagens ao usuário por conta própria. Em vez disso, instrua o subagente a ficar em silêncio e então teste para confirmar.

Alguns subagentes precisam se comunicar diretamente

Um subagente que envia mensagens diretamente ao usuário é 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 usuário, seja para entregar uma resposta longa sem copiá-la para o contexto pai, seja para manter uma conversa. Para evitar mensagens repetidas e perda de contexto, passe o contexto para o elemento pai nos resultados.

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

O subagente fornece sua resposta completa diretamente ao usuário e retorna apenas um breve resumo ou uma nota de que entregou a resposta. Use essa abordagem para respostas longas, como análises detalhadas, e limite as informações retornadas ao contexto do pai. O objetivo é manter o contexto dos pais pequeno, mas informado.

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

Faça o subagente conversar com o usuário

O subagente troca várias mensagens com o usuário em várias etapas para concluir a solicitação delimitada. O principal risco é que o pai ou mãe não esteja ciente dos passos intermediários da conversa, do trabalho do subagente e de quaisquer respostas dadas, ou de quaisquer novos pedidos que surgissem. Como resultado, o pai ou mãe não pode agir sobre novas solicitações nem responder corretamente nas etapas seguintes.

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

A instrução de nível superior também cobre esse caso de uso.

  • Last updated on