Bundled plugin guides
Вікі пам’яті
memory-wiki — це вбудований плагін, який перетворює довготривалу пам’ять на скомпільоване
сховище знань.
Він не замінює плагін активної пам’яті. Плагін активної пам’яті й надалі
відповідає за пригадування, просування, індексацію та dreaming. memory-wiki працює поруч із ним
і компілює довготривалі знання в навіговну wiki з детермінованими сторінками,
структурованими твердженнями, походженням, панелями та машинозчитуваними дайджестами.
Використовуйте його, коли хочете, щоб пам’ять поводилася радше як підтримуваний шар знань, а не як купа Markdown-файлів.
Що він додає
- Окреме wiki-сховище з детермінованою розкладкою сторінок
- Структуровані метадані тверджень і доказів, а не лише прозу
- Походження, впевненість, суперечності та відкриті питання на рівні сторінки
- Скомпільовані дайджести для споживачів агентів/середовища виконання
- Wiki-нативні інструменти пошуку/отримання/застосування/lint
- Імпорти Open Knowledge Format у скомпільовані wiki-концепти
- Опційний режим мосту, який імпортує публічні артефакти з плагіна активної пам’яті
- Опційний режим рендерингу, дружній до Obsidian, та інтеграція CLI
Як він поєднується з пам’яттю
Уявляйте поділ так:
| Шар | Відповідає за |
|---|---|
Плагін активної пам’яті (memory-core, QMD, Honcho тощо) |
Пригадування, семантичний пошук, просування, dreaming, середовище виконання пам’яті |
memory-wiki |
Скомпільовані wiki-сторінки, синтези з багатим походженням, панелі, wiki-специфічні search/get/apply |
Якщо плагін активної пам’яті надає спільні артефакти пригадування, OpenClaw може шукати
в обох шарах за один прохід через memory_search corpus=all.
Коли потрібне wiki-специфічне ранжування, походження або прямий доступ до сторінок, використовуйте натомість wiki-нативні інструменти.
Рекомендований гібридний шаблон
Сильний типовий варіант для локальних-first налаштувань:
- QMD як бекенд активної пам’яті для пригадування та широкого семантичного пошуку
memory-wikiу режиміbridgeдля довготривалих синтезованих сторінок знань
Такий поділ добре працює, бо кожен шар лишається сфокусованим:
- QMD зберігає raw-нотатки, експорти сесій і додаткові колекції доступними для пошуку
memory-wikiкомпілює стабільні сутності, твердження, панелі та сторінки джерел
Практичне правило:
- використовуйте
memory_search, коли потрібен один широкий прохід пригадування по пам’яті - використовуйте
wiki_searchіwiki_get, коли потрібні wiki-результати з урахуванням походження - використовуйте
memory_search corpus=all, коли хочете, щоб спільний пошук охоплював обидва шари
Якщо режим мосту повідомляє про нуль експортованих артефактів, плагін активної пам’яті
ще не надає публічні вхідні дані мосту. Спочатку запустіть openclaw wiki doctor,
потім підтвердьте, що плагін активної пам’яті підтримує публічні артефакти.
Коли режим мосту активний і bridge.readMemoryArtifacts увімкнено,
openclaw wiki status, openclaw wiki doctor і openclaw wiki bridge import читають через запущений Gateway. Це узгоджує перевірки мосту в CLI
з контекстом плагіна пам’яті в середовищі виконання. Якщо міст вимкнено або читання артефактів
вимкнене, ці команди зберігають локальну/offline поведінку.
Режими сховища
memory-wiki підтримує три режими сховища:
isolated
Власне сховище, власні джерела, без залежності від memory-core.
Використовуйте це, коли хочете, щоб wiki була власним кураторованим сховищем знань.
bridge
Читає публічні артефакти пам’яті та події пам’яті з плагіна активної пам’яті через публічні межі plugin SDK.
Використовуйте це, коли хочете, щоб wiki компілювала й організовувала експортовані артефакти плагіна пам’яті, не звертаючись до приватних внутрішніх частин плагіна.
Режим мосту може індексувати:
- експортовані артефакти пам’яті
- звіти сновидінь
- щоденні нотатки
- кореневі файли пам’яті
- журнали подій пам’яті
unsafe-local
Явний аварійний вихід для приватних локальних шляхів на тій самій машині.
Цей режим навмисно експериментальний і непереносний. Використовуйте його лише тоді, коли розумієте межу довіри та конкретно потребуєте локального доступу до файлової системи, якого не може надати режим мосту.
Структура сховища
Плагін ініціалізує сховище так:
<vault>/ AGENTS.md WIKI.md index.md inbox.md entities/ concepts/ syntheses/ sources/ reports/ _attachments/ _views/ .openclaw-wiki/Керований вміст лишається всередині згенерованих блоків. Блоки людських нотаток зберігаються.
Основні групи сторінок:
sources/для імпортованого raw-матеріалу та сторінок, підкріплених мостомentities/для довготривалих речей, людей, систем, проєктів і об’єктівconcepts/для ідей, абстракцій, шаблонів і політикsyntheses/для скомпільованих підсумків і підтримуваних зведеньreports/для згенерованих панелей
Імпорти Open Knowledge Format
memory-wiki може імпортувати розпаковані набори Open Knowledge Format через:
openclaw wiki okf import ./bundles/ga4Це найчистіше підходить, коли каталог даних, crawler документації або
агент збагачення вже створює OKF: зберігайте OKF як переносний артефакт обміну,
а потім дозвольте memory-wiki перетворити його на нативні для OpenClaw сторінки концептів і
скомпільовані дайджести.
Імпортер дотримується форми OKF v0.1:
- незарезервовані файли
.mdє документами концептів - кожному імпортованому концепту потрібне непорожнє поле frontmatter
type - невідомі значення OKF
typeприймаються - зарезервовані файли
index.mdіlog.mdне імпортуються як концепти - зламані або зовнішні markdown-посилання зберігаються
Імпортовані сторінки концептів сплощуються під concepts/, щоб наявні шляхи compile,
search, get, dashboard і prompt-digest бачили їх без додавання другого
wiki-дерева. Кожна сторінка зберігає оригінальний ID концепту OKF, шлях джерела, type,
resource, tags, часову мітку та повний producer frontmatter. Внутрішні OKF-посилання
переписуються на згенеровані wiki-сторінки концептів і також виводяться як структуровані
записи relationships з kind: okf-link.
Структуровані твердження та докази
Сторінки можуть містити структурований frontmatter claims, а не лише довільний текст.
Кожне твердження може містити:
idtextstatusconfidenceevidence[]updatedAt
Записи доказів можуть містити:
kindsourceIdpathlinesweightconfidenceprivacyTiernoteupdatedAt
Саме це змушує wiki діяти радше як шар переконань, ніж пасивний скид нотаток. Твердження можна відстежувати, оцінювати, оскаржувати та повертати до джерел.
Метадані сутностей для агентів
Сторінки сутностей також можуть містити routing metadata для використання агентами. Це generic frontmatter, тому він працює для людей, команд, систем, проєктів або будь-якого іншого типу сутності.
Поширені поля:
entityType: наприкладperson,team,systemабоprojectcanonicalId: стабільний ключ ідентичності, що використовується між alias та імпортамиaliases: імена, handles або labels, які мають розв’язуватися до тієї самої сторінкиprivacyTier:public,local-private,sensitiveабоconfirm-before-usebestUsedFor/notEnoughFor: компактні підказки routinglastRefreshedAt: часова мітка оновлення джерела, окрема від часу редагування сторінкиpersonCard: опційна person-specific routing card з handles, socials, emails, timezone, lane, ask-for, avoid-asking-for, confidence і privacyrelationships: типізовані ребра до пов’язаних сторінок із target, kind, weight, confidence, evidence kind, privacy tier і note
Для people wiki агенту зазвичай варто починати з
reports/person-agent-directory.md, потім відкрити сторінку людини через wiki_get
перед використанням контактних даних або виведених фактів.
Приклад:
pageType: entityentityType: personid: entity.brad-grouxcanonicalId: maintainer.brad-grouxaliases: - Brad - bgrouxprivacyTier: local-privatebestUsedFor: - Microsoft Teams and Azure routingnotEnoughFor: - legal approvallastRefreshedAt: "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-userelationships: - targetId: entity.alice targetTitle: Alice kind: collaborates-with confidence: 0.7 evidenceKind: discrawl-statclaims: - 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Конвеєр компіляції
Крок компіляції читає wiki-сторінки, нормалізує підсумки та виводить стабільні machine-facing артефакти в:
.openclaw-wiki/cache/agent-digest.json.openclaw-wiki/cache/claims.jsonl
Ці дайджести існують, щоб агентам і коду середовища виконання не доводилося scrape Markdown сторінки.
Скомпільований вивід також живить:
- перший прохід wiki-індексації для потоків search/get
- lookup claim-id назад до сторінок-власників
- компактні prompt supplements
- генерацію звітів/панелей
Панелі та звіти про стан
Коли render.createDashboards увімкнено, compile підтримує панелі в
reports/.
Вбудовані звіти містять:
reports/open-questions.mdreports/contradictions.mdreports/low-confidence.mdreports/claim-health.mdreports/stale-pages.mdreports/person-agent-directory.mdreports/relationship-graph.mdreports/provenance-coverage.mdreports/privacy-review.md
Ці звіти відстежують такі речі, як:
- кластери нотаток із суперечностями
- конкуруючі кластери тверджень
- твердження без структурованих доказів
- сторінки й твердження з низькою впевненістю
- застаріла або невідома свіжість
- сторінки з невирішеними питаннями
- картки routing для людей/сутностей
- структуровані ребра зв’язків
- покриття класів доказів
- непублічні privacy tiers, які потребують перевірки перед використанням
Пошук і отримання
memory-wiki підтримує два бекенди пошуку:
shared: використовувати спільний потік пошуку пам’яті, коли доступнийlocal: шукати wiki локально
Він також підтримує три корпуси:
wikimemoryall
Важлива поведінка:
wiki_searchіwiki_getвикористовують скомпільовані дайджести як перший прохід, коли це можливо- ID тверджень можуть розв’язуватися назад до сторінки-власника
- оскаржені/застарілі/свіжі твердження впливають на ранжування
- labels походження можуть зберігатися в результатах
- режим пошуку може зміщувати ранжування для пошуку людей, routing питань, source evidence або raw claims
Практичне правило:
- використовуйте
memory_search corpus=allдля одного широкого проходу пригадування - використовуйте
wiki_search+wiki_get, коли важливі wiki-специфічне ранжування, походження або структура переконань на рівні сторінки
Режими пошуку:
auto: збалансований типовий режимfind-person: підсилює person-like сутності, alias, handles, socials і canonical IDsroute-question: підсилює agent cards, підказки ask-for, підказки best-used-for і контекст зв’язківsource-evidence: підсилює сторінки джерел і structured evidence metadataraw-claim: підсилює відповідні структуровані твердження та повертає claim/evidence metadata в результатах
Коли результат збігається зі структурованим твердженням, wiki_search може повернути
matchedClaimId, matchedClaimStatus, matchedClaimConfidence,
evidenceKinds і evidenceSourceIds у своєму details payload. Текстовий вивід
також містить компактні рядки Claim: і Evidence:, коли вони доступні.
Інструменти агентів
Плагін реєструє ці інструменти:
wiki_statuswiki_searchwiki_getwiki_applywiki_lint
Що вони роблять:
wiki_status: поточний режим сховища, стан, доступність Obsidian CLIwiki_search: шукає wiki-сторінки та, коли налаштовано, спільні корпуси пам’яті; приймаєmodeдля пошуку людей, routing питань, source evidence або raw claim drilldownwiki_get: читає wiki-сторінку за id/path або fallback до спільного корпусу пам’ятіwiki_apply: вузькі мутації synthesis/metadata без довільної хірургії сторінокwiki_lint: структурні перевірки, прогалини походження, суперечності, відкриті питання
Plugin також реєструє неексклюзивне доповнення корпусу пам’яті, тож спільні
memory_search і memory_get можуть звертатися до вікі, коли Plugin активної пам’яті
підтримує вибір корпусу.
Поведінка промпта й контексту
Коли ввімкнено context.includeCompiledDigestPrompt, розділи промпта пам’яті
додають компактний скомпільований знімок з agent-digest.json.
Цей знімок навмисно малий і містить лише найважливіше:
- лише головні сторінки
- лише головні твердження
- кількість суперечностей
- кількість запитань
- кваліфікатори впевненості/свіжості
Це опціонально, бо змінює форму промпта й переважно корисне для контекстних рушіїв або застарілого складання промптів, які явно споживають доповнення пам’яті.
Конфігурація
Розмістіть конфігурацію в 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, }, }, }, }, },}Ключові перемикачі:
vaultMode:isolated,bridge,unsafe-localvault.renderMode:nativeабоobsidianbridge.readMemoryArtifacts: імпортувати публічні артефакти Plugin активної пам’ятіbridge.followMemoryEvents: включати журнали подій у режимі bridgesearch.backend:sharedабоlocalsearch.corpus:wiki,memoryабоallcontext.includeCompiledDigestPrompt: додавати компактний знімок дайджесту до розділів промпта пам’ятіrender.createBacklinks: генерувати детерміновані пов’язані блокиrender.createDashboards: генерувати сторінки панелей
Приклад: QMD + режим bridge
Використовуйте це, коли потрібен QMD для пригадування, а memory-wiki — для підтримуваного
шару знань:
{ 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, }, }, }, }, },}Це зберігає:
- QMD відповідальним за пригадування активної пам’яті
memory-wikiзосередженим на скомпільованих сторінках і панелях- форму промпта незмінною, доки ви навмисно не ввімкнете промпти скомпільованого дайджесту
CLI
memory-wiki також надає поверхню 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Див. CLI: wiki, щоб отримати повний довідник команд.
Підтримка Obsidian
Коли vault.renderMode має значення obsidian, Plugin записує Markdown, сумісний з Obsidian,
і за бажанням може використовувати офіційний CLI obsidian.
Підтримувані робочі процеси охоплюють:
- перевірку стану
- пошук у сховищі
- відкриття сторінки
- виклик команди Obsidian
- перехід до щоденної нотатки
Це необов’язково. Вікі й далі працює в нативному режимі без Obsidian.
Рекомендований робочий процес
- Залиште свій Plugin активної пам’яті для пригадування/просування/Dreaming.
- Увімкніть
memory-wiki. - Почніть з режиму
isolated, якщо вам явно не потрібен режим bridge. - Використовуйте
wiki_search/wiki_get, коли важливе походження даних. - Використовуйте
wiki_applyдля вузьких синтезів або оновлень метаданих. - Запускайте
wiki_lintпісля суттєвих змін. - Увімкніть панелі, якщо потрібна видимість застарілості/суперечностей.