memory-wiki ist ein gebündeltes Plugin, das dauerhaftes Wissen in einem
navigierbaren Wiki zusammenführt: deterministische Seiten, strukturierte Aussagen mit Belegen,
Herkunftsnachweise, Dashboards und maschinenlesbare Zusammenfassungen.
Es ersetzt nicht das Active-Memory-Plugin. Abruf, Übernahme, Indizierung und
Dreaming verbleiben bei dem jeweils konfigurierten Memory-Backend
(memory-core, QMD, Honcho usw.). memory-wiki wird parallel dazu eingesetzt und führt
Wissen in einer gepflegten Wiki-Ebene zusammen.
Aktivieren Sie das Plugin, bevor Sie seine CLI, Tools oder Laufzeitintegration verwenden:
Praktische Regel:
memory_searchfür einen umfassenden Abrufdurchlauf über alle konfigurierten Korporawiki_search/wiki_get, wenn Sie Wiki-spezifische Rangordnung, Herkunftsnachweise oder eine aussagenbasierte Struktur auf Seitenebene benötigenmemory_search corpus=all, um beide Ebenen in einem Aufruf abzudecken, sofern das Active-Memory-Plugin die Korpusauswahl unterstützt
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 zunächst openclaw wiki doctor aus
und prüfen Sie anschließend, ob 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 Memory-Artefakte und Ereignisprotokolle des Active-Memory-Plugins über öffentliche Schnittstellen des Plugin-SDK. Verwenden Sie diesen Modus, um die exportierten Artefakte des Memory-Plugins zusammenzustellen, ohne auf private Plugin-Interna zuzugreifen.unsafe-local: expliziter Ausweg für lokale private Pfade auf demselben Rechner. Bewusst experimentell und nicht portabel; verwenden Sie ihn nur, wenn Sie die Vertrauensgrenze verstehen und ausdrücklich lokalen Dateisystemzugriff benötigen, den der Bridge-Modus nicht bereitstellen kann.
vaultModebestimmt, woher die Wiki-Eingaben stammen.vault.scopebestimmt, ob alle Agenten einen Vault verwenden oder jeder Agent einen untergeordneten Vault erhält.
vault.scope: "global" ist der Standard und behält das bestehende Verhalten mit einem einzelnen Vault
bei. Verwenden Sie vault.scope: "agent" mit dem Modus isolated oder bridge, wenn
Agenten keine Wiki-Seiten, zusammengestellten Zusammenfassungen, Suchergebnisse oder Schreibvorgänge gemeinsam nutzen dürfen.
Der Agent-Geltungsbereich kann nicht mit dem Modus unsafe-local kombiniert werden, da diese konfigurierten
privaten Pfade keine agenteneigenen Eingaben sind. Die Konfigurationsvalidierung weist diese
Kombination zurück.
Der Bridge-Modus kann abhängig vom Konfigurationsschalter bridge.* Folgendes indizieren:
- exportierte Memory-Artefakte (
indexMemoryRoot) - tägliche Notizen (
indexDailyNotes) - Dreaming-Berichte (
indexDreamReports) - Memory-Ereignisprotokolle (
followMemoryEvents)
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 das Agenten-/Laufzeit-Memory verwenden. Wenn die Bridge deaktiviert ist oder
Artefaktlesevorgänge ausgeschaltet sind, behalten diese Befehle ihr lokales/Offline-Verhalten bei.
Vault-Struktur
sources/: importiertes Rohmaterial und durch Bridge/unsichere lokale Quellen gespeiste Seitenentities/: dauerhafte Dinge, Personen, Systeme, Projekte, Objekteconcepts/: Ideen, Abstraktionen, Muster, Richtlinien (auch das Ziel für OKF-Importe)syntheses/: zusammengestellte Zusammenfassungen und gepflegte Gesamtübersichtenreports/: generierte Dashboards
Importe im Open Knowledge Format
memory-wiki
daraus OpenClaw-native Konzeptseiten und zusammengestellte Zusammenfassungen erstellen.
- nicht reservierte
.md-Dateien sind Konzeptdokumente - jedes importierte Konzept benötigt ein nicht leeres Frontmatter-Feld
type; ein fehlendestypeerzeugt eine Warnung vom Typmissing-type, und die Datei wird übersprungen - unbekannte
type-Werte werden als generische Konzepte akzeptiert index.mdundlog.mdsind reserviert und werden niemals als Konzepte importiert- fehlerhafte oder externe Markdown-Links bleiben unverändert
concepts/ abgelegt, sodass bestehende Abläufe für Zusammenstellung, Suche, Abruf und
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 strukturiertesclaims-Frontmatter, nicht nur Freitext. 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 verfolgt, bewertet, angefochten und bis zu ihren Quellen zurückverfolgt werden.
Agentenbezogene Entitätsmetadaten
Entitätsseiten enthalten generische Routing-Metadaten, die für Personen, Teams, Systeme, Projekte oder jeden anderen Entitätstyp verwendet werden können:entityType: zum Beispielperson,team,system,projectcanonicalId: stabiler Identitätsschlüssel über Aliasse und Importe hinwegaliases: Namen, Handles oder Bezeichnungen, die auf dieselbe Seite verweisenprivacyTier: frei formulierbare Zeichenfolge;publicwird als „keine Prüfung erforderlich“ behandelt, jeder andere Wert (zum Beispiellocal-private,sensitive,confirm-before-use) wird inreports/privacy-review.mdmarkiertbestUsedFor/notEnoughFor: kompakte Routing-HinweiselastRefreshedAt: Zeitstempel der Quellenaktualisierung, getrennt vom Bearbeitungszeitpunkt der SeitepersonCard: optionale personenspezifische Routing-Karte (Handles, soziale Profile, E-Mail-Adressen, Zeitzone, Zuständigkeitsbereich, geeignete Anfragen, ungeeignete Anfragen, Konfidenz, Datenschutzstufe)relationships: typisierte Kanten zu verwandten Seiten (Ziel, Art, Gewichtung, Konfidenz, Belegart, Datenschutzstufe, Notiz)
reports/person-agent-directory.md und öffnen Sie anschließend
die Personenseite mit wiki_get, bevor Sie Kontaktdaten oder abgeleitete
Fakten verwenden.
Beispiel für eine Entitätsseite
Beispiel für eine Entitätsseite
Zusammenstellungspipeline
Die Zusammenstellung liest Wiki-Seiten, normalisiert Zusammenfassungen und speichert einen maschinenorientierten Snapshot im gemeinsam genutzten SQLite-Plugin-Status von OpenClaw. Der Laufzeitcode verwendet den lebenszykluseigenen Owner-Snapshot, um SQLite während der asynchronen Prompt-Vorbereitung zu laden; die synchrone Prompt-Zusammenstellung durchsucht niemals Markdown und liest keine Cache-Dateien. Die zusammengestellte Ausgabe ermöglicht außerdem die erste Wiki-Indizierung für Suche/Abruf, die Rückauflösung von Aussage-IDs zu ihren zugehörigen Seiten, kompakte Prompt-Ergänzungen und die Berichterstellung. Änderungen an Quellen und Vault-Wiederherstellungen werden erst nach der nächsten Zusammenstellung maschinenwirksam. Beim Neustarten oder Aktualisieren des Plugin-Lebenszyklus wird die kausal verkettete Zusammenstellungsveröffentlichung des Vaults mit SQLite verglichen und ein Snapshot aus einem neueren, zurückgesetzten Zustand abgelehnt. Ein Compiler, der vor dem Rollback gestartet wurde, kann nicht gegenüber dem wiederhergestellten Vorgänger veröffentlichen. Die Prompt-Vorbereitung fragt den Vault nicht regelmäßig ab und installiert keine Dateiwächter. Nach einer Rollback-Quarantäne entfernt eine Zusammenstellung im laufenden Prozess den Owner sofort; ein separater Compiler-Prozess erfordert eine Aktualisierung des Plugin-Lebenszyklus, damit der Daemon die neue dauerhafte Veröffentlichung bestätigen kann. Zusammengestellte Caches können neu erstellt werden: Cache-Zeilen aus Epochen vor der Veröffentlichung werden als Fehltreffer behandelt und durch die nächste Zusammenstellung ersetzt; sie werden nicht migriert.Dashboards und Zustandsberichte
Wennrender.createDashboards aktiviert ist, pflegt die Zusammenstellung Dashboards unter
reports/:
Suche und Abruf
Zwei Such-Backends:shared: verwendet den gemeinsamen Memory-Suchablauf, sofern verfügbarlocal: durchsucht das Wiki lokal
wiki, memory, all.
wiki_search/wiki_getverwenden nach Möglichkeit zusammengestellte Zusammenfassungen für den ersten Durchlauf- Aussage-IDs werden zur zugehörigen Seite zurückaufgelöst
- angefochtene/veraltete/aktuelle Aussagen beeinflussen die Rangordnung
- Herkunftsbezeichnungen bleiben in den Ergebnissen erhalten
--mode / Tool 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 kompakte Zeilen für Claim: und Evidence:, sofern verfügbar.
Agentenwerkzeuge
Das Plugin registriert außerdem eine nicht exklusive Ergänzung des Erinnerungskorpus, sodass gemeinsame
memory_search und memory_get auf das Wiki zugreifen können, wenn das aktive Erinnerungs-
Plugin die Korpusauswahl unterstützt.
Verhalten von Prompt und Kontext
Wenncontext.includeCompiledDigestPrompt aktiviert ist, hängen Erinnerungsprompt-Abschnitte
einen kompakten kompilierten Schnappschuss aus dem Plugin-Zustand an: nur die wichtigsten Seiten,
nur die wichtigsten Aussagen, Anzahl der Widersprüche, Anzahl der Fragen sowie Einstufungen
zu Konfidenz und Aktualität. Dies ist optional, da es die Prompt-Struktur ändert; relevant ist es hauptsächlich
für Kontext-Engines oder die Prompt-Zusammenstellung, die ausdrücklich Erinnerungsergänzungen
verwenden.
Konfiguration
Legen Sie die Konfiguration unterplugins.entries.memory-wiki.config ab:
Vaults pro Agent
Setzen Sievault.scope auf agent, um jedem konfigurierten Agenten ein eigenes Wiki zuzuweisen.
In diesem Umfang ist vault.path ein übergeordnetes Verzeichnis, und OpenClaw hängt die
normalisierte Agenten-ID an:
~/.openclaw/wiki/support und
~/.openclaw/wiki/marketing aufgelöst. Wenn vault.path im Agentenumfang weggelassen wird, ist das
übergeordnete Verzeichnis standardmäßig ~/.openclaw/wiki. Der standardmäßige Agent main behält daher
den vorhandenen Pfad ~/.openclaw/wiki/main bei.
Agentenwerkzeuge, kompilierte Prompt-Digests und die über
memory_search / memory_get bereitgestellte Wiki-Ergänzung lösen den Vault anhand des aktiven Agentenkontexts auf.
Geben Sie bei CLI- und Gateway-Aufrufen in einer Konfiguration mit mehreren konfigurierten Agenten
den Agenten explizit mit openclaw wiki --agent <agentId> ... oder über agentId der Gateway-
Anfrage an. Ein einzelner konfigurierter Agent bleibt die Standardeinstellung, wenn keine ID
angegeben wird.
Im Bridge-Modus akzeptieren agentenspezifische Importe ein öffentliches Erinnerungsartefakt nur, wenn
dessen agentIds den ausgewählten Agenten enthält. Artefakte, die einem anderen Agenten gehören,
keine Eigentumsmetadaten enthalten oder einen unbekannten Eigentümer haben, werden übersprungen. Der globale Umfang
behält das vorhandene Verhalten für gemeinsame Artefakte bei.
Beispiel: QMD + Bridge-Modus
Verwenden Sie dies, wenn Sie QMD für den Abruf undmemory-wiki als gepflegte
Wissensebene einsetzen möchten. Jede Ebene bleibt fokussiert: QMD hält Rohnotizen, Sitzungs-
exporte und zusätzliche Sammlungen durchsuchbar, während memory-wiki
stabile Entitäten, Aussagen, Dashboards und Quellseiten kompiliert.
memory-wiki konzentriert sich auf
kompilierte Seiten und Dashboards, und die Prompt-Struktur bleibt unverändert, bis Sie
kompilierte Digest-Prompts bewusst aktivieren.
CLI
wiki okf import, wiki apply metadata, wiki unsafe-local import,
wiki chatgpt import / wiki chatgpt rollback und des vollständigen wiki obsidian-
Unterbefehlssatzes finden Sie unter CLI: Wiki.
Obsidian-Unterstützung
Wennvault.renderMode auf obsidian gesetzt ist, schreibt das Plugin Obsidian-freundliches
Markdown und kann optional die offizielle obsidian-CLI für Zustands-
prüfungen, Vault-Suchen, das Öffnen einer Seite, das Aufrufen eines Befehls und das Wechseln zur
Tagesnotiz verwenden. Dies ist optional; das Wiki funktioniert auch im nativen Modus ohne
Obsidian.
Agentenspezifische Vaults können weiterhin Obsidian-freundliches Markdown verwenden, aber die Konfigurations-
validierung lehnt obsidian.useOfficialCli: true mit vault.scope: "agent" ab.
Die aktuelle Einstellung obsidian.vaultName ist global und kann nicht für jeden Agenten
einen eigenen Obsidian-Vault auswählen. Verwenden Sie stattdessen die Wiki-Werkzeuge und CLI-Vorgänge,
oder belassen Sie ein von Obsidian verwaltetes Wiki im globalen Umfang.
Empfohlener Arbeitsablauf
1
Aktives Memory-Plugin für den Abruf beibehalten
Abruf, Hochstufung und Dreaming bleiben dem konfigurierten Memory-Backend zugeordnet.
2
memory-wiki aktivieren
Beginnen Sie mit dem Modus
isolated, sofern Sie nicht ausdrücklich den Bridge-Modus verwenden möchten.3
wiki_search / wiki_get verwenden, wenn die Provenienz wichtig ist
Ziehen Sie diese
memory_search vor, wenn Sie Wiki-spezifisches Ranking oder eine Glaubwürdigkeitsstruktur auf Seitenebene benötigen.4
wiki_apply für eng begrenzte Synthesen oder Metadatenaktualisierungen verwenden
Vermeiden Sie die manuelle Bearbeitung verwalteter generierter Blöcke.
5
wiki_lint nach wesentlichen Änderungen ausführen
Erkennt Widersprüche, offene Fragen und Provenienzlücken.
6
Dashboards für die Sichtbarkeit veralteter Inhalte und von Widersprüchen aktivieren
Legen Sie
render.createDashboards: true fest (Standard).