memory-wiki — це вбудований Plugin, який компілює довготривалі знання в
зручну для навігації вікі: детерміновані сторінки, структуровані твердження з доказами,
походження даних, панелі огляду та машиночитні дайджести.
Він не замінює Plugin активної пам’яті. Пригадування, просування, індексування та
Dreaming залишаються у віданні налаштованого бекенда пам’яті
(memory-core, QMD, Honcho тощо). memory-wiki працює поруч із ним і компілює
знання в підтримуваний шар вікі.
Практичне правило:
memory_searchдля одного широкого проходу пригадування всіма налаштованими корпусамиwiki_search/wiki_get, коли потрібні специфічні для вікі ранжування, походження даних або структура переконань на рівні сторінкиmemory_search corpus=all, щоб охопити обидва шари одним викликом, якщо Plugin активної пам’яті підтримує вибір корпусу
memory-wiki у режимі bridge для довготривалих синтезованих сторінок. Див.
приклад QMD + режиму мосту в розділі Конфігурація.
Якщо режим мосту повідомляє про нуль експортованих артефактів, Plugin активної пам’яті
наразі не надає загальнодоступних вхідних даних мосту. Спочатку виконайте openclaw wiki doctor,
а потім переконайтеся, що Plugin активної пам’яті підтримує загальнодоступні артефакти.
Режими сховища
isolated(типово): власне сховище, власні джерела, без залежності від Plugin активної пам’яті. Використовуйте для самодостатнього впорядкованого сховища знань.bridge: зчитує загальнодоступні артефакти пам’яті та журнали подій із Plugin активної пам’яті через загальнодоступні інтерфейси SDK плагінів. Використовуйте для компіляції експортованих артефактів Plugin пам’яті без доступу до його приватної внутрішньої реалізації.unsafe-local: явний аварійний механізм для приватних локальних шляхів на тій самій машині. Навмисно експериментальний і непереносний; використовуйте лише тоді, коли розумієте межу довіри й вам потрібен саме доступ до локальної файлової системи, якого не може надати режим мосту.
vaultModeвизначає, звідки надходять вхідні дані вікі.vault.scopeвизначає, чи всі агенти використовують одне сховище, чи кожен агент отримує дочірнє сховище.
vault.scope: "global" є типовим значенням і зберігає наявну
поведінку з одним сховищем. Використовуйте vault.scope: "agent" із режимом
isolated або bridge, коли агенти не повинні спільно використовувати вікісторінки,
скомпільовані дайджести, результати пошуку чи записи.
Область агента не можна поєднувати з режимом unsafe-local, оскільки налаштовані
приватні шляхи не є вхідними даними, що належать агенту. Перевірка конфігурації відхиляє
таке поєднання.
Режим мосту може індексувати залежно від перемикачів конфігурації bridge.*:
- експортовані артефакти пам’яті (
indexMemoryRoot) - щоденні нотатки (
indexDailyNotes) - звіти Dreaming (
indexDreamReports) - журнали подій пам’яті (
followMemoryEvents)
bridge.readMemoryArtifacts увімкнено,
openclaw wiki status, openclaw wiki doctor та openclaw wiki bridge import спрямовуються через запущений Gateway, тому вони бачать той самий контекст
активного Plugin пам’яті, що й пам’ять агента/середовища виконання. Якщо міст вимкнено
або читання артефактів неактивне, ці команди зберігають локальну/офлайн-поведінку.
Структура сховища
sources/: імпортовані необроблені матеріали та сторінки, що підтримуються мостом абоunsafe-localentities/: довготривалі сутності, люди, системи, проєкти, об’єктиconcepts/: ідеї, абстракції, шаблони, політики (також місце призначення для імпорту OKF)syntheses/: скомпільовані зведення та підтримувані узагальненняreports/: згенеровані панелі огляду
Імпорт Open Knowledge Format
memory-wiki
перетворить його на нативні для OpenClaw сторінки концепцій і скомпільовані дайджести.
- незарезервовані файли
.mdє документами концепцій - кожна імпортована концепція потребує непорожнього поля
typeу frontmatter; відсутнійtypeспричиняє попередженняmissing-type, а файл пропускається - невідомі значення
typeприймаються як загальні концепції index.mdіlog.mdзарезервовані та ніколи не імпортуються як концепції- пошкоджені або зовнішні Markdown-посилання залишаються без змін
concepts/, щоб наявні процеси компіляції, пошуку, отримання та
створення панелей огляду бачили їх без другого дерева вікі. Кожна сторінка зберігає
початковий ідентифікатор концепції OKF, шлях до джерела, type, resource, tags, часову позначку
та повний frontmatter виробника. Внутрішні посилання OKF переписуються на згенеровані
сторінки концепцій вікі, а також створюють структуровані записи relationships із
kind: okf-link.
Структуровані твердження та докази
Сторінки містять структурований frontmatterclaims, а не лише довільний текст. Кожне
твердження може містити id, text, status, confidence, evidence[] і
updatedAt. Кожен запис доказу може містити kind, sourceId, path,
lines, weight, confidence, privacyTier, note і updatedAt.
Завдяки цьому вікі працює як шар переконань, а не пасивне звалище нотаток.
Твердження можна відстежувати, оцінювати, оскаржувати та зіставляти з джерелами.
Метадані сутностей для агентів
Сторінки сутностей містять загальні метадані маршрутизації, придатні для людей, команд, систем, проєктів або будь-яких інших типів сутностей:entityType: наприклад,person,team,system,projectcanonicalId: стабільний ключ ідентичності для псевдонімів та імпортівaliases: імена, облікові назви або мітки, що відповідають тій самій сторінціprivacyTier: рядок довільного формату;publicвважається таким, що не потребує перевірки, а будь-яке інше значення (наприклад,local-private,sensitive,confirm-before-use) позначається уreports/privacy-review.mdbestUsedFor/notEnoughFor: стислі підказки щодо маршрутизаціїlastRefreshedAt: часова позначка оновлення джерела, окрема від часу редагування сторінкиpersonCard: необов’язкова картка маршрутизації для конкретної особи (облікові назви, соціальні мережі, електронні адреси, часовий пояс, напрям, із чим звертатися, із чим не звертатися, упевненість, рівень приватності)relationships: типізовані зв’язки з пов’язаними сторінками (ціль, тип, вага, упевненість, тип доказу, рівень приватності, нотатка)
reports/person-agent-directory.md, а потім відкрийте
сторінку особи за допомогою wiki_get, перш ніж використовувати контактні дані або виведені
факти.
Приклад сторінки сутності
Приклад сторінки сутності
Конвеєр компіляції
Компіляція зчитує вікісторінки, нормалізує зведення та створює стабільні артефакти для машинного використання в:.openclaw-wiki/cache/agent-digest.json.openclaw-wiki/cache/claims.jsonl
Панелі огляду та звіти про стан
Колиrender.createDashboards увімкнено, компіляція підтримує панелі огляду в
reports/:
Пошук і отримання
Два бекенди пошуку:shared: використовує спільний процес пошуку в пам’яті, коли він доступнийlocal: шукає у вікі локально
wiki, memory, all.
wiki_search/wiki_getза можливості використовують скомпільовані дайджести для першого проходу- ідентифікатори тверджень зіставляються зі сторінкою-власником
- оскаржені/застарілі/актуальні твердження впливають на ранжування
- мітки походження даних зберігаються в результатах
--mode / параметр інструмента mode):
Коли результат відповідає структурованому твердженню,
wiki_search повертає
matchedClaimId, matchedClaimStatus, matchedClaimConfidence,
evidenceKinds і evidenceSourceIds у корисному навантаженні деталей. Текстовий результат
за наявності містить стислі рядки Claim: і Evidence:.
Інструменти агентів
Plugin також реєструє невиключне доповнення до корпусу пам’яті, тому спільні
memory_search і memory_get можуть звертатися до вікі, якщо активний Plugin
пам’яті підтримує вибір корпусу.
Поведінка запиту й контексту
Коли ввімкненоcontext.includeCompiledDigestPrompt, до розділів запиту пам’яті
додається компактний скомпільований знімок із agent-digest.json: лише
найважливіші сторінки, лише найважливіші твердження, кількість суперечностей,
кількість запитань, уточнення щодо впевненості й актуальності. Цю функцію
потрібно вмикати явно, оскільки вона змінює структуру запиту; вона переважно
важлива для рушіїв контексту або механізмів формування запитів, які явно
використовують доповнення пам’яті.
Конфігурація
Розмістіть конфігурацію вplugins.entries.memory-wiki.config:
Сховища для окремих агентів
Установіть дляvault.scope значення agent, щоб надати кожному налаштованому
агенту окрему вікі. У цій області vault.path є батьківським каталогом, а
OpenClaw додає нормалізований ідентифікатор агента:
~/.openclaw/wiki/support і
~/.openclaw/wiki/marketing. Якщо vault.path не вказано в області агента,
типовим батьківським каталогом буде ~/.openclaw/wiki. Тому типовий агент
main зберігає наявний шлях ~/.openclaw/wiki/main.
Інструменти агента, скомпільовані дайджести запитів і доповнення вікі, доступне
через memory_search / memory_get, визначають сховище з контексту активного
агента. Для викликів CLI і Gateway у конфігурації з кількома налаштованими
агентами явно вкажіть агента за допомогою openclaw wiki --agent <agentId> ...
або agentId у запиті Gateway. Якщо ідентифікатор не вказано, єдиний
налаштований агент залишається типовим.
У режимі мосту імпорт в області агента приймає загальнодоступний артефакт
пам’яті лише тоді, коли його agentIds містить вибраного агента. Артефакти, що
належать іншому агенту, не мають метаданих власника або мають невідомого
власника, пропускаються. Глобальна область зберігає наявну поведінку спільних
артефактів.
Приклад: QMD + режим мосту
Використовуйте цю конфігурацію, якщо вам потрібен QMD для пригадування, аmemory-wiki — для підтримуваного шару знань. Кожен шар зберігає свою
спеціалізацію: QMD забезпечує пошук у необроблених нотатках, експортованих
сеансах і додаткових колекціях, а memory-wiki компілює стабільні сутності,
твердження, панелі огляду та сторінки джерел.
memory-wiki
зосереджується на скомпільованих сторінках і панелях огляду, а структура запиту
не змінюється, доки ви навмисно не ввімкнете запити зі скомпільованим
дайджестом.
CLI
wiki okf import, wiki apply metadata,
wiki unsafe-local import, wiki chatgpt import / wiki chatgpt rollback і
повний набір підкоманд wiki obsidian, див. у розділі
CLI: вікі.
Підтримка Obsidian
Колиvault.renderMode має значення obsidian, Plugin записує Markdown,
сумісний з Obsidian, і за бажанням може використовувати офіційний CLI
obsidian для перевірки стану, пошуку в сховищі, відкриття сторінки, виклику
команди та переходу до щоденної нотатки. Це необов’язково; вікі продовжує
працювати в нативному режимі без Obsidian.
Сховища для окремих агентів також можуть використовувати Markdown, сумісний з
Obsidian, але перевірка конфігурації відхиляє поєднання
obsidian.useOfficialCli: true із vault.scope: "agent". Поточне налаштування
obsidian.vaultName є глобальним і не може вибирати окреме сховище Obsidian
для кожного агента. Натомість використовуйте інструменти вікі та операції CLI
або залиште вікі під керуванням Obsidian у глобальній області.
Рекомендований робочий процес
1
Збережіть активний Plugin пам’яті для пригадування
Пригадування, просування та Dreaming залишаються у віданні налаштованого
бекенда пам’яті.
2
Увімкніть memory-wiki
Почніть із режиму
isolated, якщо вам явно не потрібен режим мосту.3
Використовуйте wiki_search / wiki_get, коли важливе походження даних
Надавайте їм перевагу над
memory_search, коли потрібне ранжування, специфічне
для вікі, або структура переконань на рівні сторінки.4
Використовуйте wiki_apply для вузькоспрямованого синтезу або оновлення метаданих
Уникайте ручного редагування керованих згенерованих блоків.
5
Запускайте wiki_lint після суттєвих змін
Виявляє суперечності, відкриті запитання та прогалини в походженні даних.
6
Увімкніть панелі огляду для відстеження застарілих даних і суперечностей
Установіть
render.createDashboards: true (типово).