EnglishРусский Map

LLM Wiki как субстрат памяти агентов

Wiki conceptpkmai-agentsmemoryllm ↳ show in map Markdown
title
LLM Wiki как субстрат памяти агентов
type
concept
summary
Паттерн вики Карпатого становится хранилищем для памяти агентов: читаемый Markdown и grep вместо непрозрачной векторной базы
tags
pkm, ai-agents, memory, llm
created
2026-07-21
updated
2026-09-14
lang
ru
translation_of
llm-wiki-as-agent-memory
source_updated
2026-09-14
translated
2026-09-14
translator
lllm/antigravity/gemini-3.7-flash-medium

llm-wiki-pattern зарождался как приём для управления личными знаниями: LLM читает источники и поддерживает связную Markdown-вики вместо того, чтобы заново выводить ответы из документов при каждом запросе. В 2026 году он перестал быть просто приёмом и превратился в архитектурное решение для хранения данных, к которому сходятся готовые продукты для памяти агентов.

Конвергенция

Три независимых проекта на разных языках и для разной аудитории выбрали один и тот же субстрат:

  • CodeAlmanac применяет его к кодовой базе. Вики хранится простым Markdown'ом в каталоге almanac/ репозитория, проходит ревью в Git наравне с кодом и фиксирует то, чего в коде не выразить: архитектурные решения, инварианты, неочевидные грабли и потоки данных между сервисами.
  • agentmemory ссылается на паттерн напрямую: в проектном документе сказано, что он "расширяет паттерн LLM Wiki Карпатого оценкой уверенности, жизненным циклом, графами знаний и гибридным поиском", а репозиторий представляет собой реализацию этого документа.
  • OpenHuman сжимает личные данные в Markdown-деревья с оценками важности в SQLite и дублирует их в виде Obsidian-vault'а по Карпатому, цитируя тот же источник и называя альтернативы "чёрным ящиком из векторного супа".

Разница между ними показательна: кодовая база, история сессий coding-агента и вся цифровая жизнь человека. Паттерн выбирают по причинам, которые остаются в силе при любой смене предметной области.

Почему Markdown со ссылками выигрывает у векторных баз

Преимущества подхода связаны с самим артефактом, а не с механикой поиска:

  • Прозрачность для инспекции. Память можно открыть и прочитать, что именно агент думает о вас или вашем коде. Содержимое векторной базы невозможно осмысленно прочесть, поэтому ошибки остаются незамеченными, пока не приведут к неверному ответу.
  • Ручное редактирование. Неправильные воспоминания можно исправить напрямую. Это важнее, чем кажется: проблема memory-conflict-detection решается куда проще, когда человек может просто отредактировать страницу.
  • Поддержка diff и ревью. Решение CodeAlmanac хранить вики прямо в репозитории означает, что изменения памяти проходят через код-ревью. Это сильнейший аргумент в пользу подхода: память становится проверяемым артефактом, а не слепо накопленным состоянием.
  • Портируемость и поиск через grep. Обычные файлы переживут инструмент, который их создал. Запись в списке наблюдения atomicapp предупреждает как раз об обратном: если всё завязано только на SQLite, искать данные обычным grep'ом уже не выйдет.
  • Готовая единица для выборки. Страница вики по размеру примерно соответствует полезной порции контекста для инъекции. Проблема нарезки на куски (chunking), вокруг которой строится весь дизайн RAG, практически исчезает, когда автор изначально пишет текст порциями размером в страницу.

Минус в том, что в Markdown нет встроенных понятий уверенности, актуальности или угасания. Из-за этого agentmemory надстраивает поверх оценку и жизненный цикл, а OpenHuman держит дерево с оценками в SQLite, используя vault как зеркало. При этом от файлов никто не отказывается.

memoryfields превращает ту же ставку в спецификацию формата файлов: Markdown-страницы плюс удаляемый векторный индекс SQLite в одном архиве. Там отказались от навигации по wikilink'ам в пользу семантического поиска, сохранив читаемый артефакт ценой отказа от графа.

Связь с другими инструментами памяти

Остальные страницы вики о памяти агентов описывают системы, построенные противоположным образом. Проекты вроде hippo-memory и mempalace ставят во главу угла хранилище, к которому сбоку прикручены Markdown-зеркала; agent-memory-components разделяет любую подобную систему на модуль извлечения, хранилище и поисковик. В этой схеме паттерн LLM Wiki отвечает именно на вопрос хранилища - и перекладывает часть работы на модуль извлечения, поскольку для создания памяти в форме страницы LLM должна писать связный текст, а не просто выдавать набор утверждений.

Ещё одна характерная черта - шаг ухода за базой ("садоводство"). CodeAlmanac ежедневно запускает задачу Garden по устаревшим страницам, дубликатам, слабым связям и неподтверждённым утверждениям; в этом vault'е аналогичную роль играет процесс /lint. Это регулярная цена обслуживания, которую требует Markdown и от которой избавлены векторные базы: векторное хранилище никогда не выдаёт явных внутренних противоречий, оно просто начинает хуже искать.

Ограничения и оговорки

  • Популярность не означает подтверждения концепции. Два из трёх упомянутых проектов запустились недавно и набрали много звёзд, но количество звёзд не доказывает правильность выбора субстрата. Важен сам факт схождения разных авторов в одной точке при различных ограничениях, а не популярность.
  • Превосходство над векторными базами в поиске пока не доказано. Собственные показатели agentmemory в LongMemEval получены благодаря гибридному поиску поверх хранилища, а не за счёт формата Markdown. Главные аргументы в пользу паттерна - это аудит и переносимость, а не полнота выборки.
  • Масштабирование требует живого смотрителя, а не просто мощностей. Каждой из этих систем нужен регулярный проход LLM для поддержания связности графа, а это постоянные расходы, пропорциональные размеру вики.

Связанные страницы

Linked from