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, é executado na 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 consegue 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.

Desativar contexto pai de 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 da conversa 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 só funcione com as entradas enviadas pelo pai, e não com a 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. Ele é executado dentro do elemento pai e sempre recebe o contexto da conversa do pai.

Para agentes conectados que precisem manter o contexto do trabalho que lhes foi atribuído, e para agentes filhos que tenham 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 no que trabalhar, para que solicitações pendentes e sem resposta no contexto não o tirem do foco da tarefa. Se não passar o contexto, você não precisará 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.

Uma entrada de escopo é um projeto robusto mesmo quando você não mantém o contexto pai. 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 pai não consegue ver a troca do subagente com o usuário, logo, esse contrato é o único sinal confiável que ele tem.

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 evita que o subagente responda à pergunta errada quando o contexto do pai ainda contém outras solicitações não atendidas. 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 à mesma solicitação.
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 nível superior, que não mantém de maneira confiável as entradas que ela cria no próprio contexto. Em rodadas com várias intenções que exijam mais de um subagente, essa capacidade permite que o nível superior planeje corretamente e evite o roteamento do 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, de maneira que o pai saiba o que foi comunicado e não repita.
findings (saída) A resposta para scopedRequest, para que o pai o entregue ao usuário. Devolva quando o subagente permanece em silêncio, de maneira que o pai tenha o conteúdo a ser entregue.
openQuestions (saída) Qualquer parte do pedido do usuário que permanece sem resposta. Devolva de qualquer subagente que só possa atender à parte da solicitação ou em que tenha surgido uma nova solicitação na conversa do subagente, de maneira que o agente pai 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 dar uma resposta longa ou ter uma conversa com várias rodadas. 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 algum tópico ou agente for chamado, sempre procure a saída booliana "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 dê um reconhecimento estranho do conteúdo já respondido. Só dê as respostas não respondidas e continue naturalmente a conversa com a próxima etapa.

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 do subagente enviar uma mensagem ao usuário ou permanecer em silêncio, e ofereç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 Configurar entradas e saídas, para passar a resposta ao agente pai e sinalizar qualquer trabalho restante.

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 de conclusão Após a execuçã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 pai em saídas.

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. A meta é manter o contexto pai 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.

  • Última atualização em