Wiki de memória - OpenClaw

memory-wiki é um Plugin incluído que transforma memória durável em um cofre de conhecimento compilado. Ele não substitui o Plugin de memória ativa. O Plugin de memória ativa ainda controla recuperação, promoção, indexação e Dreaming. memory-wiki fica ao lado dele e compila conhecimento durável em uma wiki navegável com páginas determinísticas, declarações estruturadas, proveniência, dashboards e resumos legíveis por máquina. Use-o quando quiser que a memória se comporte mais como uma camada de conhecimento mantida e menos como uma pilha de arquivos Markdown.

O que ele adiciona

Um cofre wiki dedicado com layout de página determinístico
Metadados estruturados de declaração e evidência, não apenas prosa
Proveniência, confiança, contradições e perguntas em aberto no nível da página
Resumos compilados para consumidores de agente/runtime
Ferramentas nativas da wiki para busca/obtenção/aplicação/lint
Importações do Open Knowledge Format em conceitos wiki compilados
Modo de ponte opcional que importa artefatos públicos do Plugin de memória ativa
Modo de renderização compatível com Obsidian e integração com CLI opcionais

Como ele se encaixa com a memória

Pense na divisão assim:

Camada	Controla
Plugin de memória ativa (`memory-core`, QMD, Honcho etc.)	Recuperação, busca semântica, promoção, Dreaming, runtime de memória
`memory-wiki`	Páginas wiki compiladas, sínteses ricas em proveniência, dashboards, busca/obtenção/aplicação específicas da wiki

Se o Plugin de memória ativa expuser artefatos compartilhados de recuperação, o OpenClaw poderá pesquisar as duas camadas em uma única passagem com memory_search corpus=all. Quando você precisar de ranqueamento específico da wiki, proveniência ou acesso direto à página, use as ferramentas nativas da wiki.

Padrão híbrido recomendado

Um bom padrão para configurações local-first é:

QMD como backend de memória ativa para recuperação e busca semântica ampla
memory-wiki em modo bridge para páginas de conhecimento sintetizado durável

Essa divisão funciona bem porque cada camada permanece focada:

QMD mantém notas brutas, exportações de sessão e coleções extras pesquisáveis
memory-wiki compila entidades estáveis, declarações, dashboards e páginas de origem

Regra prática:

use memory_search quando quiser uma passagem ampla de recuperação pela memória
use wiki_search e wiki_get quando quiser resultados wiki cientes de proveniência
use memory_search corpus=all quando quiser que a busca compartilhada abranja as duas camadas

Se o modo de ponte relatar zero artefatos exportados, o Plugin de memória ativa ainda não está expondo entradas públicas de ponte no momento. Execute openclaw wiki doctor primeiro e depois confirme se o Plugin de memória ativa oferece suporte a artefatos públicos. Quando o modo de ponte está ativo e bridge.readMemoryArtifacts está habilitado, openclaw wiki status, openclaw wiki doctor e openclaw wiki bridge import leem por meio do Gateway em execução. Isso mantém as verificações de ponte da CLI alinhadas com o contexto do Plugin de memória em runtime. Se a ponte estiver desabilitada ou as leituras de artefatos estiverem desativadas, esses comandos mantêm seu comportamento local/offline.

Modos de cofre

memory-wiki oferece suporte a três modos de cofre:

`isolated`

Cofre próprio, fontes próprias, sem dependência de memory-core. Use isto quando quiser que a wiki seja seu próprio repositório de conhecimento curado.

`bridge`

Lê artefatos públicos de memória e eventos de memória do Plugin de memória ativa por meio de interfaces públicas do SDK de Plugins. Use isto quando quiser que a wiki compile e organize os artefatos exportados do Plugin de memória sem acessar partes internas privadas do Plugin. O modo de ponte pode indexar:

artefatos de memória exportados
relatórios de Dreaming
notas diárias
arquivos raiz de memória
logs de eventos de memória

`unsafe-local`

Escape hatch explícito para caminhos privados locais na mesma máquina. Este modo é intencionalmente experimental e não portátil. Use-o apenas quando você entender o limite de confiança e precisar especificamente de acesso ao sistema de arquivos local que o modo de ponte não consegue fornecer.

Layout do cofre

O Plugin inicializa um cofre assim:

<vault>/
  AGENTS.md
  WIKI.md
  index.md
  inbox.md
  entities/
  concepts/
  syntheses/
  sources/
  reports/
  _attachments/
  _views/
  .openclaw-wiki/

O conteúdo gerenciado permanece dentro de blocos gerados. Blocos de notas humanas são preservados. Os principais grupos de páginas são:

sources/ para material bruto importado e páginas apoiadas pela ponte
entities/ para coisas, pessoas, sistemas, projetos e objetos duráveis
concepts/ para ideias, abstrações, padrões e políticas
syntheses/ para resumos compilados e rollups mantidos
reports/ para dashboards gerados

Importações do Open Knowledge Format

memory-wiki pode importar pacotes Open Knowledge Format desempacotados com:

openclaw wiki okf import ./bundles/ga4

Esse é o encaixe mais limpo quando um catálogo de dados, crawler de documentação ou agente de enriquecimento já produz OKF: mantenha o OKF como artefato portátil de troca e deixe memory-wiki transformá-lo em páginas de conceito nativas do OpenClaw e resumos compilados. O importador segue o formato OKF v0.1:

arquivos .md não reservados são documentos de conceito
cada conceito importado precisa de um campo de frontmatter type não vazio
valores OKF type desconhecidos são aceitos
arquivos reservados index.md e log.md não são importados como conceitos
links Markdown quebrados ou externos são preservados

As páginas de conceito importadas são achatadas em concepts/ para que os caminhos existentes de compilação, busca, obtenção, dashboard e resumo de prompt as vejam sem adicionar uma segunda árvore wiki. Cada página mantém o ID de conceito OKF original, caminho de origem, type, resource, tags, timestamp e todo o frontmatter do produtor. Links OKF internos são reescritos para as páginas de conceito wiki geradas e também emitidos como entradas estruturadas de relationships com kind: okf-link.

Declarações e evidências estruturadas

As páginas podem carregar frontmatter estruturado de claims, não apenas texto livre. Cada declaração pode incluir:

id
text
status
confidence
evidence[]
updatedAt

Entradas de evidência podem incluir:

kind
sourceId
path
lines
weight
confidence
privacyTier
note
updatedAt

É isso que faz a wiki agir mais como uma camada de crenças do que como um depósito passivo de notas. Declarações podem ser rastreadas, pontuadas, contestadas e resolvidas de volta às fontes.

Metadados de entidade voltados ao agente

Páginas de entidade também podem carregar metadados de roteamento para uso por agentes. Este é frontmatter genérico, então funciona para pessoas, equipes, sistemas, projetos ou qualquer outro tipo de entidade. Campos comuns incluem:

entityType: por exemplo person, team, system ou project
canonicalId: chave de identidade estável usada entre aliases e importações
aliases: nomes, handles ou rótulos que devem resolver para a mesma página
privacyTier: public, local-private, sensitive ou confirm-before-use
bestUsedFor / notEnoughFor: dicas compactas de roteamento
lastRefreshedAt: timestamp de atualização de fonte separado do horário de edição da página
personCard: cartão de roteamento opcional específico de pessoa com handles, redes sociais, e-mails, fuso horário, trilha, pedir sobre, evitar pedir sobre, confiança e privacidade
relationships: arestas tipadas para páginas relacionadas com alvo, tipo, peso, confiança, tipo de evidência, camada de privacidade e nota

Para uma wiki de pessoas, o agente geralmente deve começar por reports/person-agent-directory.md e depois abrir a página da pessoa com wiki_get antes de usar detalhes de contato ou fatos inferidos. Exemplo:

pageType: entity
entityType: person
id: entity.brad-groux
canonicalId: maintainer.brad-groux
aliases:
  - Brad
  - bgroux
privacyTier: local-private
bestUsedFor:
  - Microsoft Teams and Azure routing
notEnoughFor:
  - legal approval
lastRefreshedAt: "2026-04-29T00:00:00.000Z"
personCard:
  handles:
    - "@bgroux"
  socials:
    - "https://x.example/bgroux"
  emails:
    - brad@example.com
  timezone: America/Chicago
  lane: Microsoft ecosystem
  askFor:
    - Teams rollout questions
  avoidAskingFor:
    - unrelated billing decisions
  confidence: 0.8
  privacyTier: confirm-before-use
relationships:
  - targetId: entity.alice
    targetTitle: Alice
    kind: collaborates-with
    confidence: 0.7
    evidenceKind: discrawl-stat
claims:
  - id: claim.brad.teams
    text: Brad is useful for Microsoft Teams routing.
    status: supported
    confidence: 0.9
    evidence:
      - kind: maintainer-whois
        sourceId: source.maintainers
        privacyTier: local-private

Pipeline de compilação

A etapa de compilação lê páginas wiki, normaliza resumos e emite artefatos estáveis voltados a máquina em:

.openclaw-wiki/cache/agent-digest.json
.openclaw-wiki/cache/claims.jsonl

Esses resumos existem para que agentes e código de runtime não precisem raspar páginas Markdown. A saída compilada também alimenta:

indexação wiki de primeira passagem para fluxos de busca/obtenção
lookup de ID de declaração de volta para as páginas proprietárias
suplementos compactos de prompt
geração de relatórios/dashboards

Dashboards e relatórios de saúde

Quando render.createDashboards está habilitado, a compilação mantém dashboards em reports/. Relatórios incorporados incluem:

reports/open-questions.md
reports/contradictions.md
reports/low-confidence.md
reports/claim-health.md
reports/stale-pages.md
reports/person-agent-directory.md
reports/relationship-graph.md
reports/provenance-coverage.md
reports/privacy-review.md

Esses relatórios acompanham coisas como:

clusters de notas de contradição
clusters de declarações concorrentes
declarações sem evidência estruturada
páginas e declarações de baixa confiança
frescor obsoleto ou desconhecido
páginas com perguntas não resolvidas
cartões de roteamento de pessoa/entidade
arestas de relacionamento estruturadas
cobertura de classes de evidência
camadas de privacidade não públicas que precisam de revisão antes do uso

Busca e recuperação

memory-wiki oferece suporte a dois backends de busca:

shared: usa o fluxo de busca de memória compartilhada quando disponível
local: pesquisa a wiki localmente

Ele também oferece suporte a três corpora:

wiki
memory
all

Comportamento importante:

wiki_search e wiki_get usam resumos compilados como primeira passagem quando possível
IDs de declaração podem resolver de volta para a página proprietária
declarações contestadas/obsoletas/recentes influenciam o ranqueamento
rótulos de proveniência podem sobreviver nos resultados
o modo de busca pode favorecer o ranqueamento para lookup de pessoas, roteamento de perguntas, evidência de fontes ou declarações brutas

Regra prática:

use memory_search corpus=all para uma passagem ampla de recuperação
use wiki_search + wiki_get quando você se importar com ranqueamento específico da wiki, proveniência ou estrutura de crença no nível da página

Modos de busca:

auto: padrão equilibrado
find-person: impulsiona entidades parecidas com pessoas, aliases, handles, redes sociais e IDs canônicos
route-question: impulsiona cartões de agente, dicas de pedir sobre, dicas de melhor uso e contexto de relacionamento
source-evidence: impulsiona páginas de origem e metadados de evidência estruturada
raw-claim: impulsiona declarações estruturadas correspondentes e retorna metadados de declaração/evidência nos resultados

Quando um resultado corresponde a uma declaração estruturada, wiki_search pode retornar matchedClaimId, matchedClaimStatus, matchedClaimConfidence, evidenceKinds e evidenceSourceIds em seu payload de detalhes. A saída em texto também inclui linhas compactas Claim: e Evidence: quando disponíveis.

Ferramentas do agente

O Plugin registra estas ferramentas:

wiki_status
wiki_search
wiki_get
wiki_apply
wiki_lint

O que elas fazem:

wiki_status: modo de cofre atual, saúde, disponibilidade da CLI do Obsidian
wiki_search: pesquisa páginas wiki e, quando configurado, corpora de memória compartilhada; aceita mode para lookup de pessoas, roteamento de perguntas, evidência de fonte ou drilldown de declaração bruta
wiki_get: lê uma página wiki por ID/caminho ou recorre ao corpus de memória compartilhada
wiki_apply: mutações restritas de síntese/metadados sem cirurgia livre de página
wiki_lint: verificações estruturais, lacunas de proveniência, contradições, perguntas em aberto

O plugin também registra um suplemento de corpus de memória não exclusivo, de modo que memory_search e memory_get compartilhados possam acessar a wiki quando o plugin de memória ativa oferecer suporte à seleção de corpus.

Comportamento de prompt e contexto

Quando context.includeCompiledDigestPrompt está habilitado, as seções de prompt de memória anexam um snapshot compilado compacto de agent-digest.json. Esse snapshot é intencionalmente pequeno e de alto sinal:

apenas páginas principais
apenas declarações principais
contagem de contradições
contagem de perguntas
qualificadores de confiança/atualidade

Isso é opcional porque altera o formato do prompt e é útil principalmente para mecanismos de contexto ou montagem de prompts legada que consomem explicitamente suplementos de memória.

Configuração

Coloque a configuração em plugins.entries.memory-wiki.config:

{
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "isolated",
          vault: {
            path: "~/.openclaw/wiki/main",
            renderMode: "obsidian",
          },
          obsidian: {
            enabled: true,
            useOfficialCli: true,
            vaultName: "OpenClaw Wiki",
            openAfterWrites: false,
          },
          bridge: {
            enabled: false,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true,
          },
          ingest: {
            autoCompile: true,
            maxConcurrentJobs: 1,
            allowUrlIngest: true,
          },
          search: {
            backend: "shared",
            corpus: "wiki",
          },
          context: {
            includeCompiledDigestPrompt: false,
          },
          render: {
            preserveHumanBlocks: true,
            createBacklinks: true,
            createDashboards: true,
          },
        },
      },
    },
  },
}

Alternâncias principais:

vaultMode: isolated, bridge, unsafe-local
vault.renderMode: native ou obsidian
bridge.readMemoryArtifacts: importa artefatos públicos do plugin de memória ativa
bridge.followMemoryEvents: inclui logs de eventos no modo bridge
search.backend: shared ou local
search.corpus: wiki, memory ou all
context.includeCompiledDigestPrompt: anexa snapshot compacto do digest às seções de prompt de memória
render.createBacklinks: gera blocos relacionados determinísticos
render.createDashboards: gera páginas de dashboard

Exemplo: QMD + modo bridge

Use isto quando quiser QMD para recuperação e memory-wiki para uma camada de conhecimento mantida:

{
  memory: {
    backend: "qmd",
  },
  plugins: {
    entries: {
      "memory-wiki": {
        enabled: true,
        config: {
          vaultMode: "bridge",
          bridge: {
            enabled: true,
            readMemoryArtifacts: true,
            indexDreamReports: true,
            indexDailyNotes: true,
            indexMemoryRoot: true,
            followMemoryEvents: true,
          },
          search: {
            backend: "shared",
            corpus: "all",
          },
          context: {
            includeCompiledDigestPrompt: false,
          },
        },
      },
    },
  },
}

Isso mantém:

QMD responsável pela recuperação de memória ativa
memory-wiki focado em páginas compiladas e dashboards
formato do prompt inalterado até que você habilite intencionalmente prompts de digest compilado

CLI

memory-wiki também expõe uma superfície de CLI de nível superior:

openclaw wiki status
openclaw wiki doctor
openclaw wiki init
openclaw wiki ingest ./notes/alpha.md
openclaw wiki compile
openclaw wiki lint
openclaw wiki search "alpha"
openclaw wiki get entity.alpha
openclaw wiki apply synthesis "Alpha Summary" --body "..." --source-id source.alpha
openclaw wiki bridge import
openclaw wiki obsidian status

Consulte CLI: wiki para a referência completa de comandos.

Suporte ao Obsidian

Quando vault.renderMode é obsidian, o plugin grava Markdown compatível com Obsidian e pode usar opcionalmente a CLI oficial obsidian. Os fluxos de trabalho compatíveis incluem:

sondagem de status
pesquisa no vault
abertura de uma página
invocação de um comando do Obsidian
salto para a nota diária

Isso é opcional. A wiki ainda funciona em modo nativo sem Obsidian.

Fluxo de trabalho recomendado

Mantenha seu plugin de memória ativa para recuperação/promoção/dreaming.
Habilite memory-wiki.
Comece com o modo isolated, a menos que você queira explicitamente o modo bridge.
Use wiki_search / wiki_get quando a proveniência importar.
Use wiki_apply para sínteses restritas ou atualizações de metadados.
Execute wiki_lint após alterações significativas.
Ative dashboards se quiser visibilidade de itens obsoletos/contradições.

​O que ele adiciona

​Como ele se encaixa com a memória

​Padrão híbrido recomendado

​Modos de cofre

​isolated

​bridge

​unsafe-local

​Layout do cofre

​Importações do Open Knowledge Format

​Declarações e evidências estruturadas

​Metadados de entidade voltados ao agente

​Pipeline de compilação

​Dashboards e relatórios de saúde

​Busca e recuperação

​Ferramentas do agente

​Comportamento de prompt e contexto

​Configuração

​Exemplo: QMD + modo bridge

​CLI

​Suporte ao Obsidian

​Fluxo de trabalho recomendado

​Documentos relacionados