Distribuição de contexto no arnês padrão

O arcabouço padrão distribui o contexto entre os componentes que lidam com uma solicitação. Cada componente funciona a partir de seu próprio contexto, e o harness não reconcilia automaticamente o contexto no nível superior. Essa separação oferece flexibilidade, mas pode causar mensagens duplicadas ou respostas perdidas se a informação não for retornada explicitamente por componentes independentes.

Este artigo explica por que o contexto é distribuído, como o harness do GitHub Copilot difere, como o contexto se move entre a camada de orquestração do agente e um componente, e o que cada componente pode ver e retornar. Use essas informações para identificar lacunas de contexto e projetar agentes que gerenciem o contexto deliberadamente.

O diagrama a seguir ilustra como o contexto e a comunicação fluem entre a camada de orquestração, componentes individuais e o usuário no harness padrão.

Diagrama mostrando o contexto e as comunicações passadas entre a camada de orquestração, cada componente e o usuário em um agente de harness padrão.

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.

Um arcabouço impulsiona tudo o que é criado no Copilot Studio, e o modelo selecionado é responsável pelo raciocínio e pela geração. O harness é um tempo de execução que existe entre os dois: ele determina quando chamar o modelo, quais componentes enviar a ele, interpreta o que é retornado e chama as ferramentas corretas. Saiba mais sobre os recursos do Copilot Studio.

Por que o harness padrão distribui o contexto

O arnês padrão é construído para flexibilidade:

  • Ele orquestra tarefas e apoia casos de uso transacionais.
  • Ela equilibra controle determinístico e IA por meio de variáveis, gatilhos e recursos especializados.
  • Ele distribui o controle por componentes como tópicos, conhecimento, agentes filhos, agentes conectados e ferramentas.
  • Ele suporta múltiplas opções de autenticação, canal e integração.

Distribuir o trabalho entre componentes independentes oferece flexibilidade, mas pode criar lacunas no contexto:

  • A camada de orquestração de agentes entrega o controle durante certas chamadas de componentes.
  • Enquanto um componente está rodando, a camada de orquestração não consegue ver as mensagens que o componente envia ao usuário.
  • A camada de orquestração não reconcilia o contexto no nível superior.

Se o design não gerencia o contexto do agente, se desenvolvem lacunas e pedidos podem parecer sem resposta. Essas lacunas podem causar respostas duplicadas ou erradas.

Como a estrutura do GitHub Copilot difere

A camada de orquestração do GitHub Copilot harness evita o descompasso de contexto por ser a única a se comunicar com o usuário. Nunca permite que um agente conectado assuma a comunicação:

  • O loop de raciocínio e comunicação funciona sem gerenciamento deliberado do contexto.
  • Mensagens de agentes conectados passam pela camada de IA do pai a cada etapa.

A camada de orquestração da infraestrutura do GitHub Copilot também lida com o tamanho do contexto de forma diferente, o que faz com que seu contexto seja ordens de magnitude maior do que o da infraestrutura padrão:

  • Ele tem acesso direto ao contexto do modelo.
  • Pode usar compactação.
  • Ele pode gravar dados e arquivos em seu contêiner sandbox Bash.

Como o contexto passa para os componentes e retorna para a camada de orquestração

Para gerenciar o contexto de forma eficaz no arcabouço padrão, considere tanto o que a camada de orquestração passa para um componente quanto o que o componente retorna.

O contexto passa aos componentes de duas maneiras:

  • Entradas explícitas e requisições: A camada de orquestração preenche as entradas de cada componente a partir de seu contexto ativo e passa uma requisição conforme projetada.

  • Contexto implícito de conversa: A camada de orquestração também passa um contexto de conversa mais longo para componentes como conhecimento e subagentes sem configuração explícita. Note que um agente filho sempre recebe o contexto da conversa dos pais. Um agente conectado tem uma configuração que o inclui ou exclui. Uma ferramenta ou fluxo recebe apenas suas entradas.

Um componente envia informações de volta para a camada de orquestração de duas maneiras:

  • Saídas explícitas e resposta conforme projetado.
  • Contexto implícito de certos componentes.

O que um componente só mostra ao usuário, ou mantém suas próprias variáveis, pode nunca chegar à camada de orquestração a menos que volte por um desses dois canais.

A passagem implícita de informações causa cerca de metade dos casos com respostas duplicadas ou erradas, pois um componente pode agir em uma solicitação que nunca foi explicitamente passada para ele.

Como o contexto difere entre os componentes

A conversa visível pelo usuário e o contexto da camada de orquestração se sobrepõem, mas não são a mesma coisa. Os seguintes princípios se aplicam ao que chega ao contexto da camada de orquestração a partir de uma chamada de componente:

  • O que um componente mantém para si permanece escondido. As variáveis de tópico e as conversas de vários turnos dentro dos subagentes ficam dentro do componente. A camada de orquestração só os vê se forem retornados como saídas.

  • Apenas dois tipos de retorno de informação. A camada de orquestração recebe as saídas explícitas que são projetadas e o contexto implícito de um componente. Um componente que funciona, mas não retorna nada, pode deixar a camada de orquestração sem saber o que aconteceu.

Cada componente tem seu próprio contexto ou ponto de vista. A camada de orquestração usa seu contexto ativo para selecionar passos e gerar entradas. Um agente conectado possui sua própria camada de orquestração, suas próprias instruções e suas próprias ferramentas e chamadas de conhecimento internas.

Use a tabela a seguir para fazer uma pergunta precisa: Qual componente possui um dado fato em seu contexto ativo?

Ponto de vista Tem em seu contexto ativo Pode escrever no painel de chat Pode retornar como contexto
Camada de orquestração Solicitação do usuário, contexto da conversa, descrições de componentes, descrições de entrada, descrições de saída, estado do plano, respostas implícitas (mas não se a informação implícita foi mostrada ao usuário) Sim. Suas próprias perguntas e respostas. Suas próprias perguntas, respostas, raciocínio e plano.
Tópico Variáveis do tópico, estado atual do nó Sim. Por meio de nós de mensagem, nós de pergunta e Perguntar com Cartão Adaptável. Saídas de tópicos e trocas de mensagens implícitas que ainda podem causar duplicação.
Ferramenta ou fluxo Entradas geradas pela camada de orquestração Não. Saídas da ferramenta ou do fluxo.
Etapa do conhecimento Solicitação do usuário mais o contexto ativo do seu agente Não. Ele escreve para seu próprio agente, não para o painel de chat. É a resposta.
Nó de respostas geradas por IA (dentro de um tópico) O que é enviado na entrada mais o contexto do agente Sim. Diretamente ou para uma variável de tópico. Não de forma explícita, pode ser repetido.
Subagente (filho ou agente conectado) Sua solicitação inicial, além das entradas fornecidas pelo elemento pai e de qualquer contexto do elemento pai incluído, dentro do contexto de sua própria camada de orquestração Sim, se estiver configurado ou instruído a responder diretamente. Uma resposta e seus resultados.

Importante

Tópicos: O contexto implícito retornado pelos tópicos inclui apenas informações em texto simples, mas não se o usuário as viu. Informações de texto simples podem vir de nós de mensagem, nós de perguntas, do conteúdo de Adaptive Card e das respostas digitadas pelo usuário. No entanto, os botões de ação do Adaptive Card e as interações dos usuários com eles não chegam ao contexto do harness padrão. O manuseio adaptativo de cartas causa a maioria das incompatibilidades de contexto. Não confie no conteúdo do cartão como contexto. Em vez disso, retorne qualquer informação que uma etapa posterior precise como saída de tópico e defina uma saída em estado respondido. Saiba mais em Projete tópicos como miniagentes que evitam mensagens duplicadas.

Subagentes: Quando o contexto principal é passado para um agente conectado, ele pode influenciar todas as ferramentas, tópicos e consultas de conhecimento que o agente realiza. Se o contexto incluído ainda contiver uma solicitação que parece não ter sido respondida, o agente conectado pode tentar compensar e responder novamente. Um agente infantil tem o mesmo risco, mas com menos controle. Ele roda dentro do pai e sempre recebe o contexto da conversa do pai, sem nenhuma configuração para excluí-lo. Saiba mais sobre Subagentes de Design que evitam mensagens duplicadas.

Próximas etapas

Com esse modelo de contexto em mente, o próximo artigo desta série explica por que esse modelo causa mensagens duplicadas e sugere padrões de design para preveni-las.

Melhores práticas de design para evitar mensagens duplicadas

  • Last updated on