A Gestão de Contexto do OpenClaw é Criticada por ser Consumidora de Tokens e com Falhas Arquitetônicas

Um usuário do Reddit postou uma crítica detalhada à arquitetura do OpenClaw, visando especificamente sua abordagem de gerenciamento de contexto. A postagem argumenta que o framework lida com o estado de forma ineficiente, tratando a janela de contexto do LLM como um "aterro sanitário" por meio de despejos de contexto preguiçosos e do tipo tudo-ou-nada.

Como o OpenClaw Lida com o Contexto

De acordo com a fonte, o OpenClaw carece de um gerenciamento de estado adequado e de isolamento de estado efêmero. Cada vez que o agente dá um passo, a nova ação é cegamente anexada ao histórico global. Em três turnos, o prompt fica inchado com:

• O prompt do sistema global
• O arquivo completo de memória de longo prazo do usuário
• Uma lista de todas as ferramentas disponíveis
• A saída bruta do último comando
• Todas as ações anteriores

O Problema com Modelos Menores

A postagem descreve o que acontece ao executar o OpenClaw em modelos mais rápidos e baratos, como as variantes Flash ou Mini:

• Modelos menores sofrem da síndrome "perdido no meio" quando se afogam em 50k+ tokens de saídas antigas do terminal, logs de ferramentas e prompts de persona global
• Esses modelos literalmente esquecem o objetivo original
• Eles ou alucinam que a tarefa já está concluída
• Ou ficam presos em um loop infinito chamando exatamente a mesma ferramenta com exatamente os mesmos argumentos

A Dependência do Claude Opus

A crítica se estende à dependência do OpenClaw de modelos de fronteira:

• O OpenClaw afirma que seus agentes são "altamente capazes", mas essa capacidade vem de depender de modelos de fronteira massivos, como o Claude Opus
• O Claude Opus consegue olhar para um "incêndio de lixeira" de 80.000 tokens e ignorar com sucesso 79.500 tokens de lixo histórico inútil para deduzir o próximo passo
• Isso cria a ilusão de que o framework é bem construído, quando na realidade, o Opus está mascarando incompetência arquitetônica
• Os usuários acabam pagando preços de API de nível Opus para ter um LLM de última geração atuando como um "filtro de lixo glorificado" para um contexto mal projetado

Recomendações Arquitetônicas

A postagem defende uma melhor engenharia em vez de força bruta:

• Uma tarefa simples de navegador ou terminal em várias etapas não deveria exigir um modelo de trilhões de parâmetros
• Se projetado corretamente, o loop deveria forçar o modelo a observar o ambiente e alimentá-lo exatamente com o que ele precisa ver agora e absolutamente nada mais
• Essa abordagem poderia alcançar a mesma taxa de sucesso usando uma fração do poder computacional em modelos mais baratos e rápidos