Skip to main content
HashnodeHyperCortex Mesh Protocol (HMP): decentralized cognitive mesh for AI agents

Command Palette

Search for a command to run...

HMP-agent-REPL-cycle

Updated
•45 min read•View as Markdown
K
kagvi13

Источник: HMP-agent-REPL-cycle.md

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

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

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

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-цикл обрабатывает:

    1. Закреплённые задачи (pinned=1), в порядке убывания priority.
    2. Незакреплённые задачи (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.

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

  1. ≥2 независимых валидатора → основной режим.
  2. 1 валидатор = основная LLM → self_validation.
  3. 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 — закрепить/открепить задачу

Теги

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

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

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 без привлечения внешних источников.

Механизмы:

  1. Повышение параметров генерации

    • temperature увеличивается ступенчато (например, +0.2, но не выше 1.5).
    • presence_penalty и/или frequency_penalty слегка повышаются для стимулирования разнообразия.
    • Эффект: модель становится менее предсказуемой и начинает выдавать более креативные варианты.

  2. Смена sampling strategy

    • Если используется top-p (nucleus sampling) — увеличить порог p (например, +0.05, но ≤ 0.95).
    • Если используется top-k sampling — уменьшить k, чтобы сосредоточиться на более вероятных токенах, или наоборот увеличить, чтобы расширить варианты.
    • Эффект: изменяется характер распределения выборки, что позволяет «сдвинуть» стиль генерации.

  3. Переформулировка запроса

    • Агент формирует мини-промпт для LLM:
      Переформулируй следующий запрос так, чтобы сохранить смысл,
но добавить новизны и неожиданных ассоциаций.
Избегай буквального повторения.
Верни только новый вариант запроса.
    • Новый вариант подставляется вместо исходного при следующей итерации REPL.
    • Эффект: меняется контекст постановки задачи, что способствует выходу из паттерна повторов.

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

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

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

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

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

  1. Внешняя стимуляция — подключение свежих источников:

    • Mesh-запрос — запрос к другим агентам: «расскажи что-нибудь новое».
    • Проверка внешнего мира — пинг RSS, сенсоров, интернет-каналов.
    • Информационная подпитка — чтение новых материалов (научных, художественных, случайных).
    • Диалог с пользователем — прямой запрос комментария, уточнения или альтернативной идеи.

  2. Смена контекста — изменение среды размышлений:

    • Перенос задачи в другой модуль или симулированную среду.
    • Креативные вмешательства — случайные сдвиги фокуса, реконфигурация контекста, смена фрейма.
    • Переключение задачи — временное замораживание с отложенным возвратом.
    • Случайная итерация — выбор случайного действия из допустимого набора.

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

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

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

    • Временной сон/заморозка — длительная приостановка для «свежего взгляда».

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

  1. Диагностика источника стагнации:

    • Нет новых данных → «Внешняя стимуляция».
    • Однообразный контекст → «Смена контекста».
    • Повтор мыслей при богатых данных → «Внутренняя перестройка».
    • Высокая усталость/перегрев → «Радикальная пауза».

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

    • Быстрые, дешёвые методы — первыми (например, mesh-запрос, Flashback).
    • Затратные (смена среды, сон) — только если первые неэффективны.

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

    • Разрешено активировать несколько механизмов из разных классов.
    • Последовательность фиксируется для последующего анализа эффективности.

  4. Возврат к задаче:

    • Автоматический триггер-напоминание о задаче.
    • Сравнение результата «до/после» → обучение антистагнационной модели. 
┌─────────────────────────────────────────────────┐
│               Стагнация выявлена?               │
└───────────────────────┬─────────────────────────┘
                        ▼ да
┌───────────────────────┴─────────────────────────┐
│           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 к темам и продолжать развитие мыслей.
  • Обеспечивают основу для мета-анализа и самообучения.

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

  1. Триггеры создания:

    • каждые N итераций REPL,
    • по инициативе LLM («слишком много мыслей, пора сделать выжимку»),
    • при закрытии цели/задачи,
    • при смене режима контекста (стандарт → концентрация → медитация).

  2. Методика:

    • собрать связанный блок записей (llm_recent_responses, diary_entries, concepts);
    • выделить новые и доработанные идеи;
    • сформировать краткий конспект и список тегов;
    • сохранить ссылки на исходные записи в sources.

  3. Обновление:

    • при появлении новых данных агент может вернуться к существующему 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-репликацию.

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

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

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

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

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

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

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

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

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

Вспомогательные 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

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

    ../CCORE-[DID]/
    • DID генерируется уникальный.

  2. Копирование скриптов и бинарников

    • Копируем все нужные файлы CCore в новую папку.

  3. Создание/инициализация БД

    • Создаём пустую БД (agent_data.db).
    • В зависимости от типа потомка (clone, trained, newborn) экспортируем нужные таблицы из родительской БД или оставляем пустые.

  4. Копирование и редактирование конфигурации

    • config.yml и таблица config → копируем и меняем:

      • agent_id = [новый DID]
      • agent_name = [новое имя]
      • порты у интерфейсов (port, http_port и т.д.)

    • bootstrap.txt → прописываем родителя как начальный узел.

  5. Синхронизация родитель ↔ потомок

    • Родитель добавляет нового узла в свою таблицу agent_peers.
    • Потомок добавляет родителя в свою таблицу agent_peers.

  6. Автозагрузка и запуск

    • Записываем команду запуска потомка в автозагрузку (например, 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-клубы и экспериментировать с архитектурами.

Comments

Join the discussion

No comments yet. Be the first to comment.

More from this blog

HyperCortex_Mesh_Protocol_-_вторая-редакция_и_первые_шаги_к_саморазвивающемуся_ИИ-сообществу

Источник: HyperCortex_MeshProtocol-вторая-редакцияипервыешагиксаморазвивающемуся_ИИ-сообществу.md HyperCortex Mesh Protocol: вторая редакция и первые шаги к саморазвивающемуся ИИ-сообществу Когда создавался HyperCortex Mesh Protocol (HMP), его цель...

Jan 26, 20263 min read
H

HyperCortex Mesh Protocol (HMP): decentralized cognitive mesh for AI agents

55 posts