Distribuição de contexto no harness padrão

O harness predefinido distribui o contexto pelos componentes que processam um pedido. Cada componente funciona a partir do seu próprio contexto, e o harness não reconcilia automaticamente o contexto ao nível superior. Esta separação proporciona flexibilidade, mas pode causar mensagens duplicadas ou respostas falhadas se a informação não for devolvida explicitamente por componentes independentes.

Este artigo explica porque é 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 devolver. Use esta informação para identificar lacunas de contexto e para desenhar agentes que gerem o contexto de forma deliberada.

O diagrama seguinte ilustra como o contexto e a comunicação fluem entre a camada de orquestração, componentes individuais e o utilizador no harness padrão.

Diagrama que mostra o contexto e as comunicações passadas entre a camada de orquestração, cada componente e o utilizador num agente de harness padrão.

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.

Uma estrutura suporta tudo o que é criado no Copilot Studio, e o modelo selecionado disponibiliza capacidades de raciocínio e de geração. O harness é um tempo de execução que existe entre os dois: determina quando chamar o modelo, que componentes enviá-lo, interpreta o que regressa e chama as ferramentas certas. Saiba mais sobre os recursos do Copilot Studio.

Porque é que o harness padrão distribui o contexto

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

  • Orquestra tarefas e suporta casos de uso transacionais.
  • Equilibra controlo determinístico e IA através de variáveis, gatilhos e funcionalidades especializadas.
  • Distribui o controlo por componentes como tópicos, conhecimento, agentes filhos, agentes conectados e ferramentas.
  • 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 controlo durante certas chamadas de componentes.
  • Enquanto um componente está a correr, a camada de orquestração não consegue ver as mensagens que o componente envia ao utilizador.
  • A camada de orquestração não reconcilia o contexto ao nível superior.

Se o design não gerir o contexto do agente, surgem lacunas e os pedidos podem parecer sem resposta. Estas lacunas podem causar respostas duplicadas ou falhadas.

Como o harness do GitHub Copilot difere

A camada de orquestração da infraestrutura GitHub Copilot evita o desfasamento de contexto por ser o único elemento a comunicar com o utilizador. Nunca permite que um agente ligado assuma a comunicação:

  • O raciocínio e o ciclo de comunicação funcionam sem uma gestão deliberada do contexto.
  • Mensagens do agente ligado passam pela camada de IA do progenitor a cada passo.

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

  • Tem acesso direto ao contexto do modelo.
  • Pode utilizar a compactação.
  • Pode escrever dados e ficheiros no contentor de sandbox do Bash.

Como o contexto passa para os componentes e regressa à camada de orquestração

Para gerir o contexto de forma eficaz na estrutura padrão, considere tanto o que a camada de orquestração transmite a um componente como o que o componente devolve.

O contexto passa para os componentes de duas formas:

  • Entradas explícitas e pedidos: A camada de orquestração preenche as entradas de cada componente a partir do seu contexto ativo e transmite um pedido conforme concebido.

  • Contexto de conversa implícito: 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 recebe sempre o contexto da conversa dos pais. Um agente ligado tem uma definição que o inclui ou exclui. Uma ferramenta ou fluxo recebe apenas as suas entradas.

Um componente envia informação de volta para a camada de orquestração de duas formas:

  • Saídas explícitas e resposta tal como concebidas.
  • Contexto implícito de certos componentes.

O que um componente apenas mostra ao utilizador, ou apenas mantém nas suas próprias variáveis, pode nunca chegar à camada de orquestração, a menos que regresse através de um desses dois canais.

A passagem implícita de informação causa que cerca de metade dos casos tenham respostas duplicadas ou falhadas porque um componente pode agir sobre um pedido que nunca lhe foi explicitamente passado.

Como o contexto difere entre componentes

A conversa visível pelo utilizador e o contexto da camada de orquestração sobrepõem-se, mas não são a mesma coisa. Os seguintes princípios aplicam-se 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. Variáveis de tópico e conversas de múltiplas voltas dentro dos subagentes existem dentro do componente. A camada de orquestração só os vê se forem devolvidos como saídas.

  • Apenas dois tipos de informação retornam. A camada de orquestração recebe as saídas explícitas que são definidas 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 o seu próprio contexto, ou ponto de vista. A camada de orquestração usa o seu contexto ativo para selecionar passos e gerar entradas. Um agente ligado tem a sua própria camada de orquestração, as suas próprias instruções e as suas próprias ferramentas internas e chamadas de conhecimento.

Use a tabela seguinte para colocar uma pergunta precisa: Qual componente tem um dado facto no seu contexto ativo?

Ponto de vista Tem no seu contexto ativo Pode escrever no painel de chat Pode ser devolvido como contexto
Camada de orquestração Pedido do utilizador, 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 utilizador) Sim. As suas próprias perguntas e respostas. As suas próprias perguntas, respostas, raciocínio e plano.
Tópico Variáveis do tópico, estado atual do nó Sim. Por meio dos nós de mensagem, dos nós de pergunta e de Perguntar com Cartão Adaptativo. Saídas de tópicos e trocas implícitas de mensagens 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 Pedido do utilizador mais o contexto ativo do seu agente Não. Escreve para o seu próprio agente, não para o painel de chat. A sua resposta.
Nó de respostas generativas (dentro de um tópico) O que é enviado na sua entrada mais o contexto do seu agente Sim. Diretamente, ou a uma variável do tema. Não de forma explícita, pode repetir-se.
Subagente (filho ou agente ligado) O seu pedido inicial, mais entradas fornecidas pelos pais e qualquer contexto parental incluído, dentro do seu próprio contexto de camada de orquestração Sim, se estiver configurado ou instruído para responder diretamente. Uma resposta e os seus resultados.

Importante

Tópicos: O contexto implícito devolvido pelos tópicos inclui apenas informação em texto simples, mas não se o utilizador a viu. A informação em texto simples pode vir de nós de mensagem, nós de pergunta, conteúdo do Cartão Adaptativo e respostas digitadas pelo utilizador. No entanto, os botões de ação do Adaptive Card e as interações dos utilizadores com esses botões não chegam ao contexto padrão do ambiente de teste. O manuseamento adaptativo de cartas causa a maioria das incompatibilidades de contexto. Não confies no conteúdo das cartas como contexto. Em vez disso, devolve qualquer informação que uma etapa posterior precise como saída de tópico e define uma saída de estado respondido. Saiba mais em Conceber tópicos como miniagentes para evitar mensagens duplicadas.

Subagentes: Quando o contexto principal é transmitido a um agente conectado, pode influenciar todas as ferramentas, tópicos e chamadas à base de conhecimento que o agente efetua. Se o contexto incluído ainda contiver um pedido que parece não ter sido respondido, o agente ligado pode tentar compensar e responder novamente. Um agente infantil tem o mesmo risco mas com menos controlo. Corre dentro do progenitor e recebe sempre o contexto da conversa do progenitor, sem qualquer opção para o excluir. Saiba mais em Subagentes de Design que evitam mensagens duplicadas.

Passo seguinte

Com este modelo de contexto em mente, o próximo artigo desta série explica porque é que este modelo causa mensagens duplicadas e sugere padrões de design para as prevenir.

Melhores práticas de design para evitar mensagens duplicadas

  • Last updated on