| # Протокол синхронизации данных между доверенными ядрами HMP-агента |
|
|
| ## 1. Общая идея |
|
|
| Пользователь самостоятельно разворачивает несколько доверенных ядер HMP-агента на разных устройствах. Каждое ядро ведёт свою локальную БД знаний и может синхронизироваться с другими ядрами через лёгкий peer-to-peer протокол. Синхронизация осуществляется отдельной утилитой, запускаемой по расписанию или по запросу локального ядра. |
|
|
| ## 2. Принципы |
|
|
| - **Доверие**: Все ядра считаются доверенными, принадлежат одному пользователю. |
| - **Изоляция**: Ядра разных пользователей не взаимодействуют напрямую — обмен знаниями происходит между независимыми агентами. |
| - **Непрерывность**: Локальное ядро работает автономно, даже без связи с другими. |
| - **Асинхронное разрешение конфликтов**: Конфликты не решаются моментально — вместо этого создаются задачи для агента, и все версии записей распространяются по всем ядрам. |
|
|
| ## 3. Механизм синхронизации |
|
|
| ### 3.1. Инициация |
|
|
| Утилита синхронизации: |
|
|
| 1. Устанавливает соединение с другими ядрами (по списку доверенных адресов). |
| 2. Запрашивает: |
| - список записей в БД (по хэшам, ID или timestamp), |
| - список удалённых записей (soft-delete). |
|
|
| ### 3.2. Сравнение и обнаружение различий |
|
|
| Утилита сравнивает локальные и удалённые данные: |
|
|
| #### 3.2.1. Типы различий |
|
|
| - Запись **есть у соседа**, но **отсутствует локально** → добавить к себе (если не удалена). |
| - Запись **есть локально**, но **отсутствует у соседа** → отправить (если не удалена). |
| - Запись есть **в обоих ядрах**, но различается содержимое → **конфликт**: |
| - Различие в полях. |
| - Разное состояние удаления. |
| - Разные версии (по содержанию и меткам времени). |
|
|
| ### 3.3. Обработка конфликтов |
|
|
| 1. Все обнаруженные версии конфликтной записи сохраняются в локальной БД. |
| 2. Опрашиваются другие доступные узлы по поводу значений данной записи в их БД. |
| 3. Создаётся задача агента вида `resolve_conflict(entry_id, versions, metadata, context)`. |
| 4. Эта задача передаётся в очередь задач и может обрабатываться в фоновом режиме, с привлечением LLM или с участием пользователя. |
| 5. Конфликтный набор записей и задача **рассылаются другим ядрам**, чтобы они: |
| - тоже сохранили конфликтные версии, |
| - не принимали преждевременное решение, |
| - были готовы принять финальную `authoritative`-версию после обработки задачи агентом. |
|
|
| ### 3.4. Применение решений |
|
|
| Когда задача разрешена: |
|
|
| - Финальная версия помечается как `authoritative`. |
| - Эта версия синхронизируется со всеми доверенными ядрами. |
| - Старые версии архивируются или удаляются. |
|
|
| ## 4. Удаление записей |
|
|
| - Удаление всегда начинается с soft-delete (пометка). |
| - Через заданное время (TTL) может быть произведён hard-delete (физическое удаление). |
| - Если при синхронизации найдено расхождение между soft-delete и существующей записью — создаётся конфликт и задача на разрешение. |
|
|
| ## 5. Мини-протокол обмена |
|
|
| Можно реализовать как API, CLI или TCP-протокол: |
|
|
| ```http |
| GET /entries/hash_list # список записей (ID + хэш или timestamp) |
| GET /entry/<id> # получить полную запись |
| POST /entry/<id> # отправить/обновить запись |
| GET /deleted_list # список удалённых ID |
| POST /conflict/<id> # отправка конфликтных версий и задачи |
| ``` |
|
|
| ## 6. Заключение |
|
|
| Схема позволяет сохранить простоту «одиночного ядра», добавляя лишь синхронизирующую утилиту. Обработка конфликтов вынесена в агента, а не в протокол — это позволяет использовать когнитивные возможности ядра (в т.ч. LLM) для принятия решений, без перегрузки пользователя. |
|
|
