File size: 3,111 Bytes
a82c38a |
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 |
### 💡 **Лёгкая версия HMP-агента с общей БД**
#### 📘 Общая концепция
* Все ядра работают с одной локальной базой данных (например, SQLite или PostgreSQL).
* При недоступности БД ядро "спит" (в режиме ожидания).
* Основная задача такой архитектуры — упрощённая параллельная работа HMP-ядер (например, несколько REPL-агентов на одной машине или кластере).
---
### 📍 Потенциальные проблемы и решения
#### 🔁 1. Коллизии при одновременной записи
**Проблема:** два ядра могут одновременно читать-записывать одну и ту же запись, не зная о действиях друг друга.
**Решения:**
* Использование транзакций и `SELECT ... FOR UPDATE`.
* Ведение версии записи (`version`, `updated_at`) для обнаружения изменений между чтением и записью.
* Конфликт может быть автоматически переведён в статус "нужна доработка" — и отправлен агенту.
#### 🧠 2. Смысловые конфликты (двойники)
**Проблема:** два ядра могут независимо создать записи с похожим смыслом, не зная о друг друге.
**Решения:**
* Ввести периодическую задачу **"смысловой дедупликации"**, которая запускается одним из агентов (или планировщиком).
* Агент анализирует семантическую близость новых записей к уже существующим и предлагает объединение или уточнение.
* Возможность помечать записи как `дубль`, `связано_с`, `вариант`.
---
### 🔗 Потенциальное расширение
Эта архитектура может служить промежуточной ступенью:
* В будущем к ней можно подключить модуль синхронизации между узлами (и трансформировать в полноценную распределённую сеть).
* Конфликтный модуль и задачи для агента уже сейчас можно реализовать аналогично полной версии.
---
### 💬 Поддержка задач
Можно ввести таблицу `tasks`, куда ядра будут ставить задания:
* `resolve_conflict`
* `deduplicate`
* `compress_semantic_cluster`
* `verify_coherence`
И агенты будут выполнять эти задания асинхронно.
|