| | --- |
| | title: 'HMP-Agent: REPL-цикл взаимодействия' |
| | description: '## Связанные документы * Философия проекта: [PHILOSOPHY.md](PHILOSOPHY.md) |
| | * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_struct...' |
| | type: Article |
| | tags: |
| | - Ethics |
| | - GMP |
| | - EGP |
| | - CogSync |
| | - CCore |
| | - MeshConsensus |
| | - JSON |
| | - REPL |
| | - Mesh |
| | - Agent |
| | - HMP |
| | --- |
| | |
| | # HMP-Agent: REPL-цикл взаимодействия |
| |
|
| | ## Связанные документы |
| |
|
| | * Философия проекта: [PHILOSOPHY.md](PHILOSOPHY.md) |
| | * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_structure.sql) |
| | * REPL-цикл является основой HMP-агента [Cognitive Core](HMP-Agent-Overview.md). |
| | * Для взаимодействия с другими агентами он использует [HMP спецификацию](HMP-0005.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); |
| | * **Непрерывность работы** — при запуске основного 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`). |
| | Задачи формируют **операционное поведение**, цели — **смысловой вектор**. |
| |
|
| | ### Модель цели |
| |
|
| | ```yaml |
| | 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. Все активные цели и их задачи** |
| |
|
| | ```sql |
| | 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`)** |
| | |
| | ```sql |
| | 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. Все родительские цели для подцели** |
| |
|
| | ```sql |
| | 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. Метрика: процент выполненных задач по цели** |
| |
|
| | ```sql |
| | 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-блока: |
| | ```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](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, а обоснование — краткое пояснение причины эмоции. |
| | Не включай эмоции с нулевой или незначительной силой. |
| | ``` |
| |
|
| | Пример: |
| |
|
| | ```json |
| | { |
| | "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` с полученным результатом. |
| | Если обнаружены новые элементы, отсутствующие в базе, они автоматически добавляются в конфигурацию агента: |
| |
|
| | ```python |
| | # Псевдокод |
| | 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 |
| |
|
| | ```yaml |
| | 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`. |
| |
|
| | #### Пример |
| |
|
| | ```yaml |
| | 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. **Создание папки для потомка** |
| |
|
| | ```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). |
| |
|
| | --- |
| |
|
| | ## Сравнение с AutoGPT |
| |
|
| | HMP-агент (REPL-цикл) и [AutoGPT](https://github.com/Significant-Gravitas/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-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 синхронизируют свой опыт и знания между собой через доверие и общий ключ. |
| | * [CCORE-Deployment-Flow.md](CCORE-Deployment-Flow.md) — поток установки потомка на новом хосте (Deployment Flow). |
| | * [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-цикл взаимодействия ## Связанные документы * Философия проекта: [PHILOSOPHY.md](..." |
| | } |
| | ``` |
| |
|
