Distribuição de contexto na plataforma standard

A plataforma standard distribui o contexto pelos componentes que processam um pedido. Cada componente funciona a partir do seu próprio contexto, e a plataforma 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 plataforma suporta tudo o que é criado no Copilot Studio, e o modelo selecionado disponibiliza capacidades de racionalização e de geração. A plataforma é um runtime que existe entre os dois: determina quando chamar o modelo, que componentes enviar, interpreta o que é devolvido e chama as ferramentas corretas. Saiba mais sobre os recursos do Copilot Studio.

Por que motivo a plataforma standard 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 de elemento subordinado, agentes ligados 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 agente entrega o controlo durante determinadas 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 a plataforma do GitHub Copilot é diferente

A camada de orquestração da plataforma do GitHub Copilot evita a discrepância de contexto ao ser o único comunicador 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.
  • As mensagens de agentes ligados passam pela camada de IA do agente principal em cada turno.

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 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. Tenha em atenção que um agente de elemento subordinado recebe sempre o contexto da conversação do agente principal. 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. As variáveis de tópico e as conversações de vários turnos dentro de 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, racionalização e plano.
Tópico Variáveis do tópico, estado atual do nó Sim. Através de nós de mensagem, nós de pergunta e da funcionalidade Perguntar com Cartão Adaptativo. 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 de ferramenta ou de 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 (num tópico) O que é enviado na respetiva entrada, juntamente com o contexto do agente Sim. Diretamente ou para uma variável do tópico. Não de forma explícita, pode repetir-se.
Subagente (filho ou agente ligado) O seu pedido inicial, juntamente com as entradas fornecidas pelo agente principal e qualquer contexto do agente principal 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. As informações em texto simples pode vir de nós de mensagem, nós de pergunta, conteúdo de Cartão Adaptativo e respostas escritas pelo utilizador. No entanto, os botões de ação do Cartão Adaptativo e as interações dos utilizadores com esses botões não chegam ao contexto da plataforma standard. O processamento de Cartões Adaptativos causa a maioria das discrepâncias de contexto. Não confies no conteúdo das cartas como contexto. Em vez disso, devolva como saída de tópico qualquer informação de que um passo posterior necessite e defina 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. É executado no agente principal e recebe sempre o contexto da conversação do agente principal, sem qualquer definição para excluí-lo. 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

  • Última atualização a