![Imagem de capa de [Design de agentes #2] Engenharia de contexto: trate a janela como orçamento](/assets/images/posts/2ccd4368-394d-435f-b416-66619687b32d/context-engineering-1.jpg)
Ao ver a especificação «janela de contexto de 200K tokens», parece que daria para inserir quase qualquer código inteiro. Mas, quando fazemos isso, a qualidade das respostas despenca.
Diversos estudos confirmaram que os modelos deixam passar o conteúdo intermediário em contextos longos. Poder inserir algo e usá-lo bem são problemas diferentes.
Daí surgiu a engenharia de contexto. Em uma frase: é uma técnica de design que trata a janela de contexto finita como orçamento e mantém nela apenas as informações mais úteis a cada momento.
Neste artigo, resumimos por que o contexto é um orçamento, quatro estratégias para economizá-lo e os critérios para projetar arquivos carregados sempre, como CLAUDE.md.
Vamos começar pelo resumo principal.
- Contexto maior não é necessariamente melhor; quanto mais relevante, melhor.
- São quatro estratégias principais: carregamento seletivo, resumo (compactação), isolamento e externalização (memória).
- Arquivos carregados sempre (como CLAUDE.md) devem ser mantidos curtos e conter apenas «o que é sempre verdade».
- Ferramentas e instruções também consomem contexto. Uma ferramenta registrada, mas não usada, é custo.
Por que é um orçamento: a estrutura de custos do contexto
A janela de contexto envolve três custos simultaneamente.
Primeiro, o custo de desempenho. Quanto mais conteúdo irrelevante houver, mais a atenção do modelo se dispersa. Em especial, o fenômeno «lost in the middle», no qual a recuperação do conteúdo intermediário cai em contextos longos, já é conhecido.
Segundo, o custo financeiro. Os tokens de entrada são cobrados em cada solicitação. Quanto mais longa a conversa, mais vezes o mesmo conteúdo é cobrado.
Terceiro, o custo de oportunidade. O espaço ocupado por informações inúteis reduz o espaço para o código e a documentação realmente necessários.
A mudança de perspectiva da engenharia de contexto é esta: não perguntar «quanto posso inserir?», mas «este token merece estar aqui agora?».
Estratégias 1 e 2: carregamento seletivo e resumo
O carregamento seletivo (retrieval) traz apenas o necessário quando é preciso. Em vez de ler 2.000 linhas, lemos apenas as funções relevantes; em vez de carregar toda a documentação, pesquisamos e trazemos a seção correspondente.
O carregamento progressivo de um Skill (normalmente apenas uma descrição de uma linha, carregando o corpo somente na execução) segue o mesmo princípio.
O resumo (compaction) comprime o histórico acumulado. Ele transforma dezenas de registros de chamadas de ferramentas em um parágrafo como «modificamos estes arquivos e os testes passaram».
É a compactação que agentes de programação executam automaticamente quando a conversa fica longa.
Lembre-se de que resumir envolve perda. Detalhes podem desaparecer ao serem condensados, então é mais seguro registrar decisões importantes em arquivos antes do resumo.
Estratégias 3 e 4: isolamento e externalização
Isolamento é separar em outra sessão as tarefas que deixam o contexto confuso. Se um subagente fizer uma exploração em grande escala, o despejo de arquivos é consumido no contexto dele, e apenas algumas linhas com as conclusões retornam ao agente principal.
É a maneira mais segura de proteger o orçamento do contexto principal.
A externalização (memory) usa um armazenamento fora do contexto. Quando a sessão termina, o contexto desaparece, mas o que foi escrito em arquivos permanece.
Um padrão comum é registrar o estado do trabalho em Markdown para a próxima sessão continuar de onde parou. Acumular o conhecimento do projeto em CLAUDE.md e arquivos de memória também se enquadra aqui.
| Estratégia | Resumo em uma linha | Exemplo representativo |
|---|---|---|
| Carregamento seletivo | Trazer apenas quando necessário | Leitura parcial, carregamento progressivo de Skill |
| Resumo | Condensar o histórico | Compactação automática |
| Isolamento | Delegar a outra sessão | Subagente |
| Externalização | Registrar em arquivos | Arquivos de memória, documento de estado |
Critérios para projetar arquivos carregados sempre
Arquivos como CLAUDE.md são um custo fixo descontado antecipadamente do orçamento de cada sessão. Por isso, os critérios precisam ser claros.
Inclua «o que é sempre verdade e não pode ser violado»: convenções de código, proibições, comandos de build etc.
Exclua «o que só é necessário às vezes». Procedimentos detalhados de tarefas específicas devem ir para um Skill; registros de trabalhos anteriores devem ir para arquivos de memória.
A mesma lógica se aplica ao registro de ferramentas. Quanto mais servidores MCP (Model Context Protocol) conectamos, mais definições de ferramentas se acumulam como custos fixos.
Dez servidores sem uso já são um fator de degradação do desempenho. Vale a pena revisá-los regularmente.
Conclusão
No fim, engenharia de contexto é gestão de relevância. Não se trata de preencher uma janela grande, mas de manter na mesa do modelo apenas o que está relacionado ao trabalho atual.
Quando o loop de execução abordado na parte sobre engenharia de harness se combina com o gerenciamento de orçamento deste artigo, o panorama do design de agentes se completa. No próximo artigo, veremos um caso de pipeline montado na prática.