Sediment Palace: локальная память для AI-агентов с моделью седиментации

от автора

AI-агенты в 2025 году умеют почти всё. Одного хорошо не умеют — помнить. Я взял две чужие идеи и склеил их.

Сгенерировано AI

Сгенерировано AI

Предисловие

Прежде чем начать — да, я в курсе. В этом году уже был «memory palace для AI». С рекордными бенчмарками, собственным языком AAAK ( усечённый диалект английского, созданный не для людей, а для ИИ, авторы MemPalace заявляли, что он даёт сжатие в 30 раз без потери информации) и последующим расследованием на Хабре, где выяснилось про мемкоин, поддельные результаты и плагиат у Дженнифер Пёрл.

Этот проект другой. Бенчмарков нет, монеты нет, и код реально работает.

Теперь по существу.

Что решает приложение

Типичная сценка: вы неделю работаете с агентом над проектом. Он знает архитектуру, понимает что вы имеете в виду под «тем самым коннектором», помнит что вы не любите комментарии в коде. Потом вы открываете новую сессию.

Всё. Привет, я Claude, чем могу помочь?

Существующие решения обычно идут двумя путями. Первый: суммировать контекст в один большой кусок и прикладывать к каждому запросу — дорого по токенам, плохо масштабируется. Второй: RAG поверх векторной БД — требует инфраструктуры, непрозрачно, зависит от качества эмбеддингов.

Sediment Palace — третий путь: обычные markdown-файлы на диске, структурированные по слоям важности, с автоматическим старением и продвижением.

Синтез двух концепций

Первая — «дворец памяти» для AI, пространственная организация через «комнаты» и «крылья». Идея появилась в экосистеме MemPalace, и концептуально она работает — каким бы спорным ни оказался конкретный проект.

Вторая — седиментация — подсмотрена в одной статье на Хабре про управление знаниями. Метафора точная: знания как геологические слои. Свежее лежит сверху, важное со временем оседает глубже, а мусор разрушается.

Я совместил одно с другим. Если авторы оригинальных идей почувствуют себя ущемлёнными — ссылка на репозиторий открыта, пишите в личку, разберёмся.

Как это устроено

Слои памяти

Память разбита на пять директорий:

01_Shallow — свежие наблюдения, гипотезы, временные заметки. По умолчанию живут 7 дней.

02_Sediment — то что выжило и оказалось нужным. До 60 дней.

03_Bedrock — кристаллизованное знание. decay_days: 36500, можно считать постоянным.

_Archive — куда уходят записи при распаде.

_System — журнал операций, метрики, policy.

Каждый файл памяти — это обычный markdown с YAML-фронтматтером:

---id: mem_4a8f2c1d9e3blayer: shallowcreated: 2025-04-20T14:30:00+00:00last_touched: 2025-04-21T09:15:00+00:00density: 0.4streak: 2decay_days: 7tags: [auth, oauth2]status: activesource_session: mcp_session---Решили использовать PKCE вместо client_secret. Причина: мобильные клиентыне могут безопасно хранить секрет.

density — оценка агентом ценности записи (0.0–1.0). streak — счётчик: растёт если запись регулярно читается, падает если нет. Эти два параметра решают судьбу файла при метаболизации.

Метаболизм

Раз в некоторое время агент вызывает metabolize. Операция обходит все файлы и принимает решения по правилам:

Shallow → Sediment: density >= 0.5 и файл старше порога.

Shallow → Archive: density < 0.5 и streak <= -2.

Sediment → Bedrock: возраст больше 30 дней и density >= 0.8 или streak >= 5.

# посмотреть что произойдёт без измененийresult = repo.metabolize(dry_run=True, days_threshold=7)# {'dry_run': True, 'scanned': 42, 'promoted_count': 3, 'archived_count': 1}# запустить по-настоящемуresult = repo.metabolize(confirm=True)

Параметр dry_run показывает что бы произошло — удобно проверять перед первым запуском.

MCP-транспорт

Сервер реализует Model Context Protocol — JSON-RPC 2.0 поверх stdin/stdout. Подключается к любому агенту, умеющему работать с MCP: Claude Code, Cursor, любой кастомный агент через SDK.

Доступные инструменты:

  • write_memory — сохранить запись в слой

  • read_memory — прочитать по пути или полнотекстовому запросу

  • search_room — поиск в конкретной директории

  • move_file — переместить запись в другой слой вручную

  • metabolize — запустить цикл старения

  • purge_memory — удалить с архивацией (требует confirm: true)

  • recover_journal — восстановить незавершённые операции после краша

  • get_metrics, healthcheck — служебные

Несколько деталей реализации

Атомарные записи. Каждый файл пишется через временный .tmp с последующим replace(). Краш посередине не оставит повреждённый файл.

Файловые замки. Конкурентный доступ к одному файлу разрешается через lock-файлы, созданные через O_CREAT | O_EXCL — единственный атомарный способ на файловой системе без сторонних библиотек. Зависшие замки (>30 секунд) убираются автоматически.

Journal и crash recovery. Каждая мутирующая операция пишет started до выполнения и completed после. Процесс упал между ними — recover_journal найдёт незавершённые операции и разберётся с состоянием.

Path traversal. Все пути резолвятся через Path.resolve() и проверяются на принадлежность memory_root. Попытка уйти через ../../ даёт path_violation.

Policy engine. Деструктивные операции требуют явного confirm: true. Rate limit: 20 деструктивных операций в 60 секунд по умолчанию, настраивается через policy.yaml.

Архитектура

transport/server.py              ← JSON-RPC, валидация входа, таймаутыapplication/memory_service.py    ← тонкий сервис, принимает MemoryRepository Protocolinfrastructure/  filesystem_memory_repository   ← вся логика работы с файлами  lock_manager                   ← файловые замки  journal                        ← журнал операций  policy                         ← правила и rate limit  telemetry                      ← метрики по инструментамdomain/  models, errors, repository     ← типы, ошибки, Protocol

Внешняя зависимость одна — pyyaml. Больше ничего.

Как попробовать

git clone https://github.com/dev993848/sediment-palacepip install -e .python -m sediment_palace

Конфигурация через переменные окружения:

SEDIMENT_PROJECT_ROOT=/path/to/your/projectSEDIMENT_TIMEOUT_DEFAULT_SECONDS=2.0SEDIMENT_BUDGET_WRITE_CONTENT=50000

Для Claude Code в .mcp.json:

{  "mcpServers": {    "sediment-palace": {      "command": "python",      "args": ["-m", "sediment_palace"],      "env": {        "SEDIMENT_PROJECT_ROOT": "${workspaceFolder}"      }    }  }}

После подключения агент пишет в память через write_memory, читает через read_memory и периодически вызывает metabolize.

Итого

Память для агентов — задача без идеального решения. Sediment Palace достаточно прост, чтобы его можно было читать, понимать и менять под себя. Всё хранится в файлах, которые открываются в любом редакторе. Никакой магии.

Если подход кажется полезным — берите, форкайте. Если нашли проблему — issues открыты.

И да. Мемкоина нет.

Github — https://github.com/dev993848/sediment-palace

ссылка на оригинал статьи https://habr.com/ru/articles/1026126/