OpenClaw Implementa Compressão do Histórico do Agente para Reduzir o Uso de Contexto

Problema de Gerenciamento de Contexto

Ao executar o OpenClaw dentro do Docker, a escrita direta de código pelo agente enche o contexto com ruído: leitura de arquivos (5 mil tokens), escrita de edições (500 tokens), execução de testes (200 tokens) e recebimento de rastreamentos de pilha (3 mil tokens). Um único ciclo de depuração consome 10 mil a 15 mil tokens, principalmente de saída do console e rastreamentos de pilha que se tornam inúteis após correções de bugs. Com 20 a 30 ciclos de depuração por sessão, toda a janela de contexto é consumida por ruído.

Arquitetura Cérebro/Trabalhador

A solução envolve separar responsabilidades: o OpenClawd (no Docker) atua como o cérebro para planejamento, dividindo o trabalho em subtarefas, delegando e coordenando. Um trabalhador local no host macOS, alimentado pelo Qwen3.5-27B rodando no Apple Silicon via MLX sem custo, serve como as mãos para ler arquivos, escrever código, executar testes e depurar. Isso mantém o ruído de ida e volta no contexto do trabalhador, com o cérebro vendo apenas resultados finais como "tarefa concluída, aqui estão os arquivos que mudaram".

Estratégia de Compressão

Mesmo com a divisão cérebro/trabalhador, o contexto do orquestrador ainda se enche com documentos operacionais: AGENTES (~6,6 mil tokens), ALMA (~1,5 mil tokens), LIÇÕES (~10 mil tokens) e planos/instruções (~13 mil tokens em disco), totalizando 20 mil a 30 mil tokens antes de qualquer trabalho começar. As sessões podem chegar a 100 mil a 200 mil tokens.

A percepção chave: trabalho concluído não precisa de detalhes brutos. Uma vez que uma subtarefa é finalizada, seu histórico bruto se torna peso morto. O agente só precisa saber: qual era a tarefa, se teve sucesso, quais arquivos mudaram e quaisquer erros.

Detalhes de Implementação

Passo 1: Detectar limites do ciclo de vida - O orquestrador decompõe o trabalho em subtarefas com ciclos de vida: Gerar (o agente chama sessions_spawn ou delegate_task), Executar (chamadas de ferramentas, raciocínio) e Concluir (Mensagem do Sistema "subagente 'nome_da_tarefa' concluído"). Um scanner de 4 passagens percorre o JSONL da sessão:

• Passagem 1: Encontrar eventos de geração
• Passagem 2: Encontrar erros de geração
• Passagem 3: Encontrar marcadores de conclusão
• Passagem 4: Calcular contagem de tokens e duração por ciclo de vida

Isso identifica intervalos de mensagens pertencentes a subtarefas concluídas.

Passo 2: Resumir na "linguagem do agente" (mascaramento) - Os resumos são gerados para parecerem saídas normais do agente, mantendo compatibilidade com o formato de mensagem esperado pelo orquestrador (funções, blocos de conteúdo, estruturas de chamadas de ferramentas, cadeias de IDs pai-filho). Esses resumos mascarados substituem o histórico bruto da tarefa.

Exemplo de resumo compactado de tarefa:

── TAREFA COMPACTADA ──
origem: agente
tarefa: Implementar tempo limite de inatividade para servidor MLX
resultado: sucesso
conclusão: Adicionado temporizador de 5 minutos de inatividade ao MlxServerManager.
O servidor descarrega automaticamente quando nenhuma solicitação é recebida.
arquivos+: src/services/mlx_idle_monitor.py
arquivos~: src/services/mlx_server.py, config.json
erros: nenhum
tentou_e_falhou: threading.Timer — condição de corrida
deve_lembrar: O servidor MLX deve recarregar apenas sob solicitação explícita do trabalhador, não em qualquer chamada de ferramenta
─────────────────

Este resumo de ~100 tokens substitui 5 mil tokens de chamadas de ferramentas brutas e raciocínio (redução de 99,2%). Os resumos são gerados por um LLM barato (Gemini Flash Lite ou MLX local), com mecanismos de fallback se a geração falhar.