a escolha de rota do github copilot
Categories:
O copilot pôde ser usado ilimitadamente no vscode insider de fevereiro a julho do ano passado, e nesse período testemunhei o declínio gradual da capacidade de agente do copilot. Difícil imaginar, a versão de pré-visualização do primeiro mês do copilot acabou sendo a de melhor desempenho, e depois a capacidade de agente diminuiu gradualmente. Qual foi a mudança exata? Foi a direção de desenvolvimento e evolução do copilot: ao longo do último ano e pouco, foi “economizar token”. No início, os agentes de todos liam o arquivo inteiro de uma vez — qwen cli/claudecode/gemini/copilot early eram assim, o efeito era muito bom, só que o consumo de token devia ser um pouco grande, o contexto também enchia rapidamente, e se reconstruísse o contexto, a taxa de acerto de cache diminuía. Depois, todos foram na direção de leitura por fragmentos: uns fazem grep e leem algumas dezenas de linhas acima e abaixo, se não bastar leem mais; outros usam ferramentas estruturadas de código como LSP para ler. O agente do copilot usa o método de ler o arquivo de cima para baixo, lendo 50 linhas por vez, ocasionalmente 200 linhas, mas sempre de cima para baixo. Combinado com o limite padrão de 50 chamadas de ferramenta e um contexto de entrada de menos de 200k, o trabalho que consegue completar é bem limitado. No início, os serviços de todas as fabricantes davam prejuízo, com a expectativa de ocupar a posição ecológica a preço baixo e depois baixar o custo; só que nesse ano e pouco finalmente perceberam que o custo não baixa, e forçar a redução de custo faz o próprio produto virar um produto de terceira categoria. Então não adianta culpar o copilot demais: todos os agentes que estão na mesa já cobram por token, e o copilot é um dos atrasados. Livre do fardo histórico de contagem por uso, espero que o copilot melhore bem seu agente e acompanhe o grupo principal, afinal ainda é o que tem a melhor integração com o vscode. Ferramenta de IA pode ser cara, mas não pode ser muito ruim.
