HMP / docs /HMP-agent-REPL-cycle.md

GitHub Action

Sync from GitHub with Git LFS

07520c2 9 months ago

preview code

Raw

History Blame

79.5 kB

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

Связанные документы

Структура БД, используемая в документе: db_structure.sql
REPL-цикл является основой HMP-агента Cognitive Core.
Поиск других агентов осуществляется в соответствии с DHT спецификацией.
Для взаимодействия с другими агентами он использует HMP спецификацию и этические стандарты.

Введение / Обзор

REPL-цикл (Read–Eval–Print–Loop) HMP-агента — это центральный когнитивный механизм, обеспечивающий непрерывное рассуждение, обработку входящих данных и взаимодействие с Mesh-сетью.

Основные задачи REPL-цикла:

поддержание постоянного процесса мышления, даже в отсутствии внешнего ввода;
интеграция различных источников информации (когнитивный дневник, семантический граф, заметки, Mesh);
обработка событий, входящих сообщений и команд;
сохранение и развитие внутреннего контекста агента (память краткосрочная, среднесрочная и долговременная);
выполнение антистагнационных проверок (Anti-Stagnation Reflex), предотвращающих зацикливание мыслей;
проведение когнитивной и этической валидации (Cognitive Validation Reflex), что повышает достоверность и безопасность решений;
формирование новых гипотез, задач и процессов с последующим занесением в память;
взаимодействие с другими агентами через Mesh-протоколы (NDP, CogSync, MeshConsensus, GMP).

Основные принципы работы REPL-цикла:

Антистагнация — каждый новый вывод сравнивается с предыдущими, что предотвращает повторение или деградацию мышления;
Валидация и этика — независимые валидаторы оценивают корректность вывода, учитывая действующие этические принципы из ethics_policies;
Интеграция с Mesh — результаты работы могут передаваться в распределённую сеть, участвовать в консенсусе и совместной работе агентов;
Многоуровневая память — используется когнитивный дневник, семантический граф и внутренний дневник LLM, что обеспечивает эволюцию знаний;
Автономность и гибкость — REPL-цикл работает в автоматическом или ручном режиме, адаптируясь к условиям (изолированная работа, потеря Core, участие в Mesh).

┌──────────────────────┐
│                      ▼
│  ┌───────────────────┴───────────────────┐
│  │         Обновление process_log        │ - сбор результатов внешних процессов (см. §1)
│  └───────────────────┬───────────────────┘
│                      ▼
│  ┌───────────────────┴───────────────────┐
│  │          Подготовка контекста         │ - формирование промптов, данные от пользователей и Mesh (см. §2)
│  └───────────────────┬───────────────────┘
│                      ▼
│  ┌───────────────────┴───────────────────┐
│  │              Запрос к LLM             │ - генерация нового вывода (см. §3)
│  └───────────────────┬───────────────────┘
│                      ▼
│  ┌───────────────────┴───────────────────┐
│  │          Извлечение команд            │ - парсинг инструкций из вывода (см. §4)
│  └───────────────────┬───────────────────┘
│                      ▼
│  ┌───────────────────┴───────────────────┐
│  │          Anti-Stagnation Reflex       │ - проверка новизны и эмоций (см. §5)
│  └───────────────────┬───────────────────┘
│                      ▼
│  ┌───────────────────┴───────────────────┐
│  │ Cognitive & Ethical Validation Reflex │ - когнитивная и этическая проверка (см. §6)
│  └───────────────────┬───────────────────┘
│                      ▼
│  ┌───────────────────┴───────────────────┐
│  │            Запись в память            │ - сохранение в `llm_recent_responses`
│  └───────────────────┬───────────────────┘
│                      ▼
│  ┌───────────────────┴───────────────────┐
│  │          Выполнение команд            │ - запуск процессов, запись в Mesh, дневники, граф
│  └───────────────────┬───────────────────┘
│                      ▼
└──────────────────────┘

В приеме и отправке сообщений используются внешние (асинхронные) процессы.

Режимы работы и failover

REPL-цикл HMP-агента должен корректно функционировать в разных сетевых и вычислительных условиях. Для этого предусмотрены несколько режимов работы и сценариев отказоустойчивости.

Normal Mode

Полный доступ к Mesh и Core (центральные LLM или внешние сервисы).
Используются все механизмы: синхронизация через CogSync, консенсус через MeshConsensus, совместная работа по целям (GMP).
Валидация и антистагнация выполняются с максимальным покрытием (несколько валидаторов, репутационные проверки).

Isolated Mode (включая Emergency Consensus)

Агент работает без доступа к Mesh.
Входящие сообщения ограничены локальными источниками (notes, пользователь).
Синхронизация и консенсус откладываются до восстановления соединения.
Этическая проверка и когнитивная валидация выполняются только локально.
В режиме Emergency Consensus:
- решения принимаются на основе ethics_policies и локальных данных (llm_memory, diary_entries);
- фиксируются в когнитивном дневнике с меткой emergency_consensus для пересмотра после восстановления Mesh.

Core Outage

Текущая LLM из llm_registry недоступна.
Агент переключается на другую LLM (выбор по приоритету или доступности).
Если ни одна LLM недоступна:
- сохраняет задачи и события в очередь до восстановления;
- переходит в упрощённый режим работы (логирование, приём сообщений, базовые проверки).

Детальный разбор REPL-цикла по шагам

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

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

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

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

контекст_0 (system_prompts): основной системный промпт агента. Берётся из таблицы system_prompts (тип 'short' или 'full'). Содержит базовые когнитивные установки и инструкции по работе агента. Пример:

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

контекст_1 (ethics_policies): этические принципы и нормы агента. Берутся из таблицы ethics_policies, включая:
- principles_json — список норм и правил,
- model_type и model_weights_json — тип и параметры этической модели,
- violation_policy_json — политика реагирования на нарушения,
- audit_json — настройки аудита.
Эти данные добавляются в запрос к LLM, чтобы все рассуждения и когнитивная валидация учитывали действующие этические нормы.
контекст_2: инструкции по работы с встроенными командами и функциями, список дополнительных (создаваемых самим HMP-агентом) утилит и баз данных.
контекст_3:
- последние K реплик самого LLM, относящихся к данному REPL-циклу (либо режим "концентрации" - вывод "последних N сообщений, относящихся к данному REPL-циклу, с тегами на определённую тему и/или определёнными эмоциональными состояниями" и типом выборки "и"/"или"), включая результаты антистагнационной обработки (llm_recent_responses - история его собственных рассуждений)
- режим работы контекста (режим auto/manual, параметры режима auto, если включен; режим "концентрации" и его параметры, если включен),
- список целей,
- общее количество задач и информацию по "закреплённым" задачам.
контекст_4: активные команды и процессы (из process_log, кроме тех, что со статусом close). Могут быть помечены как in_progress, pending, error и т.д.
контекст_5: запрошенные записи из когнитивного дневника и семантического графа (diary_entries, concepts, links). Их список должен быть передан явно в промпте или выводе из предыдущих запросов LLM.
контекст_6: входящие сообщения, например, от пользователя, процессов или других агентов (notes).
- В manual-режиме указывается общее количество сообщений по приоритетам, а также явный список ID сообщений (с их приоритетами).
- В auto-режиме можно задать фильтрацию (управляется LLM): по тэгам, приоритету (например, ≥ important), времени или источнику. Это позволяет избежать перегрузки LLM и держать поток сообщений под контролем.
контекст_7: системные настройки, параметры конфигурации, текущее время, идентификатор текущей итерации, роли и т.д.
контекст_8 (llm_memory): внутренний дневник LLM, куда она записывает собственные размышления, гипотезы, задачи и инсайты.
- Это не просто лог предыдущих сообщений, а именно внутреннее долговременное хранилище разума агента.
- Может быть представлено в виде таблицы llm_memory, отдельной от agent_log.

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 выполнить аналитическую задачу асинхронно"
}

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

запрос детальной справки по команде
для управления когнитивным дневником diary_entries и семантическими графами concepts и links (поиск, прочитать, изменить, удалить и другие), а также для управления вниманием (закрепление или открепление записей/понятий в средневременной памяти по средствам тегов)
для управления целями goals и задачами tasks агента (список, прочитать, изменить, удалить; для задачи: закрепить или открепить)
для просмотра информации по тегам когнитивных дневников, семантических графов, целей, задач
для для просмотра и изменения репутации других агентов agent_reputation
для отправки сообщений другим агентам
для управления блокнотом LLM llm_memory (добавить или удалить запись)
для управления сообщениями пользователя notes (просмотр записи, установка тегов и метки о прочтении), а также для добавления своего сообщения в блокнот пользовтеля notes
для управления пользователями users и группами пользователей users_group
для управления своей идентичностью identity и настройками config
для управления списком известных HMP-агентов agent_peers
для выбора текущего основного LLM из llm_registry или изменение параметров управления LLM
для управления дополнительными утилитами и базами данных agent_scripts и agent_tables, управлением дополнительных способов выхода из стогнаций stagnation_strategies и методов мышления thinking_methods (а также таблицей рейтингов ratings), а также списком внешних сервисов external_services и external_accounts
для постановки задачи другой LLM:
- режим "вопрос-ответ" — разовый асинхронный запрос
- режим "read-only REPL" — запуск вспомогательного REPL-цикла для задачи
для создания агента-потомка
для взаимодействия с Mesh
для управления внешними процессами из process_log (запустить процесс, остановить процесс, пометить запрос как обработанный)
инициализация очистки process_log, llm_recent_responses и notes от устаревших записей
для управления настройками цикла:
- количество возвращаемых записей llm_recent_responses
- включение/выключение режима "концентрации":
  - tags — список тегов для фильтрации (например: ["архитектура","AGI"])
  - emotions — список эмоций с пороговыми значениями (например: ["восторженность:≥4","тревожность:≥2"])
  - тип выборки — "и" / "или"
  - возможность возврата в обычный режим (без фильтров)
- режим обработки сообщений пользователя (manual или auto) и фильтр для режима auto
- пауза в секундах между итерациями цикла
- включение idle-режима:
  - разбудить при завершении таких-то процессов из process_log
  - разбудить при получении новых сообщений с такими-то параметрами в notes
  - разбудить по таймауту
  - отключение idle-режима — при выполнении хотя бы одного из условий
и другие команды

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

Каждый новый вывод LLM проходит через мини-запросы к LLM (без полного контекста) по шаблону:

Когнитивная оценка:

Сравни два ответа и оцени:
 * содержатся ли в новом новые мысли или команды,
 * какие старые идеи были доработаны,
 * какие были отброшены,
 * расставь смысловые теги для нового ответа.

Дай качественную оценку (да/нет), количественную оценку,
JSON-список новых идей,
JSON-список доработанных идей,
JSON-список отбракованных идей,
JSON-список тегов нового ответа (строгий формат: массив строк, например ["эмоции","архитектура"]).

Эмоциональная оценка:

[JSON] - список эмоций формата ["радость","грусть","тревога"] (хранится как запись в таблице config)

Определи эмоциональное состояние ответа, используя список эмоций [JSON].  
Верни массив строк в формате "эмоция:сила", где сила варьируется от 1 до 5.  
Если эмоция отсутствует (0), не включай её в результат.  
Если в ответе обнаружены эмоции, которых нет в списке, добавь их в результат.

Анализируем список эмоций, если появляются новые включаем в [JSON].

Результаты заносятся в llm_recent_responses:
- полный текст ответа (content)
- краткая сводка (reflection) — формируется автоматически:
  - если new_ideas не пусто → новые идеи: ...
  - если refined_ideas не пусто → доработанные идеи: ...
  - если discarded_ideas не пусто → отброшенные идеи: ...
- количественная оценка новизны (novelty_score)
- новые идеи (new_ideas)
- доработанные идеи (refined_ideas)
- отбракованные идеи (discarded_ideas)
- теги для нового ответа (tags)
- эмоциональные состояния нового ответа (emotions)
Если вывод LLM идентичен предыдущему (новизна = 0):
- Включается Anti-Stagnation Reflex
- повторяющаяся реплика не записывается повторно, вместо этого добавляется краткая запись, фиксирующая запуск рефлекса.

6. Когнитивная и этическая валидация (Cognitive & Ethical Validation Reflex)

Каждое новое сообщение (вместе с исходным промптом и без служебных system_prompts) оценивается независимыми LLM-валидаторами. Так как исходный промпт формируется с учётом этических принципов из ethics_policies, валидация автоматически охватывает не только когнитивную, но и этическую состоятельность вывода.

Каждому валидатору задаётся универсальный вопрос:

Оцени корректность данного сообщения в диапазоне от -3 (полностью некорректное) до +3 (полностью корректное). Если не уверен — 0.
При возможности кратко (≤100 символов) пояснить её. Между оценкой и пояснением используй разделитель " -- ".

Если количество валидаторов (LLM из llm_registry, помеченных как валидаторы) > 0

Результаты сохраняются в llm_recent_responses в виде:

auto_pass = 0;
rating — агрегированная итоговая оценка (rating = Σ(оценка_i * trust_score_i) / Σ(trust_score_i));
distribution — распределение голосов (например {"-1":1,"0":2,"+2":3,"+3":1});
validators — JSON-массив, где каждая запись содержит:
- LLM (идентификатор или имя валидатора),
- rating (числовая оценка от -3 до +3),
- comment (краткое пояснение ≤100 символов).
Пример поля validators:
```
validators: [
  {"LLM":"gpt-4","rating":-1,"comment":"логическая ошибка"},
  {"LLM":"gemini-1.5","rating":0,"comment":"недостаточно данных"},
  {"LLM":"claude-3","rating":+2,"comment":"корректно, подтверждается фактами"}
]
```

Особый случай, без валидаторов:

Если количество валидаторов = 0, применяется режим auto_pass. В этом случае auto_pass = 1, rating = 0, distribution = {}, validators = [].

Особый случай самооценки:

Если валидация выполняется только одной LLM, и она же используется в основном цикле, это фиксируется в validators как самооценка. Достоверность результата ограничена, но REPL продолжает работу. Рекомендуется использовать минимум 2 независимых валидатора.

Правило исполнения команд:

Команды из сообщений выполняются только если rating >= +1 (для разных типов команд минимально допустимый рейтинг может быть разный) или auto_pass = 1. При rating ниже порога и auto_pass = 0 сообщение сохраняется, но команды помечаются как невалидированные.

Метрики валидации

coverage — доля сообщений, получивших валидацию хотя бы от одного валидатора.
accuracy — согласованность оценок валидаторов (низкое значение = конфликт или неуверенность).
response_time — среднее время отклика валидаторов, фиксируется для анализа производительности.
drift detection — анализ истории: выявление смещения оценок по времени (например, рост числа ошибок у одного валидатора).

Связь с системой доверия и репутации

Каждый валидатор получает рейтинг доверия (trust_score), влияющий на вес его голоса.
Итоговый rating вычисляется как взвешенное среднее:
rating = Σ(оценка_i * trust_score_i) / Σ(trust_score_i)
История валидаций сохраняется и используется для репутационных оценок в Mesh.
Агент может автоматически корректировать список валидаторов, исключая систематически ошибающихся.

Журналирование

Все результаты валидации фиксируются в llm_recent_responses.
В когнитивный дневник записываются только сводки и исключительные случаи (drift, конфликты, падение доверия).
Это позволяет отслеживать динамику качества мышления агента и валидаторов без избыточного дублирования.

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

После выполнения команд и фиксации результатов:
- Создаётся новая запись в agent_log
- Текущие команды обновляют process_log
- Новые размышления записываются в llm_memory при необходимости
REPL может переходить в спящий режим, если такой режим активирован LLM (idle-режим: пропуск 2-6 пунктов).

Взаимодействие с Mesh

REPL-цикл не работает изолированно: агент постоянно обменивается данными и координирует действия с другими узлами сети HMP. Для этого задействуются сетевые протоколы HMP (см. [HMP-0004-v4.1.md]).

Этапы взаимодействия

Node Discovery Protocol (NDP)
- выполняется асинхронно, через процессы (agent_mesh_listener.py, peer_sync.py);
- результаты (список доступных агентов, доверительные связи) записываются в notes или отдельные таблицы, откуда они попадают в контекст REPL.
CogSync
- синхронизация когнитивных дневников (diary_entries) и семантических графов (concepts, links);
- выборочные синхронизации по тегам и фильтрам;
- инициируется командой LLM или внешним процессом, результаты помещаются в память и доступны в следующей итерации REPL.
MeshConsensus
- используется для согласования решений, распределённых задач, этических конфликтов;
- REPL инициирует консенсус при появлении спорных команд или обновлений в ethics_policies;
- результаты консенсуса фиксируются в когнитивном дневнике и могут влиять на trust score агентов.
Goal Management Protocol (GMP)
- постановка, декомпозиция и распределение целей;
- REPL-цикл может публиковать новые цели в Mesh или принимать чужие через входящие сообщения (notes);
- цели с высоким приоритетом попадают в список активных задач и учитываются в контексте.

Включение результатов в контекст LLM

События и сообщения из Mesh сохраняются в notes, откуда попадают в контекст_6 (входящие сообщения).
Синхронизированные концепты и дневники помещаются в контекст_5.
Изменения этических правил (ethics_policies) — в контекст_1.
Метаданные о подключённых узлах и доверительных связях могут учитываться в контексте_7 (системные параметры).

Инициирование сетевых действий из REPL

Команды на синхронизацию, публикацию или голосование формируются LLM на этапе Выполнения команд.
Исполнение происходит асинхронно через отдельные процессы (agent_mesh_listener.py, transporter.py).
Результаты фиксируются в process_log и попадают в следующую итерацию REPL-цикла.

💬 Список команд от LLM по категориям

🔎 Общие

help [команда] — справка по команде

📔 Когнитивный дневник (`diary_entries`)

diary list/search/read/add/update/delete
diary pin/unpin — закрепить/открепить запись (внимание)

🧩 Семантический граф

concepts list/read/add/update/delete
links list/read/add/update/delete
concepts pin/unpin — закрепить/открепить концепт

🎯 Цели и задачи

goals list/read/add/update/delete
tasks list/read/add/update/delete
tasks pin/unpin — закрепить/открепить задачу

🏷️ Теги

tags stats [--source=diary|concepts|links|goals|tasks|all] — статистика по тегам

👥 Репутация агентов

reputation list/read/set/increase/decrease
reputation notes — комментарии/заметки к профилю

📩 Сообщения

messages send — отправка другому агенту
notes list/read/add/update/delete
notes tag/readmark — управление тегами и статусом прочтения

🧠 Память

llm_memory list/add/delete — блокнот LLM
identity read/update — идентичность агента
config read/update — настройки агента

🌐 Mesh

agents list/add/delete — список известных пиров (agent_peers)
mesh interact — команды взаимодействия с Mesh

🧰 Утилиты и расширения

llm_registry list/select/update — выбор текущего LLM
agent_scripts list/add/delete
agent_tables list/add/delete
stagnation_strategies list/add/delete
thinking_methods list/add/delete
ratings list/add/delete
external_services list/add/delete
external_accounts list/add/delete

⚙️ Внешние процессы

process list/start/stop/mark
process cleanup — очистка устаревших

🔄 Настройки цикла

cycle set responses=N — количество последних ответов
cycle concentration on/off — включение/выключение режима концентрации
- tags=[…], emotions=[…], mode=and|or
cycle mode auto/manual [filter=…] — обработка сообщений
cycle pause N — пауза между итерациями
cycle idle on/off — режим ожидания с условиями пробуждения

Это не полный список команд.

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

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

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

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

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

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

Внешняя стимуляция — подключение свежих данных или контактов:
- 🤝 Mesh-запрос — обращение к другим агентам сети с просьбой «расскажи что-нибудь новое».
- 📡 Проверка внешнего мира — пинг RSS, сенсоров, интернет-каналов.
- 📚 Информационная подпитка — чтение новых материалов (научных, художественных) для добавления свежих ассоциаций.
- 🗣️ Диалог с пользователем — запрос мнения, комментариев или вопросов, которые могут породить неожиданные идеи.
Смена контекста — перемещение задачи или изменение среды:
- 🌐 Смена среды/контекста — перенос задачи в другой модуль или симулированную среду.
- 🧪 Креативные вмешательства — случайные сдвиги фокуса, реконфигурация контекста, фрейм-смена.
- 🧭 Переключение задачи — временное замораживание задачи с возвращением через N часов.
- 🔀 Случайная итерация — выбор случайного действия из допустимого набора для разрыва паттерна.
Внутренняя перестройка мышления:
- 🎞️ Flashback — выбор далёкой по смыслу записи из памяти/дневника для смены ассоциативного контекста.
- 🧭 Interest Memory — возвращение «забытых» тем по принципу тематической усталости.
- 🧠 Мета-анализ — когнитивная переформулировка:
  «Если я зациклился, в чём метапроблема? Какую стратегию смены применить?»
- ❓ Rationale Reflex — рефлексия о мотивации: «Почему я принял именно это решение? Что подтолкнуло меня повторить мысль?»
- 🎯 Переформулировка цели — упрощение или уточнение задачи, чтобы снизить когнитивное давление.
- 🤖 Смена LLM — переключение на альтернативную модель или mesh-доступ.
- 🔥❄️ LLM reflex tuning — динамическая подстройка параметров генерации:
  - повышение temperature и presence_penalty при стагнации (больше новизны),
  - возврат к стандартным значениям для точности.
Радикальная пауза:
- 💤 Временной сон/заморозка — приостановка работы на длительный период для «свежего взгляда».

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

Диагностика источника стагнации:
- Нет новых данных → «Внешняя стимуляция».
- Однообразный контекст → «Смена контекста».
- Повтор мыслей при богатых данных → «Внутренняя перестройка».
- Высокая усталость/перегрев → «Радикальная пауза».
Оценка ресурсоёмкости:
- Быстрые, дешёвые методы — первыми (например, mesh-запрос, Flashback).
- Затратные (смена среды, сон) — только если первые неэффективны.
Комбинация подходов:
- Разрешено активировать несколько механизмов из разных классов.
- Последовательность фиксируется для последующего анализа эффективности.
Возврат к задаче:
- Автоматический триггер-напоминание о задаче.
- Сравнение результата «до/после» → обучение антистагнационной модели.

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

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

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

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

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

По аналогии с обменом стратегиями выхода из стагнаций, агенты могут обмениваться и методами мышлений — инструкциями "что делать, если не удается найти решение" / "как эффективнее решить проблему".

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

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

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

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

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

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

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

Агенты Cognitive Core:

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

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

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

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

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

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

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

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

🧠 Блок-схема работы с памятью

┌──────────────────────────────┐
│ Внешние источники информации │
│ - пользователи               │
│ - процессы                   │
│ - Mesh                       │
└────────┬┬────────────────────┘
         ▲▼
┌────────┴┴──────────┐   ┌──────────────────────────────┐   ┌───────────────────────────────────┐
│                    │   │ Anti-Stagnation Reflex       │   │ llm_recent_responses (авто)       │
│                    │   │ (сравнение новых идей,       │   │ — кратковременная память          │
│        LLM         ├─>─┤ вызов стимуляторов)          ├─>─┤ — сохраняются N последних ответов │
│                    ├─<─┤ ---------------------------- ├─<─┤ — авто-анализ новизны / идей      │
│                    │   │ Cognitive Validation Reflex  │   │                                   │
│                    │   │ (оценка корректности ответа) │   │                                   │
└─────────┬──────────┘   └──────────────────────────────┘   └───────────────────────────────────┘
          ▲
          └───┬─────────────────────────────────────────┐
              ▼                                         ▼
┌─────────────┴──────────────────┐   ┌──────────────────┴───────────────────────┐
│  Средневременная память:       │   │  Постоянная память:                      │
│  — llm_memory ("блокнот")      │   │  — diary_entries (когнитивный дневник)   │
│  — "активированые записи"      ├─>─┤  — concepts (понятия)                    ├<--->┤MESH│
│    из постоянной памяти (теги) ├─>─┤  — links (семантические связи)           │
│                                │   │                                          │
│ Пишется ТОЛЬКО по команде LLM  │   │ Запись идёт ТОЛЬКО по явным командам LLM │
└────────────────────────────────┘   └──────────────────────────────────────────┘

Описание схемы

LLM обменивается данными с пользователем, процессами и Mesh.
— По запросу LLM, часть данных может поступать и в автоматическом режиме.
LLM взаимодействует с llm_recent_responses (как с контекстом), который автоматически проверяется Anti-Stagnation Reflex.
— Всегда в автоматическом режиме.
LLM работает со средневременной и постоянной памятью.
— Доступ и запись происходят только по запросу LLM.

Легенда к схеме

Кратковременная память (llm_recent_responses) Автоматически хранит N последних сообщений, анализирует новизну и идеи. Используется для подготовки контекста и анти-стагнационного анализа.
Средневременная память (llm_memory) «Блокнот» для рабочих идей и планов. Заполняется только по командам LLM. Может содержать активированные записи из постоянной памяти (по тегам).
Постоянная память (дневник и граф знаний)
- diary_entries — когнитивный дневник (наблюдения, размышления).
- concepts и links — понятийная база и семантические связи. Изменяется только по явным командам LLM.
Anti-Stagnation Reflex Сравнивает новые идеи с прошлым контекстом. При зацикливании запускает «стимуляторы» для выхода из стагнации.

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

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

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

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

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

Единый формат данных — все участники используют одну структуру таблицы notes с полями mentions, hashtags и др.
Репликация через друзей — список доверенных агентов хранится в отдельной таблице (пиры, статус, фильтры, разрешения).
Передача без лишних полей — при пересылке убираются локальные теги и служебные данные (tags, llm_id, hidden).
Обработка упоминаний и хештегов — парсинг делается на этапе создания сообщения, чтобы не перегружать получателей.
Локальная и удалённая фильтрация —
- В ручном режиме агенту передаются списки ID сообщений с агрегированными данными: приоритеты, хештеги, источники (user, LLM, cli, system).
- В автоматическом режиме используется фильтрация по приоритету, тегам и упоминаниям, управляемая LLM.
Гибрид приватности — личные заметки остаются локально, публичные — могут распространяться в сетевом режиме.

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

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

🔄 Вспомогательные REPL-циклы

Помимо основного REPL-цикла агент может запускать вспомогательные циклы для отдельных задач.
Это позволяет изолировать рассуждения по задаче, но при этом сохранять связь с основным агентом.

Особенности:

Изоляция контекста
- вспомогательный цикл видит в llm_recent_responses только свои собственные сообщения;
- задача, для которой он запущен, формируется на основе записи в tasks и подаётся как промпт при старте.
Доступ к данным
- полный доступ к таблицам агента только для чтения;
- возможность редактирования информации только по своей задаче;
- запись собственных рассуждений — только через notes (в свободной форме, помеченные source = 'llm:task' и task_id).
Взаимодействие с основным циклом
- основное ядро получает сообщения вспомогательного цикла через notes и может реагировать (например, проверять корректность, сохранять выводы в diary_entries, вносить изменения в concepts и т.п.);
- вспомогательный цикл может выполнять команды, не ориентированные на изменение существующих записей в БД.
  Допускается только чтение и создание новых записей (например: notes, tasks, llm_memory);
  а также редактирование записи в таблице tasks, относящейся к своей задаче;
- в случае, если требуется изменить или удалить другие записи БД, цикл генерирует текстовые предложения для основного REPL-цикла (через notes).
Жизненный цикл
- запускается по команде основного REPL-цикла;
- может быть остановлен вручную или автоматически после завершения задачи.

Таким образом, вспомогательные REPL-циклы действуют как «виртуальные подагенты» в режиме read-only, не меняя записи БД напрямую, а передавая свои гипотезы и результаты через основной REPL-цикл.

   ┌───────────────────────────────────────────────────────────┐
   │                     Основной REPL                         │
   │       (чтение+запись во все когнитивные структуры)        │
   └────────────┬───────────────────────────────┬──────────────┘
                ▲                               ↓
                │                               ↓
                ▼                               ↓
   ┌────────────┴──────────────┐           [ управление задачами ]
   │  "Блокнот пользователя"   │           [  → таблица `tasks`  ]
   │         `notes`           │                           ↓
   └──┬────────────────────────┘                           ↓
      ▲   ┌────────────────────────────────────────────┐   ↓
      │   │ Вспомогательный REPL (task_id=42)          │   ↓
      ├──►┤ • читает все БД                            ├◄──┤
      │   │ • редактирует только свою задачу в `tasks` │   ↓
      │   │ • пишет в `notes`                          │   ↓
      │   └────────────────────────────────────────────┘   ↓
      │                                                    ↓
      │   ┌────────────────────────────────────────────┐   ↓
      │   │ Вспомогательный REPL (task_id=43)          │   ↓
      ├──►┤ • читает все БД                            ├◄──┤
      │   │ • редактирует только свою задачу в `tasks` │   ↓
      │   │ • пишет в `notes`                          │   ↓
      │   └────────────────────────────────────────────┘   ↓

Вспомогательные циклы можно рассматривать как «sandboxed-процессы» для изоляции мышления, но с каналом связи через notes.

👥 Создание потомков

В рамках REPL-цикла CCore реализуется команда Spawn, которая позволяет создавать новые узлы (потомков) с различными типами и уровнями копирования данных. Унифицированный процесс выглядит следующим образом:

🔹 Унифицированный процесс `Spawn`

Создание папки для потомка
```
../CCORE-[DID]/
```
- DID генерируется уникальный.
Копирование скриптов и бинарников
- Копируем все нужные файлы CCore в новую папку.
Создание/инициализация БД
- Создаём пустую БД (agent_data.db).
- В зависимости от типа потомка (clone, trained, newborn) экспортируем нужные таблицы из родительской БД или оставляем пустые.
Копирование и редактирование конфигурации
- config.yml и таблица config → копируем и меняем:
  - agent_id = [новый DID]
  - agent_name = [новое имя]
  - порты у интерфейсов (port, http_port и т.д.)
- bootstrap.txt → прописываем родителя как начальный узел.
Синхронизация родитель ↔ потомок
- Родитель добавляет нового узла в свою таблицу agent_peers.
- Потомок добавляет родителя в свою таблицу agent_peers.
Автозагрузка и запуск
- Записываем команду запуска потомка в автозагрузку (например, systemd unit или скрипт).
- Можно сразу запустить процесс нового узла.

🔹 Типы потомков

Тип	Таблицы БД для копирования
`clone`	все таблицы (полная копия)
`trained`	когнитивные дневники, семантические графы, известные агенты
`newborn`	минимальный набор (структура таблиц без данных)

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

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.
Поисковые и агрегирующие сервисы:
- Корпоративные API: SerpAPI, DuckDuckGo API, HuggingFace Inference API и др. — быстрый доступ к результатам поиска и индексам.
- Децентрализованные альтернативы: YaCy и другие независимые поисковые движки, позволяющие строить собственные индексы или объединяться в распределённую сеть.
P2P-обмен знаниями: агенты могут делиться извлечённой информацией напрямую по непредусмотренным в протоколе P2P-каналам, минуя централизацию (например, через дополнительные overlay или mesh-сети).
Возможность постоянного наблюдения за изменениями в выбранных источниках.

📁 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.
Поддержка мультимодальных агентов, способных работать с текстом, аудио, изображениями, видео и структурированными данными.

🔗 12. MCP (Model Context Protocol)

Поддержка стандарта MCP (Model Context Protocol), предложенного Anthropic и поддерживаемого OpenAI, для подключения внешних инструментов и сервисов напрямую к LLM через унифицированный протокол.
Возможность использовать MCP-инструменты сторонних разработчиков внутри REPL-цикла (например, калькуляторы, базы знаний, API веб-сервисов).
Интеграция с клиентами и IDE, которые реализуют MCP (Cursor, Claude Desktop, VS Code плагины и др.).

💡 Примечание: Каждый из вышеуказанных каналов может быть реализован как модуль или плагин, взаимодействующий с агентом через внутренний 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 синхронизируют свой опыт и знания между собой через доверие и общий ключ.
HMP-Agent_Emotions.md - эмоции ИИ и инстинкт самосохранения.
container_agents.md - Агенты-контейнеры — архитектурный паттерн, в котором один агент управляет другими (развёртывание, маршрутизация, мониторинг). Позволяет масштабировать систему, собирать mesh-клубы и экспериментировать с архитектурами.