Gedächtnis-Wiki

memory-wiki ist ein gebündeltes Plugin, das dauerhaftes Wissen in ein navigierbares Wiki kompiliert: deterministische Seiten, strukturierte Aussagen mit Belegen, Provenienz, Dashboards und maschinenlesbare Digests.

Es ersetzt nicht das Active-Memory-Plugin. Abruf, Überführung, Indizierung und Dreaming verbleiben bei dem jeweils konfigurierten Speicher-Backend (memory-core, QMD, Honcho usw.). memory-wiki wird ergänzend eingesetzt und kompiliert Wissen in eine gepflegte Wiki-Ebene.

Praktische Regel:

• memory_search für einen umfassenden Abrufdurchlauf über alle konfigurierten Korpora
• wiki_search / wiki_get, wenn Sie Wiki-spezifische Rangfolge, Provenienz oder eine aussagenbasierte Struktur auf Seitenebene benötigen
• memory_search corpus=all, um beide Ebenen in einem Aufruf abzudecken, sofern das Active-Memory-Plugin die Korpusauswahl unterstützt

Eine verbreitete Local-First-Konfiguration: QMD als Active-Memory-Backend für den Abruf und memory-wiki im Modus bridge für dauerhafte synthetisierte Seiten. Siehe das Beispiel für QMD und den Bridge-Modus unter Konfiguration.

Wenn der Bridge-Modus null exportierte Artefakte meldet, stellt das Active-Memory-Plugin derzeit keine öffentlichen Bridge-Eingaben bereit. Führen Sie zuerst openclaw wiki doctor aus und vergewissern Sie sich anschließend, dass das Active-Memory-Plugin öffentliche Artefakte unterstützt.

Vault-Modi

• isolated (Standard): eigener Vault, eigene Quellen, keine Abhängigkeit vom Active-Memory-Plugin. Verwenden Sie diesen Modus für einen eigenständigen kuratierten Wissensspeicher.
• bridge: Liest öffentliche Speicherartefakte und Ereignisprotokolle des Active-Memory-Plugins über öffentliche Schnittstellen des Plugin-SDK. Verwenden Sie diesen Modus, um die exportierten Artefakte des Speicher-Plugins zu kompilieren, ohne auf private Plugin-Interna zuzugreifen.
• unsafe-local: expliziter Ausweg für private lokale Pfade auf demselben Rechner. Absichtlich experimentell und nicht portabel; verwenden Sie diesen Modus nur, wenn Sie die Vertrauensgrenze verstehen und ausdrücklich lokalen Dateisystemzugriff benötigen, den der Bridge-Modus nicht bereitstellen kann.

Vault-Modus und Vault-Geltungsbereich sind voneinander unabhängige Optionen:

• vaultMode legt fest, woher die Wiki-Eingaben stammen.
• vault.scope legt fest, ob alle Agenten einen Vault verwenden oder jeder Agent einen untergeordneten Vault erhält.

vault.scope: "global" ist der Standard und erhält das bestehende Verhalten mit einem einzigen Vault. Verwenden Sie vault.scope: "agent" mit dem Modus isolated oder bridge, wenn Agenten Wiki-Seiten, kompilierte Digests, Suchergebnisse oder Schreibvorgänge nicht gemeinsam nutzen dürfen. Der Agenten-Geltungsbereich kann nicht mit dem Modus unsafe-local kombiniert werden, da die konfigurierten privaten Pfade keine agenteneigenen Eingaben sind. Die Konfigurationsvalidierung lehnt diese Kombination ab.

Der Bridge-Modus kann abhängig vom jeweiligen Konfigurationsschalter unter bridge.* Folgendes indizieren:

• exportierte Speicherartefakte (indexMemoryRoot)
• tägliche Notizen (indexDailyNotes)
• Dreaming-Berichte (indexDreamReports)
• Speicherereignisprotokolle (followMemoryEvents)

Wenn der Bridge-Modus aktiv und bridge.readMemoryArtifacts aktiviert ist, werden openclaw wiki status, openclaw wiki doctor und openclaw wiki bridge import über den laufenden Gateway geleitet, sodass sie denselben Kontext des Active-Memory-Plugins wie der Agenten-/Laufzeitspeicher verwenden. Wenn die Bridge deaktiviert ist oder Artefaktlesevorgänge ausgeschaltet sind, behalten diese Befehle ihr lokales Offline-Verhalten bei.

Vault-Struktur

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

Verwaltete Inhalte bleiben innerhalb generierter Blöcke; von Menschen erstellte Notizblöcke bleiben bei der Neugenerierung erhalten.

• sources/: importiertes Rohmaterial und Seiten, die auf Bridge- bzw. unsafe-local-Quellen basieren
• entities/: dauerhafte Dinge, Personen, Systeme, Projekte und Objekte
• concepts/: Ideen, Abstraktionen, Muster und Richtlinien (auch der Zielort für OKF-Importe)
• syntheses/: kompilierte Zusammenfassungen und gepflegte Übersichten
• reports/: generierte Dashboards

Importe im Open Knowledge Format

openclaw wiki okf import ./bundles/ga4

Importieren Sie ein entpacktes Paket im Open Knowledge Format in Wiki-Konzeptseiten. Dies eignet sich gut, wenn ein Datenkatalog, Dokumentations-Crawler oder Anreicherungsagent bereits OKF erzeugt: Behalten Sie OKF als portables Austauschartefakt bei und lassen Sie memory-wiki daraus OpenClaw-native Konzeptseiten und kompilierte Digests erstellen.

• Nicht reservierte .md-Dateien sind Konzeptdokumente
• Jedes importierte Konzept benötigt ein nicht leeres Frontmatter-Feld type; fehlt type, wird eine Warnung missing-type erzeugt und die Datei übersprungen
• Unbekannte type-Werte werden als generische Konzepte akzeptiert
• index.md und log.md sind reserviert und werden niemals als Konzepte importiert
• Defekte oder externe Markdown-Links bleiben unverändert

Importierte Seiten werden direkt unter concepts/ abgelegt, sodass bestehende Abläufe zum Kompilieren, Suchen, Abrufen und Erstellen von Dashboards sie ohne einen zweiten Wiki-Baum erfassen. Jede Seite behält die ursprüngliche OKF-Konzept-ID, den Quellpfad, type, resource, tags, den Zeitstempel und das vollständige Frontmatter des Erzeugers. Interne OKF-Links werden auf die generierten Wiki-Konzeptseiten umgeschrieben und erzeugen außerdem strukturierte relationships-Einträge mit kind: okf-link.

Strukturierte Aussagen und Belege

Seiten enthalten strukturiertes claims-Frontmatter, nicht nur unstrukturierten Text. Jede Aussage kann id, text, status, confidence, evidence[] und updatedAt enthalten. Jeder Belegeintrag kann kind, sourceId, path, lines, weight, confidence, privacyTier, note und updatedAt enthalten.

Dadurch verhält sich das Wiki wie eine Überzeugungsebene und nicht wie eine passive Notizablage. Aussagen können nachverfolgt, bewertet, angefochten und anhand ihrer Quellen geklärt werden.

Agentenbezogene Entitätsmetadaten

Entitätsseiten enthalten generische Routing-Metadaten, die für Personen, Teams, Systeme, Projekte oder beliebige andere Entitätstypen verwendet werden können:

• entityType: zum Beispiel person, team, system, project
• canonicalId: stabiler Identitätsschlüssel über Aliasse und Importe hinweg
• aliases: Namen, Handles oder Bezeichnungen, die auf dieselbe Seite verweisen
• privacyTier: frei formulierbare Zeichenfolge; public wird so behandelt, als sei keine Prüfung erforderlich, jeder andere Wert (zum Beispiel local-private, sensitive, confirm-before-use) wird in reports/privacy-review.md gekennzeichnet
• bestUsedFor / notEnoughFor: kompakte Routing-Hinweise
• lastRefreshedAt: Zeitstempel der Quellenaktualisierung, unabhängig vom Bearbeitungszeitpunkt der Seite
• personCard: optionale personenspezifische Routing-Karte (Handles, soziale Profile, E-Mail-Adressen, Zeitzone, Bereich, geeignete Anfragen, zu vermeidende Anfragen, Konfidenz, Datenschutzstufe)
• relationships: typisierte Kanten zu verwandten Seiten (Ziel, Art, Gewichtung, Konfidenz, Belegart, Datenschutzstufe, Anmerkung)

Beginnen Sie bei einem Personen-Wiki mit reports/person-agent-directory.md und öffnen Sie anschließend die Personenseite mit wiki_get, bevor Sie Kontaktdaten oder abgeleitete Fakten verwenden.

pageType: entityentityType: personid: entity.example-personcanonicalId: maintainer.example-personaliases:- Alex- example-handleprivacyTier: local-privatebestUsedFor:- Beispielhafte Weiterleitung innerhalb des ÖkosystemsnotEnoughFor:- rechtliche GenehmigunglastRefreshedAt: "2026-04-29T00:00:00.000Z"personCard:handles:  - "@example-handle"socials:  - "https://x.example/example-handle"emails:  - alex@example.comtimezone: America/Chicagolane: Beispiel-ÖkosystemaskFor:  - Fragen zur beispielhaften EinführungavoidAskingFor:  - nicht zugehörige Abrechnungsentscheidungenconfidence: 0.8privacyTier: confirm-before-userelationships:- targetId: entity.other-person  targetTitle: Andere Person  kind: collaborates-with  confidence: 0.7  evidenceKind: discrawl-statclaims:- id: claim.example.routing  text: Alex ist für die Weiterleitung innerhalb des Beispiel-Ökosystems hilfreich.  status: supported  confidence: 0.9  evidence:    - kind: maintainer-whois      sourceId: source.maintainers      privacyTier: local-private

Kompilierungs-Pipeline

Die Kompilierung liest Wiki-Seiten, normalisiert Zusammenfassungen und erzeugt stabile maschinenorientierte Artefakte unter:

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

Agenten und Laufzeitcode lesen diese Digests, anstatt Markdown auszulesen. Die kompilierte Ausgabe unterstützt außerdem die Wiki-Indizierung im ersten Durchlauf für Suche/Abruf, die Rückverfolgung von Aussage-IDs zu den zugehörigen Seiten, kompakte Prompt-Ergänzungen und die Berichtserstellung.

Dashboards und Zustandsberichte

Wenn render.createDashboards aktiviert ist, pflegt die Kompilierung Dashboards unter reports/:

Suche und Abruf

Zwei Such-Backends:

• shared: Verwendet den gemeinsamen Speicher-Suchablauf, sofern verfügbar
• local: Durchsucht das Wiki lokal

Drei Korpora: wiki, memory, all.

• wiki_search / wiki_get verwenden nach Möglichkeit kompilierte Digests als ersten Durchlauf
• Aussage-IDs werden auf die zugehörige Seite zurückgeführt
• angefochtene, veraltete und aktuelle Aussagen beeinflussen die Rangfolge
• Provenienzbezeichnungen bleiben in den Ergebnissen erhalten

Suchmodi (--mode / Werkzeugparameter mode):

Wenn ein Ergebnis mit einer strukturierten Aussage übereinstimmt, gibt wiki_search matchedClaimId, matchedClaimStatus, matchedClaimConfidence, evidenceKinds und evidenceSourceIds in seiner Detailnutzlast zurück. Die Textausgabe enthält, sofern verfügbar, kompakte Zeilen Claim: und Evidence:.

Agentenwerkzeuge

Das Plugin registriert außerdem eine nicht exklusive Ergänzung des Speicherkorpus, sodass die gemeinsamen Funktionen memory_search und memory_get auf das Wiki zugreifen können, wenn das aktive Speicher-Plugin die Korpusauswahl unterstützt.

Verhalten von Prompt und Kontext

Wenn context.includeCompiledDigestPrompt aktiviert ist, hängen Speicher-Promptabschnitte eine kompakte kompilierte Momentaufnahme aus agent-digest.json an: nur die wichtigsten Seiten, nur die wichtigsten Behauptungen, Anzahl der Widersprüche, Anzahl der Fragen sowie Angaben zu Konfidenz und Aktualität. Dies muss explizit aktiviert werden, da es die Promptstruktur verändert; es ist hauptsächlich für Kontext-Engines oder die Promptzusammenstellung relevant, die Speicherergänzungen ausdrücklich verarbeiten.

Konfiguration

Legen Sie die Konfiguration unter plugins.entries.memory-wiki.config ab:

{  plugins: {    entries: {      "memory-wiki": {        enabled: true,        config: {          vaultMode: "isolated",          vault: {            scope: "global",            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,          },          unsafeLocal: {            allowPrivateMemoryCoreAccess: false,            paths: [],          },          ingest: {            autoCompile: true,            maxConcurrentJobs: 1,            allowUrlIngest: true,          },          search: {            backend: "shared",            corpus: "wiki",          },          context: {            includeCompiledDigestPrompt: false,          },          render: {            preserveHumanBlocks: true,            createBacklinks: true,            createDashboards: true,          },        },      },    },  },}

Wichtige Schalter:

Vaults pro Agent

Setzen Sie vault.scope auf agent, um jedem konfigurierten Agent ein separates Wiki zuzuweisen. In diesem Umfang ist vault.path ein übergeordnetes Verzeichnis, an das OpenClaw die normalisierte Agent-ID anhängt:

{  agents: {    list: [{ id: "support" }, { id: "marketing" }],  },  plugins: {    entries: {      "memory-wiki": {        enabled: true,        config: {          vaultMode: "bridge",          vault: {            scope: "agent",            path: "~/.openclaw/wiki",          },          bridge: {            enabled: true,            readMemoryArtifacts: true,          },        },      },    },  },}

Dies wird zu ~/.openclaw/wiki/support und ~/.openclaw/wiki/marketing aufgelöst. Wenn vault.path im Agent-Umfang weggelassen wird, ist das übergeordnete Verzeichnis standardmäßig ~/.openclaw/wiki. Der standardmäßige Agent main behält daher den vorhandenen Pfad ~/.openclaw/wiki/main.

Agent-Tools, kompilierte Prompt-Digests und die über memory_search / memory_get bereitgestellte Wiki-Ergänzung lösen den Vault anhand des aktiven Agent-Kontexts auf. Geben Sie bei CLI- und Gateway-Aufrufen in einer Einrichtung mit mehreren konfigurierten Agents den Agent explizit mit openclaw wiki --agent <agentId> ... oder über agentId in der Gateway-Anfrage an. Ein einzelner konfigurierter Agent bleibt der Standard, wenn keine ID angegeben wird.

Im Bridge-Modus akzeptieren Agent-bezogene Importe ein öffentliches Speicherartefakt nur, wenn dessen agentIds den ausgewählten Agent enthält. Artefakte, die einem anderen Agent gehören, keine Eigentümermetadaten besitzen oder einen unbekannten Eigentümer haben, werden übersprungen. Der globale Umfang behält das bisherige Verhalten für gemeinsame Artefakte bei.

Beispiel: QMD + Bridge-Modus

Verwenden Sie dies, wenn Sie QMD für den Abruf und memory-wiki für eine gepflegte Wissensebene einsetzen möchten. Jede Ebene bleibt fokussiert: QMD hält Rohnotizen, Sitzungsexporte und zusätzliche Sammlungen durchsuchbar, während memory-wiki stabile Entitäten, Behauptungen, Dashboards und Quellseiten kompiliert.

{  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,          },        },      },    },  },}

Dadurch bleibt QMD für den Abruf aus dem aktiven Speicher zuständig, memory-wiki konzentriert sich auf kompilierte Seiten und Dashboards, und die Promptstruktur bleibt unverändert, bis Sie kompilierte Digest-Prompts bewusst aktivieren.

CLI

openclaw wiki statusopenclaw wiki doctoropenclaw wiki initopenclaw wiki ingest ./notes/alpha.mdopenclaw wiki compileopenclaw wiki lintopenclaw wiki search "alpha"openclaw wiki get entity.alphaopenclaw wiki apply synthesis "Alpha Summary" --body "..." --source-id source.alphaopenclaw wiki bridge importopenclaw wiki obsidian status

Die vollständige Befehlsreferenz einschließlich wiki okf import, wiki apply metadata, wiki unsafe-local import, wiki chatgpt import / wiki chatgpt rollback und aller wiki obsidian-Unterbefehle finden Sie unter CLI: Wiki.

Obsidian-Unterstützung

Wenn vault.renderMode auf obsidian gesetzt ist, schreibt das Plugin Obsidian-freundliches Markdown und kann optional die offizielle obsidian-CLI verwenden, um den Status abzufragen, den Vault zu durchsuchen, eine Seite zu öffnen, einen Befehl aufzurufen und zur Tagesnotiz zu wechseln. Dies ist optional; das Wiki funktioniert auch im nativen Modus ohne Obsidian.

Agent-bezogene Vaults können weiterhin Obsidian-freundliches Markdown verwenden, aber die Konfigurationsvalidierung lehnt obsidian.useOfficialCli: true zusammen mit vault.scope: "agent" ab. Die aktuelle Einstellung obsidian.vaultName ist global und kann nicht für jeden Agent einen eigenen Obsidian-Vault auswählen. Verwenden Sie stattdessen die Wiki-Tools und CLI-Operationen oder betreiben Sie ein von Obsidian verwaltetes Wiki im globalen Umfang.

Empfohlener Arbeitsablauf

Verwandte Dokumentation

• Speicherübersicht
• CLI: Speicher
• CLI: Wiki
• Übersicht über das Plugin SDK