File size: 5,913 Bytes
aadd3ed |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
# Протокол синхронизации данных между доверенными ядрами 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) для принятия решений, без перегрузки пользователя.
|