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_4a8f2c1d9e3b
layer: shallow
created: 2025-04-20T14:30:00+00:00
last_touched: 2025-04-21T09:15:00+00:00
density: 0.4
streak: 2
decay_days: 7
tags: [auth, oauth2]
status: active
source_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 Protocol
infrastructure/
  filesystem_memory_repository   ← вся логика работы с файлами
  lock_manager                   ← файловые замки
  journal                        ← журнал операций
  policy                         ← правила и rate limit
  telemetry                      ← метрики по инструментам
domain/
  models, errors, repository     ← типы, ошибки, Protocol

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

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

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

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

SEDIMENT_PROJECT_ROOT=/path/to/your/project
SEDIMENT_TIMEOUT_DEFAULT_SECONDS=2.0
SEDIMENT_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

Комментарии (0)