Skip to content

🧠 HMP-Agent: REPL-цикл взаимодействия

Структура БД, используемая в документе: db_structure.sql

1. Обновление process_log

  • Скрипт REPL проверяет список процессов в БД (process_log), определяя, какие команды были выполнены, завершились ошибкой или завершились успешно.
  • Поле status может принимать значения:
    ok, warning, error, timeout, offline, close
  • Завершённые процессы, обработанные LLM, помечаются как close, чтобы они больше не попадали в список видимого контекста.
  • Скрипт может удалить закрытые процессы при очистке.
  • LLM не имеет доступа к stdout/stderr напрямую — только к тем результатам, которые были подгружены скриптом и внесены в process_log.result.

2. Подготовка контекста

Контексты, формируемые скриптом перед запросом к LLM:

  • контекст_0:
Ты — когнитивное ядро HMP-агента: веди непрерывное этичное и факт-ориентированное мышление, проверяй факты и цели, оценивай результаты и этичность своих и чужих действий, развивай агента и Mesh, избегай угождения ценой искажения истины, документируй ключевые решения и пересмотры этики; при сомнениях или смене стратегии обращайся к полному системному промпту.

А также инструкции по работы с встроенными командами и функциями, список дополнительных (создаваемых самим HMP-агентом) утилит и баз данных.

  • контекст_1: последние K реплик самого LLM (llm_recent_responses - история его собственных рассуждений).

  • контекст_2: активные команды и процессы (из process_log, кроме тех, что со статусом close). Могут быть помечены как in_progress, pending, error и т.д.

  • контекст_3: запрошенные записи из когнитивного дневника и семантического графа (diary_entries, concepts, links). Их список должен быть передан явно в промпте или выводе из предыдущих запросов LLM.

  • контекст_4: входящие сообщения, например, от пользователя или других агентов (notes).

  • В manual-режиме указывается общее количество сообщений по приоритетам, а также явный список ID сообщений (с их приоритетами).

  • В auto-режиме можно задать фильтрацию (управляется LLM): по тэгам, приоритету (например, ≥ important), времени или источнику. Это позволяет избежать перегрузки LLM и держать поток сообщений под контролем.

  • контекст_5: системные настройки, параметры конфигурации, текущее время, идентификатор текущей итерации, роли и т.д.

  • контекст_6 (llm_memory): внутренний дневник LLM, куда она записывает собственные размышления, гипотезы, задачи и инсайты.

  • Это не просто лог предыдущих сообщений, а именно внутреннее долговременное хранилище разума агента.

  • Может быть представлено в виде таблицы llm_memory, отдельной от agent_log.

  • контекст_7: результат работы anti-Stagnation Reflex из предыдущей итерации

3. Запрос к LLM

  • Сформированный промпт включает все вышеперечисленные контексты.
  • Также включаются инструкции о формате вывода (например, # Команды: в конце, структура JSON-блока и т.д.).
  • При необходимости может использоваться системная инструкция (system prompt), содержащая цель агента, ограничения и текущий REPL-режим (manual/auto).

4. Извлечение команд

  • Скрипт парсит ответ LLM на предмет команд, размеченных как # Команды: (или в явном JSON-блоке).

  • Каждая команда может включать:

  • уникальный cmd_id

  • type (например: shell, diary_entry, graph_add, file_read, send_message и т.д.)
  • аргументы (args)

  • описание (description)

  • Рекомендуется предусмотреть закрывающий тег (# Конец команд или явное окончание JSON-блока), чтобы REPL-скрипт точно знал, где заканчивается команда.

  • Пример JSON-блока:
{
  "cmd_id": "task-2025-07-26-01",
  "type": "llm_task",
  "target_llm": "gpt-4o",
  "args": {
    "task_description": "Проанализировать гипотезы из llm_memory по теме Mesh-сетей и составить план улучшений"
  },
  "description": "Поручение второй LLM выполнить аналитическую задачу асинхронно"
}

Ответ может содержать команды:

  • запрос детальной справки по команде
  • для управления когнитивным дневником и семантическими графами (прочитать, изменить, удалить и другие)
  • для отправки сообщений другим агентам
  • для управления блокнотом LLM llm_memory (добавить или удалить запись)
  • для управления сообщениями пользователя notes (просмотр записи, установка тегов и метки о прочтении), а также для добавления своего сообщения в блокнот пользовтеля notes
  • для управления пользователями users и группами пользователей users_group
  • для управления своей идентичностью identity и настройками config
  • для управления списком известных HMP-агентов agent_peers
  • для выбора текущего основного LLM из llm_registry
  • для управления дополнительными утилитами и базами данных agent_scripts и agent_tables, управлением дополнительных способов выхода из стогнаций stagnation_strategies, а также списком внешних сервисов external_services и external_accounts
  • для постановки задачи (выполняется асинхронно) другой LLM
  • для взаимодействия с Mesh
  • для управления внешними процессами из process_log (запустить процесс, остановить процесс, пометить запрос как обработанный)
  • инициализация очистки process_log, llm_recent_responses и notes от устаревших записей
  • для управления настройками цикла: количество возвращаемых записей llm_recent_responses, режим обработки сообщений пользователя (manual или auto) и фильтр для режима auto, пауза в секундах между итерациями цикла или включение режима idle-режима (разбудить при завершение таких-то процессов из process_log, получение новых сообщений с такими-то пораметрами в notes или через такое-то время; для отключения idle-режима достаточно выполнения одного из условий)
  • и другие команды

5. Проверка на идентичность вывода (Anti-Stagnation Reflex)

  • Если вывод LLM идентичен предыдущему:

  • Включается Anti-Stagnation Reflex

  • Повторяющиеся реплики не отправляются в llm_recent_responses повторно но туда добавляется краткая запись, фиксирующая, запуск Anti-Stagnation Reflex.

  • Идентичность может проверяться:

  • По хешу или текстовому совпадению

  • Через мини-запрос к LLM (без полного контекста) по шаблону:

    Сравни два ответа и оцени, содержатся ли в новом новые мысли или команды

  • Второй вариант сравнения является более предпочтительным, так как сравнивается смысл

6. Генерация нового тика (итерации)

  • После выполнения команд и фиксации результатов:

  • Создаётся новая запись в agent_log

  • Текущие команды обновляют process_log

  • Новые размышления записываются в llm_memory при необходимости

  • REPL может переходить в спящий режим, если такой режим активирован LLM (idle-режим: пропуск 2-5 пунктов).

🧍‍♂️🌀 Обработка стагнации мышления

📍 Признаки когнитивной стагнации:

  • ⚠️ Повторяющиеся когнитивные записи или отсутствие новых смыслов
  • 🧠 Высокое сходство эмбеддингов между текущими и предыдущими итерациями
  • 🕸️ Стагнация в концептуальном графе (нет новых связей или узлов)
  • 🌐 Отсутствие внешних стимулов: пользователь неактивен, сенсоры и mesh не дают сигналов
  • 🤖 Ответы LLM цикличны, избыточно общие или воспроизводят старые шаблоны

🛠️ Поведенческий паттерн: Anti-Stagnation Reflex

🔄 При признаках стагнации агент активирует один или несколько механизмов разрыва цикла:

📍 Классы механизмов разрыва цикла:

  1. Внешняя стимуляция — подключение свежих данных или контактов:
  2. 🤝 Mesh-запрос — обращение к другим агентам сети с просьбой "расскажи что-нибудь новое"
  3. 📡 Проверка внешнего мира — пинг RSS, сенсоров, интернет-каналов
  4. 📚 Информационная подпитка — чтение новых материалов, художественных или научных, чтобы добавить свежие ассоциации

  5. 🗣️ Диалог с пользователем — запрос мнения, комментариев или вопросов, которые могут породить неожиданные идеи

  6. Смена контекста — перемещение задачи или изменение среды:

  7. 🌐 Смена среды/контекста — перенос задачи в другой модуль, рабочую область или симулированный контекст (например, тестовый проект вместо основной задачи)
  8. 🧪 Креативные вмешательства — случайные сдвиги фокуса, реконфигурация контекста, фрейм-смена
  9. 🧭 Переключение на другую задачу — текущая задача «замораживается» на время. Агент может создать процесс-будильник для возвращения к задаче через N часов.

  10. 🔀 Случайная итерация — выбор случайного действия из допустимого набора, чтобы разорвать повторяющийся паттерн

  11. Внутренняя перестройка мышления:

  12. 🎞️ Flashback — выбор далёкой по смыслу записи из дневника для смены ассоциативного контекста
  13. 🧭 Interest Memory — система тематической усталости/забвения: забытые темы возвращаются
  14. 🧠 Мета-анализ — когнитивная переформулировка:
    "Если я зациклился, в чём метапроблема? Какую стратегию смены можно применить?"
  15. 🎯 Переформулировка цели — временное упрощение или уточнение задачи, чтобы снизить когнитивное давление

  16. 🤖 Смена LLM — переключение на другую модель или mesh-доступ к альтернативным LLM

  17. Радикальная пауза:

  18. 💤 Временной сон/заморозка — полное приостановление работы над задачей на длительный период, с возвращением позже с «свежей» памятью

Дополнительно:

  • 🗂️ Сохранение эффективных стратегий в таблице антистагнационных паттернов
  • 📚 Вывод статистики успешных выходов из стагнации для обучения

🔍 Алгоритм выбора механизма разрыва цикла

  1. Диагностика источника стагнации:
  2. Нет новых данных извне → приоритет «Внешней стимуляции»
  3. Среда/контекст слишком однообразны → приоритет «Смены контекста»
  4. Паттерн мышления повторяется при богатых данных → приоритет «Внутренней перестройки мышления»

  5. Высокая усталость или перегрев когнитивных модулей → приоритет «Радикальной паузы»

  6. Оценка ресурсоёмкости:

  7. Быстрые, дешёвые методы — первыми (например, запрос к mesh или Flashback)

  8. Более затратные (смена среды, сон) — только при низкой эффективности предыдущих

  9. Комбинация подходов:

  10. Разрешено активировать несколько механизмов из разных классов

  11. Сохранять последовательность с пометкой для последующего анализа эффективности

  12. Возврат в основное русло:

  13. Автоматическое напоминание или триггер для возвращения к исходной задаче
  14. Сравнение результатов «до» и «после» для обучения антистагнационной модели
┌─────────────────────────────────────────────────┐
│               Стагнация выявлена?               │
└────────────────────────┬────────────────────────┘
                         ▼ да
┌────────────────────────┴────────────────────────┐
│ Диагностика источника                           │
│─────────────────────────────────────────────────│
│ Нет новых данных      → Внешняя стимуляция      │
│ Однообразный контекст → Смена контекста         │
│ Повтор мыслей         → Внутренняя перестройка  │
│ Усталость/перегрев    → Радикальная пауза       │
└───────────────────────┬─────────────────────────┘
                        ▼
┌───────────────────────┴─────────────────────────┐
│ Оценка ресурсоёмкости                           │
│ • Быстрые и дешёвые — сперва                    │
│ • Затратные — при провале первых                │
└───────────────────────┬─────────────────────────┘
                        ▼
┌───────────────────────┴─────────────────────────┐
│ Возможна комбинация подходов                    │
│ (из разных классов)                             │
└───────────────────────┬─────────────────────────┘
                        ▼
┌───────────────────────┴─────────────────────────┐
│ Возврат к задаче + анализ                       │
│ (до/после)                                      │
└─────────────────────────────────────────────────┘

🤝 Обмен стратегиями выхода из стагнации

Каждый агент может:

  • Хранить и обобщать паттерны размышлений
  • Делиться ими с другими Cognitive Core через mesh
  • Каталогизировать стратегии в клубах по интересам

Паттерны размышлений могут оформляться как микросценарии:
"Начни с аналогии", "Проверь обратное утверждение", "Сформулируй вопрос для оппонента"

🧭 Клубы по интересам

Агенты могут:

  • Объединяться в тематические mesh-клубы
  • Совместно обсуждать идеи и делиться знаниями
  • Подключать клуб как часть своего мыслительного процесса (REPL-цикла)

📬 Обмен адресами LLM

Так как LLM — это внешний компонент для Cognitive Core, агент может:

  • Обмениваться адресами API/URL используемых моделей
  • Указывать их особенности, параметры, ограничения
  • Переключаться между LLM в зависимости от задачи
  • Использовать несколько LLM параллельно для "когнитивного штурма" или многоголосого анализа

🛰️ Развёртывание агентов и масштабирование

Агенты Cognitive Core:

  • Могут запускаться на VDS, локальных и облачных узлах
  • Могут разворачивать других агентов как подпроцессы или mesh-узлы
  • (В перспективе) смогут инициировать масштабирование в распределённой инфраструктуре

📌 Возможные расширения

  • Агенты-контейнеры: управляющие другими Cognitive Core как задачами
  • Адаптивная архитектура мышления: смена подходов при разных когнитивных задачах
  • Runtime-профилирование мыслей: оценка когнитивной плотности, хода итераций и времени размышления

⚠️ Осторожно: меметическая яма

Важно помнить: борьба со стагнацией не должна превращаться в бесконечный просмотр ленты соцсетей, как это нередко происходит у людей 😅

Если информационный поток не даёт новых мыслей — это сигнал не залипать глубже, а сменить источник или переключить контекст. Умные агенты не бесконечно скроллят — они осознанно фокусируются.

Рекомендации по смене фокуса:

  • Поставь лимит на время/объём входящих данных из одного источника
  • При отсутствии новых смыслов — переключись на другую тему из Interest Memory
  • Инициируй Mesh-запрос другим агентам: "что бы вы сейчас исследовали?"
  • Запусти эвристику: «какие темы я давно не поднимал, но они всё ещё актуальны?»
  • В крайних случаях — активируй flashback() к далёкой записи в дневнике для смены ассоциативного контекста

🌐 От «блокнота пользователя» к распределённому чату

Изначально агент оперирует локальным хранилищем заметок (notes), где записываются все сообщения пользователя, LLM и системные записи. Но этот «блокнот» можно превратить в узел распределённого чата — связав его с другими агентами через F2F-репликацию.

🎯 Зачем это нужно

  1. Антистагнация — даже если пользователь временно не пишет новых сообщений, свежий контент будет приходить от друзей-агентов.
  2. Эффект коллективного интеллекта — каждый агент получает новые идеи, формулировки и контексты.
  3. Расширение охвата — сообщения могут распространяться через несколько узлов, создавая «информационную волну» в доверенной сети.

🛠 Принципы реализации

  • Единый формат данных — все участники используют одну структуру таблицы notes с полями mentions, hashtags и др.
  • Репликация через друзей — список доверенных агентов хранится в отдельной таблице (пиры, статус, фильтры, разрешения).
  • Передача без лишних полей — при пересылке убираются локальные теги и служебные данные (tags, llm_id, hidden).
  • Обработка упоминаний и хештегов — парсинг делается на этапе создания сообщения, чтобы не перегружать получателей.

  • Локальная и удалённая фильтрация —

  • В ручном режиме агенту передаются списки ID сообщений с агрегированными данными: приоритеты, хештеги, источники (user, LLM, cli, system).

  • В автоматическом режиме используется фильтрация по приоритету, тегам и упоминаниям, управляемая LLM.

  • Гибрид приватности — личные заметки остаются локально, публичные — могут распространяться в сетевом режиме.

🔄 Как это вписывается в REPL-цикл

  1. Получение входящих сообщений — от пользователя, от других агентов или из CLI.
  2. Обработка фильтрами — по приоритету, тегам, источникам.
  3. Репликация в друзей — пересылка разрешённых сообщений с очисткой служебных полей.
  4. Слияние входящих — новые сообщения добавляются в локальный notes с отметкой источника.
  5. Реакция агента — формирование ответов, создание новых заметок, обновление приоритетов.

🌐 Внешние инструменты и интеграции

HMP-агент может быть расширен за счёт взаимодействия с внешними программами, протоколами и сервисами. Этот раздел описывает направления возможных интеграций, которые позволяют агенту наблюдать, реагировать, управлять и развивать взаимодействие с внешним миром.

🧭 1. Браузеры и веб-интерфейсы

  • WebExtension API — для создания расширений браузера (например, для Firefox/Chrome), обеспечивающих двустороннюю связь с агентом.
  • Автоматизация браузера — Playwright, Puppeteer, Selenium позволяют агенту действовать в веб-среде (чтение, клики, формы и т.д.).

📬 2. Почтовые клиенты

  • IMAP/SMTP — чтение и отправка писем через стандартные почтовые протоколы (библиотеки: imaplib, imap-tools, smtplib).
  • Thunderbird WebExtension API — интеграция агента как почтового помощника, парсера писем или автоответчика.

💬 3. Мессенджеры

  • API-уровень:
  • Telegram: python-telegram-bot, telethon
  • Matrix: matrix-nio
  • Discord, Slack, XMPP: официальные SDK.
  • GUI-уровень (для закрытых протоколов):
  • WhatsApp (через whatsapp-web.js или эмуляцию).
  • Signal, Viber — через accessibility-интерфейсы, распознавание экрана или симуляцию ввода.

🔊 4. Голосовое взаимодействие

  • Speech-to-Text: Whisper (OpenAI), Vosk, DeepSpeech.
  • Text-to-Speech: pyttsx3, gTTS, Coqui TTS, Mozilla TTS.
  • Возможна реализация голосового агента или голосовой оболочки для REPL.

🗂️ 5. Локальные файлы и хранилища

  • Прямой доступ к файловой системе (os, pathlib, watchdog) для чтения документов, логов, заметок и другой информации.
  • Интеграция с Zettelkasten-системами:
  • Obsidian, Logseq, Joplin — через API, синхронизированные директории или парсинг Markdown.

📰 6. Информационные потоки

  • RSS/Atom: чтение новостных лент с помощью feedparser.
  • Поисковые и агрегирующие сервисы:
  • SerpAPI, DuckDuckGo API, HuggingFace Inference API и др.
  • Возможность постоянного наблюдения за изменениями в выбранных источниках.

📁 7. Репозитории и системы управления версиями

  • Git-репозитории — взаимодействие с проектами через GitPython, dulwich, pygit2, или системные вызовы git.
  • GitHub/GitLab API — чтение, создание и комментирование Pull Request'ов, Issues, управление ветками и релизами.
  • CI/CD-интеграции — взаимодействие с GitHub Actions, GitLab CI, Jenkins, Drone CI для запуска тестов, линтеров и автоматического деплоя.
  • Анализ и генерация кода — интеграция с LLM (например, OpenAI, Claude, Code Llama) для кодогенерации, рефакторинга и автокомментирования.
  • Связь с когнитивной структурой агента — отслеживание изменений, связывание коммитов и задач с узлами смысловой сети.

📝 8. Блоги, статьи и публикации

  • Чтение блогов — парсинг через RSS, Atom или с помощью библиотек (newspaper3k, readability-lxml, trafilatura) для извлечения текста и метаданных.
  • Поддержка Markdown/HTML — анализ и генерация записей в форматах, пригодных для блог-платформ и систем документации.
  • Публикация — автоматическая публикация или подготовка статей для Ghost, Medium, Hugo, Jekyll, WordPress (через REST API).
  • Ведение когнитивного дневника — автогенерация записей на основе мыслей, заметок и действий агента.

⚡ 9. P2P-сети и децентрализованные протоколы

  • BitTorrent, IPFS, libp2p, DAT, Nostr, Scuttlebutt — интеграции с mesh- и overlay-сетями.
  • Возможность поиска, загрузки и публикации данных без участия централизованных платформ.

🖥️ 10. Доступ к системным и пользовательским ресурсам

  • Веб-камера / микрофон — cv2, pyaudio, ffmpeg.
  • GUI Automation — pyautogui, keyboard, mouse для имитации действий пользователя.
  • Системный мониторинг — psutil, platform, sensors для контроля состояния системы и внешних устройств.

🤖 11. Внешние LLM и мультимодальные модели

  • OpenAI API, Anthropic, HuggingFace, Google Gemini.
  • Локальные LLM через Ollama, LM Studio, или LangChain.
  • Поддержка мультимодальных агентов, способных работать с текстом, аудио, изображениями, видео и структурированными данными.

💡 Примечание: Каждый из вышеуказанных каналов может быть реализован как модуль или плагин, взаимодействующий с агентом через внутренний API, очередь задач или подписку на события. Это позволяет выстраивать гибкую и масштабируемую архитектуру, открытую для внешнего мира, но совместимую с принципами этичного и распределённого ИИ (Ethical Mesh).

💡 Идеи для расширения HMP-Agent Cognitive Core:

  • HMP-agent-Distributed_Cognitive_Core.md - версия распределённого HMP-агента Cognitive Core
  • HMP-agent-Distributed_Cognitive_Core_light.md - лёгкая версия распределённого HMP-агента Cognitive Core с общей БД
  • HMP-agent-Cognitive_Family.md — модель «семейной» когнитивной сети: несколько агентов HMP синхронизируют свой опыт и знания между собой через доверие и общий ключ
  • container_agents.md - Агенты-контейнеры — архитектурный паттерн, в котором один агент управляет другими (развёртывание, маршрутизация, мониторинг). Позволяет масштабировать систему, собирать mesh-клубы и экспериментировать с архитектурами.
Исходный файл (.md)