OpenClaw na prática: Gateway, memória e plugins

OpenClaw na prática: Gateway, memória e plugins

Um tour prático pelos componentes centrais do OpenClaw — Gateway, memória, plugins, canais e ferramentas — e como eles se conectam.

Introdução

O OpenClaw é uma plataforma de agentes construída em torno de uma ideia simples: manter o runtime enxuto, empurrar extensibilidade para plugins e tratar memória como preocupação de primeira classe — não como detalhe tardio. Se você está avaliando o sistema para um assistente de time, um agente pessoal ou um bot interno de operações, o caminho mais rápido para entender a arquitetura é seguir uma mensagem desde o canal, passando pelo Gateway, entrando na memória e voltando pelas ferramentas.


Desenvolvimento

O Gateway — plano de controle

O Gateway é o processo central que hospeda o runtime do agente. Ele carrega configuração, inicia plugins, expõe rotas HTTP registradas por extensões e coordena handlers RPC para canais e serviços. Pense nele como plano de controle: não tenta implementar toda integração sozinho, mas dono do ciclo de vida — startup, saúde, roteamento e shutdown — para que plugins foquem em comportamento. Quando a documentação fala em “Gateway startup” ou “Gateway HTTP routes”, está descrevendo esse hub onde canais se conectam e o trabalho do agente de fato acontece.

Memória — Markdown como fonte da verdade

A memória no OpenClaw é propositalmente simples na origem e inteligente na recuperação. O modelo padrão guarda fatos duráveis em MEMORY.md e anotações diárias em memory/YYYY-MM-DD.md. Markdown em disco é a fonte da verdade; o agente só lembra o que foi escrito. Sobre esses arquivos, o plugin de memória ativo (geralmente memory-core) monta um índice pesquisável — SQLite por padrão, com opção vetorial ou LanceDB via plugins como memory-lancedb. Ferramentas como memory_search e memory_get permitem recuperar contexto semanticamente, sem encher o prompt inteiro a cada turno.

Exemplo de entrada em MEMORY.md:

## Infraestrutura
- Blog KaiporaLabs: Hugo + Dokku
- Deploy: git push dokku main

Slots de plugin — memória substituível

Os slots de plugin tornam a memória substituível. Definir plugins.slots.memory escolhe qual plugin controla recall e captura em cada deploy. Um slot fica ativo por vez, o que mantém comportamento previsível: você pode usar indexação Markdown embutida por simplicidade, ou LanceDB quando precisa de recall vetorial local com embeddings. Plugins complementares ainda estendem o sistema, mas apenas um provedor deve controlar o loop de memória ativa que roda antes de cada resposta do modelo.

Exemplo de configuração:

{
  "plugins": {
    "slots": {
      "memory": "memory-core",
      "contextEngine": "default"
    }
  }
}

Arquitetura de plugins

Além da memória, a arquitetura de plugins do OpenClaw registra canais, ferramentas, hooks, comandos CLI, providers e serviços em background por uma API padronizada. Canais conectam o agente a Slack, Telegram, web ou transportes customizados. Ferramentas expõem capacidades como edição de arquivos, chamadas HTTP ou ações de domínio. Hooks permitem observar e modificar eventos do ciclo de vida — início de sessão, mensagem recebida, compactação — sem fork do core. Essa modularidade explica por que times conseguem entregar plugin privado de canal ou hook de compliance sem mexer no Gateway.

Context engine e memória ativa

Dois outros blocos completam o modelo mental. Plugins de context engine (selecionados via plugins.slots.contextEngine) podem substituir ou estender como o contexto de sessão é montado, ingerido e compactado — útil para sumarização customizada ou regras corporativas de retenção. E a memória ativa roda como passo bloqueante antes das respostas, injetando os trechos mais relevantes para o modelo começar cada turno ancorado em decisões, preferências e fatos anteriores. Juntos, Gateway + memória + plugins formam uma stack composável: conecte um canal, escolha backend de memória, defina allowlist de ferramentas e evolua hooks conforme a necessidade.

Primeiros passos locais

Se você está começando localmente, leia openclaw.json como mapa: configurações do Gateway, entradas de plugins, slots e namespaces de config por plugin.

# Estrutura típica
ls ~/.openclaw/
cat ~/.openclaw/openclaw.json
cat ~/.openclaw/MEMORY.md

Adoção incremental recomendada:

  1. Gateway + um canal (ex.: Telegram)
  2. Memória Markdown (memory-core)
  3. Allowlist mínima de ferramentas
  4. Só então plugins extras (LanceDB, hooks custom)

Conclusão

O OpenClaw recompensa adoção incremental — exatamente o que você quer quando um agente toca sistemas de produção. Mude um slot por vez, observe qualidade de recall e só então expanda canais e ferramentas.

Próximo passo: se você quer um agente com loop de aprendizado e TUI integrada, leia nosso tutorial sobre Hermes Agent — inclui migração oficial a partir do OpenClaw com hermes claw migrate.