Seu agente chega a 80% da janela de contexto. A compactação dispara e descarta os turnos mais antigos. Dez minutos depois, ele relê um arquivo que já tinha lido e refaz uma pergunta que já tinha respondido.
O limite sabia que você estava sem espaço. Não sabia nada sobre o que era seguro perder.
Esta é a terceira nota de uma série sobre design de agentes de longo horizonte, motivada por uma leitura atenta do BEACON (Universidade de Zhejiang, arXiv:2605.06078). A primeira tratou de detecção de estagnação, a segunda, de design de marcos.
Começando pela nossa própria implementação
O Orkas é um cliente de desktop multiagente. Tarefas longas são o caso normal aqui, então compactação aparece todo dia. Nossa implementação dispara em um limite de tokens, compactando quando o contexto atinge cerca de 80% da janela. Até escrevermos isto, ninguém achava que houvesse algo errado nisso.
Existem cerca de três fronteiras comuns por aí: porcentagem da janela, contagem de turnos, ou deixar o modelo escrever um resumo que cobre o conteúdo antigo. A nossa é a primeira.
As duas primeiras nunca olham o conteúdo. A terceira olha, mas entrega ao modelo a questão inteira do que importa.
As três respondem quando eu preciso jogar algo fora. A pergunta que você realmente tem é o que é seguro jogar fora. Cortar no limite descarta o conteúdo mais antigo, não o menos importante.
A fronteira de marcos e a suposição por baixo dela
Os marcos da nota anterior poderiam dar uma fronteira melhor do que qualquer uma das três. Mas há uma armadilha aqui, e a nota anterior a deixou lisa demais.
O BEACON contém uma suposição chamada propriedade de Markov de marcos. Em termos simples: uma vez alcançado um marco, o que acontece depois depende apenas dos subobjetivos restantes, não de como você chegou lá. Com a chave em mãos, o que importa é qual porta você abre, não como a encontrou.
Isso soa como licença para compactar: passado um marco, o trecho anterior pode ser dobrado e descartado.
Mas é uma suposição, não um fato. O artigo escreve ≈, não =, e os autores discutem onde ela falha.
Adequada para treinamento, inadequada para compactação
Mesma suposição, dois usos, uma ordem de grandeza de diferença em rigor.
No treinamento ela só precisa valer estatisticamente. Se algumas dezenas entre alguns milhares de rollouts a violam, o viés se dilui na média. O treinamento também roda um sinal em nível de trajetória por baixo, como rede de segurança; remova essa camada e o ALFWorld cai de 91.4 para 23.4, muito abaixo de não fazer nada.
Na compactação ela precisa valer ponto a ponto, para a única execução à sua frente. Descarte a coisa errada uma vez e aquela tarefa morreu. Não há nada sobre o que tirar média.
Então o artigo se apoiar nessa suposição não significa que você possa levá-la para a compactação. Os dois usos não pedem a mesma coisa dela.
Quatro casos em que ela quebra
Usamos estes quatro como checklist ao pensar em uma política de compactação.
1. Conhecimento implícito acumulado no caminho. Em algum ponto inicial, uma etapa estabelece que certa API retorna timestamps em UTC. Isso não pertence a marco nenhum, e toda etapa seguinte precisa disso.
2. Recursos já consumidos. Orçamento de tokens, cota de chamadas, tempo restante. Um marco não registra gastei 60% do orçamento, mas esse número decide se ainda dá para tentar de novo.
3. Efeitos colaterais dependentes do caminho. O marco diz refatoração concluída. No momento em que a depuração começa, você precisa saber quais cinco arquivos foram de fato tocados.
4. O próprio marco é subespecificado. O pior dos quatro. No artigo, um marco é um estado completo do ambiente — você tem a chave ou não tem, sem ambiguidade. Uma etapa de plano é uma frase em linguagem natural. "Concluir a limpeza de dados" não chega nem perto de cobrir o que aconteceu naquele trecho.
O que carregar em vez disso
Não guarde apenas um resumo. Um resumo é escrito pelo modelo, que decide por intuição o que importava.
Guarde um conjunto fixo de campos, escolhidos por uma pessoa. No mínimo quatro:
- Como está o workspace agora — quais arquivos foram tocados e em que estado ficaram.
- Quanto orçamento resta — tokens, cota de chamadas, tempo.
- O que já foi estabelecido — o fato do UTC e tudo do mesmo tipo que moldará decisões futuras.
- O que ainda está em aberto — aquilo que travou uma vez, foi contornado, e pode voltar.
Coloque isso contra os quatro casos de falha acima e eles se alinham um a um. Essa correspondência é a maneira mais simples de julgar se uma política de compactação é suficiente.
Metade disso é quase de graça. Como descreveu a nota anterior, o host já registra fatos determinísticos após cada chamada de ferramenta: se um arquivo foi mesmo reescrito, se um comando realmente rodou. Esses dados foram coletados para verificar marcos, mas eles são o retrato do workspace, então a compactação pode carregá-los diretamente sem pedir a um modelo que os resuma de novo.
A metade difícil são os outros dois. O que foi estabelecido e o que segue em aberto só existem hoje se o modelo os escrever, e é exatamente por isso que são as primeiras baixas da compactação.
Isso é mensurável, não discutível
Depois da compactação, se o agente relê um arquivo que foi descartado, ou refaz uma pergunta já respondida, a suposição falhou naquela tarefa e a evidência está bem ali.
A instrumentação é simples: cruze os caminhos de arquivo lidos após o ponto de compactação com o que foi registrado antes dele.
Com esse número, quais tipos de tarefa podem ser compactados agressivamente e quais não vira uma consulta, e não um debate de design. É a mesma abordagem da primeira nota da série: medir primeiro, depois mudar.
Onde isso precisa ser descontado
Nada disso está em produção. Estamos em design e instrumentação.
Quais campos manter e em que granularidade deve vir de dados sobre o que realmente é buscado de novo. Decidir agora é um bom jeito de decidir errado.
E esta é uma abordagem entre várias. Onde fica a fronteira e como os campos são definidos pode ser completamente diferente em outro formato de produto. O checklist de quatro casos viaja; a resposta específica, não.
A próxima e última nota da série trata da autorreflexão: por que as lições destiladas por um agente insistem em sair tão genéricas quanto "seja mais cuidadoso", e uma constatação genuinamente surpreendente sobre o que suas entradas contêm e o que não contêm.