13 Semanas com OpenClaw como Motorista Diário: O que Funcionou, o que Quebrou, o que Ainda Dói

Após 13 semanas executando o OpenClaw como seu sistema de agente pessoal principal em um Raspberry Pi — lidando com chat do Telegram, memória de longo prazo, tarefas cron, subagentes, fluxos de pesquisa e APIs externas — um usuário do r/openclaw postou um resumo detalhado. O veredito: o OpenClaw é poderoso o suficiente para ser tratado como infraestrutura, mas ainda é bruto o suficiente para exigir paciência, logs, backups e disposição para depurar casos extremos estranhos.

O Que Funcionou Bem

• Camadas de fluxo de trabalho. O agente fica entre mensagens, arquivos, crons, APIs, memória e ferramentas. O sistema cron é genuinamente útil — tarefas recorrentes coletam, processam, resumem, notificam e acionam fluxos de acompanhamento. Depois de ajustados, eles se tornam entediantes no bom sentido.
• Memória — se selecionada. O OpenClaw pode lembrar decisões, estado do projeto, preferências, erros e correções anteriores. Mas deixar cada fragmento bruto entrar na memória de longo prazo a transforma em lodo. Com limpeza e arquivos de memória específicos do projeto, torna-se uma camada operacional real.
• Subagentes para tarefas delimitadas. Padrão mais útil: humano decide a direção, agente principal coordena, subagentes fazem análise ou implementação delimitada, agente principal verifica. Menos útil quando o contexto é vago ou o roteamento de modelo/configuração não é explícito.
• Continuidade. O maior sucesso não é um recurso — é que o sistema agora lida com memória operacional, verificações agendadas, análise recorrente, depuração técnica, revisões de configuração, pequenas alterações de código e acompanhamento estruturado diariamente.

O Que Quebrou ou Incomodou

• Problemas de modelo/configuração. No início, configurações de modelo local/pequeno (ex.: contexto de 4k) não conseguiam lidar com o prompt do sistema do OpenClaw mais ferramentas. Erros de "Falha na vez do assistente" geralmente eram rastreados até problemas de chave de API/configuração, não de RAM.
• Lacuna de interação entre cron e subagente. Fluxos de trabalho agendados geravam um subagente que fazia o trabalho corretamente, mas o pai não conseguia ler a saída do filho porque o histórico entre agentes estava desabilitado. Solução: redesenhar para que o filho escreva os resultados diretamente (write --file) em vez de depender da leitura do pai.
• Escaping de shell. Passar JSON por comandos do shell quebrava em apóstrofos e aspas aninhadas. Solução: escrever JSON em um arquivo temporário e passar --file.
• Desvio de atualização. As atualizações do OpenClaw melhoraram o desempenho de inicialização e a pressão de memória no Pi, mas os dias de atualização exigiam cautela — desvio de configuração, desvio de comando ACP, desvio de documentação. Tinha que verificar o que realmente mudou em vez de confiar que estava tudo bem.
• Sobrescrita de modelo de subagente. Os padrões nem sempre eram respeitados; agora passa IDs de modelo/agente explicitamente.
• Não confiabilidade do ACP. O Claude ACP via OpenClaw falhava com erros internos de tempo de execução; caminhos diretos ACP/CLI funcionavam.
• Higiene de segredos/configuração. O OpenClaw suporta SecretRefs estruturados, mas arquivos antigos de configuração/perfil de autenticação ainda podem conter segredos em texto puro. Migrar com segurança requer backups, verificações de esquema e planejamento de reversão.
• Pressão de recursos no Pi. Processos de longa duração do Claude/Codex, crons e artefatos de memória se acumulam. Adicionou rotinas de limpeza; arquivou um projeto morto que havia crescido para ~1,6 GB de inchaço regenerável.

Para Quem É

Desenvolvedores executando o OpenClaw como sistema de agente pessoal — especialmente em hardware limitado — que desejam um relato realista dos pontos problemáticos do mundo real e soluções práticas.