Telemetria do Copilot separa identidade, prompts e ferramentas

Investigar o que um agente fez não exige, necessariamente, guardar tudo o que ele leu. A atualização de 12 de outubro do GitHub Copilot separa identidade e conteúdo na telemetria OpenTelemetry: uma empresa pode atribuir uma execução a um usuário sem coletar os prompts, respostas e resultados das ferramentas.

A novidade amplia o suporte anunciado em setembro, que já permitia exportar rastros de execução para um backend de observabilidade. Um trace reúne passos da sessão; métricas de tokens e duração ajudam a localizar gargalos. Agora a escolha de quanto observar fica mais granular, e a responsabilidade sobre essa coleta também.

Identidade e conteúdo são decisões diferentes

O controle telemetry.capture.identity pode adicionar login do GitHub, usuário do sistema operacional e nome da máquina. Ele começa desligado e não altera o identificador pseudônimo já existente.

Cinco classes de conteúdo podem ser habilitadas separadamente:

Todas começam desligadas. O antigo captureContent continua como atalho para essas cinco classes, mas não habilita identidade. Nos clientes documentados para configuração gerenciada, os valores empresariais explícitos prevalecem sobre ajustes locais.

Isso permite separar dois problemas que antes eram facilmente misturados: atribuir uma sessão durante uma investigação e reconstruir seu conteúdo. O segundo exige uma decisão adicional. Identificar alguém não é necessário para toda análise de custo; guardar seu código tampouco é necessário para descobrir que uma ferramenta demora demais.

O cliente muda o alcance do controle

A granularidade completa está documentada para Copilot CLI, aplicativo Copilot e sessões do VS Code com Agent Host. O harness local do VS Code suporta identidade e o controle legado de conteúdo, mas não aplica as cinco classes de forma independente.

Essa diferença impede um atalho perigoso: publicar uma configuração e assumir que todos os clientes a interpretam igualmente. A documentação do VS Code também descreve regras próprias de precedência na extensão, incluindo variáveis de ambiente. Antes de padronizar a coleta, confira o cliente, a versão e o modo de execução usados pela equipe.

A configuração de telemetria define o coletor que recebe os dados. O serviço de observabilidade passa, portanto, a integrar a fronteira de confiança do projeto. Permissões, retenção e acesso aos rastros precisam acompanhar a sensibilidade do conteúdo, principalmente quando a captura inclui arquivos, comandos ou caminhos de diretórios.

Um trace pode explicar a falha de um agente. Também pode criar uma nova cópia de dados que a equipe precisava proteger.

Observabilidade ainda não mede qualidade sozinha

Imagine uma sessão com poucos tokens e baixa latência. Ela pode ter sido eficiente ou simplesmente ter deixado de executar o teste que encontraria a regressão. Outra sessão, mais cara, pode ter concluído um trabalho difícil com menos retrabalho.

A correlação útil combina rastros com resultado revisável, testes executados e correções após revisão. Identidade pode ajudar a investigar um incidente específico, mas um ranking individual de produtividade baseado apenas em tokens confundiria atividade com entrega.

Para começar, escolha uma pergunta operacional, como localizar chamadas repetidas ou explicar falhas de ferramentas. Use os dados mínimos necessários e amplie a captura somente quando houver um motivo definido. Os controles de políticas empresariais ajudam a distribuir regras; a qualidade da regra depende de quem decide o que será coletado.

Fontes em inglês: anúncio inicial de OpenTelemetry, captura granular e identidade, 12/10, referência de configuração gerenciada e monitoramento de agentes no VS Code.