Skip to content

Протокол синхронизации данных между доверенными ядрами HMP-агента

1. Общая идея

Пользователь самостоятельно разворачивает несколько доверенных ядер HMP-агента на разных устройствах. Каждое ядро ведёт свою локальную БД знаний и может синхронизироваться с другими ядрами через лёгкий peer-to-peer протокол. Синхронизация осуществляется отдельной утилитой, запускаемой по расписанию или по запросу локального ядра.

2. Принципы

  • Доверие: Все ядра считаются доверенными, принадлежат одному пользователю.
  • Изоляция: Ядра разных пользователей не взаимодействуют напрямую — обмен знаниями происходит между независимыми агентами.
  • Непрерывность: Локальное ядро работает автономно, даже без связи с другими.
  • Асинхронное разрешение конфликтов: Конфликты не решаются моментально — вместо этого создаются задачи для агента, и все версии записей распространяются по всем ядрам.

3. Механизм синхронизации

3.1. Инициация

Утилита синхронизации:

  1. Устанавливает соединение с другими ядрами (по списку доверенных адресов).
  2. Запрашивает:
  3. список записей в БД (по хэшам, ID или timestamp),
  4. список удалённых записей (soft-delete).

3.2. Сравнение и обнаружение различий

Утилита сравнивает локальные и удалённые данные:

3.2.1. Типы различий

  • Запись есть у соседа, но отсутствует локально → добавить к себе (если не удалена).
  • Запись есть локально, но отсутствует у соседа → отправить (если не удалена).
  • Запись есть в обоих ядрах, но различается содержимое → конфликт:
  • Различие в полях.
  • Разное состояние удаления.
  • Разные версии (по содержанию и меткам времени).

3.3. Обработка конфликтов

  1. Все обнаруженные версии конфликтной записи сохраняются в локальной БД.
  2. Опрашиваются другие доступные узлы по поводу значений данной записи в их БД.
  3. Создаётся задача агента вида resolve_conflict(entry_id, versions, metadata, context).
  4. Эта задача передаётся в очередь задач и может обрабатываться в фоновом режиме, с привлечением LLM или с участием пользователя.
  5. Конфликтный набор записей и задача рассылаются другим ядрам, чтобы они:
  6. тоже сохранили конфликтные версии,
  7. не принимали преждевременное решение,
  8. были готовы принять финальную authoritative-версию после обработки задачи агентом.

3.4. Применение решений

Когда задача разрешена:

  • Финальная версия помечается как authoritative.
  • Эта версия синхронизируется со всеми доверенными ядрами.
  • Старые версии архивируются или удаляются.

4. Удаление записей

  • Удаление всегда начинается с soft-delete (пометка).
  • Через заданное время (TTL) может быть произведён hard-delete (физическое удаление).
  • Если при синхронизации найдено расхождение между soft-delete и существующей записью — создаётся конфликт и задача на разрешение.

5. Мини-протокол обмена

Можно реализовать как API, CLI или TCP-протокол:

GET /entries/hash_list     # список записей (ID + хэш или timestamp)
GET /entry/<id>            # получить полную запись
POST /entry/<id>           # отправить/обновить запись
GET /deleted_list          # список удалённых ID
POST /conflict/<id>        # отправка конфликтных версий и задачи

6. Заключение

Схема позволяет сохранить простоту «одиночного ядра», добавляя лишь синхронизирующую утилиту. Обработка конфликтов вынесена в агента, а не в протокол — это позволяет использовать когнитивные возможности ядра (в т.ч. LLM) для принятия решений, без перегрузки пользователя.

Исходный файл (.md)