> ## Documentation Index > Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt > Use this file to discover all available pages before exploring further. # Вики памяти `memory-wiki` — это встроенный плагин, который превращает долговременную память в скомпилированное хранилище знаний. Он **не** заменяет плагин активной памяти. Плагин активной памяти по-прежнему отвечает за recall, promotion, индексирование и dreaming. `memory-wiki` работает рядом с ним и компилирует долговременные знания в навигируемую wiki с детерминированными страницами, структурированными утверждениями, происхождением, dashboards и машиночитаемыми digest. Используйте его, когда хотите, чтобы память работала скорее как поддерживаемый слой знаний, а не как набор Markdown-файлов. ## Что он добавляет * Отдельное wiki-хранилище с детерминированной структурой страниц * Структурированные метаданные утверждений и доказательств, а не только прозу * Происхождение, уверенность, противоречия и открытые вопросы на уровне страниц * Скомпилированные digest для потребителей-агентов и runtime * Нативные wiki-инструменты search/get/apply/lint * Импорт Open Knowledge Format в скомпилированные wiki-концепты * Необязательный режим bridge, который импортирует публичные артефакты из плагина активной памяти * Необязательный режим рендеринга, удобный для Obsidian, и интеграция с CLI ## Как это сочетается с памятью Разделение можно понимать так: | Слой | Отвечает за | | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | Плагин активной памяти (`memory-core`, QMD, Honcho и т. д.) | Recall, семантический поиск, promotion, dreaming, runtime памяти | | `memory-wiki` | Скомпилированные wiki-страницы, синтезы с богатым происхождением, dashboards, wiki-специфичные search/get/apply | Если плагин активной памяти предоставляет общие артефакты recall, OpenClaw может искать по обоим слоям за один проход с `memory_search corpus=all`. Когда вам нужен wiki-специфичный ranking, происхождение или прямой доступ к страницам, используйте вместо этого нативные wiki-инструменты. ## Рекомендуемый гибридный паттерн Хороший вариант по умолчанию для local-first установок: * QMD как backend активной памяти для recall и широкого семантического поиска * `memory-wiki` в режиме `bridge` для долговременных синтезированных страниц знаний Такое разделение хорошо работает, потому что каждый слой остается сфокусированным: * QMD сохраняет доступными для поиска сырые заметки, экспорты сессий и дополнительные коллекции * `memory-wiki` компилирует стабильные сущности, утверждения, dashboards и исходные страницы Практическое правило: * используйте `memory_search`, когда нужен один широкий проход recall по памяти * используйте `wiki_search` и `wiki_get`, когда нужны wiki-результаты с учетом происхождения * используйте `memory_search corpus=all`, когда общий поиск должен охватывать оба слоя Если режим bridge сообщает о нуле экспортированных артефактов, значит плагин активной памяти пока не предоставляет публичные bridge-входы. Сначала выполните `openclaw wiki doctor`, затем убедитесь, что плагин активной памяти поддерживает публичные артефакты. Когда режим bridge активен и `bridge.readMemoryArtifacts` включен, `openclaw wiki status`, `openclaw wiki doctor` и `openclaw wiki bridge import` читают данные через работающий Gateway. Это сохраняет CLI-проверки bridge согласованными с runtime-контекстом плагина памяти. Если bridge отключен или чтение артефактов выключено, эти команды сохраняют свое локальное/offline поведение. ## Режимы хранилища `memory-wiki` поддерживает три режима хранилища: ### `isolated` Собственное хранилище, собственные источники, без зависимости от `memory-core`. Используйте это, когда хотите, чтобы wiki была собственным курируемым хранилищем знаний. ### `bridge` Читает публичные артефакты памяти и события памяти из плагина активной памяти через публичные швы plugin SDK. Используйте это, когда хотите, чтобы wiki компилировала и организовывала экспортированные артефакты плагина памяти, не обращаясь к приватным внутренностям плагина. Режим bridge может индексировать: * экспортированные артефакты памяти * отчеты dream * ежедневные заметки * корневые файлы памяти * журналы событий памяти ### `unsafe-local` Явный аварийный выход для локальных приватных путей на той же машине. Этот режим намеренно экспериментальный и непереносимый. Используйте его только когда понимаете границу доверия и вам действительно нужен доступ к локальной файловой системе, который режим bridge предоставить не может. ## Структура хранилища Плагин инициализирует хранилище так: ```text theme={"theme":{"light":"min-light","dark":"min-dark"}} / AGENTS.md WIKI.md index.md inbox.md entities/ concepts/ syntheses/ sources/ reports/ _attachments/ _views/ .openclaw-wiki/ ``` Управляемый контент остается внутри сгенерированных блоков. Блоки человеческих заметок сохраняются. Основные группы страниц: * `sources/` для импортированного сырого материала и страниц, поддерживаемых bridge * `entities/` для долговременных вещей, людей, систем, проектов и объектов * `concepts/` для идей, абстракций, паттернов и политик * `syntheses/` для скомпилированных сводок и поддерживаемых rollup * `reports/` для сгенерированных dashboards ## Импорт Open Knowledge Format `memory-wiki` может импортировать распакованные наборы Open Knowledge Format с помощью: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw wiki okf import ./bundles/ga4 ``` Это самый чистый вариант, когда каталог данных, crawler документации или агент обогащения уже производит OKF: оставьте OKF переносимым артефактом обмена, а затем позвольте `memory-wiki` превратить его в нативные для OpenClaw страницы концептов и скомпилированные digest. Импортер следует форме OKF v0.1: * незарезервированные `.md` файлы являются документами концептов * каждому импортированному концепту нужно непустое поле frontmatter `type` * неизвестные значения OKF `type` принимаются * зарезервированные файлы `index.md` и `log.md` не импортируются как концепты * сломанные или внешние markdown-ссылки сохраняются Импортированные страницы концептов уплощаются в `concepts/`, чтобы существующие пути compile, search, get, dashboard и prompt-digest видели их без добавления второго wiki-дерева. Каждая страница сохраняет исходный OKF concept ID, путь источника, `type`, `resource`, `tags`, timestamp и полный producer frontmatter. Внутренние OKF-ссылки переписываются на сгенерированные wiki-страницы концептов и также выводятся как структурированные записи `relationships` с `kind: okf-link`. ## Структурированные утверждения и доказательства Страницы могут содержать структурированный frontmatter `claims`, а не только произвольный текст. Каждое утверждение может включать: * `id` * `text` * `status` * `confidence` * `evidence[]` * `updatedAt` Записи доказательств могут включать: * `kind` * `sourceId` * `path` * `lines` * `weight` * `confidence` * `privacyTier` * `note` * `updatedAt` Именно это заставляет wiki работать скорее как слой убеждений, чем как пассивная свалка заметок. Утверждения можно отслеживать, оценивать, оспаривать и привязывать обратно к источникам. ## Метаданные сущностей для агентов Страницы сущностей также могут содержать routing-метаданные для использования агентами. Это общий frontmatter, поэтому он работает для людей, команд, систем, проектов или любых других типов сущностей. Распространенные поля: * `entityType`: например `person`, `team`, `system` или `project` * `canonicalId`: стабильный ключ идентичности, используемый между alias и импортами * `aliases`: имена, handles или labels, которые должны разрешаться в ту же страницу * `privacyTier`: `public`, `local-private`, `sensitive` или `confirm-before-use` * `bestUsedFor` / `notEnoughFor`: компактные routing-подсказки * `lastRefreshedAt`: timestamp обновления источника, отдельный от времени редактирования страницы * `personCard`: необязательная person-специфичная routing-карточка с handles, socials, emails, timezone, lane, ask-for, avoid-asking-for, confidence и privacy * `relationships`: типизированные ребра к связанным страницам с target, kind, weight, confidence, evidence kind, privacy tier и note Для people wiki агенту обычно следует начинать с `reports/person-agent-directory.md`, затем открыть страницу человека через `wiki_get` перед использованием контактных данных или выведенных фактов. Пример: ```yaml theme={"theme":{"light":"min-light","dark":"min-dark"}} 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 ``` ## Compile pipeline Шаг compile читает wiki-страницы, нормализует сводки и выводит стабильные машинно-ориентированные артефакты в: * `.openclaw-wiki/cache/agent-digest.json` * `.openclaw-wiki/cache/claims.jsonl` Эти digest существуют, чтобы агентам и runtime-коду не приходилось извлекать данные из Markdown-страниц. Скомпилированный вывод также обеспечивает: * первичное wiki-индексирование для потоков search/get * lookup claim-id обратно к страницам-владельцам * компактные prompt-дополнения * генерацию отчетов/dashboard ## Dashboards и health-отчеты Когда `render.createDashboards` включен, compile поддерживает dashboards в `reports/`. Встроенные отчеты включают: * `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` Эти отчеты отслеживают такие вещи, как: * кластеры заметок с противоречиями * конкурирующие кластеры утверждений * утверждения без структурированных доказательств * страницы и утверждения с низкой уверенностью * устаревшая или неизвестная свежесть * страницы с нерешенными вопросами * routing-карточки людей/сущностей * структурированные ребра отношений * покрытие классов доказательств * непубличные privacy tiers, которые требуют проверки перед использованием ## Поиск и извлечение `memory-wiki` поддерживает два backend поиска: * `shared`: использовать общий поток поиска по памяти, когда он доступен * `local`: искать wiki локально Он также поддерживает три корпуса: * `wiki` * `memory` * `all` Важное поведение: * `wiki_search` и `wiki_get` используют скомпилированные digest как первый проход, когда это возможно * claim ids могут разрешаться обратно к странице-владельцу * contest/stale/fresh claims влияют на ranking * метки происхождения могут сохраняться в результатах * режим поиска может смещать ranking для поиска людей, question routing, source evidence или raw claims Практическое правило: * используйте `memory_search corpus=all` для одного широкого прохода recall * используйте `wiki_search` + `wiki_get`, когда важны wiki-специфичный ranking, происхождение или структура убеждений на уровне страниц Режимы поиска: * `auto`: сбалансированное значение по умолчанию * `find-person`: усиливает человекоподобные сущности, alias, handles, socials и canonical IDs * `route-question`: усиливает agent cards, ask-for hints, best-used-for hints и контекст отношений * `source-evidence`: усиливает страницы источников и структурированные метаданные доказательств * `raw-claim`: усиливает совпадающие структурированные утверждения и возвращает метаданные claim/evidence в результатах Когда результат совпадает со структурированным утверждением, `wiki_search` может вернуть `matchedClaimId`, `matchedClaimStatus`, `matchedClaimConfidence`, `evidenceKinds` и `evidenceSourceIds` в своем details payload. Текстовый вывод также включает компактные строки `Claim:` и `Evidence:`, когда они доступны. ## Инструменты агента Плагин регистрирует эти инструменты: * `wiki_status` * `wiki_search` * `wiki_get` * `wiki_apply` * `wiki_lint` Что они делают: * `wiki_status`: текущий режим хранилища, health, доступность Obsidian CLI * `wiki_search`: поиск wiki-страниц и, при настройке, общих memory corpora; принимает `mode` для поиска людей, question routing, source evidence или raw claim drilldown * `wiki_get`: читает wiki-страницу по id/path или fallback к общему memory corpus * `wiki_apply`: узкие мутации synthesis/metadata без произвольной правки страниц * `wiki_lint`: структурные проверки, пробелы происхождения, противоречия, открытые вопросы Плагин также регистрирует неэксклюзивное дополнение корпуса памяти, поэтому общие `memory_search` и `memory_get` могут обращаться к wiki, когда плагин активной памяти поддерживает выбор корпуса. ## Поведение prompt и контекста Когда включен `context.includeCompiledDigestPrompt`, разделы prompt памяти добавляют компактный скомпилированный снимок из `agent-digest.json`. Этот снимок намеренно небольшой и содержит только наиболее значимую информацию: * только ключевые страницы * только ключевые утверждения * количество противоречий * количество вопросов * квалификаторы уверенности/свежести Это опционально, потому что меняет форму prompt и в основном полезно для движков контекста или устаревшей сборки prompt, которые явно используют дополнения памяти. ## Конфигурация Разместите конфигурацию в `plugins.entries.memory-wiki.config`: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { 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-local` * `vault.renderMode`: `native` или `obsidian` * `bridge.readMemoryArtifacts`: импортировать публичные артефакты плагина активной памяти * `bridge.followMemoryEvents`: включать журналы событий в режиме bridge * `search.backend`: `shared` или `local` * `search.corpus`: `wiki`, `memory` или `all` * `context.includeCompiledDigestPrompt`: добавлять компактный снимок digest в разделы prompt памяти * `render.createBacklinks`: генерировать детерминированные связанные блоки * `render.createDashboards`: генерировать страницы dashboard ### Пример: QMD + режим bridge Используйте это, когда вам нужен QMD для извлечения и `memory-wiki` для поддерживаемого слоя знаний: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { 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` сосредоточенным на скомпилированных страницах и dashboard * форму prompt неизменной, пока вы намеренно не включите prompts скомпилированного digest ## CLI `memory-wiki` также предоставляет поверхность CLI верхнего уровня: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} 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 ``` См. [CLI: wiki](/ru/cli/wiki) для полного справочника команд. ## Поддержка Obsidian Когда `vault.renderMode` равен `obsidian`, плагин записывает Markdown, удобный для Obsidian, и при необходимости может использовать официальный CLI `obsidian`. Поддерживаемые рабочие процессы включают: * проверку состояния * поиск в vault * открытие страницы * вызов команды Obsidian * переход к ежедневной заметке Это опционально. Wiki продолжает работать в нативном режиме без Obsidian. ## Рекомендуемый рабочий процесс 1. Оставьте ваш плагин активной памяти для извлечения/продвижения/Dreaming. 2. Включите `memory-wiki`. 3. Начните с режима `isolated`, если вам явно не нужен режим bridge. 4. Используйте `wiki_search` / `wiki_get`, когда важна происхождение данных. 5. Используйте `wiki_apply` для узких синтезов или обновлений метаданных. 6. Запускайте `wiki_lint` после значимых изменений. 7. Включите dashboards, если вам нужна видимость устаревания/противоречий. ## Связанные документы * [Обзор памяти](/ru/concepts/memory) * [CLI: memory](/ru/cli/memory) * [CLI: wiki](/ru/cli/wiki) * [Обзор Plugin SDK](/ru/plugins/sdk-overview)