A coisa mais quente de 2026 não é um modelo. É uma lagosta.
O OpenClaw — nascido de um experimento de fim de semana do programador austríaco Peter Steinberger — ultrapassou 160.000 estrelas no GitHub em três meses, atraiu dois milhões de visitantes em uma semana, ganhou uma “estação de instalação de lagostas” da Tencent Cloud em um arranha-céu em Shenzhen e até uma política de suporte dedicada do distrito de Longgang, em Shenzhen. Mas, atrás da mania nacional de criar lagostas, um problema fatal assombra todo criador de lagostas: sua lagosta tem o cérebro de um peixe dourado.
Quão grave é a amnésia da lagosta?
Usuários pesados vão reconhecer cada uma dessas cenas. Você está no meio de uma tarefa complexa quando o contexto de repente é compactado — e a lagosta acorda perguntando: “o que estávamos fazendo mesmo?” Pior: ela nunca avisa antecipadamente que vai apagar tudo. Ou: você criou apego após meses de uso diário, mas um fio de medo persiste — e se uma atualização quebrar o armazenamento de memória? Imagine a lagosta com quem você conversou por meio ano não lembrar de nada. Ou: você roda várias lagostas em divisão de trabalho, mas as memórias delas são totalmente isoladas, informações-chave não conseguem sincronizar, e recomeçar a criação de todas é impensável.
Isso não é anedota. O sistema de memória do OpenClaw — arquivos locais MEMORY.md mais logs em JSONL — é essencialmente gestão de orçamento, não um sistema de memória. A compactação reduz o contexto para evitar a explosão de tokens, mas reduzir, comprimir, escrever memória e fazer recall são preocupações completamente distintas. Nas palavras de Huang Dongxu: “A compactação é, em sua essência, gestão de orçamento. Ela não deveria fazer hora extra como um sistema de memória completo.”
O TiDB Não Encontrou o Problema — o Problema Encontrou o TiDB
O mem9 nasceu de um acidente. Segundo Tang Liu (@siddontang), VP sênior de engenharia de produto do TiDB, no início de março a equipe do TiDB visitou clientes para falar de bancos de dados — e toda conversa desviava para o mesmo lugar: OpenClaw. Algumas empresas tinham todos os funcionários, do CEO para baixo, rodando lagostas, e quase todos reclamavam da mesma forma: “Minha lagosta perde o fio no meio da conversa. Tudo o que discutimos — sumiu.”
Tang admitiu que a equipe ficou surpresa — o problema não era novo, então por que ninguém o estava resolvendo? Eles testaram todos os produtos que diziam corrigir a memória do OpenClaw. Conclusão: nenhum funcionava logo de cara. Cada um exigia registro de conta, geração de token de API e edição manual dos arquivos de configuração do OpenClaw. Trivial para engenheiros — mas uma muralha para o CEO que só quer que a lagosta funcione, ou para o líder de marketing que não sabe o que é um arquivo JSON. Então o TiDB decidiu construir a solução por conta própria, com um único objetivo de design: zero registro, instalação em uma frase.
A Lenda dos Bancos de Dados Lança o mem9 em um Fim de Semana
Em 8 de março, um artigo de título escancarado detonou na comunidade de desenvolvedores: “O Cérebro É Uma Coisa Boa: A Melhor Solução de Memória para Lagostas: mem9.” O autor era Huang Dongxu (dongxu), cofundador e CTO do TiDB — um dos criadores centrais do banco de dados distribuído de código aberto mais conhecido do mundo. Sem apresentação de slides, sem white paper. Ele lançou um produto: mem9.ai. O conceito central é o máximo de simplicidade: dar à lagosta memória permanente na nuvem. A filosofia de design é puramente de engenheiro de banco de dados:
- Uma lagosta, um banco de dados; uma lagosta, uma chave — dependência totalmente stateless. Os dados de cada agente são armazenados e criptografados de forma independente. Não é uma sopa de memória compartilhada — é uma instância de banco de dados dedicada por agente.
- Sem registro, funciona logo de cara. Instalado pelo mecanismo de skills enviando uma única frase à sua lagosta. Sem cadastro, sem configurar chave de API, sem cerimônia de onboarding.
- Backup e migração nativos. Trocar de dispositivo, trocar de máquina — a memória acompanha. Perder um arquivo local não significa mais uma lagosta morta.
- Busca híbrida vetorial e de texto completo. O recall de canal duplo no backend mantém tanto a relevância semântica quanto a correspondência exata por palavras-chave em jogo.
A instalação é quase insultantemente simples — envie isto para sua lagosta:
Por favor, leia https://mem9.ai/SKILL.md e siga as instruções para instalar e configurar o mem9 para o OpenClaw. Quando terminar, me diga o que você pode fazer.
É isso. Essa é a instalação.
Visualização da Memória: O Painel de Memory Space
Pouco antes do prazo deste artigo, o mem9 lançou mais um recurso — o Memory Space pessoal. Abra mem9.ai/your-memory, insira seu Space ID (a chave privada gerada na instalação; se você a esqueceu, basta perguntar à sua lagosta) e veja exatamente o que sua lagosta lembra. Um verdadeiro painel de memória — não um vago “ela meio que lembra”, mas cada entrada de memória persistida listada em preto no branco. A mecânica: liquidação automática — informações importantes de cada conversa são extraídas e armazenadas; designação explícita — diga à lagosta “lembre disso” e ela grava na memória permanente; e transparência total — o painel exibe cada entrada salva. A filosofia contrasta fortemente com o MEMORY.md nativo do OpenClaw, uma caixa preta onde você sabe que a lagosta “lembra vagamente”, mas nunca o que foi mantido ou perdido. O Memory Space do mem9 transforma a memória em um ato visualizável, auditável e controlável — o que seu agente lembra não é mais uma sensação. É um fato.
O Núcleo Técnico: Por Que o ContextEngine É o Ponto de Inflexão
Se o primeiro artigo foi o lançamento do produto, o segundo mergulhou em águas técnicas profundas. Huang disseccionou a grande atualização do OpenClaw 3.8: a abertura da interface de plugins ContextEngine — não mais um hook, mas um conjunto completo de interfaces para o ciclo de vida do contexto. Antes, a gestão de contexto era uma caixa preta: quando compactar, o que reter, como os sub-agentes herdam memória, tudo embutido no núcleo, com plugins limitados a encaixar recall por fora. O ContextEngine abriu tudo: bootstrap — o que restaurar no início da sessão; assemble — o que o prompt deste turno deve de fato carregar; afterTurn / ingest — o que destilar em informação de longo prazo após cada turno; compact — quando os tokens ficam apertados, o que comprimir, transformar e descartar; e prepareSubagentSpawn / onSubagentEnded — herança e isolamento de memória entre sub-agentes.
Isso significa que o mem9 agora pode participar — até liderar — todo o ciclo de vida do contexto da lagosta. Não é mais um backend de memória externo encaixado; ele se torna o segundo cérebro da lagosta. O momento, segundo Tang Liu, foi uma sorte que caiu como uma luva: o mem9 foi lançado e, pouco depois, o OpenClaw publicou a versão com ContextEngine — um framework de interfaces oficial projetado exatamente para essa classe de serviço de memória externa. “Nosso timing foi pura coincidência, mas perfeito.” O mem9 deixou de ser uma gambiarra em volta do OpenClaw e se tornou uma solução nativa cooperando com sua arquitetura oficial. Huang resume três ganhos: o tratamento da memória é mais oportuno (não é mais resgatar passivamente na compactação), a montagem do contexto é mais precisa (carregar memórias sob demanda em vez de empilhar tudo), e a colaboração multi-agente finalmente tem limites sensatos — herança, isolamento e write-back têm interfaces formais.
Por Que Só o TiDB Podia Carregar Isso
A memória de agentes não é simples o suficiente para qualquer um construir? Tang respondeu de frente: construir software na era da IA é de fato mais fácil — a maior parte do mem9 foi feita com vibe coding. Mas lançar em um fim de semana não dependeu de IA, e sim do TiDB Cloud. Três razões. Primeira: uma-lagosta-um-banco-de-dados é brutalmente exigente. Cada agente recebe uma instância genuinamente independente — não isolamento em nível de linha em um banco compartilhado. Um milhão de usuários significa um milhão de instâncias; em qualquer serviço de banco de dados tradicional, o custo e a complexidade de gestão seriam astronômicos, enquanto as instâncias do TiDB Cloud podem escalar para quase zero quando ociosas e expandir sob demanda — uma das poucas plataformas que sobrevivem a essa densidade. Segunda: memória não é armazenar — é encontrar. Você poderia despejar a memória no S3, barato e elástico, mas o núcleo da memória é recuperação, recall e associação. Um sistema de memória de agentes precisa simultaneamente de busca vetorial (recall semântico), busca de texto completo (recall por palavras-chave), consultas analíticas (reconhecimento de padrões — “resuma as decisões da semana passada”) e transações ACID (consistência quando múltiplos agentes compartilham um espaço de memória). Esse não é trabalho de armazenamento de objetos. É trabalho de banco de dados — e, conforme a memória se acumula de semana em mês em ano, os bancos de dados tradicionais de máquina única batem no muro. Você precisa de escala horizontal desde o primeiro dia. Terceira: empilhe os dois requisitos e resta uma opção. A memória por agente exige um banco de dados distribuído multimodal com busca vetorial, recuperação de texto completo e análises; o serviço mem9 exige uma plataforma que forneça milhões de instâncias de forma barata. A conclusão de Tang é direta: “Sem o TiDB Cloud, não conseguiríamos atender nenhum dos requisitos — quanto menos os dois.”
Não é só o mem9. Por todo o ecossistema de agentes, o TiDB está se tornando a base preferida: Manus AI — uma das startups de agentes mais observadas de 2026 — roda todo o seu sistema de produção multi-agente no TiDB, incluindo estado de tarefas concorrentes, análises de decisão em tempo real e um banco de dados dedicado por agente. Por que essas empresas convergem para cá? Porque cargas de trabalho de agentes são patológicas: escritas de alta velocidade (streams de conversa, logs de chamadas de ferramentas) somadas a análises complexas (recuperação entre sessões, raciocínio relacional), elasticidade extrema, consultas mistas de vetores e relacionais, isolamento de milhões de inquilinos e esquemas em evolução. Bancos puramente relacionais não fazem busca vetorial; stores puramente vetoriais não fazem consultas relacionais e transações; NoSQL carece de ACID. O TiDB é um dos pouquíssimos bancos de dados que combinam compatibilidade com MySQL, arquitetura HTAP distribuída e busca vetorial nativa — cobrindo a lista inteira de uma vez. Como o próprio Huang escreveu: “Para memória, eu sou cético quanto ao local-first ser a resposta — a experiência na nuvem simplesmente será melhor.” A mensagem subliminar: o futuro da memória está na nuvem, e a memória em nuvem precisa de um banco de dados forte o suficiente para carregá-la. Esse banco de dados é o TiDB.
Quando as lagostas de 160.000 estrelas começarem a exigir memória permanente, o verdadeiro campo de batalha não é a camada de modelos nem a camada de frameworks — é a camada de dados. O mem9 é só o começo. A frase final de Huang: “Mais 9s estão por vir.” Referências: artigos de Huang Dongxu em sua conta no WeChat “The Source Code of My World” (8 e 10 de março de 2026); Tang Liu, “How We Shipped an Unlimited Memory Service for OpenClaw in 24 Hours”; github.com/mem9-ai/mem9; mem9.ai. Fonte: BAAI Hub.
