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