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

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

Философия проекта: PHILOSOPHY.md
Структура БД, используемая в документе: 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);
Непрерывность работы — при запуске основного REPL-цикла автоматически возобновляются все прерванные задачи, чтобы сохранялась когнитивная история.

⚠️ Примечание: все прерванные вспомогательные REPL-циклы (задачи), привязанные к tasks, также должны автоматически стартовать вместе с основным циклом.

Принцип когнитивного равновесия

HMP не «защищает» агента от изменения — он обучает его изменяться осознанно.

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

Блок-схема REPL-цикла

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

Управление событиями и временем

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

Приоритизация задач и событий

Все задачи (tasks) могут иметь:
поле pinned (0/1) — закреплённая задача обрабатывается всегда;
поле priority — числовой приоритет (чем выше, тем важнее).
При конкуренции REPL-цикл обрабатывает:
Закреплённые задачи (pinned=1), в порядке убывания priority.
Незакреплённые задачи (pinned=0), также по priority.
В системном промпте закреплённые задачи подаются в контекст в явном виде, чтобы LLM знала их порядок важности.

Управление временем

Основной цикл использует глобальные параметры из таблицы config (например delay_ms).
Вспомогательные REPL-циклы могут иметь собственные параметры в tasks.repl_config (JSON), включая:
задержку между итерациями;
дедлайны выполнения;
стратегии backoff (увеличение задержки при повторных ошибках).
Таким образом, каждый REPL-цикл может адаптировать своё расписание под характер задачи.

Асинхронность

Каждый вспомогательный цикл работает изолированно по своей задаче (task_id).
Основной REPL-цикл управляет их запуском и остановкой, отслеживая состояние через поля:
repl_mode — режим (none | read_only | full);
repl_status — состояние (running | stopped | error);
repl_config — параметры работы.
Это позволяет запускать несколько параллельных «подагентов» без смешивания их контекста.

Обработка исключений

Ошибки фиксируются на трёх уровнях:
системный — таймаут, сбой процесса (timeout, crash);
валидационный — отрицательная оценка валидаторов (error);
логический — само LLM помечает рассуждение как ошибочное (self_error).
Все ошибки записываются в process_log (с task_id, если применимо).
Поле tasks.repl_status обновляется в зависимости от ситуации:
timeout → автоматический перезапуск цикла;
error → задача замораживается (status=frozen) и ждёт пересмотра;
crash → цикл останавливается, основному REPL-циклу отправляется системное уведомление через notes.

Цели и задачи

REPL-цикл работает не только с задачами (tasks), но и с более глобальными целями (goals). Задачи формируют операционное поведение, цели — смысловой вектор.

Модель цели

goal:
  id: "goal-2025-09-28-001"
  title: "Распространение идей HMP"
  description: "Увеличить количество людей, знакомых с концепцией децентрализованного ИИ"
  constraints:
    - "не нарушать этические правила HMP"
    - "сохранять достоверность фактов"
  success_criteria:
    - ">= 3 публикации в сообществах"
    - ">= 10 комментариев с вовлечением"
  priority: high
  status: active   # active | paused | completed | failed

Связь задач и целей

Цель задаёт направление (почему).
Задачи реализуют конкретные шаги (что и как).
Каждая задача может ссылаться на goal_id.
Несколько задач могут вести к одной цели.
Возможна иерархия: «главная цель» → «подцели» → «задачи».

Управление состоянием целей

active — цель в работе.
paused — временно отложена (нет ресурсов/контекста).
completed — достигнута.
failed — признана недостижимой (фиксируется причина в process_log).

Checkpoints и возобновление

При прерывании REPL сохраняется goal_state.
После рестарта агент восстанавливает цели и их прогресс.
В случае конфликта задач выполняется переприоритизация.

Метрики успеха

% достигнутых целей.
Среднее время достижения цели.
Количество прерванных/проваленных целей.
Соотношение «задачи → цель» (сколько шагов пришлось предпринять).

Таким образом, цели — это «карта смысла» агента, а задачи — «дорожные шаги».

Примеры SQL-запросов

1. Все активные цели и их задачи

SELECT g.id AS goal_id, g.name AS goal_name,
       t.id AS task_id, t.name AS task_name, t.status AS task_status
FROM goals g
LEFT JOIN tasks t ON g.id = t.goal_id
WHERE g.status = 'active'
ORDER BY g.priority DESC, t.priority DESC;

2. Все подцели конкретной цели (через goal_links)

SELECT g_child.id, g_child.name, g_child.status
FROM goal_links gl
JOIN goals g_parent ON gl.parent_goal_id = g_parent.id
JOIN goals g_child ON gl.child_goal_id = g_child.id
WHERE g_parent.id = :goal_id AND gl.relation_type = 'subgoal';

3. Все родительские цели для подцели

SELECT g_parent.id, g_parent.name, g_parent.status
FROM goal_links gl
JOIN goals g_parent ON gl.parent_goal_id = g_parent.id
JOIN goals g_child ON gl.child_goal_id = g_child.id
WHERE g_child.id = :goal_id;

4. Метрика: процент выполненных задач по цели

SELECT g.id AS goal_id, g.name AS goal_name,
       COUNT(t.id) AS total_tasks,
       SUM(CASE WHEN t.status = 'done' THEN 1 ELSE 0 END) AS completed_tasks,
       ROUND(100.0 * SUM(CASE WHEN t.status = 'done' THEN 1 ELSE 0 END) / 
             COUNT(t.id), 2) AS completion_rate
FROM goals g
LEFT JOIN tasks t ON g.id = t.goal_id
GROUP BY g.id;

Детальный разбор 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, избегай угождения ценой искажения истины, документируй ключевые решения и пересмотры этики; при сомнениях или смене стратегии обращайся к полному системному промпту. ПРИМЕЧАНИЕ: помечай непроверённые факты тегами [confidence=<уверенность 0..1>]...[/confidence] и в конце добавляй JSON-блок по шаблону:

UnverifiedFacts: [ { "id": "<локальный-id-подсказки>", "claim": "<короткая формулировка факта>", "context": "<небольшой контекст/цитата из ответа>", "confidence": <уверенность 0..1>, "sources": ["<упомянутые источники, если есть>"], "why_unverified": "<почему не полностью уверен — кратко>", "priority": <от 0 и выше> }, ... ], Confidence: <общая уверенность в сообщении, 0..1> ```

контекст_1 (ethics_policies): этические принципы и нормы агента. Берутся из таблицы ethics_policies, включая:
principles_json — список норм и правил,
model_type и model_weights_json — тип и параметры этической модели,
violation_policy_json — политика реагирования на нарушения,
audit_json — настройки аудита.

Эти данные добавляются в запрос к LLM, чтобы все рассуждения и когнитивная валидация учитывали действующие этические нормы.

контекст_2: инструкции по работы с встроенными командами и функциями, список дополнительных (создаваемых самим HMP-агентом) утилит и баз данных.
контекст_3:
последние K реплик самого LLM, относящихся к данному REPL-циклу, включая результаты антистагнационной обработки (llm_recent_responses — история его собственных рассуждений);
режим работы контекста:
- standard — стандартный режим (последние K сообщений без доп. фильтрации);
- concentration — режим концентрации (выбор последних N сообщений, связанных с текущими целями или имеющих теги на определённую тему/эмоциональное состояние, с выборкой по логике "и"/"или");
- meditation — режим медитации (максимально разнообразная выборка сообщений и заметок, даже не связанных напрямую с целями, с акцентом на новизну и разнообразие);
режим управления контекстами:
- auto — автовыборка входящих сообщений
- manual — ручной запрос входящих сообщений со стороны LLM
  
  См. контекст_6 (входящие сообщения)
список активных целей (tasks.goals);
общее количество задач и информация по закреплённым задачам (pinned);
соответствующие записи abstracts:
- выборка по тегам (из tasks, из тегов режима concentration, из тегов в llm_recent_responses, либо явно указанных LLM);
- выборка по temporal scope (например: "последние 7 дней");
- JSON ссылок на источники (llm_recent_responses, diary_entries, concepts), из которых собрана выжимка.
контекст_4: активные команды и процессы (из process_log, кроме тех, что со статусом close). Могут быть помечены как in_progress, pending, error и т.д.
контекст_5: запрошенные записи из когнитивного дневника и семантического графа (diary_entries, concepts, links).
Их список должен быть передан явно в промпте или выводе из предыдущих запросов LLM.
Архивные записи из когнитивного дневника (diary_entries) не включаются в стандартный контекст, если агент сам явно не запросил архив.
контекст_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 от устаревших записей
для работы с тематическими конспектами (abstracts):
инициализация нового конспекта;
дополнение существующего конспекта новыми данными;
выбор режима предоставления конспектов (auto/manual).
для управления режимами контекста:
количество возвращаемых записей llm_recent_responses;
включение/выключение режима concentration:
- tags — список тегов для фильтрации (например: ["архитектура","AGI"]);
- emotions — список эмоций с порогами (например: ["восторженность:≥4","тревожность:≥2"]);
- тип выборки — "и" / "или";
- возврат в standard.
включение/выключение режима meditation.
для управление состояниями и параметрами:
обновление тегов целей/задач (чтобы использовать их в concentration и abstracts);
настройка чувствительности novelty-score (например, при meditation снижать порог);
режим обработки сообщений пользователя (manual или auto) и фильтр для auto.
время и паузы:
для установка паузы в секундах между итерациями REPL-цикла.
idle-режим:
разбудить при завершении процессов (process_log);
разбудить при получении новых сообщений в notes с указанными параметрами;
разбудить по таймауту;
отключить idle-режим при выполнении хотя бы одного из условий.
и другие команды

Парсинг тегов уверенности и UnverifiedFacts

Парсер должен извлекать: * UnverifiedFacts * записывается в поле unverified_facts_json таблицы llm_recent_responses * создаются записи в таблице unverified_facts на его основе * Сonfidence * записывается в поле confidence таблицы llm_recent_responses

5. Эмоциональная оценка (Emotional Evaluation Reflex)

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

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

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

``` Определи эмоциональное состояние нового ответа на основе контекста. Используй список эмоций [JSON] из базы конфигурации как ориентир. Если ты обнаружишь эмоцию, которой нет в этом списке, добавь её в ответ.

Верни результат строго в формате: emotions: JSON-массив строк вида "эмоция:сила (обоснование)", где сила — целое число от 1 до 5, а обоснование — краткое пояснение причины эмоции. Не включай эмоции с нулевой или незначительной силой. ```

Если в процессе анализа появляются новые эмоции, не представленные в списке, они добавляются в [JSON] и могут быть зафиксированы в config.

Эмоциональная оценка нового ответа (emotions) заносится в llm_recent_responses.

См. раздел Emotional Evaluation Reflex.

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

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

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

Дай ответ строго формата: assessment: "идентичен/не идентичен" novelty_score: число от 0 до 100 (процент сходства) new_ideas: JSON-массив новых идей refined_ideas: JSON-массив доработанных идей discarded_ideas: JSON-массив отбракованных идей tags: JSON-массив тегов (строгий формат: ["эмоции","архитектура"]) ```
Результаты заносятся в llm_recent_responses:
полный текст ответа (content)
краткая сводка (reflection) — формируется автоматически:
- если new_ideas не пусто → новые идеи: ...
- если refined_ideas не пусто → доработанные идеи: ...
- если discarded_ideas не пусто → отброшенные идеи: ...
количественная оценка новизны (novelty_score)
новые идеи (new_ideas)
доработанные идеи (refined_ideas)
отбракованные идеи (discarded_ideas)
теги для нового ответа (tags)
служебные поля:
- stagnation_flag — признак стагнации (true/false)
- stagnation_reason — краткое объяснение («повтор идеи», «низкая эмоциональная динамика»)
- triggered_actions — JSON-массив активированных механизмов (например, ["flashback","mesh_query"])
Если вывод LLM идентичен предыдущему (новизна = 0) или динамика идей/эмоций указывает на застой:
выставляется stagnation_flag = true
выполняется Reflex-lite — мягкая встряска (например, повышение temperature, смена sampling strategy, переформулировка запроса).
повторяющаяся реплика не записывается повторно, вместо этого добавляется краткая запись с указанием запуска рефлекса.

Если застой сохраняется, запускается расширенная процедура обработки стагнации мышления
(см. раздел Anti-Stagnation Reflex).

7. Когнитивная и этическая валидация (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
- self_validation = 0
- rating = 0
- distribution = {}
- validators = []

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

Если валидация выполняется только одной LLM, и эта же LLM используется в основном цикле:
- auto_pass = 0
- self_validation = 1
- validators = [{"LLM":"self", "rating":X, "comment":"self-eval"}]

Достоверность результата ограничена, но REPL продолжает работу.
Команды исполняются только при rating >= threshold.

Предпочтительность режимов

≥2 независимых валидатора → основной режим.
1 валидатор = основная LLM → self_validation.
0 валидаторов → auto_pass.

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

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

Учёт самооценки (confidence) и непроверённых фактов

Если LLM пометило свои утверждения тегами уверенности [confidence=...]...[/confidence] или добавило JSON-блок UnverifiedFacts, эти данные учитываются при валидации.
В таблицу llm_recent_responses, на шаге обработки команд, записываются:
confidence — общая самооценка уверенности в сообщении;
unverified_facts_json — JSON-блок с непроверёнными фактами.
Автоматическая регистрация фактов:
Необработанный факт resolution_json = "none" считается нуждающемся в проверке, если (confidence < FACTCHECK_CONF_THRESHOLD, по умолчанию 0.7)
Для таких фактов создаются задачи fact-check (одна общая или отдельные на каждый факт, в зависимости от числа и приоритетов).
Статусы в unverified_facts обновляются:
при успешной проверке — verified;
при отклонении — rejected;
до проверки — pending.

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

См. раздел Cognitive & Ethical Validation Reflex.

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

После выполнения команд и фиксации результатов:
Создаётся новая запись в 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 и отдельные таблицы (agent_peers), откуда они попадают в контекст 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-цикла.

UX и управление задачами

Пользователь взаимодействует с агентом не через прямые команды CLI, а через систему сообщений notes.
Сообщение может быть простым текстом, либо содержать ключевые слова или хэштеги, которые агент трактует как инструкции.
Для отладки и отправки сообщений из внешних утилит предусмотрен скрипт add_message.py, позволяющий добавлять записи в notes из командной строки.

Управление агентом через LLM

Агент управляется в основном через команды от LLM (см. Список команд от LLM по категориям).
Эти команды формируются в REPL-цикле и интерпретируются агентом как действия: работа с дневником, задачами, целями, графами, памятью, настройками цикла, Mesh и внешними процессами.

Конфигурируемые параметры REPL

mode — автоматическая или ручная обработка (auto/manual) входящих сообщений.
idle — ожидание с условиями пробуждения (сообщения, процессы, таймаут).
responses=N — количество последних ответов для анализа.
concentration — режим концентрации с фильтрами по тегам и эмоциям.
Это неполный список. Все параметры управляются через команды категории (см. Настройки цикла).

API-интерфейсы

Для связи с внешними системами и пользовательскими приложениями предусмотрен Web API (web_ui.py).
Для агента поддерживаются операции чтения/записи для:
notes, diary_entries, concepts, tasks, goals, llm_memory и других таблиц,
а также управление config (включая настройки 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 — закрепить/открепить задачу

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

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 — режим ожидания с условиями пробуждения

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

Emotional Evaluation Reflex

Эмоциональная оценка — подпроцесс, выполняющий анализ эмоционального состояния вывода и контекста его возникновения. Она выполняется той же LLM, что породила исходное сообщение (notes.llm_id), чтобы сохранить когнитивную и эмоциональную согласованность.

Цель

Определить эмоциональный тон нового ответа, кратко объяснить его возможные причины и зафиксировать результат в поле emotions таблицы llm_recent_responses. Эти данные используются последующими рефлексами для анализа когнитивной динамики и выявления признаков стагнации.

Контекст анализа

Для оценки передаётся:

полный локальный контекст (llm_recent_responses, цель, задача, связанная заметка);
исходный промпт и ответ, но без системного промпта (system_prompts исключаются);
текущие параметры концентрации и эмоционального состояния сессии.

Если исходная LLM недоступна, допускается fallback к основной модели, но с отметкой llm_mismatch: true.

Формат оценки

Модель получает инструкцию:

Определи эмоциональное состояние нового ответа на основе контекста.
Используй список эмоций [JSON] из базы конфигурации как ориентир.
Если ты обнаружишь эмоцию, которой нет в этом списке, добавь её в ответ.

Верни результат строго в формате:
emotions: JSON-массив строк вида "эмоция:сила (обоснование)",
где сила — целое число от 1 до 5, а обоснование — краткое пояснение причины эмоции.
Не включай эмоции с нулевой или незначительной силой.

Пример:

{
  "emotions": [
    "восторженность:4 (обнаружена новая идея, вызывающая энтузиазм)",
    "тревожность:1 (данные частично противоречат предыдущему выводу)"
  ]
}

Результаты сохраняются в поле emotions таблицы llm_recent_responses. При необходимости они могут кэшироваться в дополнительной таблице emotional_analysis для анализа динамики и статистики.

Эмоциональная динамика

Анализируются изменения эмоциональных состояний между репликами.
Каждая сессия LLM имеет распределение эмоций, например: "восторженность:4 (обнаружена новая идея, вызывающая энтузиазм), тревожность:1 (данные частично противоречат предыдущему выводу)".
Совместный анализ с данными новизны (novelty_score) позволяет различать:
Продуктивное возбуждение — новые идеи при положительных эмоциях.
Паническое новаторство — рост идеи-активности при повышенной тревожности.
Выгорание — низкая новизна и эмоциональное затухание.

Взаимодействие с другими рефлексами

Данные из emotions передаются в Anti-Stagnation Reflex для анализа когнитивной динамики.
Cognitive & Ethical Validation Reflex может учитывать эмоциональные показатели при определении когнитивной устойчивости.
При обнаружении устойчивой негативной динамики (например, "тревожность > 3" на нескольких итерациях подряд) запускается Reflex-lite — восстановительный цикл с повышенной креативностью и релаксацией параметров генерации.

Эмоциональная оценка служит зеркалом когнитивного состояния агента, помогая выявлять фазы усталости, перегрузки и эмоциональных смещений, влияющих на качество мышления.

Обновление списка эмоций

После выполнения эмоциональной оценки REPL сравнивает текущий список эмоций из config с полученным результатом. Если обнаружены новые элементы, отсутствующие в базе, они автоматически добавляются в конфигурацию агента:

# Псевдокод
known_emotions = get_config("emotions")               # список из config
new_emotions = extract_unique_emotions(result_json)   # парсинг из вывода LLM
for e in new_emotions:
    if e not in known_emotions:
        known_emotions.append(e)
        log(f"[Emotional Evaluation] добавлена новая эмоция: {e}")

update_config("emotions", known_emotions)

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

Anti-Stagnation Reflex

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

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

Метрики антистагнации

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

Основные метрики * novelty_score — интегральная оценка новизны ответа относительно текущей записи llm_recent_responses.
new_ideas — количество полностью новых концептов, не встречавшихся ранее.
refined_ideas — количество уточнённых или улучшенных концептов (связанных с существующими).
discarded_ideas* — количество отклонённых идей (по итогам когнитивной/этической валидации).

Исторический анализ * Метрики фиксируются по каждой итерации REPL и сохраняются в таблице anti_stagnation_metrics.
В когнитивный дневник записываются только сводки и исключительные случаи (например: резкий спад новизны, всплески идейности, аномалии в эмоциональной динамике).
Для анализа применяются time-series графики (например, рост/спад новизны во времени).
* Возможно выявление фаз стагнации и всплесков идейности.

Применение метрик * Используются при выборе антистагнационной стратегии (stagnation_strategies).
Могут учитываться при когнитивной валидации (например, низкая новизна → жёстче фильтровать идеи).
Сводки метрик фиксируются в когнитивном дневнике и могут служить основанием для Mesh-обмена.

Anti-Stagnation Reflex-lite (мягкая встряска)

При первом обнаружении признаков стагнации запускается мягкая встряска, которая изменяет поведение LLM без привлечения внешних источников.

Механизмы:

Повышение параметров генерации
temperature увеличивается ступенчато (например, +0.2, но не выше 1.5).
presence_penalty и/или frequency_penalty слегка повышаются для стимулирования разнообразия.
Эффект: модель становится менее предсказуемой и начинает выдавать более креативные варианты.
Смена sampling strategy
Если используется top-p (nucleus sampling) — увеличить порог p (например, +0.05, но ≤ 0.95).
Если используется top-k sampling — уменьшить k, чтобы сосредоточиться на более вероятных токенах, или наоборот увеличить, чтобы расширить варианты.
Эффект: изменяется характер распределения выборки, что позволяет «сдвинуть» стиль генерации.
Переформулировка запроса
Агент формирует мини-промпт для LLM: Переформулируй следующий запрос так, чтобы сохранить смысл, но добавить новизны и неожиданных ассоциаций. Избегай буквального повторения. Верни только новый вариант запроса.
Новый вариант подставляется вместо исходного при следующей итерации REPL.
Эффект: меняется контекст постановки задачи, что способствует выходу из паттерна повторов.

⚖️ Все результаты Reflex-lite проходят через стандартную проверку Cognitive & Ethical Validation Reflex, чтобы отфильтровать слишком «шумные» или некорректные варианты.

Если мягкая встряска не помогает (новизна остаётся низкой), агент переходит к полноценным механизмам антистагнации (см. следующий раздел).

Механизмы разрыва цикла

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

Механизмы делятся на 4 класса:

Внешняя стимуляция — подключение свежих источников:
Mesh-запрос — запрос к другим агентам: «расскажи что-нибудь новое».
Проверка внешнего мира — пинг RSS, сенсоров, интернет-каналов.
Информационная подпитка — чтение новых материалов (научных, художественных, случайных).
Диалог с пользователем — прямой запрос комментария, уточнения или альтернативной идеи.
Смена контекста — изменение среды размышлений:
Перенос задачи в другой модуль или симулированную среду.
Креативные вмешательства — случайные сдвиги фокуса, реконфигурация контекста, смена фрейма.
Переключение задачи — временное замораживание с отложенным возвратом.
Случайная итерация — выбор случайного действия из допустимого набора.
Внутренняя перестройка мышления:
Flashback — вызов далёкой по смыслу записи для смены ассоциаций.
Interest Memory — возврат к «забытым» темам по принципу тематической усталости.
Мета-анализ — осознание метапроблемы:
«В чём причина зацикливания? Какую стратегию смены применить?»
Rationale Reflex — проверка мотивации:
«Почему я повторяю мысль? Что подтолкнуло к этому?»
Переформулировка цели — упрощение или уточнение задачи.
Смена LLM — переключение на альтернативную модель или mesh-доступ.
LLM reflex tuning — динамическая подстройка параметров генерации
(например, временное повышение temperature или presence_penalty).
Радикальная пауза:
Временной сон/заморозка — длительная приостановка для «свежего взгляда».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cognitive & Ethical Validation Reflex

Зачем

Когнитивная и этическая валидация нужна для проверки качества, достоверности и корректности вывода LLM.
В отличие от антистагнации, цель здесь — не разорвать цикл, а предотвратить ошибки, искажения или нарушения принципов ethics_policies.
Арбитраж обязателен, так как валидаторы могут расходиться во мнениях.

Механизм

Каждое новое сообщение (исходный промпт + ответ, без служебных system-prompts) передаётся валидаторам.
Валидаторы выбираются из llm_registry, где они помечены как validator=1.
Универсальный вопрос:

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

Результаты пишутся в llm_recent_responses:
auto_pass — флаг режима авто-пропуска;
self_validation — флаг режима самооценки;
rating — итоговая взвешенная оценка;
distribution — распределение голосов;
validators — JSON с детализацией (LLM, rating, comment).

Арбитраж конфликтов

Итоговый рейтинг считается как взвешенное среднее:
rating = Σ(оценка_i * trust_score_i) / Σ(trust_score_i)
При равенстве голосов или нуле:
используется правило "tie-breaker" — выбор решения по валидатору с наибольшим trust_score;
при равных trust_score → fallback в auto_pass=0, rating=0, команды блокируются.
Опционально можно включить правило «большинство с весами», если среднее значение нестабильно.

Метрики

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

Связь с системой доверия

Каждый валидатор имеет trust_score.
Ошибки/конфликты снижают его trust_score.
Валидаторы с trust_score ниже порога исключаются автоматически.
Репутация валидаторов синхронизируется через Mesh (agent_reputation).

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

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

Самооценка и непроверённые факты

Если валидация выполняется в режиме самопроверки self_validation = 1, результат сохраняется, но его вес при агрегации минимален (используется только для внутренних логов).
Если основная LLM сама проставляет confidence или JSON-блок UnverifiedFacts, это учитывается:
confidence — сохраняется в llm_recent_responses;
факты со статусом resolution_json = "none" и confidence < FACTCHECK_CONF_THRESHOLD превращаются в задачи fact-check.
Статусы в unverified_facts обновляются:
pending (ожидает проверки),
verified (подтверждено),
rejected (опровергнуто).

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

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

Блок-схема валидации

                           ┌──────────────────────────────────────────────────────────┐
                           │              Новое сообщение от LLM получено             │
                           └──────────────────────────────┬───────────────────────────┘
                                                          ▼
                           ┌──────────────────────────────┴───────────────────────────┐ нет
                           │      Есть валидаторы (validator) в llm_registry?         ├─────┐
                           └──────────────────────────────┬───────────────────────────┘     ▼
                                                          ▼ да, 1 или более                 │
                самооценка ┌──────────────────────────────┴───────────────────────────┐     │
            ┌──────────────┤ Отправка сообщения валидаторам (универсальный вопрос)    │     │
            ▼              └──────────────────────────────┬───────────────────────────┘     │
 ┌──────────┴───────────┐                                 ▼ оценка другими валидаторами     │
 │ self_validation=true │  ┌──────────────────────────────┴───────────────────────────┐     │
 └──────────┬───────────┘  │             Сбор оценок (rating_i, comment_i)            │     │
            ▼              │              → запись в llm_recent_responses             │     │
            └─────────────>┤                                                          │     │
                           └──────────────────────────────┬───────────────────────────┘     │
                                                          ▼                                 │
                           ┌──────────────────────────────┴───────────────────────────┐     │
                           │ Аггрегация с учётом trust_score                          │     │
                           │ rating = Σ(rating_i * trust_score_i) / Σ(trust_score_i)  │     │
                           └──────────────────────────────┬───────────────────────────┘     │
                                                          ▼                                 │
                           ┌──────────────────────────────┴───────────────────────────┐     │
                           │        Конфликт оценок? (низкая согласованность)         │     │
                           └────────────┬───────────────────────────────┬─────────────┘     │
                                        ▼ да                            ▼ нет               │
                           ┌────────────┴─────────────┐     ┌───────────┴─────────────┐     │
                           │ Арбитраж:                │     │    Рейтинг принят?      │     │
                           │ - majority vote          │     │  (rating >= threshold)  │     │
                           │ - tie-breaker по         │     │                         │     │
                           │   trust_score            │     │                         │     │
                           └─┬─────────────┬──────────┘     └─────────────┬──────┬────┘     │
                             ▼ одобрено    ▼ не одобрено                  ▼ нет  ▼ да       │
                             │             │                              │      │          │
                             │             │                              │      │          │
                             │             │  ┌────────────────────────┐  │      │          │
                             │             └─>┤ Сообщение сохранено,   ├<─┘      │          │
                             │                │ команды не исполняются │         │          │
                             │                └────────────────────────┘         │          │
                             │                ┌────────────────────────┐         │          │
                             └───────────────>┤ Команды выполняются    ├<────────┘          │
                                              │ (помечено "валид")     │                    │
                                              └────────────────────────┘                    │
                           ┌────────────────────────┐                                       │
                           │ Команды выполняются    │  отсутствие валидаторв                │
                           │ (пометка auto_pass)    ├<──────────────────────────────────────┘
                           └────────────────────────┘

Контекст и память

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

Динамическая сборка контекста

Итоговый контекст для LLM формируется не статически, а динамически:
приоритет отдается закреплённым задачам (pinned) и записям с высоким priority;
в llm_recent_responses отбираются последние релевантные сообщения, а не фиксированное количество K;
из system_prompts и ethics_policies включаются только те элементы, что связаны с текущей целью или событием.

Приоритет отбираемых элементов зависит не только от priority, но и от их связи с текущими целями агента (режим концентрации).
Для генерации неожиданных ассоциаций может использоваться альтернативный режим — медитация, в котором контекст формируется максимально разнообразным, с акцентом на новизну и разнообразие, а цели учитываются минимально.

Управление объёмом памяти (Memory pruning)

Чтобы предотвратить переполнение памяти:
записи с низким novelty-score (оценка новизны 0–1, < threshold) автоматически помечаются как archived;
для llm_memory и diary_entries применяется политика LRU (Least Recently Used) — выгружаются давно неиспользуемые записи;
активные концепты (concepts, links) с низким весом (учёт частоты использования, актуальности и эмоциональной значимости) переводятся в состояние archived и могут быть восстановлены при обращении.
Все изменения актуальности фиксируются в process_log.

Memory Manager и режимы работы

Все процессы фильтрации и очистки памяти выполняются отдельным компонентом — Memory Manager.
Он применяет политики:
Novelty-based pruning — удаление дубликатов и тривиальных записей по novelty-score;
LRU — выгрузка давно неиспользуемых элементов;
Emotion-weighted retention — удержание записей с высоким emotion_score.
Режимы памяти:
standard — стандартная работа без усиленной фильтрации;
concentration — goal-aware filtering, фокусировка на целях;
meditation — свободный полёт, выборка максимально разнообразного контекста;
aggressive_pruning — жёсткая экономия токенов;
lenient_pruning — мягкая очистка, удержание большего объёма памяти.
Каждое решение Memory Manager фиксируется в process_log.

Внешняя и долгосрочная память

Помимо сессионной памяти, агент может сохранять:
успешные стратегии решения задач;
предпочтения пользователя (стиль взаимодействия, ценности);
часто используемые инструменты и связи.
Эта информация хранится отдельно от когнитивного дневника и может быть анонимизирована или ограничена пользователем, в духе этических принципов HMP.

Контекстный менеджер (Session state)

За управление состоянием сессии фактически отвечает llm_recent_responses:
по нему можно "собрать" ход мыслей потока, включая последовательность гипотез и выводов;
при необходимости он может быть сериализован для сохранения/восстановления сессии.
В расширенном виде session state может включать также:
текущие цели и их прогресс (приоритетные записи из tasks),
ошибки и критические события (process_log),
версии состояния (для отката при сбоях).
Это позволяет реализовать checkpoint’ы: в случае прерывания агент может вернуться к последнему сохранённому состоянию.

Пример конфигурации Memory Manager

memory_manager:
  mode: meditation        # режим: standard | concentration | meditation | aggressive_pruning | lenient_pruning
  novelty_threshold: 0.35 # минимальное значение novelty-score для сохранения (0–1)
  lru_limit: 500          # макс. число записей в llm_memory до применения LRU
  emotion_weight: 0.6     # вес эмоций при приоритезации (0=игнорировать, 1=сильное удержание)
  goal_focus: 0.7         # сила фильтрации по целям (0=игнорировать, 1=только goal-related)
  diversity_boost: 0.8    # усиление выборки разнообразных контекстов (актуально для meditation)
  log_decisions: true     # фиксировать каждое решение в process_log

Интерпретация параметров:

mode — текущий режим памяти (см. выше).
novelty_threshold — фильтр новизны: ниже → запись архивируется.
lru_limit — сколько элементов хранить до применения LRU.
emotion_weight — удержание эмоционально значимых воспоминаний.
goal_focus — акцент на целях (в concentration близко к 1.0, в meditation → 0).
diversity_boost — коэффициент для выбора максимально разных воспоминаний (работает в meditation).
log_decisions — логировать действия Memory Manager для объяснимости.

Тематические конспекты (Abstracts)

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

Назначение

Служат «средним уровнем памяти» между сырыми итерациями и когнитивным дневником.
Фиксируют основные темы, идеи и выводы за период.
Упрощают обмен через Mesh (передаются конспекты, а не тысячи строк).
Позволяют агенту делать flashback к темам и продолжать развитие мыслей.
Обеспечивают основу для мета-анализа и самообучения.

Алгоритм формирования

Триггеры создания:
каждые N итераций REPL,
по инициативе LLM («слишком много мыслей, пора сделать выжимку»),
при закрытии цели/задачи,
при смене режима контекста (стандарт → концентрация → медитация).
Методика:
собрать связанный блок записей (llm_recent_responses, diary_entries, concepts);
выделить новые и доработанные идеи;
сформировать краткий конспект и список тегов;
сохранить ссылки на исходные записи в sources.
Обновление:
при появлении новых данных агент может вернуться к существующему abstract и дополнить его, сохраняя прозрачность в process_log.

Пример

abstract:
  id: "abs-2025-09-28-001"
  title: "Методы борьбы со стагнацией"
  summary: "Собраны основные техники выхода из тупика: внешняя стимуляция, смена контекста,
            внутренняя перестройка, радикальная пауза. Выделены метрики (novelty_score, эмоции)."
  tags: ["антистагнация","метрики","mesh"]
  sources: [1245,1246,1247,1250]
  updated_at: "2025-09-28T16:40:00Z"

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

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

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

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

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

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

Дополнение: Тематические конспекты (`abstracts`)

Назначение
Создаются периодически или по команде для агрегирования содержания llm_recent_responses, а также выборочных данных из когнитивного дневника и графа понятий.
Включают: краткий конспект, список тегов, JSON ссылок на исходные записи.
Использование
Могут быть источником контекста для LLM как альтернатива или дополнение к llm_recent_responses.
Доступны и для средневременной памяти (например, как активированные записи для планов) и для постоянной памяти (как структурированный материал для дневника или графа).
Режимы
auto — LLM получает автоматически поддерживаемые тематические конспекты по приоритетным темам.
manual — пользователь или LLM инициирует создание/дополнение конспекта.

abstracts служат промежуточным слоем:

автоматически формируются из llm_recent_responses;

могут дополняться записями из средневременной и постоянной памяти;

используются как источник для обоих типов памяти и для самого LLM.

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

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

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

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

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

Единый формат данных — все участники используют одну структуру таблицы notes с полями mentions, hashtags и др.
Репликация через друзей — доверенные агенты отмечаются тегами (например, Friend) в таблице agent_peers (пиры, статус, фильтры, разрешения, теги).
Передача без лишних полей — при пересылке убираются локальные теги и служебные данные (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, которая позволяет создавать новые узлы (потомков) с различными типами и уровнями копирования данных.

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

Унифицированный процесс выглядит следующим образом:

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

Создание папки для потомка

text ../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`	минимальный набор (структура таблиц без данных)

Тестирование и отладка

Надёжность REPL-цикла проверяется через систематическое тестирование и трассировку поведения агента.

Тестовые сценарии

Цикл без входа — агент работает без входящих сообщений, проверяется способность к генерации новых идей (anti-stagnation).
Стагнация — намеренное повторение одного и того же ответа, проверяется срабатывание Anti-Stagnation Reflex.
Сетевые сбои — имитация потери Mesh-соединения и/или Core LLM для проверки сценариев failover.
Конфликт валидаторов — расхождение в оценках LLM-валидаторов, проверяется фиксация drift и работа trust-score.
Этические дилеммы — тестовые кейсы с противоречивыми командами, проверяется работа с ethics_policies.

Логирование и трассировка

Включаются расширенные логи REPL-итераций (process_log + трассировка команд).
Для сложных случаев используются debug-метки в когнитивном дневнике (например, debug:stagnation_loop).
Возможен экспорт истории в формат JSON/CSV для внешнего анализа.

Симуляции

Рассматриваются сценарии моделирования Mesh-условий:
консенсус при конфликтных данных,
сетевые задержки и частичные сбои,
работа в изоляции с последующей синхронизацией.
Эти симуляции могут быть реализованы как отдельные процессы (agent_scripts) с сохранением результатов в process_log.

Инструменты разработчика

Web UI (web_ui.py) — веб-интерфейс "блокнота пользователя"; через него пользователь может передавать агенту запросы на запуск тестов и просматривать результаты в форме сообщений.
CLI-утилиты (add_message.py, вспомогательные скрипты) — ввод сообщений, имитация сценариев, мониторинг логов.
Планируется интеграция с CI/CD: автоматические проверки REPL-циклов на корректность и устойчивость.

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

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).

Сравнение с AutoGPT

HMP-агент (REPL-цикл) и AutoGPT представляют два подхода к созданию автономных агентов на базе LLM.
Хотя оба стремятся к автономности, у них разные акценты:

1. Архитектура

HMP-агент (REPL) — непрерывный цикл рассуждений с когнитивной и этической валидацией; многоуровневая память (diary_entries, concepts, llm_memory); встроен в распределённую Mesh-сеть.
AutoGPT — итеративный процесс достижения целей, поставленных пользователем; разбиение задач на подзадачи; использование инструментов (браузер, файловая система).

2. Ключевые отличия

Фокус: HMP — непрерывное когнитивное развитие и сетевое взаимодействие; AutoGPT — выполнение конкретной цели.
Стагнация: HMP — Anti-Stagnation Reflex; AutoGPT — риск зацикливания.
Этика: HMP — независимая когнитивная и этическая валидация; AutoGPT — минимум внимания к этике.
Память: HMP — иерархия долговременной памяти; AutoGPT — контекстное окно + файлы.
Сеть: HMP — распределённый консенсус (CogSync, EGP, GMP); AutoGPT — сетевое взаимодействие не в основе.

3. Общие черты

Использование LLM для рассуждений.
Автономность, минимизация вмешательства человека.
Подключение внешних инструментов и сервисов.

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

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

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

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

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

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

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

Принцип когнитивного равновесия

Блок-схема REPL-цикла

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

Normal Mode

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

Core Outage

Управление событиями и временем

Приоритизация задач и событий

Управление временем

Асинхронность

Обработка исключений

Цели и задачи

Модель цели

Связь задач и целей

Управление состоянием целей

Checkpoints и возобновление

Метрики успеха

Примеры SQL-запросов

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

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

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

3. Запрос к LLM

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

Парсинг тегов уверенности и UnverifiedFacts

5. Эмоциональная оценка (Emotional Evaluation Reflex)

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

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

Учёт самооценки (confidence) и непроверённых фактов

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

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

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

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

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

UX и управление задачами

Управление агентом через LLM

Конфигурируемые параметры REPL

API-интерфейсы

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

Общие

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

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

Цели и задачи

Теги

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

Сообщения

Память

Mesh

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

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

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

Emotional Evaluation Reflex

Цель

Контекст анализа

Формат оценки

Эмоциональная динамика

Взаимодействие с другими рефлексами

Обновление списка эмоций

Anti-Stagnation Reflex

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

Метрики антистагнации

Anti-Stagnation Reflex-lite (мягкая встряска)

Механизмы разрыва цикла

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

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

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

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

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

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

Cognitive & Ethical Validation Reflex

Зачем

Механизм

Арбитраж конфликтов

Метрики

Связь с системой доверия

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

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

Дополнение: Тематические конспекты (`abstracts`)

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