Usar um modelo menor como camada de higiene de tempo de execução melhora a confiabilidade do agente OpenClaw

Problema: Saídas descuidadas degradam agentes de longa duração

Ao executar o OpenClaw localmente em um Mac Studio M4 (36GB) com Qwen 3.5 27B (4-bit, oMLX) como agente doméstico, o modelo não se tornou menos capaz ao longo do tempo—ele se tornou descuidado. Problemas específicos incluíam:

• Chamadas de ferramentas vazando como texto bruto em vez de uso estruturado de ferramentas
• Pensamentos de planejamento vazando para respostas finais
• Repetição de resultados de ferramentas e texto de política de volta para o usuário
• Saídas malformadas envenenando o contexto, causando degradação com cada turno subsequente

O problema central não era capacidade, mas higiene em tempo de execução: o modelo sabia o que fazer, mas falhava no comportamento adequado dentro do ambiente de execução do OpenClaw.

Solução: Arquitetura de quatro camadas para higiene em tempo de execução

O desenvolvedor implementou uma abordagem de quatro camadas que se mostrou mais eficaz do que simplesmente usar um modelo maior:

• Resumo: Compactação de contexto via lossless-claw (baseado em DAG, freshTailCount=12, contextThreshold=0.60). Isso forneceu a maior melhoria individual.
• Xerife: Verificações de regex e heurísticas que capturam respostas malformadas antes que entrem no OpenClaw. Isso impede que marcação de ferramentas vazada, divagações do planejador e JSON bruto se tornem contexto duradouro.
• Juiz: Um modelo menor e mais barato que classifica saídas limítrofes como "resposta final válida" versus "lixo". Este modelo não é para inteligência, mas para higiene em tempo de execução—é um sistema imunológico em vez de um segundo cérebro. Ele também trata toda a sumarização para o lossless-claw.
• Ozempic (nome interno): Limpeza agressiva de memória que garante que o modelo releia apenas solicitações do usuário, respostas finais e fatos compactos derivados de ferramentas em turnos futuros—não divagações do planejador, JSON bruto de ferramentas, artefatos de repetição ou auto-diálogo de política.

Por que isso supera usar um modelo maior

Um único modelo deve simultaneamente resolver tarefas, manter disciplina de formatação, gerenciar coerência de contexto, evitar envenenar-se com suas próprias saídas e recuperar-se de saídas ruins—especialmente desafiador em níveis de quantização local. Dividir responsabilidades para que o modelo principal faça o trabalho enquanto um modelo menor mantém a higiene em tempo de execução provou ser mais eficaz do que adicionar mais parâmetros.

Resultado: Operação sustentada sem redefinições

A abordagem passou de necessitar redefinições /new a cada 20-30 minutos para operação sustentada em sessão única em um Mac Studio M4 com 36GB de RAM, totalmente local sem chamadas de API.