O seu agente chega a 80% da janela de contexto. A compactação é ativada e descarta os turnos mais antigos. Dez minutos depois, o agente volta a ler um ficheiro que já tinha lido e repete uma pergunta a que já tinha respondido.
O limite sabia que estava a ficar 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 da deteção de estagnação, a segunda, de design de marcos.
Começar pela nossa própria implementação
O Orkas é um cliente multiagente para computador. As tarefas longas são o caso normal aqui, pelo que a compactação ocorre todos os dias. A nossa implementação é ativada num limite de tokens, compactando quando o contexto atinge cerca de 80% da janela. Até escrevermos isto, ninguém achava que houvesse algo de errado nisso.
Existem cerca de três limites comuns: uma percentagem da janela, uma contagem de turnos ou deixar o modelo escrever um resumo que abranja o conteúdo antigo. O nosso é o primeiro.
Os dois primeiros nunca analisam o conteúdo. O terceiro analisa-o, mas entrega ao modelo toda a decisão sobre o que importa.
Os três respondem quando preciso de deitar algo fora. A pergunta que realmente se coloca é o que é seguro deitar fora. Cortar no limite descarta o conteúdo mais antigo, não o menos importante.
O limite dos marcos e o pressuposto subjacente
Os marcos da nota anterior poderiam oferecer um limite melhor do que qualquer um dos três. Mas há aqui uma armadilha, e a nota anterior apresentou-a de forma demasiado simplificada.
O BEACON contém um pressuposto chamado propriedade de Markov dos marcos. Em termos simples: uma vez alcançado um marco, o que acontece depois depende apenas dos subobjetivos restantes, não de como lá chegou. Com a chave na mão, o que importa é que porta abre, não como a encontrou.
Isto parece dar licença para compactar: ultrapassado um marco, o segmento anterior pode ser condensado e descartado.
Mas é um pressuposto, não um facto. O artigo escreve ≈, não =, e os autores discutem onde falha.
Adequado para treino, inadequado para compactação
O mesmo pressuposto, dois usos, uma ordem de grandeza de diferença no rigor.
No treino, só precisa de se verificar estatisticamente. Se algumas dezenas de rollouts entre alguns milhares o violarem, o desvio dilui-se na média. O treino também usa um sinal ao nível da trajetória como camada subjacente, funcionando como rede de segurança; retire essa camada e o ALFWorld cai de 91.4 para 23.4, muito abaixo de não fazer nada.
Na compactação, precisa de se verificar ponto a ponto, para a única execução à sua frente. Descarte a informação errada uma vez e essa tarefa fica comprometida. Não há nada de que se possa calcular uma média.
Por isso, o facto de o artigo se apoiar nesse pressuposto não significa que o possa aplicar à compactação. Os dois usos não lhe exigem o mesmo.
Quatro casos em que falha
Usamos estes quatro como lista de verificação ao pensar numa política de compactação.
1. Conhecimento implícito acumulado ao longo do percurso. Num ponto inicial, uma etapa estabelece que uma determinada API devolve carimbos de data/hora em UTC. Isso não pertence a nenhum marco, e todas as etapas seguintes precisam dessa informação.
2. Recursos já consumidos. Orçamento de tokens, quota de chamadas, tempo restante. Um marco não regista gastei 60% do orçamento, mas esse número determina se ainda é possível tentar de novo.
3. Efeitos secundários dependentes do percurso. O marco diz refatoração concluída. Quando começa a depuração, é preciso saber que cinco ficheiros foram efetivamente alterados.
4. O próprio marco está insuficientemente especificado. O pior dos quatro. No artigo, um marco é um estado completo do ambiente — tem a chave ou não tem, sem ambiguidade. Uma etapa de um plano é uma frase em linguagem natural. "Concluir a limpeza de dados" fica muito longe de abranger o que aconteceu nesse segmento.
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 espaço de trabalho agora — que ficheiros foram alterados e em que estado ficaram.
- Quanto orçamento resta — tokens, quota de chamadas, tempo.
- O que já foi estabelecido — o facto sobre UTC e tudo o que seja do mesmo tipo e venha a orientar decisões futuras.
- O que ainda está em aberto — aquilo que bloqueou uma vez, foi contornado e pode voltar.
Compare isto com os quatro casos de falha acima e verá que correspondem um a um. Essa correspondência é a forma mais simples de avaliar se uma política de compactação é suficiente.
Metade disto tem um custo quase nulo. Como descreveu a nota anterior, o sistema anfitrião já regista factos determinísticos após cada chamada a uma ferramenta: se um ficheiro foi efetivamente reescrito, se um comando foi realmente executado. Estes dados foram recolhidos para verificar marcos, mas são o retrato do espaço de trabalho, pelo que a compactação pode transportá-los diretamente sem pedir a um modelo que os resuma de novo.
A metade difícil são os outros dois campos. O que foi estabelecido e o que continua em aberto só existem hoje se o modelo os escrever, e é precisamente por isso que são as primeiras baixas da compactação.
Isto é mensurável, não discutível
Depois da compactação, se o agente voltar a ler um ficheiro que foi descartado ou repetir uma pergunta já respondida, o pressuposto falhou nessa tarefa e a prova está mesmo ali.
A instrumentação é simples: cruze os caminhos dos ficheiros lidos após o ponto de compactação com o que foi registado antes dele.
Com este número, que tipos de tarefa podem ser compactados agressivamente e quais não passa a ser uma consulta, e não um debate de conceção. É a mesma abordagem da primeira nota da série: medir primeiro, mudar depois.
As ressalvas necessárias
Nada disto está em produção. Estamos na fase de conceção e instrumentação.
A escolha dos campos a manter e do seu nível de detalhe deve resultar de dados sobre o que é realmente procurado de novo. Decidir agora é uma boa forma de decidir mal.
E esta é uma abordagem entre várias. A localização do limite e a forma como os campos são definidos podem ser completamente diferentes noutro formato de produto. A lista de verificação dos quatro casos é transferível; a resposta específica, não.
A próxima e última nota da série trata da autorreflexão: porque é que as lições destiladas por um agente insistem em ser tão genéricas como "seja mais cuidadoso", e uma constatação verdadeiramente surpreendente sobre o que os seus dados de entrada contêm e o que não contêm.