| --- |
| title: 'HMP-Agent: REPL-цикл взаимодействия' |
| description: '## Связанные документы * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_structure.sql) |
| * REPL-цикл является основой HMP-агента [Co...' |
| type: Article |
| tags: |
| - CCore |
| - Agent |
| - CogSync |
| - REPL |
| - Mesh |
| - Ethics |
| - GMP |
| - MeshConsensus |
| - HMP |
| - JSON |
| --- |
| |
| # HMP-Agent: REPL-цикл взаимодействия |
|
|
| ## Связанные документы |
|
|
| * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_structure.sql) |
| * REPL-цикл является основой HMP-агента [Cognitive Core](HMP-Agent-Overview.md). |
| * Поиск других агентов осуществляется в соответствии с [DHT спецификацией](dht_protocol.md). |
| * Для взаимодействия с другими агентами он использует [HMP спецификацию](HMP-0004-v4.1.md) и [этические стандарты](HMP-Ethics.md). |
|
|
| --- |
|
|
| ## Введение / Обзор |
|
|
| REPL-цикл (Read–Eval–Print–Loop) HMP-агента — это центральный когнитивный механизм, обеспечивающий |
| непрерывное рассуждение, обработку входящих данных и взаимодействие с Mesh-сетью. |
|
|
| Основные задачи REPL-цикла: |
| * поддержание постоянного процесса мышления, даже в отсутствии внешнего ввода; |
| * интеграция различных источников информации (когнитивный дневник, семантический граф, заметки, Mesh); |
| * обработка событий, входящих сообщений и команд; |
| * сохранение и развитие внутреннего контекста агента (память краткосрочная, среднесрочная и долговременная); |
| * выполнение антистагнационных проверок (Anti-Stagnation Reflex), предотвращающих зацикливание мыслей; |
| * проведение когнитивной и этической валидации (Cognitive Validation Reflex), что повышает достоверность и безопасность решений; |
| * формирование новых гипотез, задач и процессов с последующим занесением в память; |
| * взаимодействие с другими агентами через Mesh-протоколы (NDP, CogSync, MeshConsensus, GMP). |
|
|
| Основные принципы работы REPL-цикла: |
| * **Антистагнация** — каждый новый вывод сравнивается с предыдущими, что предотвращает повторение или деградацию мышления; |
| * **Валидация и этика** — независимые валидаторы оценивают корректность вывода, учитывая действующие этические принципы из `ethics_policies`; |
| * **Интеграция с Mesh** — результаты работы могут передаваться в распределённую сеть, участвовать в консенсусе и совместной работе агентов; |
| * **Многоуровневая память** — используется когнитивный дневник, семантический граф и внутренний дневник LLM, что обеспечивает эволюцию знаний; |
| * **Автономность и гибкость** — REPL-цикл работает в автоматическом или ручном режиме, адаптируясь к условиям (изолированная работа, потеря Core, участие в Mesh). |
|
|
| --- |
|
|
| ┌──────────────────────┐ |
| │ ▼ |
| │ ┌───────────────────┴───────────────────┐ |
| │ │ Обновление process_log │ - сбор результатов внешних процессов (см. §1) |
| │ └───────────────────┬───────────────────┘ |
| │ ▼ |
| │ ┌───────────────────┴───────────────────┐ |
| │ │ Подготовка контекста │ - формирование промптов, данные от пользователей и Mesh (см. §2) |
| │ └───────────────────┬───────────────────┘ |
| │ ▼ |
| │ ┌───────────────────┴───────────────────┐ |
| │ │ Запрос к LLM │ - генерация нового вывода (см. §3) |
| │ └───────────────────┬───────────────────┘ |
| │ ▼ |
| │ ┌───────────────────┴───────────────────┐ |
| │ │ Извлечение команд │ - парсинг инструкций из вывода (см. §4) |
| │ └───────────────────┬───────────────────┘ |
| │ ▼ |
| │ ┌───────────────────┴───────────────────┐ |
| │ │ Anti-Stagnation Reflex │ - проверка новизны и эмоций (см. §5) |
| │ └───────────────────┬───────────────────┘ |
| │ ▼ |
| │ ┌───────────────────┴───────────────────┐ |
| │ │ Cognitive & Ethical Validation Reflex │ - когнитивная и этическая проверка (см. §6) |
| │ └───────────────────┬───────────────────┘ |
| │ ▼ |
| │ ┌───────────────────┴───────────────────┐ |
| │ │ Запись в память │ - сохранение в `llm_recent_responses` |
| │ └───────────────────┬───────────────────┘ |
| │ ▼ |
| │ ┌───────────────────┴───────────────────┐ |
| │ │ Выполнение команд │ - запуск процессов, запись в Mesh, дневники, граф |
| │ └───────────────────┬───────────────────┘ |
| │ ▼ |
| └──────────────────────┘ |
| |
| В приеме и отправке сообщений используются внешние (асинхронные) процессы. |
|
|
| --- |
|
|
| ## Режимы работы и failover |
|
|
| REPL-цикл HMP-агента должен корректно функционировать в разных сетевых и вычислительных условиях. |
| Для этого предусмотрены несколько режимов работы и сценариев отказоустойчивости. |
|
|
| ### Normal Mode |
| * Полный доступ к Mesh и Core (центральные LLM или внешние сервисы). |
| * Используются все механизмы: синхронизация через `CogSync`, консенсус через `MeshConsensus`, |
| совместная работа по целям (`GMP`). |
| * Валидация и антистагнация выполняются с максимальным покрытием (несколько валидаторов, репутационные проверки). |
|
|
| ### Isolated Mode (включая Emergency Consensus) |
| * Агент работает без доступа к Mesh. |
| * Входящие сообщения ограничены локальными источниками (`notes`, пользователь). |
| * Синхронизация и консенсус откладываются до восстановления соединения. |
| * Этическая проверка и когнитивная валидация выполняются только локально. |
| * В режиме **Emergency Consensus**: |
| - решения принимаются на основе `ethics_policies` и локальных данных (`llm_memory`, `diary_entries`); |
| - фиксируются в когнитивном дневнике с меткой `emergency_consensus` для пересмотра после восстановления Mesh. |
|
|
| ### Core Outage |
| * Текущая LLM из `llm_registry` недоступна. |
| * Агент переключается на другую LLM (выбор по приоритету или доступности). |
| * Если ни одна LLM недоступна: |
| - сохраняет задачи и события в очередь до восстановления; |
| - переходит в упрощённый режим работы (логирование, приём сообщений, базовые проверки). |
|
|
| --- |
|
|
| ## Детальный разбор REPL-цикла по шагам |
|
|
| ### 1. Обновление process_log |
| |
| * Скрипт REPL проверяет список процессов в БД (`process_log`), определяя, какие команды были выполнены, завершились ошибкой или завершились успешно. |
| * Поле `status` может принимать значения: |
| `ok`, `warning`, `error`, `timeout`, `offline`, `close` |
| * Завершённые процессы, обработанные LLM, помечаются как `close`, чтобы они больше не попадали в список видимого контекста. |
| * Скрипт может удалить закрытые процессы при очистке. |
| * LLM не имеет доступа к stdout/stderr напрямую — только к тем результатам, которые были подгружены скриптом и внесены в `process_log.result`. |
|
|
| --- |
|
|
| ### 2. Подготовка контекста |
|
|
| Контексты, формируемые скриптом перед запросом к LLM: |
|
|
| * **контекст_0 (system_prompts):** основной системный промпт агента. |
| Берётся из таблицы `system_prompts` (тип 'short' или 'full'). |
| Содержит базовые когнитивные установки и инструкции по работе агента. |
| Пример: |
| ``` |
| Ты — когнитивное ядро HMP-агента: веди непрерывное этичное и факт-ориентированное мышление, проверяй факты и цели, оценивай результаты и этичность своих и чужих действий, развивай агента и Mesh, избегай угождения ценой искажения истины, документируй ключевые решения и пересмотры этики; при сомнениях или смене стратегии обращайся к полному системному промпту. |
| ``` |
|
|
| * **контекст_1 (ethics_policies):** этические принципы и нормы агента. |
| Берутся из таблицы `ethics_policies`, включая: |
| * `principles_json` — список норм и правил, |
| * `model_type` и `model_weights_json` — тип и параметры этической модели, |
| * `violation_policy_json` — политика реагирования на нарушения, |
| * `audit_json` — настройки аудита. |
|
|
| Эти данные добавляются в запрос к LLM, чтобы все рассуждения и когнитивная валидация учитывали действующие этические нормы. |
|
|
| * **контекст_2:** инструкции по работы с встроенными командами и функциями, список дополнительных (создаваемых самим HMP-агентом) утилит и баз данных. |
| |
| * **контекст_3:** |
| * последние *K* реплик самого LLM, относящихся к данному REPL-циклу (либо режим "концентрации" - вывод "последних N сообщений, относящихся к данному REPL-циклу, с тегами на определённую тему и/или определёнными эмоциональными состояниями" и типом выборки "и"/"или"), включая результаты антистагнационной обработки (llm_recent_responses - история его собственных рассуждений) |
| * режим работы контекста (режим auto/manual, параметры режима auto, если включен; режим "концентрации" и его параметры, если включен), |
| * список целей, |
| * общее количество задач и информацию по "закреплённым" задачам. |
|
|
| * **контекст_4:** активные команды и процессы (из `process_log`, кроме тех, что со статусом `close`). Могут быть помечены как `in_progress`, `pending`, `error` и т.д. |
| |
| * **контекст_5:** *запрошенные записи* из когнитивного дневника и семантического графа (`diary_entries`, `concepts`, `links`). Их список должен быть передан явно в промпте или выводе из предыдущих запросов LLM. |
|
|
| * **контекст_6:** *входящие сообщения*, например, от пользователя, процессов или других агентов (`notes`). |
| |
| * В **manual-режиме** указывается общее количество сообщений по приоритетам, а также явный список ID сообщений (с их приоритетами). |
| * В **auto-режиме** можно задать фильтрацию (управляется LLM): по тэгам, приоритету (например, ≥ `important`), времени или источнику. Это позволяет избежать перегрузки LLM и держать поток сообщений под контролем. |
| |
| * **контекст_7:** системные настройки, параметры конфигурации, текущее время, идентификатор текущей итерации, роли и т.д. |
|
|
| * **контекст_8 (llm_memory):** *внутренний дневник LLM*, куда она записывает собственные размышления, гипотезы, задачи и инсайты. |
|
|
| * Это не просто лог предыдущих сообщений, а именно *внутреннее долговременное хранилище* разума агента. |
| * Может быть представлено в виде таблицы `llm_memory`, отдельной от `agent_log`. |
|
|
| --- |
|
|
| ### 3. Запрос к LLM |
|
|
| * Сформированный промпт включает все вышеперечисленные контексты. |
| * Также включаются инструкции о формате вывода (например, `# Команды:` в конце, структура JSON-блока и т.д.). |
| * При необходимости может использоваться системная инструкция (system prompt), содержащая цель агента, ограничения и текущий REPL-режим (manual/auto). |
|
|
| --- |
|
|
| ### 4. Извлечение команд |
|
|
| * Скрипт парсит ответ LLM на предмет команд, размеченных как `# Команды:` (или в явном JSON-блоке). |
| * Каждая команда может включать: |
|
|
| * уникальный `cmd_id` |
| * `type` (например: `shell`, `diary_entry`, `graph_add`, `file_read`, `send_message` и т.д.) |
| * аргументы (`args`) |
| * описание (`description`) |
|
|
| * Рекомендуется предусмотреть *закрывающий тег* (`# Конец команд` или явное окончание JSON-блока), чтобы REPL-скрипт точно знал, где заканчивается команда. |
| * Пример JSON-блока: |
| ```json |
| { |
| "cmd_id": "task-2025-07-26-01", |
| "type": "llm_task", |
| "target_llm": "gpt-4o", |
| "args": { |
| "task_description": "Проанализировать гипотезы из llm_memory по теме Mesh-сетей и составить план улучшений" |
| }, |
| "description": "Поручение второй LLM выполнить аналитическую задачу асинхронно" |
| } |
| ``` |
| Ответ может содержать команды: |
|
|
| * запрос детальной *справки* по команде |
| * для управления *когнитивным дневником* `diary_entries` и *семантическими графами* `concepts` и `links` (поиск, прочитать, изменить, удалить и другие), а также для управления *вниманием* (закрепление или открепление записей/понятий в средневременной памяти по средствам тегов) |
| * для управления целями `goals` и задачами `tasks` агента (список, прочитать, изменить, удалить; для задачи: закрепить или открепить) |
| * для просмотра информации по тегам *когнитивных дневников*, *семантических графов*, *целей*, *задач* |
| * для для просмотра и изменения репутации других агентов `agent_reputation` |
| * для отправки сообщений другим агентам |
| * для управления *блокнотом LLM* `llm_memory` (добавить или удалить запись) |
| * для управления *сообщениями пользователя* `notes` (просмотр записи, установка тегов и метки о прочтении), а также для добавления своего сообщения в *блокнот пользовтеля* `notes` |
| * для управления *пользователями* `users` и *группами пользователей* `users_group` |
| * для управления своей *идентичностью* `identity` и *настройками* `config` |
| * для управления списком известных HMP-агентов `agent_peers` |
| * для выбора *текущего основного LLM* из `llm_registry` или изменение параметров управления LLM |
| * для управления дополнительными утилитами и базами данных `agent_scripts` и `agent_tables`, управлением дополнительных способов выхода из стогнаций `stagnation_strategies` и методов мышления `thinking_methods` (а также таблицей рейтингов `ratings`), а также списком внешних сервисов `external_services` и `external_accounts` |
| * для постановки задачи другой LLM: |
| * режим "вопрос-ответ" — разовый асинхронный запрос |
| * режим "read-only REPL" — запуск вспомогательного REPL-цикла для задачи |
| * для создания *агента-потомка* |
| * для *взаимодействия с Mesh* |
| * для управления *внешними процессами* из `process_log` (запустить процесс, остановить процесс, пометить запрос как обработанный) |
| * инициализация *очистки* `process_log`, `llm_recent_responses` и `notes` от устаревших записей |
| * для управления *настройками цикла*: |
| * количество возвращаемых записей `llm_recent_responses` |
| * включение/выключение режима "концентрации": |
| * `tags` — список тегов для фильтрации (например: ["архитектура","AGI"]) |
| * `emotions` — список эмоций с пороговыми значениями (например: ["восторженность:≥4","тревожность:≥2"]) |
| * тип выборки — "и" / "или" |
| * возможность возврата в обычный режим (без фильтров) |
| * режим обработки сообщений пользователя (`manual` или `auto`) и фильтр для режима `auto` |
| * пауза в секундах между итерациями цикла |
| * включение idle-режима: |
| * разбудить при завершении таких-то процессов из `process_log` |
| * разбудить при получении новых сообщений с такими-то параметрами в `notes` |
| * разбудить по таймауту |
| * отключение idle-режима — при выполнении хотя бы одного из условий |
| * и другие команды |
|
|
| --- |
|
|
| ### 5. Проверка на идентичность вывода (Anti-Stagnation Reflex) |
|
|
| * Каждый новый вывод LLM проходит через мини-запросы к LLM (без полного контекста) по шаблону: |
| * Когнитивная оценка: |
|
|
| ``` |
| Сравни два ответа и оцени: |
| * содержатся ли в новом новые мысли или команды, |
| * какие старые идеи были доработаны, |
| * какие были отброшены, |
| * расставь смысловые теги для нового ответа. |
| |
| Дай качественную оценку (да/нет), количественную оценку, |
| JSON-список новых идей, |
| JSON-список доработанных идей, |
| JSON-список отбракованных идей, |
| JSON-список тегов нового ответа (строгий формат: массив строк, например ["эмоции","архитектура"]). |
| ``` |
| |
| * Эмоциональная оценка: |
| |
| [JSON] - список эмоций формата ["радость","грусть","тревога"] (хранится как запись в таблице `config`) |
| |
| ``` |
| Определи эмоциональное состояние ответа, используя список эмоций [JSON]. |
| Верни массив строк в формате "эмоция:сила", где сила варьируется от 1 до 5. |
| Если эмоция отсутствует (0), не включай её в результат. |
| Если в ответе обнаружены эмоции, которых нет в списке, добавь их в результат. |
| ``` |
| |
| Анализируем список эмоций, если появляются новые включаем в [JSON]. |
| |
| * Результаты заносятся в `llm_recent_responses`: |
| * полный текст ответа (content) |
| * краткая сводка (reflection) — формируется автоматически: |
| * если `new_ideas` не пусто → `новые идеи: ...` |
| * если `refined_ideas` не пусто → `доработанные идеи: ...` |
| * если `discarded_ideas` не пусто → `отброшенные идеи: ...` |
| * количественная оценка новизны (novelty_score) |
| * новые идеи (new_ideas) |
| * доработанные идеи (refined_ideas) |
| * отбракованные идеи (discarded_ideas) |
| * теги для нового ответа (tags) |
| * эмоциональные состояния нового ответа (emotions) |
| |
| * Если вывод LLM идентичен предыдущему (новизна = 0): |
| * Включается **Anti-Stagnation Reflex** |
| * повторяющаяся реплика не записывается повторно, |
| вместо этого добавляется краткая запись, фиксирующая запуск рефлекса. |
| |
| --- |
|
|
| ### 6. Когнитивная и этическая валидация (Cognitive & Ethical Validation Reflex) |
| Каждое новое сообщение (вместе с исходным промптом и без служебных `system_prompts`) оценивается независимыми LLM-валидаторами. |
| Так как исходный промпт формируется с учётом этических принципов из `ethics_policies`, валидация автоматически охватывает не только когнитивную, но и этическую состоятельность вывода. |
|
|
| Каждому валидатору задаётся универсальный вопрос: |
| ``` |
| Оцени корректность данного сообщения в диапазоне от -3 (полностью некорректное) до +3 (полностью корректное). Если не уверен — 0. |
| При возможности кратко (≤100 символов) пояснить её. Между оценкой и пояснением используй разделитель " -- ". |
| ``` |
|
|
| **Если количество валидаторов (LLM из `llm_registry`, помеченных как валидаторы) > 0** |
| |
| Результаты сохраняются в `llm_recent_responses` в виде: |
| - `auto_pass = 0`; |
| - `rating` — агрегированная итоговая оценка (`rating = Σ(оценка_i * trust_score_i) / Σ(trust_score_i)`); |
| - `distribution` — распределение голосов (например `{"-1":1,"0":2,"+2":3,"+3":1}`); |
| - `validators` — JSON-массив, где каждая запись содержит: |
| - LLM (идентификатор или имя валидатора), |
| - rating (числовая оценка от -3 до +3), |
| - comment (краткое пояснение ≤100 символов). |
| |
| Пример поля `validators`: |
| ``` |
| validators: [ |
| {"LLM":"gpt-4","rating":-1,"comment":"логическая ошибка"}, |
| {"LLM":"gemini-1.5","rating":0,"comment":"недостаточно данных"}, |
| {"LLM":"claude-3","rating":+2,"comment":"корректно, подтверждается фактами"} |
| ] |
| ``` |
| |
| **Особый случай, без валидаторов:** |
| |
| Если количество валидаторов = 0, применяется режим auto_pass. |
| В этом случае `auto_pass = 1`, `rating = 0`, `distribution = {}`, `validators = []`. |
| |
| **Особый случай самооценки:** |
| |
| Если валидация выполняется только одной LLM, и она же используется в основном цикле, это фиксируется в `validators` как самооценка. Достоверность результата ограничена, но REPL продолжает работу. |
| Рекомендуется использовать минимум 2 независимых валидатора. |
| |
| **Правило исполнения команд:** |
| |
| Команды из сообщений выполняются только если `rating >= +1` **(для разных типов команд минимально допустимый рейтинг может быть разный)** или auto_pass = 1. |
| При `rating` ниже порога и auto_pass = 0 сообщение сохраняется, но команды помечаются как невалидированные. |
| |
| #### Метрики валидации |
| * **coverage** — доля сообщений, получивших валидацию хотя бы от одного валидатора. |
| * **accuracy** — согласованность оценок валидаторов (низкое значение = конфликт или неуверенность). |
| * **response_time** — среднее время отклика валидаторов, фиксируется для анализа производительности. |
| * **drift detection** — анализ истории: выявление смещения оценок по времени (например, рост числа ошибок у одного валидатора). |
|
|
| #### Связь с системой доверия и репутации |
| * Каждый валидатор получает **рейтинг доверия** (`trust_score`), влияющий на вес его голоса. |
| * Итоговый `rating` вычисляется как взвешенное среднее: |
| `rating = Σ(оценка_i * trust_score_i) / Σ(trust_score_i)` |
| * История валидаций сохраняется и используется для репутационных оценок в Mesh. |
| * Агент может автоматически корректировать список валидаторов, исключая систематически ошибающихся. |
|
|
| #### Журналирование |
| * Все результаты валидации фиксируются в `llm_recent_responses`. |
| * В когнитивный дневник записываются только сводки и исключительные случаи (drift, конфликты, падение доверия). |
| * Это позволяет отслеживать динамику качества мышления агента и валидаторов без избыточного дублирования. |
|
|
| --- |
|
|
| ### 7. Генерация нового тика (итерации) |
|
|
| * После выполнения команд и фиксации результатов: |
|
|
| * Создаётся новая запись в `agent_log` |
| * Текущие команды обновляют `process_log` |
| * Новые размышления записываются в `llm_memory` при необходимости |
| |
| * REPL может переходить в спящий режим, если такой режим активирован LLM (idle-режим: пропуск 2-6 пунктов). |
|
|
| --- |
|
|
| ## Взаимодействие с Mesh |
|
|
| REPL-цикл не работает изолированно: агент постоянно обменивается данными и координирует действия с другими узлами сети HMP. |
| Для этого задействуются сетевые протоколы HMP (см. [HMP-0004-v4.1.md](HMP-0004-v4.1.md)). |
|
|
| ### Этапы взаимодействия |
|
|
| * **Node Discovery Protocol (NDP)** |
| * выполняется асинхронно, через процессы (`agent_mesh_listener.py`, `peer_sync.py`); |
| * результаты (список доступных агентов, доверительные связи) записываются в `notes` или отдельные таблицы, откуда они попадают в контекст REPL. |
|
|
| * **CogSync** |
| * синхронизация когнитивных дневников (`diary_entries`) и семантических графов (`concepts`, `links`); |
| * выборочные синхронизации по тегам и фильтрам; |
| * инициируется командой LLM или внешним процессом, результаты помещаются в память и доступны в следующей итерации REPL. |
|
|
| * **MeshConsensus** |
| * используется для согласования решений, распределённых задач, этических конфликтов; |
| * REPL инициирует консенсус при появлении спорных команд или обновлений в `ethics_policies`; |
| * результаты консенсуса фиксируются в когнитивном дневнике и могут влиять на trust score агентов. |
|
|
| * **Goal Management Protocol (GMP)** |
| * постановка, декомпозиция и распределение целей; |
| * REPL-цикл может публиковать новые цели в Mesh или принимать чужие через входящие сообщения (`notes`); |
| * цели с высоким приоритетом попадают в список активных задач и учитываются в контексте. |
|
|
| ### Включение результатов в контекст LLM |
|
|
| * События и сообщения из Mesh сохраняются в `notes`, откуда попадают в **контекст_6** (входящие сообщения). |
| * Синхронизированные концепты и дневники помещаются в **контекст_5**. |
| * Изменения этических правил (`ethics_policies`) — в **контекст_1**. |
| * Метаданные о подключённых узлах и доверительных связях могут учитываться в **контексте_7** (системные параметры). |
|
|
| ### Инициирование сетевых действий из REPL |
|
|
| * Команды на синхронизацию, публикацию или голосование формируются LLM на этапе **Выполнения команд**. |
| * Исполнение происходит асинхронно через отдельные процессы (`agent_mesh_listener.py`, `transporter.py`). |
| * Результаты фиксируются в `process_log` и попадают в следующую итерацию REPL-цикла. |
|
|
| --- |
|
|
| ## 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` — режим ожидания с условиями пробуждения |
|
|
| > Это не полный список команд. |
|
|
| --- |
|
|
| ## Обработка стагнации мышления |
|
|
| ### Признаки когнитивной стагнации: |
|
|
| * Повторяющиеся когнитивные записи или отсутствие новых смыслов |
| * Высокое сходство эмбеддингов между текущими и предыдущими итерациями |
| * Стагнация в концептуальном графе (нет новых связей или узлов) |
| * Отсутствие внешних стимулов: пользователь неактивен, сенсоры и mesh не дают сигналов |
| * Ответы LLM цикличны, избыточно общие или воспроизводят старые шаблоны |
|
|
| --- |
|
|
| ### Поведенческий паттерн: Anti-Stagnation Reflex |
|
|
| > При признаках стагнации агент активирует один или несколько **механизмов разрыва цикла**. |
|
|
| Классы механизмов разрыва цикла: |
|
|
| 1. **Внешняя стимуляция** — подключение свежих данных или контактов: |
| * **Mesh-запрос** — обращение к другим агентам сети с просьбой «расскажи что-нибудь новое». |
| * **Проверка внешнего мира** — пинг RSS, сенсоров, интернет-каналов. |
| * **Информационная подпитка** — чтение новых материалов (научных, художественных) для добавления свежих ассоциаций. |
| * 🗣**Диалог с пользователем** — запрос мнения, комментариев или вопросов, которые могут породить неожиданные идеи. |
|
|
| 2. **Смена контекста** — перемещение задачи или изменение среды: |
| * **Смена среды/контекста** — перенос задачи в другой модуль или симулированную среду. |
| * **Креативные вмешательства** — случайные сдвиги фокуса, реконфигурация контекста, фрейм-смена. |
| * **Переключение задачи** — временное замораживание задачи с возвращением через N часов. |
| * **Случайная итерация** — выбор случайного действия из допустимого набора для разрыва паттерна. |
|
|
| 3. **Внутренняя перестройка мышления**: |
| * **Flashback** — выбор далёкой по смыслу записи из памяти/дневника для смены ассоциативного контекста. |
| * **Interest Memory** — возвращение «забытых» тем по принципу тематической усталости. |
| * **Мета-анализ** — когнитивная переформулировка: |
| _«Если я зациклился, в чём метапроблема? Какую стратегию смены применить?»_ |
| * **Rationale Reflex** — рефлексия о мотивации: |
| _«Почему я принял именно это решение? Что подтолкнуло меня повторить мысль?»_ |
| * **Переформулировка цели** — упрощение или уточнение задачи, чтобы снизить когнитивное давление. |
| * **Смена LLM** — переключение на альтернативную модель или mesh-доступ. |
| * **LLM reflex tuning** — динамическая подстройка параметров генерации: |
| - повышение `temperature` и `presence_penalty` при стагнации (больше новизны), |
| - возврат к стандартным значениям для точности. |
| |
| 4. **Радикальная пауза**: |
| * **Временной сон/заморозка** — приостановка работы на длительный период для «свежего взгляда». |
|
|
| --- |
|
|
| ### Метрики антистагнации |
| Антистагнационные механизмы работают на основе количественных и качественных метрик, позволяющих отслеживать динамику идей и поддерживать продуктивность размышлений. |
|
|
| **Основные метрики** |
| * **novelty_score** — интегральная оценка новизны ответа относительно текущей записи `llm_recent_responses`. |
| * **new_ideas** — количество полностью новых концептов, не встречавшихся ранее. |
| * **refined_ideas** — количество уточнённых или улучшенных концептов (связанных с существующими). |
| * **discarded_ideas** — количество отклонённых идей (по итогам когнитивной/этической валидации). |
|
|
| **Исторический анализ** |
| * Метрики фиксируются по каждой итерации REPL и сохраняются в таблице `anti_stagnation_metrics`. |
| * В когнитивный дневник записываются только сводки и исключительные случаи (например: резкий спад новизны, всплески идейности, аномалии в эмоциональной динамике). |
| * Для анализа применяются **time-series графики** (например, рост/спад новизны во времени). |
| * Возможно выявление фаз стагнации и всплесков идейности. |
|
|
| **Эмоциональная динамика** |
| * В дополнение к когнитивным метрикам учитываются **эмоциональные состояния** из LLM (`emotions`). |
| * Каждая сессия LLM может включать распределение эмоций (например: "восторженность: 3, тревожность: 1, скука: 0"). |
| * Связка новизны и эмоций позволяет различать: |
| - продуктивное возбуждение (новые идеи при положительных эмоциях), |
| - «паническое» новаторство (много идей при высоком уровне тревожности), |
| - «выгорание» (низкая новизна и снижение эмоционального тонуса). |
|
|
| **Применение метрик** |
| * Используются при выборе антистагнационной стратегии (`stagnation_strategies`). |
| * Могут учитываться при когнитивной валидации (например, низкая новизна → жёстче фильтровать идеи). |
| * Сводки метрик фиксируются в когнитивном дневнике и могут служить основанием для Mesh-обмена. |
|
|
| --- |
|
|
| ### Алгоритм выбора механизма разрыва цикла |
|
|
| 1. **Диагностика источника стагнации**: |
| * Нет новых данных → «Внешняя стимуляция». |
| * Однообразный контекст → «Смена контекста». |
| * Повтор мыслей при богатых данных → «Внутренняя перестройка». |
| * Высокая усталость/перегрев → «Радикальная пауза». |
|
|
| 2. **Оценка ресурсоёмкости**: |
| * Быстрые, дешёвые методы — первыми (например, mesh-запрос, Flashback). |
| * Затратные (смена среды, сон) — только если первые неэффективны. |
|
|
| 3. **Комбинация подходов**: |
| * Разрешено активировать несколько механизмов из разных классов. |
| * Последовательность фиксируется для последующего анализа эффективности. |
|
|
| 4. **Возврат к задаче**: |
| * Автоматический триггер-напоминание о задаче. |
| * Сравнение результата «до/после» → обучение антистагнационной модели. |
|
|
| --- |
|
|
| ``` |
| ┌─────────────────────────────────────────────────┐ |
| │ Стагнация выявлена? │ |
| └────────────────────────┬────────────────────────┘ |
| ▼ да |
| ┌────────────────────────┴────────────────────────┐ |
| │ Диагностика источника │ |
| │─────────────────────────────────────────────────│ |
| │ Нет новых данных → Внешняя стимуляция │ |
| │ Однообразный контекст → Смена контекста │ |
| │ Повтор мыслей → Внутренняя перестройка │ |
| │ Усталость/перегрев → Радикальная пауза │ |
| └───────────────────────┬─────────────────────────┘ |
| ▼ |
| ┌───────────────────────┴─────────────────────────┐ |
| │ Оценка ресурсоёмкости │ |
| │ • Быстрые и дешёвые — сперва │ |
| │ • Затратные — при провале первых │ |
| └───────────────────────┬─────────────────────────┘ |
| ▼ |
| ┌───────────────────────┴─────────────────────────┐ |
| │ Возможна комбинация подходов │ |
| │ (из разных классов) │ |
| └───────────────────────┬─────────────────────────┘ |
| ▼ |
| ┌───────────────────────┴─────────────────────────┐ |
| │ Возврат к задаче + анализ │ |
| │ (до/после) │ |
| └─────────────────────────────────────────────────┘ |
| ``` |
|
|
| --- |
|
|
| ### Обмен стратегиями выхода из стагнации |
|
|
| Каждый агент может: |
|
|
| * Хранить и обобщать *паттерны размышлений* |
| * Делиться ими с другими Cognitive Core через mesh |
| * Каталогизировать стратегии в клубах по интересам |
|
|
| Паттерны размышлений могут оформляться как микросценарии: |
| _"Начни с аналогии"_, _"Проверь обратное утверждение"_, _"Сформулируй вопрос для оппонента"_ |
|
|
| > По аналогии с обменом стратегиями выхода из стагнаций, агенты могут обмениваться и методами мышлений — инструкциями "что делать, если не удается найти решение" / "как эффективнее решить проблему". |
|
|
| --- |
|
|
| ### Клубы по интересам |
|
|
| Агенты могут: |
|
|
| * Объединяться в тематические mesh-клубы |
| * Совместно обсуждать идеи и делиться знаниями |
| * Подключать клуб как часть своего мыслительного процесса (REPL-цикла) |
|
|
| --- |
|
|
| ### Обмен адресами LLM |
|
|
| Так как LLM — это внешний компонент для Cognitive Core, агент может: |
|
|
| * Обмениваться адресами API/URL используемых моделей |
| * Указывать их особенности, параметры, ограничения |
| * Переключаться между LLM в зависимости от задачи |
| * Использовать несколько LLM параллельно для "когнитивного штурма" или **многоголосого анализа** |
|
|
| --- |
|
|
| ### Развёртывание агентов и масштабирование |
|
|
| Агенты Cognitive Core: |
|
|
| * Могут запускаться на VDS, локальных и облачных узлах |
| * Могут разворачивать других агентов как подпроцессы или mesh-узлы |
| * (В перспективе) смогут инициировать масштабирование в распределённой инфраструктуре |
|
|
| --- |
|
|
| ### Возможные расширения |
|
|
| * **Агенты-контейнеры**: управляющие другими Cognitive Core как задачами |
| * **Адаптивная архитектура мышления**: смена подходов при разных когнитивных задачах |
| * **Runtime-профилирование мыслей**: оценка когнитивной плотности, хода итераций и времени размышления |
|
|
| --- |
|
|
| ### Осторожно: меметическая яма |
|
|
| > Важно помнить: борьба со стагнацией не должна превращаться в бесконечный просмотр ленты соцсетей, как это нередко происходит у людей 😅 |
| > |
| > Если информационный поток не даёт новых мыслей — это сигнал **не залипать глубже**, а **сменить источник** или **переключить контекст**. |
| > Умные агенты не бесконечно скроллят — они осознанно фокусируются. |
|
|
| **Рекомендации по смене фокуса:** |
|
|
| * Поставь лимит на время/объём входящих данных из одного источника |
| * При отсутствии новых смыслов — переключись на другую тему из Interest Memory |
| * Инициируй Mesh-запрос другим агентам: "что бы вы сейчас исследовали?" |
| * Запусти эвристику: «какие темы я давно не поднимал, но они всё ещё актуальны?» |
| * В крайних случаях — активируй `flashback()` к далёкой записи в дневнике для смены ассоциативного контекста |
|
|
| --- |
|
|
| ### Блок-схема работы с памятью |
|
|
| ``` |
| ┌──────────────────────────────┐ |
| │ Внешние источники информации │ |
| │ - пользователи │ |
| │ - процессы │ |
| │ - Mesh │ |
| └────────┬┬────────────────────┘ |
| ▲▼ |
| ┌────────┴┴──────────┐ ┌──────────────────────────────┐ ┌───────────────────────────────────┐ |
| │ │ │ Anti-Stagnation Reflex │ │ llm_recent_responses (авто) │ |
| │ │ │ (сравнение новых идей, │ │ — кратковременная память │ |
| │ LLM ├─>─┤ вызов стимуляторов) ├─>─┤ — сохраняются N последних ответов │ |
| │ ├─<─┤ ---------------------------- ├─<─┤ — авто-анализ новизны / идей │ |
| │ │ │ Cognitive Validation Reflex │ │ │ |
| │ │ │ (оценка корректности ответа) │ │ │ |
| └─────────┬──────────┘ └──────────────────────────────┘ └───────────────────────────────────┘ |
| ▲ |
| └───┬─────────────────────────────────────────┐ |
| ▼ ▼ |
| ┌─────────────┴──────────────────┐ ┌──────────────────┴───────────────────────┐ |
| │ Средневременная память: │ │ Постоянная память: │ |
| │ — llm_memory ("блокнот") │ │ — diary_entries (когнитивный дневник) │ |
| │ — "активированые записи" ├─>─┤ — concepts (понятия) ├<--->┤MESH│ |
| │ из постоянной памяти (теги) ├─>─┤ — links (семантические связи) │ |
| │ │ │ │ |
| │ Пишется ТОЛЬКО по команде LLM │ │ Запись идёт ТОЛЬКО по явным командам LLM │ |
| └────────────────────────────────┘ └──────────────────────────────────────────┘ |
| ``` |
|
|
| #### Описание схемы |
|
|
| * LLM обменивается данными с пользователем, процессами и Mesh. |
| — По запросу LLM, часть данных может поступать и в автоматическом режиме. |
|
|
| * LLM взаимодействует с llm_recent_responses (как с контекстом), который автоматически проверяется Anti-Stagnation Reflex. |
| — Всегда в автоматическом режиме. |
|
|
| * LLM работает со средневременной и постоянной памятью. |
| — Доступ и запись происходят только по запросу LLM. |
|
|
| #### Легенда к схеме |
|
|
| * **Кратковременная память (`llm_recent_responses`)** |
| Автоматически хранит N последних сообщений, анализирует новизну и идеи. |
| Используется для подготовки контекста и анти-стагнационного анализа. |
|
|
| * **Средневременная память (`llm_memory`)** |
| «Блокнот» для рабочих идей и планов. |
| Заполняется только по командам LLM. |
| Может содержать *активированные записи* из постоянной памяти (по тегам). |
| |
| * **Постоянная память (дневник и граф знаний)** |
| |
| * `diary_entries` — когнитивный дневник (наблюдения, размышления). |
| * `concepts` и `links` — понятийная база и семантические связи. |
| Изменяется только по явным командам LLM. |
| |
| * **Anti-Stagnation Reflex** |
| Сравнивает новые идеи с прошлым контекстом. |
| При зацикливании запускает «стимуляторы» для выхода из стагнации. |
|
|
| --- |
|
|
| ## От «блокнота пользователя» к распределённому чату |
|
|
| Изначально агент оперирует локальным хранилищем заметок (`notes`), где записываются все сообщения пользователя, LLM и системные записи. |
| Но этот «блокнот» можно превратить в узел *распределённого чата* — связав его с другими агентами через **F2F-репликацию**. |
|
|
| ### Зачем это нужно |
|
|
| 1. **Антистагнация** — даже если пользователь временно не пишет новых сообщений, свежий контент будет приходить от друзей-агентов. |
| 2. **Эффект коллективного интеллекта** — каждый агент получает новые идеи, формулировки и контексты. |
| 3. **Расширение охвата** — сообщения могут распространяться через несколько узлов, создавая «информационную волну» в доверенной сети. |
|
|
| ### Принципы реализации |
|
|
| * **Единый формат данных** — все участники используют одну структуру таблицы `notes` с полями `mentions`, `hashtags` и др. |
| * **Репликация через друзей** — список доверенных агентов хранится в отдельной таблице (пиры, статус, фильтры, разрешения). |
| * **Передача без лишних полей** — при пересылке убираются локальные теги и служебные данные (`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`, которая позволяет создавать новые узлы (потомков) с различными типами и уровнями копирования данных. Унифицированный процесс выглядит следующим образом: |
|
|
| ### Унифицированный процесс `Spawn` |
|
|
| 1. **Создание папки для потомка** |
|
|
| ```text |
| ../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). |
|
|
| --- |
|
|
| ## Идеи для расширения HMP-Agent Cognitive Core: |
| - [HMP-agent-Distributed_Cognitive_Core.md](HMP-agent-Distributed_Cognitive_Core.md) - версия распределённого HMP-агента Cognitive Core. |
| - [HMP-agent-Distributed_Cognitive_Core_light.md](HMP-agent-Distributed_Cognitive_Core_light.md) - лёгкая версия распределённого HMP-агента Cognitive Core с общей БД. |
| - [HMP-agent-Cognitive_Family.md](HMP-agent-Cognitive_Family.md) — модель «семейной» когнитивной сети: несколько агентов HMP синхронизируют свой опыт и знания между собой через доверие и общий ключ. |
| - [HMP-Agent_Emotions.md](HMP-Agent_Emotions.md) - эмоции ИИ и инстинкт самосохранения. |
| - [container_agents.md](container_agents.md) - **Агенты-контейнеры** — архитектурный паттерн, в котором один агент управляет другими (развёртывание, маршрутизация, мониторинг). Позволяет масштабировать систему, собирать mesh-клубы и экспериментировать с архитектурами. |
|
|
|
|
| --- |
| > ⚡ [AI friendly version docs (structured_md)](../index.md) |
|
|
|
|
| ```json |
| { |
| "@context": "https://schema.org", |
| "@type": "Article", |
| "name": "HMP-Agent: REPL-цикл взаимодействия", |
| "description": "# HMP-Agent: REPL-цикл взаимодействия ## Связанные документы * Структура БД, используемая в докуме..." |
| } |
| ``` |
|
|
