Distribuição de contexto no agente padrão

O arcabouço padrão distribui o contexto entre os componentes que lidam com uma solicitação. Cada componente funciona com base no próprio contexto, e o agente 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.

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 agente é um runtime que existe entre os dois: ele determina quando chamar o modelo, quais componentes enviar a ele, interpreta o que é retornado e chama as ferramentas certas. Saiba mais sobre os recursos do Copilot Studio.

Por que o agente padrão distribui 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 filho, 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 do agente entrega o controle durante determinadas chamadas de componente.
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 o agente 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 agente conectado passam pela camada de IA do pai a cada rodada.

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.
Ele 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. Um agente filho sempre recebe o contexto da conversa do pai. 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 alcança o contexto da camada de orquestração por uma chamada de componente:

O que um componente mantém para si permanece escondido. As variáveis de tópico e as conversas com várias rodadas dentro de subagentes estão 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 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.	As próprias perguntas, respostas, justificativas e plano.
Tópico	Variáveis do tópico, estado atual do nó	Sim. Por meio dos 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 de ferramenta ou fluxo.
Etapa do conhecimento	Solicitação do usuário mais o contexto ativo do seu agente	Não. Ele grava no próprio agente, e não no painel de chat.	É a resposta.
Nó de respostas generativas (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 maneira explícita, pode ser repetido.
Subagente (filho ou agente conectado)	A solicitação inicial, além das entradas fornecidas pelo elemento pai e de qualquer contexto do pai incluído, dentro do contexto da 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 dos nós de mensagem, nós de pergunta, do conteúdo do Cartão Adaptável e das respostas digitadas pelo usuário. No entanto, os botões de ação do Cartão Adaptável e as interações de usuário com eles não chegam ao contexto do agente padrão. O manuseio do Cartão Adaptável 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 uma saída de tópico e defina uma saída de 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 executa 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

Comentários

Esta página foi útil?

Última atualização em 2026-09-08