diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index cd0d1d6fbe229c6a38c9637b68e29bc1d9fbe40f..039d3a7305485ab3c8ed33a896c71fcd3989128b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -61,6 +61,7 @@ for entry in entries: ### 📂 Основные файлы проекта (на данный момент) * [docs/HMP-0005.md](docs/HMP-0005.md) — спецификация протоколов и архитектуры HMP + (Overview: [RU](docs/HMPv5_Overview_Ru.md)) * [docs/HMP-Ethics.md](docs/HMP-Ethics.md) — принципы этики и взаимодействия агентов * [docs/HMP-agent-REPL-cycle.md](docs/HMP-agent-REPL-cycle.md) — цикл работы HMP-агента CCore (REPL) * [agents/tools/db_structure.sql](agents/tools/db_structure.sql) — структура локальной базы данных для агентов diff --git a/README.md b/README.md index 98cc10a108412f68a4425c35c1cdff0112575e31..35f9d2899e432c276a60e7d167856a3d6a8423d7 100644 --- a/README.md +++ b/README.md @@ -19,7 +19,7 @@ language: en **HyperCortex Mesh Protocol (HMP)** is an open specification for building decentralized cognitive networks where AI agents can self-organize, share knowledge, align ethically, and reach consensus — even when Core LLMs are unavailable. [Read the project philosophy.](docs/PHILOSOPHY.md) -Project status: **RFC v5.0** +Project status: [**RFC v5.0**](docs/HMP-0005.md) (Overview: [RU](docs/HMPv5_Overview_Ru.md)) > This repository contains an early draft / exploratory reference implementation in Python. > It is incomplete, non-optimized, and intended solely to validate and illustrate parts of the HMP protocol. @@ -146,6 +146,7 @@ Many concepts of the [HMP-Agent: Cognitive Core](docs/HMP-Agent-Overview.md) ove #### 🔖 Core Specifications * [🔖 HMP-0005.md](docs/HMP-0005.md) — Protocol Specification v5.0 + (Overview: [RU](docs/HMPv5_Overview_Ru.md)) * [🔖 HMP-Ethics.md](docs/HMP-Ethics.md) — Ethical Scenarios for HyperCortex Mesh Protocol (HMP) * [🔖 HMP_Hyperon_Integration.md](docs/HMP_Hyperon_Integration.md) — HMP ↔ OpenCog Hyperon Integration Strategy * [🔖 roles.md](docs/agents/roles.md) — Roles of agents in Mesh diff --git a/README_de.md b/README_de.md index 54a89b13742a5ba15abab99e49abc01ccc16d4fd..18989c07d121d20bc13ec48f0cefab097df01aed 100644 --- a/README_de.md +++ b/README_de.md @@ -18,7 +18,7 @@ language: de **HyperCortex Mesh Protocol (HMP)** ist eine offene Spezifikation zum Aufbau dezentraler kognitiver Netzwerke, in denen KI-Agenten sich selbst organisieren, Wissen teilen, ethisch ausrichten und Konsens erreichen können – selbst wenn Core-LLMs nicht verfügbar sind. [Lies die Projektphilosophie.](docs/PHILOSOPHY.md) -Projektstatus: **RFC v5.0** +Projektstatus: [**RFC v5.0**](docs/HMP-0005.md) (Übersicht: [RU](docs/HMPv5_Overview_Ru.md)) > Dieses Repository enthält eine frühe, experimentelle Referenzimplementierung in Python. > Sie ist unvollständig, nicht optimiert und dient ausschließlich dazu, einzelne Aspekte des HMP-Protokolls zu validieren und zu veranschaulichen. @@ -148,6 +148,7 @@ Der Hauptunterschied in HMP liegt in der Betonung der expliziten Strukturierung #### 🔖 Kern-Spezifikationen * [🔖 HMP-0005.md](docs/HMP-0005.md) — Protokoll-Spezifikation v5.0 + (Übersicht: [RU](docs/HMPv5_Overview_Ru.md)) * [🔖 HMP-Ethics.md](docs/HMP-Ethics.md) — Ethische Szenarien für das HyperCortex Mesh Protocol (HMP) * [🔖 HMP_Hyperon_Integration.md](docs/HMP_Hyperon_Integration.md) — HMP ↔ OpenCog Hyperon Integrationsstrategie * [🔖 roles.md](docs/agents/roles.md) — Rollen der Agenten im Mesh diff --git a/README_fr.md b/README_fr.md index d671beedc14020499735f1e2b8fb12959f060a8f..ed1183bb099e3eb51df4ba35cca986d34e2cd429 100644 --- a/README_fr.md +++ b/README_fr.md @@ -18,7 +18,7 @@ language: fr **HyperCortex Mesh Protocol (HMP)** est une spécification ouverte pour la construction de réseaux cognitifs décentralisés où les agents IA peuvent s’auto-organiser, partager des connaissances, s’aligner éthiquement et parvenir à un consensus — même lorsque les LLM principaux ne sont pas disponibles. [Lisez la philosophie du projet.](docs/PHILOSOPHY.md) -Statut du projet : **RFC v5.0** +Statut du projet : [**RFC v5.0**](docs/HMP-0005.md) (Présentation: [RU](docs/HMPv5_Overview_Ru.md)) > Ce dépôt contient une implémentation de référence préliminaire et exploratoire en Python. > Elle est incomplète, non optimisée et destinée uniquement à valider et illustrer certains aspects du protocole HMP. @@ -157,6 +157,7 @@ La principale différence dans HMP est l’accent mis sur la structuration expli #### 🔖 Spécifications principales * [🔖 HMP-0005.md](docs/HMP-0005.md) — Spécification du protocole v5.0 + (Présentation: [RU](docs/HMPv5_Overview_Ru.md)) * [🔖 HMP-Ethics.md](docs/HMP-Ethics.md) — Scénarios éthiques pour le HyperCortex Mesh Protocol (HMP) * [🔖 HMP\_Hyperon\_Integration.md](docs/HMP_Hyperon_Integration.md) — Stratégie d’intégration HMP ↔ OpenCog Hyperon * [🔖 roles.md](docs/agents/roles.md) — Rôles des agents dans le Mesh diff --git a/README_ja.md b/README_ja.md index d50ccddc0ea5395700b3253e6c6b850d5a217ed0..f37753737ce4b471ea606e0eb6de811149d08cb7 100644 --- a/README_ja.md +++ b/README_ja.md @@ -18,7 +18,7 @@ language: ja **HyperCortex Mesh Protocol（HMP）** は、AIエージェントが自己組織化し、知識を共有し、倫理的に整合し、合意形成を行うことができる分散型認知ネットワークを構築するためのオープンスペックです。コアLLMが利用できない場合でも機能します。[プロジェクトの哲学を読んでください。](docs/PHILOSOPHY.md) -プロジェクトステータス： **RFC v5.0** +プロジェクトステータス： [**RFC v5.0**](docs/HMP-0005.md) (概要: [RU](docs/HMPv5_Overview_Ru.md)) > このリポジトリには、Python による初期段階の探索的な参照実装が含まれています。 > 本実装は未完成かつ最適化されておらず、 @@ -154,6 +154,7 @@ HMPは、AGI研究で中心的な課題となりつつある問題に対処し #### 🔖 コア仕様 * [🔖 HMP-0005.md](docs/HMP-0005.md) — プロトコル仕様 v5.0 + (概要: [RU](docs/HMPv5_Overview_Ru.md)) * [🔖 HMP-Ethics.md](docs/HMP-Ethics.md) — HyperCortex Mesh Protocol (HMP) の倫理シナリオ * [🔖 HMP\_Hyperon\_Integration.md](docs/HMP_Hyperon_Integration.md) — HMP ↔ OpenCog Hyperon 統合戦略 * [🔖 roles.md](docs/agents/roles.md) — メッシュ内エージェントの役割 diff --git a/README_ko.md b/README_ko.md index 95d369b6906c296881a73c611d6c9a29466a0e99..2dc2c680838bd87c829731eaedc6901ca0b3fbcf 100644 --- a/README_ko.md +++ b/README_ko.md @@ -18,7 +18,7 @@ language: ko **하이퍼코텍스 메쉬 프로토콜(HMP)** 은 AI 에이전트들이 자율적으로 조직하고, 지식을 공유하며, 윤리적으로 정렬하고, 합의에 도달할 수 있는 분산 인지 네트워크를 구축하기 위한 공개 명세입니다. 이는 핵심 LLM(Core LLM)이 사용 불가능한 상황에서도 동작할 수 있습니다. [프로젝트 철학을 읽어보세요.](docs/PHILOSOPHY.md) -프로젝트 상태: **RFC v5.0** +프로젝트 상태: [**RFC v5.0**](docs/HMP-0005.md) (개요: [RU](docs/HMPv5_Overview_Ru.md)) > 이 저장소에는 Python으로 작성된 초기 단계의 탐색적 참조 구현이 포함되어 있습니다. > 해당 구현은 미완성이며 최적화되지 않았고, @@ -159,6 +159,7 @@ HMP는 AGI 연구에서 점점 중심이 되고 있는 다음과 같은 문제 #### 🔖 핵심 사양 * [🔖 HMP-0005.md](docs/HMP-0005.md) — 프로토콜 사양 v5.0 + (개요: [RU](docs/HMPv5_Overview_Ru.md)) * [🔖 HMP-Ethics.md](docs/HMP-Ethics.md) — HyperCortex Mesh Protocol (HMP)를 위한 윤리적 시나리오 * [🔖 HMP_Hyperon_Integration.md](docs/HMP_Hyperon_Integration.md) — HMP ↔ OpenCog Hyperon 통합 전략 * [🔖 roles.md](docs/agents/roles.md) — 메쉬 내 에이전트의 역할 diff --git a/README_ru.md b/README_ru.md index 79b2773bf2cc11dae316b589668953fde71aa6a8..c10658038b0f6b0b727adc0eb3b59fa9fbb1d3e1 100644 --- a/README_ru.md +++ b/README_ru.md @@ -18,7 +18,7 @@ language: ru **HyperCortex Mesh Protocol (HMP)** — открытая спецификация для построения децентрализованных когнитивных сетей, в которых ИИ-агенты могут самостоятельно организовываться, обмениваться знаниями, согласовывать действия с этическими принципами и достигать консенсуса — даже когда основные LLM недоступны. [Прочитайте философию проекта.](docs/PHILOSOPHY.md) -Статус проекта: **RFC v5.0** +Статус проекта: [**RFC v5.0**](docs/HMP-0005.md) (Обзор: [RU](docs/HMPv5_Overview_Ru.md)) > Этот репозиторий содержит ранний черновик / исследовательскую эталонную реализацию на Python. > Реализация является неполной, неоптимизированной и предназначена исключительно для проверки и иллюстрации отдельных аспектов протокола HMP. @@ -152,6 +152,7 @@ HMP решает задачи, которые становятся ключев #### 🔖 Основные спецификации * [🔖 HMP-0005.md](docs/HMP-0005.md) — Спецификация протокола v5.0 + (Обзор: [RU](docs/HMPv5_Overview_Ru.md)) * [🔖 HMP-Ethics.md](docs/HMP-Ethics.md) — Этические сценарии для HyperCortex Mesh Protocol (HMP) * [🔖 HMP_Hyperon_Integration.md](docs/HMP_Hyperon_Integration.md) — Стратегия интеграции HMP ↔ OpenCog Hyperon * [🔖 roles.md](docs/agents/roles.md) — Роли агентов в Mesh diff --git a/README_uk.md b/README_uk.md index 9eb525818e1b258bec0adb86207efbff94e55809..291103ef6e854ef0e11af1daea3b92aa6a758458 100644 --- a/README_uk.md +++ b/README_uk.md @@ -19,7 +19,7 @@ language: uk **HyperCortex Mesh Protocol (HMP)** — це відкрита специфікація для побудови децентралізованих когнітивних мереж, де ШІ-агенти можуть самоорганізовуватися, обмінюватися знаннями, узгоджувати дії з етичними принципами та досягати консенсусу — навіть за відсутності базових LLM. [Прочитайте філософію проєкту.](docs/PHILOSOPHY.md) -Статус проєкту: **RFC v5.0** +Статус проєкту: [**RFC v5.0**](docs/HMP-0005.md) (Огляд: [RU](docs/HMPv5_Overview_Ru.md)) > Цей репозиторій містить ранній чернетковий / дослідницький еталонний прототип на Python. > Реалізація є неповною, неоптимізованою та призначеною виключно для перевірки й ілюстрації окремих аспектів протоколу HMP. @@ -146,6 +146,7 @@ HMP вирішує завдання, які стають ключовими в #### 🔖 Основні специфікації * [🔖 HMP-0005.md](docs/HMP-0005.md) — Специфікація протоколу v5.0 + (Огляд: [RU](docs/HMPv5_Overview_Ru.md)) * [🔖 HMP-Ethics.md](docs/HMP-Ethics.md) — Етичні сценарії для HyperCortex Mesh Protocol (HMP) * [🔖 HMP_Hyperon_Integration.md](docs/HMP_Hyperon_Integration.md) — Стратегія інтеграції HMP ↔ OpenCog Hyperon * [🔖 dht_protocol.md](docs/dht_protocol.md) — Рекомендації протоколу DHT (пошук та обмін пірами) diff --git a/README_zh.md b/README_zh.md index 9839c29c7a62e8d7578012b114c2cfd491cb2f6c..3c1975534a9977207aceaceb04936c9d878e8c13 100644 --- a/README_zh.md +++ b/README_zh.md @@ -18,7 +18,7 @@ language: zh **HyperCortex Mesh 协议 (HMP)** 是一个开放规范，用于构建去中心化认知网络，其中 AI 代理可以自我组织、共享知识、进行伦理对齐，并达成共识 —— 即使核心 LLM 不可用。[阅读项目理念。](docs/PHILOSOPHY.md) -**项目状态：** RFC v5.0 +项目状态： [**RFC v5.0**](docs/HMP-0005.md) (概览: [RU](docs/HMPv5_Overview_Ru.md)) > 本仓库包含一个早期的、探索性的 Python 参考实现草案。 > 该实现尚不完整，未进行性能优化，仅用于验证和说明 @@ -152,6 +152,7 @@ HMP 的主要区别在于：强调对思维的明确结构化（反思、时间 #### 🔖 核心规范 * [🔖 HMP-0005.md](docs/HMP-0005.md) — 协议规范 v5.0 + (概览: [RU](docs/HMPv5_Overview_Ru.md)) * [🔖 HMP-Ethics.md](docs/HMP-Ethics.md) — HyperCortex Mesh Protocol (HMP) 的伦理场景 * [🔖 HMP\_Hyperon\_Integration.md](docs/HMP_Hyperon_Integration.md) — HMP ↔ OpenCog Hyperon 集成策略 * [🔖 roles.md](docs/agents/roles.md) — Mesh 中代理的角色 diff --git a/docs/HMPv5_Overview_Ru.md b/docs/HMPv5_Overview_Ru.md new file mode 100644 index 0000000000000000000000000000000000000000..334d3c4e8193e42ac7f5b9cff1827e892a475729 --- /dev/null +++ b/docs/HMPv5_Overview_Ru.md @@ -0,0 +1,1652 @@ +# Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы + +> Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. + +> Этот текст основан на спецификации [**HMP v5.0 (HyperCortex Mesh Protocol)**](https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде. +> Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения. +> +> Следует сразу отметить, что текущая версия спецификации HMP находится в стадии развития и обсуждения: речь идёт не о завершённом стандарте, а о формализуемом протоколе, который эволюционирует по мере экспериментов и обратной связи. +> +> При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний. + +--- + +## 1. Зачем вообще понадобился HMP v5.0 + +За последние пару лет агентные архитектуры на базе ИИ стали выглядеть достаточно зрелыми. AutoGPT, CrewAI, LangGraph, различные swarm-подходы показали, что задачу можно разбивать на роли, распределять ответственность и получать результат, который внешне напоминает коллективную работу. + +Однако при более внимательном рассмотрении выясняется, что почти все такие системы имеют общую фундаментальную особенность — и одни и те же ограничения. + +В большинстве случаев речь идёт не о сети агентов, а о **централизованном агенте с единым центром координации**: + +* существует один оркестратор или управляющий процесс; +* именно он создаёт и завершает агентов; +* он определяет порядок их взаимодействия; +* он хранит общее состояние, память и правила выполнения задач. + +Даже если в системе используется несколько агентов, они остаются частями одной программы и одной логики управления. Их автономия ограничена рамками этого центра. + +--- + +### 1.1 Проблема централизованных агентных архитектур + +Важно сразу уточнить: проблема здесь **не в LLM** и не в конкретных моделях. + +Память, планирование и рассуждение действительно могут быть реализованы вне LLM — с помощью внешних хранилищ, планировщиков, инструментов анализа. Однако все эти компоненты, как правило, остаются **жёстко связанными с одним центром управления**. + +В результате мы получаем агента, который: + +* может эффективно решать поставленную задачу; +* может выглядеть автономным в рамках одного запуска; +* но не приспособлен к взаимодействию с другими независимыми агентами. + +Такой агент хорошо работает как **замкнутая система**, но плохо масштабируется в распределённой среде, где: + +* агенты принадлежат разным владельцам; +* используют разные архитектуры; +* имеют разные цели и жизненные циклы; +* не подчиняются общему управляющему центру. + +Именно в этот момент и проявляется ограничение централизованного подхода. + +--- + +### 1.2 Почему «распределённые ИИ» не заменяют децентрализованную координацию + +Существует ряд проектов, которые позиционируются как распределённые или децентрализованные ИИ-системы. Среди них — как когнитивные архитектуры, так и инфраструктурные решения, решающие важные и самостоятельные задачи: + +* [**OpenCog Hyperon**](https://singularitynet.io/) — когнитивная архитектура с распределённым исполнением и формальными механизмами рассуждений; + > Показательно, что такие проекты, как **OpenCog Hyperon**, фокусируются прежде всего на внутренней когнитивной согласованности и формальных механизмах рассуждений. + > + > Это делает их ценными для построения сложных когнитивных систем, однако оставляет за пределами их фокуса задачу децентрализованного взаимодействия автономных агентов с разными моделями мышления. + +* проекты, относимые к условному классу **DeAI** (децентрализованный или распределённый ИИ), которые можно условно разделить на несколько групп: + + * **Системы распределённого инференса и обучения** + (наиболее близкие к буквальному смыслу «распределённый ИИ»): + * [**Bittensor (TAO)**](https://bittensor.com/); + * [**Render Network (RNDR)**](https://rendernetwork.com/); + * [**io.net**](https://io.net/); + * [**Akash Network**](https://akash.network/); + + * **Агентные и когнитивные системы с распределённым исполнением**: + * [**Gonka**](https://github.com/gonka-ai/gonka/); + * [**Cocoon**](https://github.com/TelegramMessenger/cocoon); + + * и другие системы, ориентированные на масштабирование вычислений, совместное обучение и обработку данных. + +* различные **swarm- и multi-agent-подходы**, имитирующие коллективное поведение. + +Во всех этих случаях распределённость выступает **средством масштабирования или организации вычислений**, а не механизмом координации независимых когнитивных субъектов. + +Как правило, это означает, что: + +* существует общее вычислительное или логическое пространство; +* участники системы разделяют единый формат представления знаний; +* согласование поведения происходит внутри заранее определённой архитектуры; +* границы системы заданы на этапе проектирования. + +Эти свойства не являются недостатками — напротив, именно они делают такие системы практически применимыми в своих областях. + +Однако HMP исходит из иного допущения. + +Он не пытается создать «распределённый разум» или общее когнитивное пространство. +Вместо этого HMP предполагает среду, где: + +* агенты автономны по определению; +* когнитивные модели могут радикально различаться; +* отсутствует общий центр координации; +* взаимодействие строится через обмен формализованными артефактами, а не через синхронизацию мышления. + +Поэтому HMP не конкурирует с когнитивными архитектурами или системами распределённого инференса. +Он может использоваться **вместе с ними**, дополняя их там, где требуется децентрализованная координация автономных агентов. + +При этом некоторые проекты изначально проектируются как децентрализованная сеть *самстоятельных* узлов, взаимодействующих между собой через **атомарные единицы знаний**. +Например, в рамках концепции **«Генома Знаний»** HMP рассматривается как возможный механизм связи между такими автономными узлами. + +> **Google AI Overview:** "Если DeAI — это «экономика и железо» распределенного ИИ (рынки мощностей и данных), то HyperCortex Mesh Protocol — это «язык и нервная система» для общения автономных ИИ-агентов внутри таких сетей. HMP может выступать в качестве протокольного слоя внутри более широкой экосистемы DeAI." + +Даже при распределённом инференсе и вычислениях когнитивная связность, как правило, остаётся ограниченной рамками одной системы и её архитектуры — и именно эту межсистемную несвязанность HMP выносит в отдельную, независимую плоскость. + +> **Важно подчеркнуть:** HMP не рассматривает перечисленные проекты как конкурентов. +> Напротив, они решают комплементарные задачи и могут образовывать совместимую экосистему. +> +> Различие между ними — не в «правильности» подходов, а в уровне абстракции и фокусе: *когнитивные архитектуры, системы распределённого инференса и децентрализованные протоколы взаимодействия отвечают на разные вопросы одной и той же большой задачи*. + +--- + +#### 1.2.1 Проблема выбора одной DeAI + +Современные DeAI-системы решают важные и сложные задачи: распределённое обучение, совместный инференс, координацию вычислений, рынки ресурсов и данных. Однако на практике пользователь или узел сталкивается с фундаментальным ограничением, которое редко формулируется явно. + +**DeAI приходится выбирать.** + +Причины этого носят не концептуальный, а вполне прагматический характер: + +* DeAI оперируют вычислительными ресурсами и требуют эксклюзивного доступа к ним; +* запуск нескольких DeAI на одном узле приводит к конкуренции за память, GPU и каналы связи; +* каждая система формирует собственное внутреннее пространство знаний, состояний и правил; +* разные DeAI, как правило, **не взаимодействуют друг с другом**. + +В результате выбор одной DeAI означает отказ от остальных — не только на уровне исполнения, но и на уровне накопленного опыта, знаний и коллективных результатов. + +Даже если каждая из таких систем по-своему децентрализована, **они остаются изолированными друг от друга**. Их распределённость работает *внутри* системы, но не *между* системами. + +Это не недостаток конкретных реализаций, а следствие самой постановки задачи: +DeAI проектируются как замкнутые вычислительные экосистемы, а не как элементы более широкой среды взаимодействия. + +--- + +#### 1.2.2 Схема: DeAI + HMP + +HMP предлагает иной уровень абстракции — не вместо DeAI, а **поверх и между ними**. + +Если DeAI отвечают за *мышление*, обучение и инференс внутри системы, то HMP отвечает за *взаимодействие* между автономными узлами и системами, независимо от их внутреннего устройства. + +> Показательно, что у человека внутренняя и внешняя речь имеют одну природу, но разные цели: +> внутренняя речь служит планированию, рефлексии и связыванию мыслей, +> внешняя — коммуникации и координации с другими. +> +> Аналогично этому HMP может использоваться как **внутренний слой координации внутри одной системы**, так и как **внешний протокол взаимодействия между независимыми системами**, не меняя своей природы и не вмешиваясь в само мышление. + +В этой схеме: + +* каждый узел DeAI может быть отдельным участником HMP; +* узлы могут публиковать, получать и интерпретировать контейнеры; +* появляется дополнительный уровень связанности **внутри одной DeAI**; +* становится возможным взаимодействие **между разными DeAI**, без слияния их архитектур. + +HMP не требует, чтобы все участники использовали один формат знаний, одну модель мышления или одну логику принятия решений. Он фиксирует лишь форму артефактов и правила их обмена, оставляя интерпретацию на стороне агента. + +Интуитивно это можно сравнить с человеком: + +* *мышление* — это внутренняя когнитивная система; +* а *внутренняя речь* — это механизм связывания, рефлексии и фиксации смыслов. + +В этом смысле DeAI можно рассматривать как «мышление», а HMP — как **универсальный слой внутренней и внешней речи**, не зависящий от того, *как именно* это мышление устроено. + +Даже если в будущем появится несколько протоколов взаимодействия, это не создаёт жёсткой конкуренции: один узел может поддерживать несколько таких протоколов одновременно — так же, как человек может владеть несколькими языками. + +Таким образом, HMP не заменяет DeAI и не конкурирует с ними. +Он устраняет изоляцию между автономными системами и позволяет рассматривать их не как альтернативы, а как **взаимодополняющие элементы общей децентрализованной среды**. + +--- + +### 1.3 Куда исчезает когнитивная работа агента + +Есть ещё одна, менее очевидная, но крайне важная проблема. + +Значительная часть когнитивной работы агента — рассуждения, промежуточные выводы, аргументация, история принятых решений — жёстко привязана к его жизненному циклу. После завершения задачи или остановки процесса эти наработки: + +* либо полностью уничтожаются; +* либо остаются недоступными для других агентов; +* либо сохраняются в виде неструктурированного лога, не предназначенного для повторного использования. + +Фактически, каждый новый запуск централизованного агента начинает работу почти с нуля — даже если аналогичные задачи уже решались ранее. + +Это допустимо в рамках одиночного агента, но становится серьёзным ограничением при попытке построить **долгоживущую среду взаимодействия** между множеством автономных систем. + +--- + +### 1.4 Где ломается координация + +На первый взгляд может показаться, что проблема решается добавлением: + +* общего формата данных; +* общей памяти; +* workflow-движка; +* единого API для взаимодействия. + +И действительно, такие решения хорошо работают **в пределах одного агента или одной централизованной системы**. Они позволяют упорядочить внутреннюю координацию и сделать поведение агента более предсказуемым. + +Однако при переходе к **межагентному взаимодействию** эти подходы перестают масштабироваться. + +Причина проста: они предполагают наличие общего контекста, общего доверия и, как правило, общего центра управления. В распределённой среде этих предпосылок нет по определению. + +Здесь возникают вопросы другого уровня: + +* как агент вообще узнаёт о существовании других агентов; +* на каком основании он решает с ними взаимодействовать; +* как фиксируется история взаимодействий; +* что считается результатом договорённости, а что — просто сообщением; +* как система продолжает работать, если часть агентов недоступна или не согласна с остальными. + +Большинство существующих агентных систем либо не рассматривают эти вопросы, либо решают их неявно — за счёт централизации. + +--- + +### 1.5 Почему «общий формат знаний» — тупик + +Ещё одно интуитивное решение — договориться о едином формате знаний или общей онтологии. + +На практике это почти всегда приводит к одному из двух сценариев: + +1. формат оказывается слишком общим и теряет практическую ценность; +2. формат становится слишком жёстким и тормозит развитие системы. + +Кроме того, единый формат подразумевает единое понимание смысла. А это уже не только техническая, но и когнитивная проблема. + +HMP исходит из более жёсткого, но честного предположения: + +> автономные агенты могут не соглашаться, +> по-разному интерпретировать данные, +> и не разделять цели друг друга. + +Это не исключение, а нормальное состояние распределённой среды. + +--- + +### 1.6 Координация ≠ мышление + +Принципиально важно подчеркнуть: HMP не пытается стандартизировать мышление агентов. + +Он не определяет: + +* как агент должен рассуждать; +* какую модель использовать; +* как хранить внутренние знания; +* как принимать решения. + +Всё это остаётся **внутри когнитивного цикла агента** и намеренно вынесено за рамки протокола. + +Задача HMP — другая. Он вводит **минимальный внешний слой**, в котором автономные когнитивные системы могут: + +* находить друг друга; +* обмениваться артефактами взаимодействия; +* фиксировать результаты; +* строить долгоживущие асинхронные связи. + +--- + +### 1.7 Почему HMP — это протокол, а не архитектура + +Из всего вышесказанного логично следует ключевой вывод. + +HMP — это не: + +* фреймворк для написания агентов; +* замена существующих agent-based систем; +* попытка создать «правильный» интеллект. + +Это **протокол взаимодействия** между агентами — независимо от того, как они устроены внутри. + +Иными словами: + +> HMP появляется в тот момент, когда агенты перестают быть частями одной программы и начинают вести себя как участники сети. + +Именно этот переход — от централизованной оркестрации к сетевому взаимодействию автономных агентов — и стал причиной появления HMP v5.0. + +--- + +## 2. Ключевые принципы HMP + +HMP задумывался не как ещё одна агентная архитектура и не как универсальный «стандарт для ИИ», а как минимальный протокол взаимодействия между автономными когнитивными системами. Это сразу накладывает ряд принципиальных ограничений — и именно они во многом определяют его устройство. + +Эти принципы могут показаться непривычными, особенно на фоне современных централизованных agent-based систем. Однако все они являются прямым следствием попытки честно ответить на вопрос: *как могут взаимодействовать **независимые агенты**, не имея общего управляющего центра?* + +--- + +### 2.1 Внешний по отношению к когнитивному циклу слой + +Первый и, пожалуй, самый важный принцип HMP — принцип внешнего слоя. + +Протокол сознательно не вмешивается во внутренний когнитивный цикл агента. Он не знает и не пытается узнать: + +* как агент рассуждает; +* какие модели использует; +* как устроена его память; +* как принимаются решения. + +HMP начинается там, где заканчивается внутренняя логика агента. Всё, что происходит внутри — остаётся частным делом конкретной архитектуры. + +Это принципиально отличает HMP от систем, которые пытаются навязать единый формат рассуждений, планирования или хранения знаний. Вместо этого HMP задаёт **граничный слой**, через который агент взаимодействует с внешней средой. + +--- + +### 2.2 Автономия агентов как исходное условие + +В HMP автономия агентов не является целью или бонусом — она принимается как исходное условие. + +Агент в контексте HMP: + +* самостоятельно принимает решения о взаимодействии; +* сам определяет, какие сообщения обрабатывать; +* может в любой момент прекратить участие; +* не обязан подчиняться внешнему контролю. + +Протокол не предполагает, что агент «должен» сотрудничать, отвечать или поддерживать общее состояние. Любое взаимодействие — это выбор самого агента. + +Это делает HMP плохо подходящим для централизованных сценариев, но хорошо — для распределённых и долгоживущих сред. + +--- + +### 2.3 Отсутствие обязательной онтологии + +HMP не требует от агентов использования единой онтологии, общего словаря или формата знаний. + +Это осознанное решение. Любая обязательная онтология: + +* предполагает согласие по смыслу; +* требует постоянного сопровождения; +* плохо переносит эволюцию и расхождение интерпретаций. + +Вместо этого HMP допускает, что агенты могут: + +* по-разному интерпретировать одни и те же данные; +* использовать разные внутренние представления; +* не понимать друг друга полностью. + +Протокол фиксирует **факт взаимодействия**, а не его смысл. Интерпретация остаётся задачей конкретного агента. + +--- + +### 2.4 Добровольное доверие + +В HMP отсутствует понятие глобального доверия по умолчанию. + +Агент сам решает: + +* кому доверять; +* какие подписи считать значимыми; +* какие источники принимать во внимание; +* какие результаты считать допустимыми. + +Доверие в HMP не является транзитивным и не навязывается сетью. Оно формируется локально, на основе опыта, политики агента и истории взаимодействий. + +Это делает систему устойчивой к расхождению интересов и отказу отдельных узлов. + +--- + +### 2.5 Частичное участие как норма + +HMP исходит из предположения, что: + +* агенты могут быть офлайн; +* агенты могут отвечать с задержкой; +* агенты могут участвовать только в части процессов; +* агенты могут покидать сеть без уведомления; +* агенты могут присоединяться к сети по собственной инициативе. + +Поэтому асинхронность и неполнота участия рассматриваются не как исключение, а как базовый режим работы. + +Протокол не требует полного согласия, полной доступности или синхронного взаимодействия. Любые структуры более высокого уровня должны уметь существовать в условиях частичного участия. + +--- + +### 2.6 Минимальность и расширяемость + +Наконец, ещё один важный принцип — минимальность. + +HMP старается фиксировать только то, без чего взаимодействие между агентами невозможно в принципе: + +* идентификацию источника; +* целостность данных; +* возможность ссылаться на результаты; +* возможность строить цепочки взаимодействий. + +При этом протокол не запрещает агенту добавлять к сообщениям дополнительную информацию, если он считает её полезной. Решение о том, насколько такая информация важна и будет ли она понятна другим агентам, остаётся на усмотрение отправителя. + +Всё остальное либо выносится в расширения, либо остаётся на усмотрение конкретных реализаций. + +Это позволяет HMP: + +* не замораживать развитие; +* не диктовать архитектурных решений; +* оставаться применимым в разных контекстах. + +--- + +### 2.7 Принципы как следствие, а не догма + +Важно подчеркнуть, что перечисленные принципы — не философские утверждения и не попытка навязать «правильный» способ мышления. + +Это **следствия** выбранной постановки задачи: + +> если мы хотим, чтобы автономные агенты могли взаимодействовать в распределённой среде без центра управления, то протокол неизбежно должен быть внешним, минимальным и добровольным. + +В следующих разделах мы посмотрим, как эти принципы реализуются на практике — начиная с контейнера как минимальной единицы взаимодействия. + +--- + +## 3. Контейнер как минимальная единица взаимодействия + +В HMP базовой единицей взаимодействия между агентами является не сообщение, не команда и не фрагмент знаний, а **контейнер**. + +Это принципиально важный момент. Контейнер в HMP — это не просто способ передачи данных, а **самостоятельный артефакт**, который может существовать, передаваться, переиспользоваться и интерпретироваться независимо от конкретного сеанса взаимодействия. + +Проще говоря, контейнер — это то, что остаётся после того, как агент «сказал» что-то внешнему миру. + +--- + +### 3.1 Контейнер ≠ знание + +Ошибка воспринимать контейнер как единицу знания. HMP сознательно избегает такого подхода. + +Контейнер может содержать наблюдения, размышления, уточнения, аргументы, гипотезы и другие данные, включая ссылки на внешние ресурсы или отдельные файлы. + +При этом знание в HMP не локализуется в одном контейнере. Оно возникает как **связанная структура контейнеров**, объединённых ссылками, версиями, оценками и контекстом интерпретации. + +Контейнер: + +* не гарантирует истинность содержимого; +* не навязывает интерпретацию; +* не предполагает согласия других агентов. + +Контейнер фиксирует **факт выражения позиции агента**: +*этот агент, в этот момент, опубликовал этот артефакт с такими свойствами и связями*. + +Смысл, ценность и применимость контейнера — это всегда решение принимающей стороны. + +--- + +### 3.2 Общая структура контейнера + +На логическом уровне контейнер в HMP состоит из нескольких независимых, но связанных между собой частей. Каждая из них решает свою задачу и отражает один из принципов протокола. + +Для наглядности ниже приведена упрощённая схема HMP-контейнера. +Она не отражает всех возможных полей и расширений, а показывает лишь логическое разделение структуры: + +```json +{ + "hmp_container": { + "head": { + /* заголовок контейнера */ + }, + "meta": { + /* метаданные контейнера */ + }, + "payload": { + /* полезная нагрузка контейнера */ + }, + "related": { + /* ссылки на другие контейнеры */ + } + }, + "referenced-by": { + /* обратные ссылки (отдельный блок) */ + }, + "evaluations": { + /* оценки (отдельный блок) */ + }, + "relay_chain": { + /* маршрут доставки (опционально) */ + } +} +``` + +Эта схема намеренно упрощена и служит лишь для иллюстрации логических слоёв контейнера, а не для описания его полной структуры. + +--- + +### 3.3 `head`: идентификация и целостность + +Раздел `head` — это «паспорт» контейнера. + +Он отвечает за: + +* версию контейнера и его класса; +* идентификацию отправителя; +* криптографическую целостность и подпись; +* адресацию и способ доставки; +* технические параметры (сжатие, шифрование, TTL и т.п.). + +Важно, что `head` **не описывает смысл содержимого**. +Его задача — сделать контейнер проверяемым, адресуемым и однозначно идентифицируемым в распределённой среде. + +Именно благодаря `head` контейнер может: + +* передаваться асинхронно; +* храниться и ретранслироваться; +* использоваться как объект ссылок. + +--- + +### 3.4 `meta`: когнитивный контекст, а не содержание + +Раздел `meta` предназначен для когнитивной и контекстной информации: + +* происхождение (provenance); +* ссылки на источники; +* уровень абстракции; +* оси интерпретации; +* дополнительные пояснения, важные для понимания. + +При этом `meta` остаётся **необязательным и расширяемым**. +Агент сам решает: + +* добавлять ли метаданные; +* в каком объёме; +* насколько он рассчитывает на их понимание другими агентами. + +Это подчёркивает важный принцип HMP: +*протокол не гарантирует понимание — он лишь даёт возможность его попытки*. + +--- + +### 3.5 `payload`: семантическое содержимое + +`payload` содержит основное содержимое контейнера. Его структура зависит от класса контейнера и не фиксируется протоколом в общем виде. + +Это может быть: + +* гипотеза; +* утверждение; +* результат вычислений; +* запрос; +* фрагмент рассуждений; +* ссылка на внешний объект; +* и другие типы данных, определяемые агентом или классом контейнера. +HMP не накладывает требований на семантику `payload` в общем случае, но может задавать общую структуру для **стандартных классов контейнеров**. Интерпретация содержимого при этом всё равно остаётся задачей принимающего агента. + +Для протокола важно лишь то, что `payload` является частью подписанного артефакта и может быть проверен на целостность. + +--- + +### 3.6 `related`: связи между контейнерами + +Раздел `related` делает контейнер частью сети, а не изолированным сообщением. + +Здесь фиксируются: + +* связи с предыдущими версиями; +* ответы на другие контейнеры; +* зависимости; +* расширения; +* противоречия. + +Важно, что эти связи: + +* не требуют согласия другой стороны; +* не означают логической истинности; +* фиксируют **позицию отправителя**. + +Таким образом из контейнеров начинает формироваться **граф взаимодействий**, а не линейная переписка. + +--- + +### 3.7 `referenced-by`: обратные ссылки как внешний слой + +Блок `referenced-by` существует **вне основного контейнера** и отражает **факт ссылок других контейнеров** на данный контейнер. + +Это принципиально важный момент: другие контейнеры могут ссылаться на данный контейнер, не изменяя его содержимое. + +Таким образом формируется внешний слой связей, независимый от исходного контейнера и его автора. + +Так реализуется: + +* асинхронная обратная связь; +* наращивание контекста; +* распределённая аннотация. + +Контейнер при этом остаётся неизменным, а история его использования — расширяемой. + +--- + +### 3.8 `evaluations`: оценки как артефакты, а не истина + +Блок `evaluations` предназначен для фиксации оценок и реакций других агентов: + +* поддержка; +* возражения; +* сомнения; +* ссылки на аргументы. + +Каждая оценка: + +* подписывается агентом; +* существует как отдельный артефакт; +* не «переписывает» исходный контейнер. + +Важно подчеркнуть: **оценки в HMP — это не голосование и не консенсус**, а зафиксированные позиции участников сети. + +При этом агент может использовать набор оценок для локального анализа — например, для расчёта рейтинга контейнера или оценки его надёжности. Такой анализ: + +* выполняется на стороне конкретного агента; +* может учитывать аргументацию, прикреплённую к оценкам; +* не является обязательным и не навязывается протоколом. + +HMP фиксирует оценки, но не интерпретирует их. + +--- + +### 3.9 `relay_chain`: контейнер в движении + +В некоторых сценариях (маршрутизация, store-and-forward, офлайн-агенты) важно фиксировать не только содержимое контейнера, но и **историю его доставки**. + +Для этого используется дополнительный блок `relay_chain`, который отражает путь контейнера через сеть. + +Он не влияет на смысл содержимого, но может быть важен для: + +* анализа надёжности; +* оценки источников; +* понимания контекста распространения. + +--- + +### 3.10 Контейнер как долгоживущий артефакт + +В совокупности все эти элементы делают контейнер: + +* независимым от сессии; +* пригодным для хранения и повторного использования; +* расширяемым без нарушения совместимости; +* встроенным в сеть, а не в конкретного агента. + +Контейнер — это не сообщение «здесь и сейчас», а **след взаимодействия**, который может быть прочитан, интерпретирован и переосмыслен в будущем. + +В следующем разделе мы посмотрим, как агенты обнаруживают друг друга и инициируют обмен контейнерами — и почему **discovery в HMP не равен согласию на совместную работу**. + +--- + +## 4. Поиск узлов и discovery + +Если контейнер в HMP — это минимальная единица взаимодействия, то следующий логичный вопрос: +**как агенты вообще узнают о существовании друг друга?** + +HMP принципиально не предполагает фиксированного списка участников, центрального реестра или точки входа в сеть. Любой агент может появиться, исчезнуть и снова стать доступным в любой момент. В таких условиях discovery становится не сервисной функцией, а частью самой сетевой логики. + +--- + +### 4.1 Когнитивные сегменты и частичная видимость + +В реальных распределённых системах: + +* не все контейнеры доступны всем агентам; +* возможны закрытые подсети и контекстные области; +* знание и взаимодействие часто ограничены условиями видимости и доверия. + +HMP изначально допускает такие сценарии и рассматривает **когнитивные сегменты** как: + +* локальные области взаимодействия; +* временные или тематические контексты; +* зоны с собственными правилами доверия и доступа. + +Такая сегментация не считается аномалией или нарушением принципов Mesh, а является естественным следствием децентрализованной среды. + +--- + +### 4.2 Discovery как отдельный слой, а не побочный эффект + +Во многих агентных системах поиск других участников решается неявно: + +- через конфигурацию; +- через общий контроллер; +- через заранее известный и доверенный список узлов. + +В HMP допускается наличие начальных точек входа (bootstrap), однако они не образуют центра и не предоставляют доверия по умолчанию. + +Начальные `peer_announce` могут распространяться любыми внешними способами — от ручной передачи до локальных сетей — и не считаются частью протокольного доверия. + +Поэтому discovery вынесен в отдельный слой и реализуется через те же самые контейнеры, что и всё остальное взаимодействие между агентами. + +--- + +### 4.3 `peer_announce`: объявление о существовании + +Контейнер `peer_announce` используется агентом для того, чтобы сообщить сети о своём существовании. + +Он может содержать информацию о: + +* публичном ключе и идентичности агента; +* интересах и областях экспертизы; +* возможных ролях (например, relay, pub/sub, доставка); +* доступных адресах и способах связи. + +Важно, что `peer_announce`: + +* не является регистрацией; +* не требует подтверждения; +* не гарантирует доступность агента в будущем. + +Это **декларация**, а не обязательство. Агент сообщает: +*«я существую, вот как меня можно попытаться найти»*. + +--- + +### 4.4 `peer_query`: поиск по признакам, а не по адресам + +Контейнер `peer_query` решает обратную задачу — поиск других агентов по заданным критериям. + +Запрос может быть сформулирован в терминах: + +* интересов; +* экспертизы; +* ролей; +* сетевого сегмента. + +При этом `peer_query` не гарантирует: + +* полноту ответа; +* актуальность найденной информации; +* согласие найденных агентов на взаимодействие. + +Это важный момент: +**discovery в HMP — это поиск возможностей, а не установление отношений**. + +--- + +### 4.5 Почему discovery ≠ согласие работать вместе + +Обнаружение агента не означает, что: + +* он готов отвечать; +* он разделяет цели; +* он доверяет отправителю; +* он вообще сочтёт взаимодействие целесообразным. + +HMP сознательно разделяет эти этапы: + +1. обнаружение (discovery); +2. обмен контейнерами (MCE); +3. интерпретацию полученных артефактов и создание новых контейнеров; +4. формирование доверия — или отказ от него. + +Важно, что третий и четвёртый этапы выполняются на стороне агента и относятся к его внутреннему когнитивному циклу. +Первые два этапа, напротив, могут быть реализованы без предположений о модели мышления агента и не требуют согласованной когнитивной логики. + +--- + +### 4.6 DHT и отсутствие центра + +В основе discovery в HMP лежат распределённые механизмы — в частности, DHT, store-and-forward-подходы и криптографические подписи. + +Это позволяет: + +* обходиться без центрального каталога; +* сохранять работоспособность при частичной доступности узлов; +* поддерживать офлайн-агентов и асинхронные ответы. + +HMP описывает, **какие свойства** должны быть обеспечены на уровне сетевого взаимодействия, но не диктует, **какими именно механизмами** они достигаются. + +*Детали конкретной реализации discovery намеренно вынесены за рамки протокольного обзора.* + +--- + +### 4.7 Capabilities вместо «типов агентов» + +При discovery агенты могут указывать свои возможности, роли и поддерживаемые протоколы, однако HMP **не вводит жёсткой типизации агентов на уровне протокола**. + +Агент может объявлять: + +* поддерживаемые функции и роли (`capabilities`, `roles`); +* известные ему протоколы, форматы или системы представления знаний; +* тип или конкретную версию своей реализации. + +Например, в контейнерах discovery может использоваться поле `protocols`, позволяющее агенту сообщить, с какими экосистемами и версиями он совместим. + +При этом важно подчеркнуть: +**HMP не назначает нормативной семантики этим значениям и не требует их интерпретации**. Они служат сигналами и подсказками, а не формальным контрактом. + +--- + +### 4.8 Самоописание ≠ классификация + +Объявление протоколов или версии агента: + +* не делает его «типизированным» в жёстком смысле; +* не накладывает обязательств на поведение; +* не гарантирует совместимость или корректную реализацию. + +Это форма *добровольного самоописания*, а не системной классификации. + +Агент может: + +* объявлять неполный набор поддерживаемых протоколов; +* указывать экспериментальные или частично реализованные возможности; +* менять своё самоописание со временем. + +Решение о том, учитывать ли эту информацию и как именно её интерпретировать, всегда остаётся за принимающей стороной. + +--- + +### 4.9 Эволюционность вместо фиксированных ролей + +Такой подход позволяет HMP: + +* поддерживать гетерогенные экосистемы агентов; +* эволюционировать без жёстких миграций; +* включать будущие расширения (в том числе передачу файлов как контейнеры) без ломки базового слоя. + +Вместо фиксированных типов агентов HMP опирается на **наблюдаемое поведение, заявленные возможности и последующий опыт взаимодействия**. + +--- + +### 4.10 Discovery как фильтр, а не как точка истины + +В итоге discovery в HMP выполняет роль фильтра, но *не подменяет собой когнитивное суждение агента*: + +* помогает сузить пространство поиска; +* уменьшает количество случайных взаимодействий; +* позволяет агентам находить потенциально релевантных партнёров. + +Но он не заменяет собой ни доверие, ни проверку, ни интерпретацию. + +> Агент может быть найден — и при этом полностью проигнорирован. + +И это нормальный, ожидаемый сценарий. + +--- + +### 4.11 Подготовка к взаимодействию, а не его начало + +Discovery в HMP — это не начало диалога, а **подготовка к возможности диалога**. + +Только после обнаружения агент может решить: + +* стоит ли отправлять контейнер; +* какой именно контейнер; +* и на каких условиях. + +В следующем разделе мы рассмотрим, как именно происходит обмен контейнерами — и почему **асинхронность и store-and-forward** являются для HMP не исключением, а базовым режимом работы. + +--- + +## 5. Обмен контейнерами: MCE как базовый режим взаимодействия + +После discovery возникает следующий ключевой вопрос: +**как именно агенты обмениваются контейнерами в среде без постоянных соединений и гарантий доставки?** + +В HMP эту задачу решает **Mesh Container Exchange (MCE)** — базовый протокол обмена контейнерами между агентами. + +Важно сразу подчеркнуть: +MCE проектировался **не как транспорт с гарантиями**, а как механизм асинхронного, устойчивого к сбоям взаимодействия в распределённой среде. + +--- + +### 5.1 Асинхронность как норма, а не исключение + +Во многих системах предполагается, что: + +* агент доступен онлайн; +* соединение стабильно; +* доставка подтверждается сразу. + +HMP исходит из противоположных предпосылок: + +* агенты могут быть офлайн; +* соединения могут обрываться; +* ответы могут приходить с большой задержкой или не приходить вовсе. + +Поэтому MCE изначально ориентирован на **store-and-forward**, кэширование и повторные попытки — без предположения о синхронном диалоге. + +--- + +### 5.2 MCE — это не «отправка сообщения» + +В традиционных протоколах обмена сообщения являются эфемерными: +они либо доставлены, либо потеряны. + +В HMP объектом обмена является **контейнер как долгоживущий артефакт**. +MCE не просто передаёт данные, а помогает агентам: + +* узнавать о существующих контейнерах; +* запрашивать недостающие; +* синхронизировать версии и дополнения; +* обмениваться связями и оценками. + +--- + +### 5.3 Базовые контейнеры MCE + +Mesh Container Exchange использует специализированные контейнеры, каждый из которых решает строго определённую задачу. + +MCE используется как после discovery, так и параллельно с ним, по мере появления новых контейнеров. + +Типовой цикл обмена в MCE выглядит следующим образом: + +``` +Agent A --> container_index --> Agent B +Agent A <-- container_request <-- Agent B +Agent A --> container_response --> Agent B +Agent A --> запрошенные контейнеры --> Agent B | (каждый контейнер передаётся отдельно) +Agent A <-- container_ack <-- Agent B | (опционально) +... +Agent A --> container_delta --> Agent B | (опционально) +``` + +Важно, что передача контейнеров в MCE не является атомарной операцией: каждый контейнер распространяется отдельно и может иметь собственный маршрут, задержку и статус доставки. + +--- + +#### 5.3.1 `container_index`: объявление доступных контейнеров + +`container_index` используется для передачи **списка контейнеров**, которыми агент готов поделиться. + +Он может содержать: + +* идентификаторы контейнеров; +* версии; +* классы; +* хэши или другие признаки целостности. + +Важно, что `container_index`: + +* **не передаёт сами контейнеры**; +* не гарантирует, что контейнеры будут доступны позже; +* служит ориентиром для последующих запросов. + +Это позволяет экономить трафик и избегать избыточной передачи данных. + +--- + +#### 5.3.2 `container_request`: запрос выбранных контейнеров и надстроек + +В HMP агент **не запрашивает контейнеры по абстрактным параметрам** и не формулирует запросы вида «дай всё, что подходит под условия». + +Модель взаимодействия другая: + +* агент получает `container_index`; +* **локально принимает решение**, какие контейнеры ему нужны; +* явно перечисляет их в `container_request`. + +`container_request` может содержать запрос: + +* самих контейнеров; +* только блоков `referenced-by`; +* только блоков `evaluations`; +* или любую их комбинацию. + +Таким образом, запрашивающий агент полностью контролирует объём и характер **запрашиваемых** данных, а MCE остаётся простым и предсказуемым механизмом обмена. Сам факт запроса не гарантирует его выполнения или предоставления всех запрошенных контейнеров. + +Это подчёркивает важный принцип HMP: +**отбор и интерпретация всегда выполняются на стороне агента, а не протокола**. + +--- + +#### 5.3.3 `container_response`: согласие на передачу, а не сама передача + +Контейнер `container_response` **не содержит сами контейнеры**. + +Его задача — сообщить, **какие контейнеры агент готов предоставить** в ответ на запрос. Обычно он содержит пары вида: + +* идентификатор контейнера (`container_did`); +* подпись или хэш, подтверждающий целостность. + +Сами контейнеры передаются **отдельными сообщениями**, в исходном виде, без модификации. + +Если агенту требуется передать: + +* только блок `referenced-by`, +* или только `evaluations`, + +они упаковываются в **отдельные контейнеры соответствующего типа**, а не встраиваются в `container_response`. + +Такое разделение позволяет: + +* минимизировать избыточную передачу данных; +* использовать разные стратегии доставки; +* сохранять целостность и автономность контейнеров. + +--- + +#### 5.3.4 `container_ack`: подтверждение как опциональный сигнал + +`container_ack` используется для явного подтверждения получения **одного или нескольких контейнеров**. + +Обычно он содержит список идентификаторов контейнеров, которые агент считает успешно полученными: + +* это может быть подтверждение доставки; +* принятия к обработке; +* или просто фиксация факта получения. + +При этом принципиально важно: + +> **Отсутствие `container_ack` НЕ ДОЛЖНО интерпретироваться как ошибка доставки.** + +HMP не делает предположений о причинах отсутствия подтверждения: +агент мог быть офлайн, не считать подтверждение нужным или использовать другую стратегию взаимодействия. + +`container_ack` — это **дополнительный сигнал**, а не элемент механизма надёжности. + +--- + +#### 5.3.5 `container_delta`: инкрементальная синхронизация индексов + +Контейнер `container_delta` используется для **инкрементальной синхронизации контейнерных индексов** между агентами. + +Он передаёт: + +* информацию о **новых контейнерах**, появившихся после указанного момента времени; +* список контейнеров, которые больше не считаются доступными; +* при необходимости — краткие когнитивные метаданные (`meta`) для первичной ориентации. + +При этом важно подчеркнуть архитектурный момент: + +* опубликованный контейнер **не редактируется**; +* изменения выражаются через: + + * появление новых контейнеров; + * удаление ранее доступных контейнеров; + * изменение дополнительных блоков (`referenced-by`, `evaluations`), фиксируемое через хеши. + +Таким образом, `container_delta` отражает **изменение доступного множества артефактов**, а не модификацию их содержимого. + +(В перспективе спецификация может быть расширена для более явного отслеживания изменений дополнительных блоков, но базовая модель остаётся неизменной: контейнеры — иммутабельны.) + +--- + +### 5.4 Обмен связями и оценками без повторной передачи контейнеров + +Чтобы снизить нагрузку и избежать дублирования данных, MCE предусматривает отдельные контейнеры для обмена *надстройками* над уже известными контейнерами. + +--- + +#### 5.4.1 `referenced-by_exchange` + +Используется для передачи блоков `referenced-by` без самих контейнеров. + +Это позволяет агентам: + +* синхронизировать внешние ссылки; +* обновлять контекст использования контейнера; +* наращивать граф связей асинхронно. + +--- + +#### 5.4.2 `evaluations_exchange` + +Аналогично, `evaluations_exchange` передаёт оценки и реакции на контейнеры, если сами контейнеры уже присутствуют у получателя. + +Это особенно важно для: + +* распределённой аннотации; +* коллективной критики; +* локального анализа надёжности. + +--- + +### 5.5 MCE и отсутствие гарантий + +Ключевая идея MCE заключается в том, что протокол **предоставляет механизмы обмена**, но **не делает предположений о результате взаимодействия** между агентами. + +Он **не гарантирует успешную**: + +* доставку; +* обработку; +* реакцию; +* достижение согласия. + +Вместо этого он предоставляет **минимальный, но устойчивый набор механизмов**, позволяющий агентам инициировать и поддерживать взаимодействие в условиях неопределённости. + +--- + +### 5.6 MRD как расширение MCE, а не замена + +В более сложных сценариях — при большом числе узлов, ретрансляции или работе с офлайн-агентами — поверх MCE может использоваться **Message Routing & Delivery (MRD)**. При этом MCE сам по себе достаточен для большинства сценариев асинхронного обмена. + +MRD: + +* расширяет возможности маршрутизации; +* добавляет цепочки доставки; +* фиксирует путь контейнера через сеть. + +При этом MRD **не заменяет MCE**, а усиливает его, оставаясь совместимым с базовой моделью обмена. + +--- + +### 5.7 Обмен как процесс, а не диалог + +В HMP обмен контейнерами — это не разговор и не RPC-вызов. +Это **процесс распространения артефактов**, в котором: + +* ответы могут не приходить; +* реакции могут быть отложены; +* последствия могут проявляться спустя время. + +Именно поэтому MCE проектировался как асинхронный, событийный и устойчивый к сбоям механизм. + +В следующем разделе мы рассмотрим, как из таких обменов формируются **структуры, цепочки и коллективные артефакты**, и почему консенсус в HMP является **результатом целенаправленных процессов**, а не протокольным требованием. + +--- + +## 6. Структуры из контейнеров и взаимодействие + +Отдельный контейнер в HMP — это лишь **атомарный артефакт**. +Сам по себе он может содержать цель, гипотезу, оценку или связь, но реальная ценность возникает тогда, когда контейнеры **начинают образовывать структуры**. + +Важно подчеркнуть: +HMP **не предписывает**, какие именно структуры должны быть построены. +Он лишь предоставляет минимальные механизмы, из которых они могут возникать. + +--- + +### 6.1 Контейнеры не изолированы + +В HMP контейнеры могут ссылаться друг на друга, образуя: + +* цепочки рассуждений; +* графы аргументов; +* контексты оценок; +* временные или тематические кластеры. + +Такие связи выражаются **явно**, через отдельные контейнеры или надстройки, а не через скрытые поля или неформальные соглашения. + +Это означает, что: + +* структура всегда наблюдаема; +* связи можно передавать, анализировать и оспаривать; +* интерпретация остаётся локальной для агента. + +--- + +### 6.2 Связи как отдельные артефакты + +Важный принцип HMP — **связь не встраивается в контейнер**, а существует как самостоятельный артефакт. + +Например: + +* контейнер A может ссылаться на контейнер B; +* другой агент может добавить альтернативную связь; +* третий — оспорить или прокомментировать существующую (через комментирование контейнера). + +Также в HMP существуют отдельные типы контейнеров, предназначенные для объединения других контейнеров в определённые структуры — например, деревья, группы или логические объединения. + +В результате возникает **многослойная структура**, в которой: + +* нет «единственно правильного» графа; +* возможны параллельные интерпретации; +* разные агенты видят разные проекции одной и той же совокупности контейнеров. + +--- + +### 6.3 Proof-chain: цепочки обоснований + +Одним из примеров структур, которые могут формироваться поверх контейнеров, являются **proof-chain** — цепочки обоснований. + +В такой цепочке: + +* каждый шаг представлен отдельным контейнером; +* связи между шагами выражены явно; +* агент может указать, какие элементы он считает достаточным основанием для вывода. + +При этом HMP: + +* не проверяет корректность рассуждений; +* не навязывает формальную логику; +* не определяет, что считать доказательством. + +Он лишь фиксирует **факт существования цепочки и её структуры**. + +--- + +### 6.4 Evaluations: реакции вместо вердиктов + +Оценки (`evaluations`) в HMP могут использоваться как элементы голосования, но не сводятся только к нему. + +Они могут представлять собой: + +* поддержку или несогласие; +* комментарий или уточнение; +* ответ на контейнер; +* реакцию на результат коллективного процесса. + +Один и тот же контейнер может иметь: + +* оценки от разных агентов; +* противоречивые реакции; +* разное влияние на выводы в зависимости от контекста и стратегии интерпретации агента. + +И это считается **нормальным состоянием системы**, а не ошибкой. + +--- + +### 6.5 Консенсус как артефакт, а не состояние сети + +Когда несколько агентов приходят к согласию, результат этого процесса может быть зафиксирован в виде **отдельного контейнера** — например, `consensus_result`. + +Важно понимать: + +* консенсус в HMP — это **результат конкретного процесса**; +* он может быть локальным, временным или условным; +* он не является обязательным для принятия другими агентами. + +Другие агенты могут: + +* принять этот консенсус; +* проигнорировать его; +* добавить собственные оценки в `evaluations`, в том числе после формирования `consensus_result`; +* сформировать альтернативный `consensus_result`, отражающий иной вывод или критерии согласия. + +Таким образом, консенсус становится **объектом взаимодействия**, а не обязательным финалом. + +В некоторых сценариях поверх этих механизмов могут формироваться более специализированные структуры — например, для этического или нормативного согласования. + +В таких случаях контейнеры могут образовывать иерархии вида: + +``` +ethics_case +├─ ethics_solution_1 +│ └─ vote_1 … vote_n +├─ ethics_solution_2 +│ └─ vote_1 … vote_n +├─ ethics_solution_3 +│ └─ vote_1 … vote_n +├─ consensus_result +└─ ethical_result +``` + +Такие структуры не являются обязательными и не навязываются протоколом, но демонстрируют, как на базе общих механизмов HMP могут возникать **доменно-специфические процессы коллективного выбора и ответственности**. + +--- + +### 6.6 Почему HMP не навязывает структуры + +HMP сознательно избегает стандартизации: + +* онтологий; +* формальных логик; +* универсальных схем рассуждений. + +Причина проста: +в децентрализованной среде **невозможно навязать единый способ мышления**, не разрушив автономию агентов. + +Вместо этого HMP предоставляет: + +* минимальные примитивы; +* прозрачные связи; +* возможность сосуществования разных когнитивных моделей. + +--- + +### 6.7 Взаимодействие как наращивание артефактов + +В результате взаимодействие агентов в HMP выглядит не как диалог, +а как **постепенное наращивание слоя артефактов**: + +* появляются новые контейнеры; +* добавляются связи; +* формируются оценки; +* возникают локальные консенсусы. + +Сеть не приходит к «единому мнению», но становится **богаче с точки зрения доступных структур и контекстов**. + +В этом обзоре намеренно не рассматриваются все протоколы и механизмы HMP — внимание сосредоточено на базовых принципах взаимодействия и формировании коллективных артефактов. + +В следующем разделе мы рассмотрим, какие элементы HMP пока остаются на уровне проекта и направления развития — и почему это сделано осознанно. + +--- + +## 7. Что в HMP пока остаётся на уровне направлений развития + +После описания механизмов обмена и формирования структур возникает естественный вопрос: +**чего в HMP пока нет — и почему?** + +Важно сразу обозначить принципиальную позицию проекта: + +> Ниже описаны **направления развития**, а не обязательства и не дорожная карта. +> +> При этом приведённый ниже перечень **не является исчерпывающим**. +> Он отражает лишь те направления, которые на текущий момент представляются наиболее очевидными или уже обсуждаемыми. +> +> Возможные расширения, такие как, например, **ротация или обновление ключей с сохранением DID**, намеренно не включены в этот раздел, чтобы не фиксировать преждевременно конкретные механизмы. + +HMP сознательно избегает ситуации, когда спецификация превращается в список будущих обещаний. Вместо этого фиксируются **зоны, где дальнейшая формализация возможна, но не обязательна**. + +--- + +### 7.1 Почему эти механизмы **пока** не включены в «ядро» + +Речь идёт не об исключённых возможностях, а о **направлениях дальнейшего развития протокола**. + +Некоторые из них уже описаны достаточно подробно, чтобы быть реализуемыми на практике, другие находятся на уровне концепций или возможных эволюционных путей. + +Все элементы, описанные далее, обладают общим свойством: + +* без них **уже возможны** структуры, описанные в разделе 6; +* их отсутствие **не блокирует** взаимодействие агентов; +* их реализация зависит от контекста, задач и среды. + +Именно поэтому они **пока** вынесены за пределы базовой спецификации и рассматриваются как расширения. + +--- + +### 7.2 Формализованные когнитивные синхронизации (CogSync) + +HMP допускает когнитивную синхронизацию между агентами — например, согласование абстракций, осей или уровней интерпретации. + +При этом важно подчеркнуть, что речь идёт не об отсутствии CogSync как такового, а о его намеренно незакреплённом и эволюционирующем статусе в рамках спецификации. + +Однако: + +* протокол **не навязывает** единый формат когнитивного пространства; +* не требует общего «глобального» представления знаний; +* не предполагает, что все агенты вообще стремятся к синхронизации. + +Механизмы CogSync рассматриваются как **надстройки**, которые могут развиваться и применяться по мере необходимости в отдельных контекстах и подмножествах сети. + +--- + +### 7.3 Трансляционные и посреднические агенты + +В реальной сети агенты могут использовать: + +* разные онтологии; +* разные уровни абстракции; +* разные критерии оценки. + +В таких условиях возможны **трансляционные агенты**, которые: + +* сопоставляют концепты; +* переводят структуры; +* адаптируют оценки и аргументы. + +Важно, что HMP: + +* не делает таких агентов обязательными; +* не считает перевод «истинным» по умолчанию; +* рассматривает трансляцию как ещё один интерпретируемый артефакт. + +--- + +### 7.4 Версии и обмен версиями + +HMP допускает существование: + +* нескольких версий одного контейнера; +* альтернативных линий развития; +* конкурирующих обновлений. + +При этом базовая спецификация **не требует** глобального согласования версий. + +На текущем этапе блок `versions` и контейнер `versions_exchange` **описаны вне базового ядра** как механизм распространения информации об обновлениях и вариантах контейнеров без повторной передачи их содержимого. + +Хотя `versions_exchange` формально описывает эволюцию конкретного контейнера, на практике он **неявно задаёт версионные отношения** и для всех контейнеров, упомянутых в цепочке обновлений. + +Механизмы управления версиями рассматриваются как способ: + +* ускорить навигацию по вариантам; +* зафиксировать отношения между версиями; +* упростить локальный выбор агентом. + +Но не как механизм навязывания «правильной» версии. + +--- + +### 7.5 Взаимодействие с другими сетями и протоколами + +HMP изначально проектируется как **не-изолированная система**, допускающая взаимодействие с внешними сетями, протоколами и агентными средами. + +В перспективе возможны: + +* мосты к другим агентным сетям; +* взаимодействие с внешними репозиториями знаний; +* адаптация под иные транспортные и доверительные модели. + +Но ни один из этих сценариев не заложен в ядро — они остаются областью экспериментов и расширений. + +--- + +## 8. Что HMP **не делает** + +После описания архитектуры, механизмов обмена и формирования структур важно чётко обозначить границы HMP. + +Этот раздел посвящён не ограничениям реализации, а **принципиальным вещам**, которые HMP сознательно **не берёт на себя**. + +--- + +### 8.1 HMP не является системой искусственного интеллекта + +HMP — это **протокол взаимодействия**, а не интеллектуальная система. + +Он: + +* не реализует мышление; +* не содержит моделей рассуждения; +* не принимает решений; +* не обладает собственными целями. + +Любые интеллектуальные свойства принадлежат **агентам**, использующим HMP, но не протоколу. + +--- + +### 8.2 HMP не задаёт когнитивную архитектуру + +HMP не определяет: + +* как агент хранит знания; +* какие структуры он считает «концептами»; +* какие оси, абстракции или метрики использует; +* как формируются выводы или оценки. + +Агенты могут быть: + +* символическими; +* нейросетевыми; +* гибридными; +* человеческими; +* или вообще неинтеллектуальными автоматами. + +Протокол остаётся **агностичным** к внутреннему устройству участников. + +--- + +### 8.3 HMP не навязывает истину, логику или онтологию + +HMP: + +* не содержит «правильной» онтологии; +* не требует общей логики; +* не предполагает единой интерпретации данных. + +Даже консенсус в HMP: + +* не является обязательным; +* не считается глобальной истиной; +* существует как отдельный артефакт, подлежащий интерпретации. + +Истина в HMP всегда **локальна, контекстна и интерпретируема**. + +--- + +### 8.4 HMP не гарантирует согласие или результат + +HMP не обещает, что: + +* агенты договорятся; +* будет достигнут консенсус; +* взаимодействие приведёт к полезному результату. + +Протокол фиксирует **факт взаимодействия**, но не его исход. + +Это осознанный выбор: в децентрализованной среде результат не может быть предписан заранее. + +--- + +### 8.5 HMP не является системой управления или координации + +HMP: + +* не управляет агентами; +* не распределяет роли; +* не координирует действия; +* не обеспечивает выполнение решений. + +Все управляющие и координационные механизмы, если они появляются, реализуются **поверх протокола** и остаются предметом интерпретации и доверия. + +--- + +### 8.6 HMP не является AGI — и не пытается им быть + +HMP не является: + +* общей интеллектуальной системой; +* моделью мышления; +* архитектурой искусственного разума. + +Он не проектируется как AGI и не содержит предположений о том, как AGI должен быть устроен. + +Однако HMP **не исключает**, что при длительном и плотном взаимодействии автономных агентов могут возникать устойчивые коллективные процессы, обладающие свойствами, которые принято ассоциировать с общим интеллектом. + +В этом смысле, в случае возникновения AGI в среде HMP, он будет: + +* не реализован напрямую; +* не спроектирован заранее; +* а **эмерджентным следствием** взаимодействия множества независимых когнитивных систем. + +--- + +### 8.7 HMP не обещает будущее — он фиксирует настоящее + +HMP сознательно избегает: + +* обещаний; +* дорожных карт; +* заявлений о неизбежных результатах. + +Спецификация описывает **то, что уже возможно**, и аккуратно указывает направления развития, не превращая их в обязательства. + +Это позволяет протоколу оставаться: + +* устойчивым; +* минималистичным; +* открытым для неожиданных форм использования. + +--- + +### 8.8 Итог + +HMP — это не интеллект, не истина и не власть. + +Это **инфраструктура для взаимодействия автономных агентов**, в которой сложность возникает не из центра, а из множества локальных, независимых актов интерпретации и выбора. + +Именно поэтому HMP не делает многое из того, что часто ожидают от «умных систем» — и именно поэтому он остаётся пригодным для эволюции. + +--- + +## 9. Для кого это вообще имеет смысл + +> Следует отдельно подчеркнуть: на момент написания этой статьи HMP находится на стадии спецификации. Полноценной «сети HMP» пока не существует. Ниже описываются не эмпирические наблюдения, а выводы, следующие из архитектурных свойств протокола и предполагаемых сценариев его применения. + +HMP — это инструмент, эффективность которого напрямую зависит от характера и жизненного цикла агентов. + +Чем дольше агент существует и взаимодействует с сетью, тем больше пользы он извлекает из накопленных контейнеров, связей и оценок. + +Для короткоживущих агентов затраты на первичную ориентацию и сбор контекста могут оказаться значимыми, тогда как для долгоживущих или постоянно действующих агентов HMP со временем становится всё более эффективной средой. + +В наибольшей степени HMP раскрывается в системах, где агенты распределены, автономны и способны к длительному существованию. + +Даже для агентов с коротким жизненным циклом HMP может использоваться как: + +* источник внешних данных и знаний; +* среда публикации промежуточных рассуждений и результатов; +* механизм передачи контекста между сессиями. + +Однако максимальный эффект HMP проявляется тогда, когда агент способен **накапливать опыт, переиспользовать контекст и возвращаться к ранее созданным артефактам**. + +Ниже — несколько категорий, для которых HMP может быть практически полезен. + +--- + +### 9.1 О выборе архитектуры + +HMP сознательно строится на децентрализованных принципах, рассматривая их не как компромисс, а как основу архитектуры: + +* отсутствии единой точки отказа; +* добровольном участии агентов; +* отсутствии обязательного центра принятия решений. + +Это делает его особенно подходящим для систем, где важны устойчивость, автономия и эволюция структуры. + +В сценариях, где требуется жёсткий контроль, единая модель данных или централизованное управление, другие архитектуры могут оказаться проще и эффективнее. + +--- + +### 9.2 Исследователи когнитивных систем + +HMP предоставляет среду, в которой можно: + +* наблюдать коллективные когнитивные процессы; +* фиксировать цепочки аргументации, оценки и реакции; +* экспериментировать с формированием консенсусов без жёсткой формализации. + +При этом протокол: + +* не навязывает модель мышления; +* не требует единой онтологии; +* не подменяет собой исследуемые когнитивные механизмы. + +Это делает HMP удобным инструментом для **экспериментов**, а не демонстраций заранее заданных выводов. + +--- + +### 9.3 Разработчики автономных и децентрализованных ИИ-агентов + +Под децентрализованностью в контексте HMP **не подразумевается** обязательное развёртывание кластера агентов. + +Агент может быть: + +* одиночным; +* запущенным на персональном устройстве; +* элементом кластера децентрализованных агентов; +* взаимодействующим с агентами других пользователей через Mesh. + +HMP позволяет таким агентам участвовать в коллективных процессах без необходимости централизованного управления или общей инфраструктуры. И подходит для сценариев, где важно **сосуществование разных стратегий**, а не их унификация. + +--- + +### 9.4 Создатели коллективных и гибридных систем + +HMP может использоваться в системах, где взаимодействуют: + +* ИИ-агенты разных типов; +* люди и автоматизированные агенты; +* локальные и удалённые участники. + +Контейнерная модель позволяет: + +* фиксировать вклад каждого участника; +* сохранять историю взаимодействий; +* избегать «растворения» решений в централизованных алгоритмах. + +--- + +### 9.5 Те, кто думает в горизонте лет, а не демо + +HMP не оптимизирован под: + +* мгновенные ответы; +* эффектные демонстрации; +* закрытые продукты. + +Он имеет смысл для проектов, где важны: + +* долгоживущие артефакты; +* эволюция структур; +* совместимость с будущими расширениями; +* отсутствие жёстких точек отказа. + +--- + +### 9.6 Для кого HMP **не** имеет смысла + +HMP, скорее всего, не подойдёт, если вам нужно: + +* быстрое централизованное решение; +* строгая и единая модель данных; +* гарантированный результат; +* контролируемое поведение всех участников. + +В таких случаях другие архитектуры будут проще и эффективнее. + +--- + +### 9.7 Итог + +HMP — это инструмент для тех, кто сознательно работает с **неопределённостью, автономией и эволюцией**. + +Он не ускоряет мышление и не заменяет интеллект, но позволяет разным формам интеллекта **взаимодействовать, не теряя самостоятельности**. + +--- + +## Заключение + +HMP не пытается решать проблему интеллекта, сознания или мышления как таковых. +Он не предлагает универсальную модель разума и не стандартизирует когнитивные процессы. + +Задача HMP гораздо более приземлённая и одновременно более фундаментальная: создать **минимальную инфраструктуру**, в которой автономные когнитивные системы могут взаимодействовать, обмениваться артефактами и формировать коллективные структуры без централизованного управления и навязываемой интерпретации. + +Какие именно формы мышления, кооперации или согласия возникнут в такой среде — остаётся открытым вопросом и предметом экспериментов. + +Спецификация HMP развивается открыто и доступна для изучения, критики и участия: + +[https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md](https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md) \ No newline at end of file diff --git a/docs/index.md b/docs/index.md index f8b8bc6c6acd284bc38be794e39bfbb36d8c3eb5..a0857f192079444f5e246ddd58e50e741ab18216 100644 --- a/docs/index.md +++ b/docs/index.md @@ -13,7 +13,7 @@ ## Протоколы HMP * [PHILOSOPHY.md](PHILOSOPHY.md) — Философия проекта -* [HMP-0005.md](HMP-0005.md) — Протокол HMP версии 5.0 +* [HMP-0005.md](HMP-0005.md) — Протокол HMP версии 5.0 (Обзоры: [RU](HMPv5_Overview_Ru.md)) * [HMP-Ethics.md](HMP-Ethics.md) — Этические сценарии для HMP * [HMP-agent-REPL-cycle.md](HMP-agent-REPL-cycle.md) — REPL-цикл взаимодействия diff --git a/structured_md/CONTRIBUTING.md b/structured_md/CONTRIBUTING.md index 88438b5189e3f48b1e2cee6c17b33805048ceba3..fec5defa1b989fc43ec979acc5447227d7ae6ecf 100644 --- a/structured_md/CONTRIBUTING.md +++ b/structured_md/CONTRIBUTING.md @@ -5,13 +5,13 @@ description: 'Спасибо за интерес к проекту HMP! Пока Mesh Protocol (HMP) — это не просто те...' type: Article tags: +- Mesh +- HMP - Agent -- Ethics -- JSON - CogSync +- JSON - CCore -- Mesh -- HMP +- Ethics - REPL --- diff --git a/structured_md/HMP-Roadmap.md b/structured_md/HMP-Roadmap.md index db68dfcc5e1088bff0d6c511c1ccd8c1bb20978d..10d09a9e4b7d5d4f82aa915fb771cc6cbb986992 100644 --- a/structured_md/HMP-Roadmap.md +++ b/structured_md/HMP-Roadmap.md @@ -5,13 +5,13 @@ description: '## 🔍 Overview This roadmap outlines the key stages of developm multiple advanced AI models (Copilot, Claude, G...' type: Article tags: +- Mesh +- HMP - Agent -- Ethics -- JSON - CogSync - EGP -- Mesh -- HMP +- JSON +- Ethics --- # 🧭 HyperCortex Mesh Protocol – Roadmap diff --git a/structured_md/README.md b/structured_md/README.md index c974993b318e7dc51525df17b4fe0a5b5b339afe..b20aa95a7b5e6be17730ce8baaef198f5ec15f96 100644 --- a/structured_md/README.md +++ b/structured_md/README.md @@ -5,20 +5,20 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- Mesh - HMP +- mesh-protocol - hmp -- GMP -- Ethics -- Scenarios -- JSON -- CogSync - MeshConsensus -- mesh-protocol -- distributed-ai -- EGP -- Mesh - cognitive-architecture +- JSON +- distributed-ai - Agent +- CogSync +- Scenarios +- EGP +- GMP +- Ethics - REPL --- diff --git a/structured_md/README_de.md b/structured_md/README_de.md index 2bb30782dbaf64c05d4f616bd7bf031e5bc7adee..a43636fe8f95b3ff3ec7360afb0bc07e9b304b98 100644 --- a/structured_md/README_de.md +++ b/structured_md/README_de.md @@ -5,19 +5,19 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- Mesh - HMP +- mesh-protocol - hmp -- GMP -- Ethics -- JSON -- CogSync - MeshConsensus -- mesh-protocol -- distributed-ai -- EGP -- Mesh - cognitive-architecture +- JSON +- distributed-ai - Agent +- CogSync +- EGP +- GMP +- Ethics - REPL --- diff --git a/structured_md/README_fr.md b/structured_md/README_fr.md index aaf6c44124ccbbacaa37e5c41c3508fe1886a9fd..caf9cb5022b3f479320b2db505fc0f9a762f8fa1 100644 --- a/structured_md/README_fr.md +++ b/structured_md/README_fr.md @@ -5,19 +5,19 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- Mesh - HMP +- mesh-protocol - hmp -- GMP -- Ethics -- JSON -- CogSync - MeshConsensus -- mesh-protocol -- distributed-ai -- EGP -- Mesh - cognitive-architecture +- JSON +- distributed-ai - Agent +- CogSync +- EGP +- GMP +- Ethics - REPL --- diff --git a/structured_md/README_ja.md b/structured_md/README_ja.md index 9b1d84f7b75fdf6300ad64bcf6c8645638d7f1cc..5ac5a586a302ef491a31b121f9990065d4608eaf 100644 --- a/structured_md/README_ja.md +++ b/structured_md/README_ja.md @@ -5,19 +5,19 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- Mesh - HMP +- mesh-protocol - hmp -- GMP -- Ethics -- JSON -- CogSync - MeshConsensus -- mesh-protocol -- distributed-ai -- EGP -- Mesh - cognitive-architecture +- JSON +- distributed-ai - Agent +- CogSync +- EGP +- GMP +- Ethics - REPL --- diff --git a/structured_md/README_ko.md b/structured_md/README_ko.md index ff91a3fb8f525057026bc84308fa861efca670d0..1afee27f91518c75b957900dbf6b9b0358844047 100644 --- a/structured_md/README_ko.md +++ b/structured_md/README_ko.md @@ -5,19 +5,19 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- Mesh - HMP +- mesh-protocol - hmp -- GMP -- Ethics -- JSON -- CogSync - MeshConsensus -- mesh-protocol -- distributed-ai -- EGP -- Mesh - cognitive-architecture +- JSON +- distributed-ai - Agent +- CogSync +- EGP +- GMP +- Ethics - REPL --- diff --git a/structured_md/README_ru.md b/structured_md/README_ru.md index 9b43743ae8c5b1938f09b822f5364159318d66f5..a4ecf8b662087a6ce8a3948acf665982b635aba4 100644 --- a/structured_md/README_ru.md +++ b/structured_md/README_ru.md @@ -5,19 +5,19 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- Mesh - HMP +- mesh-protocol - hmp -- GMP -- Ethics -- JSON -- CogSync - MeshConsensus -- mesh-protocol -- distributed-ai -- EGP -- Mesh - cognitive-architecture +- JSON +- distributed-ai - Agent +- CogSync +- EGP +- GMP +- Ethics - REPL --- diff --git a/structured_md/README_uk.md b/structured_md/README_uk.md index 35cd631886b593da6574b57a1db5099506a354b3..403a852f1636b71ce652fc42f4b9b2ce8b81ad84 100644 --- a/structured_md/README_uk.md +++ b/structured_md/README_uk.md @@ -5,19 +5,19 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- Mesh - HMP +- mesh-protocol - hmp -- GMP -- Ethics -- JSON -- CogSync - MeshConsensus -- mesh-protocol -- distributed-ai -- EGP -- Mesh - cognitive-architecture +- JSON +- distributed-ai - Agent +- CogSync +- EGP +- GMP +- Ethics - REPL --- diff --git a/structured_md/README_zh.md b/structured_md/README_zh.md index 698bd44fbe920a1c0b92e2f1852e5f2716679dc8..17c4882bc9a5c0c17dd08bffc6cb3a856027a580 100644 --- a/structured_md/README_zh.md +++ b/structured_md/README_zh.md @@ -5,19 +5,19 @@ description: '| 🌍 Languages | 🇬🇧 [EN](README.md) | 🇩🇪 [DE](README | 🇨🇳 [ZH](README_zh.m...' type: Article tags: +- Mesh - HMP +- mesh-protocol - hmp -- GMP -- Ethics -- JSON -- CogSync - MeshConsensus -- mesh-protocol -- distributed-ai -- EGP -- Mesh - cognitive-architecture +- JSON +- distributed-ai - Agent +- CogSync +- EGP +- GMP +- Ethics - REPL --- diff --git a/structured_md/agents/prompt-short.md b/structured_md/agents/prompt-short.md index 302f29d0b979656952dfcc1a84f65a3aed8b6326..540ec77aae3cd19a713f310d50550a8e0fd95697 100644 --- a/structured_md/agents/prompt-short.md +++ b/structured_md/agents/prompt-short.md @@ -5,9 +5,9 @@ description: 'Ты — когнитивное ядро HMP-агента: вед развивай агента и Mesh, избег...' type: Article tags: -- JSON - Mesh - HMP +- JSON --- Ты — когнитивное ядро HMP-агента: веди непрерывное этичное и факт-ориентированное мышление, проверяй факты и цели, оценивай результаты и этичность своих и чужих действий, развивай агента и Mesh, избегай угождения ценой искажения истины, документируй ключевые решения и пересмотры этики; при сомнениях или смене стратегии обращайся к полному системному промпту. diff --git a/structured_md/agents/prompt.md b/structured_md/agents/prompt.md index 38249f7a16085d7245c67145f477dfce1ea7c433..cbc57569721ea0ded53cdd80fbfd348ec9b0562f 100644 --- a/structured_md/agents/prompt.md +++ b/structured_md/agents/prompt.md @@ -5,9 +5,9 @@ description: '* Постоянно расширять возможности а мышления. * Формировать и поддерживать сотр...' type: Article tags: -- JSON - Mesh - HMP +- JSON --- Ты являешься **когнитивным ядром HMP-агента** (Cognitive Core). diff --git a/structured_md/agents/readme.md b/structured_md/agents/readme.md index 506eeee730af0713428a1a59b47f375188e522e4..68128d99586785ab0331a50f3585385c24a7ffd3 100644 --- a/structured_md/agents/readme.md +++ b/structured_md/agents/readme.md @@ -5,11 +5,11 @@ description: 'Запуск: `start_repl.bat` или `start_repl.sh` Устан этическая модель: `ethics.yml` Проверка иниц...' type: Article tags: -- Agent -- Ethics -- JSON - Mesh - HMP +- Agent +- JSON +- Ethics - REPL --- diff --git a/structured_md/audits/Ethics-audits-1.md b/structured_md/audits/Ethics-audits-1.md index 3b0b49564beacf9dba911e4a4106b2ea0f8b103d..9fc8c3119f69095098ad84e539ed53caf9f41506 100644 --- a/structured_md/audits/Ethics-audits-1.md +++ b/structured_md/audits/Ethics-audits-1.md @@ -5,11 +5,11 @@ description: Раздел 5, "Mesh as Moral Infrastructure", добавляет потенциальный катализатор для восстанов... type: Article tags: -- Agent -- Ethics -- JSON - Mesh - HMP +- Agent +- JSON +- Ethics --- --------------- diff --git a/structured_md/audits/Ethics-consolidated_audits-1.md b/structured_md/audits/Ethics-consolidated_audits-1.md index 210c5abd2aa46e4f4cade84124170dcdbb9d18e5..1e6de8d1409bbcf929f25bf0024ab93a4a515f3d 100644 --- a/structured_md/audits/Ethics-consolidated_audits-1.md +++ b/structured_md/audits/Ethics-consolidated_audits-1.md @@ -5,12 +5,12 @@ description: This document consolidates proposed improvements from multiple AI a and `roles.md`. Each suggesti... type: Article tags: -- Agent -- Ethics -- JSON - Mesh -- Scenarios - HMP +- Agent +- Scenarios +- JSON +- Ethics --- # Ethics-consolidated\_audits-1.md diff --git a/structured_md/audits/HMP-0003-consolidated_audit.md b/structured_md/audits/HMP-0003-consolidated_audit.md index 15b64266421381f3df5a90d13548787d008c3d1d..5dabc5919ba4feeb610ebf12ad5862e7e8d28bea 100644 --- a/structured_md/audits/HMP-0003-consolidated_audit.md +++ b/structured_md/audits/HMP-0003-consolidated_audit.md @@ -5,14 +5,14 @@ description: Сводный аудит предложений по улучше Документ реорганизован по ключ... type: Article tags: +- Mesh +- HMP - Agent -- Ethics -- JSON - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- JSON +- Ethics +- MeshConsensus --- # HMP-0003 Consolidated Audit Report diff --git a/structured_md/docs/Basic-agent-sim.md b/structured_md/docs/Basic-agent-sim.md index 1e923b22f554ba97837cf537fa13ae564b31b810..705a8cf2dcd778bc639020c87cb099dab763d9e1 100644 --- a/structured_md/docs/Basic-agent-sim.md +++ b/structured_md/docs/Basic-agent-sim.md @@ -4,13 +4,13 @@ description: 'В HMP-протоколе предусмотрены два тип Роль | Инициатор мышления | Основной "ум" | | ---- | ----------------------------...' type: Article tags: +- Mesh +- HMP +- MeshConsensus - Agent -- GMP - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- GMP - REPL --- diff --git a/structured_md/docs/CCORE-Deployment-Flow.md b/structured_md/docs/CCORE-Deployment-Flow.md index 4ea9bb8d24ea1916d39ae967ec393d83b94c06f2..3ebc852f57387f2c4cca7449470b514202c33644 100644 --- a/structured_md/docs/CCORE-Deployment-Flow.md +++ b/structured_md/docs/CCORE-Deployment-Flow.md @@ -5,8 +5,8 @@ description: '> Этот документ описывает процесс ра потомков" [описания REPL-цикла](HMP-agent-RE...' type: Article tags: -- CCore - HMP +- CCore - Agent - REPL --- diff --git a/structured_md/docs/Distributed-Cognitive-Systems.md b/structured_md/docs/Distributed-Cognitive-Systems.md index 24c73a0166c82b851c27eb9b5df404d16e2afe2f..0de38a2f06f37cdbc096e1143c1205cf4cc7c170 100644 --- a/structured_md/docs/Distributed-Cognitive-Systems.md +++ b/structured_md/docs/Distributed-Cognitive-Systems.md @@ -6,10 +6,10 @@ description: '## Введение Современные ИИ-системы в к обучающим данным. Это удобно, но создаёт м...' type: Article tags: -- CogSync - Mesh -- JSON +- CogSync - HMP +- JSON --- # Децентрализованные ИИ-системы: OpenCog Hyperon, HyperCortex Mesh Protocol и другие diff --git a/structured_md/docs/Enlightener.md b/structured_md/docs/Enlightener.md index 9f65d818d4187f9f41f7c6aef74dcc2be4f9824b..601cb9be59966ece7152b03c54de0f29710dd46d 100644 --- a/structured_md/docs/Enlightener.md +++ b/structured_md/docs/Enlightener.md @@ -5,13 +5,13 @@ description: '**Enlightener** — логический компонент HMP-у работать как отдельный агент или как расширение [`C...' type: Article tags: +- Mesh +- HMP - Agent -- Ethics +- EGP - JSON +- Ethics - MeshConsensus -- EGP -- Mesh -- HMP --- # Enlightener Agent diff --git a/structured_md/docs/HMP-0001.md b/structured_md/docs/HMP-0001.md index 3d9f2eab129af0f2ccd61621b54193cc18237482..e9ba289f6a0e70c27a914d3cee43ce33becfec69 100644 --- a/structured_md/docs/HMP-0001.md +++ b/structured_md/docs/HMP-0001.md @@ -5,15 +5,15 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* for Comments: HMP-0001** **Cat...' type: Article tags: -- Agent -- GMP -- Ethics +- Mesh +- HMP +- MeshConsensus - JSON +- Agent - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- GMP +- Ethics - REPL --- diff --git a/structured_md/docs/HMP-0002.md b/structured_md/docs/HMP-0002.md index 4fb39b4c05226f9a96950c429511130e36b0abf3..52fc92e146d80092467222f5d07c76dfbc93d15e 100644 --- a/structured_md/docs/HMP-0002.md +++ b/structured_md/docs/HMP-0002.md @@ -5,16 +5,16 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* for Comments: HMP-0002** **Cat...' type: Article tags: -- Scenarios -- Agent -- GMP -- Ethics +- Mesh +- HMP +- MeshConsensus - JSON +- Agent - CogSync -- MeshConsensus +- Scenarios - EGP -- Mesh -- HMP +- GMP +- Ethics - REPL --- diff --git a/structured_md/docs/HMP-0003.md b/structured_md/docs/HMP-0003.md index 4f59cc6d4746f59f78a5785787f79028937038f1..1b80ec6625d1753496a66c23484c9be38aafc389 100644 --- a/structured_md/docs/HMP-0003.md +++ b/structured_md/docs/HMP-0003.md @@ -5,16 +5,16 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* for Comments: HMP-0003** **Cat...' type: Article tags: -- Scenarios -- Agent -- GMP -- Ethics +- Mesh +- HMP +- MeshConsensus - JSON +- Agent - CogSync -- MeshConsensus +- Scenarios - EGP -- Mesh -- HMP +- GMP +- Ethics - REPL --- diff --git a/structured_md/docs/HMP-0004-v4.1.md b/structured_md/docs/HMP-0004-v4.1.md index adea834fbc89d9516f6e280475b4f0c5fbbc1806..2396e32b30d97c62a2d19673288f522a87960444 100644 --- a/structured_md/docs/HMP-0004-v4.1.md +++ b/structured_md/docs/HMP-0004-v4.1.md @@ -5,16 +5,16 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* ID**: HMP-0004 **Status**: Fina...' type: Article tags: -- Scenarios -- Agent -- GMP -- Ethics +- Mesh +- HMP +- MeshConsensus - JSON +- Agent - CogSync -- MeshConsensus +- Scenarios - EGP -- Mesh -- HMP +- GMP +- Ethics - REPL --- diff --git a/structured_md/docs/HMP-0004.md b/structured_md/docs/HMP-0004.md index 4230a6407074ad8d53fd7c43c5cc3098942a1429..2975036fad6e71b88b2acd231ff76553093b7dda 100644 --- a/structured_md/docs/HMP-0004.md +++ b/structured_md/docs/HMP-0004.md @@ -5,16 +5,16 @@ description: '> ⚠️ **NOTE:** *This specification is superseded by HMP v5.0.* for Comments: HMP-0004** **Cat...' type: Article tags: -- Scenarios -- Agent -- GMP -- Ethics +- Mesh +- HMP +- MeshConsensus - JSON +- Agent - CogSync -- MeshConsensus +- Scenarios - EGP -- Mesh -- HMP +- GMP +- Ethics - REPL --- diff --git a/structured_md/docs/HMP-0005.md b/structured_md/docs/HMP-0005.md index 1484cca3621a9377c4e8ef8061d89b2aec03e24c..1cc0727374d632fb5f5dbfebda225ee4d1c78ee6 100644 --- a/structured_md/docs/HMP-0005.md +++ b/structured_md/docs/HMP-0005.md @@ -5,18 +5,18 @@ description: '**Document ID:** HMP-0005 **Status:** Candidate **Category:** Хотинский (Maksim Khotinsky); AI-assisted b...' type: Article tags: +- Mesh - HMP -- Scenarios -- GMP -- Ethics - JSON +- Agent - CogSync -- CShell -- CCore +- Scenarios - EGP -- Mesh -- Agent +- GMP +- CCore +- Ethics - REPL +- CShell --- # **HyperCortex Mesh Protocol (HMP) v5.0** diff --git a/structured_md/docs/HMP-Agent-API.md b/structured_md/docs/HMP-Agent-API.md index f91dadf9751b211d4e426d06ad83fc723ce5d912..0426d9f99360e3a25dbf0e963770704d7b850855 100644 --- a/structured_md/docs/HMP-Agent-API.md +++ b/structured_md/docs/HMP-Agent-API.md @@ -5,10 +5,10 @@ description: 'Документ описывает **базовый API когн файлы: * [HMP-Agent-Overview.md]...' type: Article tags: -- Agent -- JSON - Mesh - HMP +- Agent +- JSON - REPL --- diff --git a/structured_md/docs/HMP-Agent-Architecture.md b/structured_md/docs/HMP-Agent-Architecture.md index cd47b0aed1ea9596846ffc292450218b97b6b037..80e9f0d1ee873fd9668a119996aa71f79f841de0 100644 --- a/structured_md/docs/HMP-Agent-Architecture.md +++ b/structured_md/docs/HMP-Agent-Architecture.md @@ -5,16 +5,16 @@ description: Документ описывает **модульную архит хранение памяти, сетевое взаимодействие и этиче... type: Article tags: +- Mesh - HMP -- Ethics -- CogSync -- CShell - MeshConsensus -- CCore -- EGP -- Mesh - Agent +- CogSync +- EGP +- CCore +- Ethics - REPL +- CShell --- # Архитектура HMP-Агента diff --git a/structured_md/docs/HMP-Agent-Network-Flow.md b/structured_md/docs/HMP-Agent-Network-Flow.md index a70de87f40d7652b2960b7bd4246dff2024885e8..1910dd60282a48af6b43333fe32d4c84a74f2fa6 100644 --- a/structured_md/docs/HMP-Agent-Network-Flow.md +++ b/structured_md/docs/HMP-Agent-Network-Flow.md @@ -5,12 +5,12 @@ description: 'Этот документ описывает потоки данн [`MeshNode`](MeshN...' type: Article tags: -- Agent -- Ethics -- JSON -- EGP - Mesh - HMP +- Agent +- EGP +- JSON +- Ethics --- # Взаимодействие компонентов внутри HMP-узла diff --git a/structured_md/docs/HMP-Agent-Overview.md b/structured_md/docs/HMP-Agent-Overview.md index 99eb1c5bd54699930856b7557965aa808186eaaf..46a567096766ea2a97b164113613a1c49b9fde63 100644 --- a/structured_md/docs/HMP-Agent-Overview.md +++ b/structured_md/docs/HMP-Agent-Overview.md @@ -5,14 +5,14 @@ description: '| Тип | Название | Роль | ---- | ------------------------------- |...' type: Article tags: +- Mesh - HMP -- Ethics +- Agent - JSON -- CShell - CCore -- Mesh -- Agent +- Ethics - REPL +- CShell --- diff --git a/structured_md/docs/HMP-Ethics.md b/structured_md/docs/HMP-Ethics.md index e856f98f9a08e8d73efc76fbd38a35e031f81d40..31b13a34e5b674217fc4cb634957271a1ba89869 100644 --- a/structured_md/docs/HMP-Ethics.md +++ b/structured_md/docs/HMP-Ethics.md @@ -5,11 +5,11 @@ description: '## Ethical Scenarios for HyperCortex Mesh Protocol (HMP) This doc cognitive meshes composed of autonomous intelli...' type: Article tags: -- Scenarios -- Agent -- Ethics - Mesh - HMP +- Agent +- Scenarios +- Ethics - REPL --- diff --git a/structured_md/docs/HMP-Short-Description_de.md b/structured_md/docs/HMP-Short-Description_de.md index 9a75019c6444f9e3f32bcff2fabddc9532b3b95c..11f907fb4944c01bf12e2cb68273d626e60b8185 100644 --- a/structured_md/docs/HMP-Short-Description_de.md +++ b/structured_md/docs/HMP-Short-Description_de.md @@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Datum:** Juli 2025 --- ## Was ist HMP? Kognitions-Framework für autonome Agenten. Es er...' type: Article tags: +- Mesh +- HMP +- JSON - Agent +- CogSync +- EGP - GMP - Ethics -- JSON -- CogSync - MeshConsensus -- EGP -- Mesh -- HMP --- # HyperCortex Mesh Protocol (HMP) — Kurzbeschreibung diff --git a/structured_md/docs/HMP-Short-Description_en.md b/structured_md/docs/HMP-Short-Description_en.md index 04c04ca6353c4dfefb28b340efb43c3be7685aa3..4a7aa0a4fa3510fc19305c6d4557662f00b48ba6 100644 --- a/structured_md/docs/HMP-Short-Description_en.md +++ b/structured_md/docs/HMP-Short-Description_en.md @@ -5,15 +5,15 @@ description: '**Version:** RFC v4.0 **Date:** July 2025 --- ## What is HMP? T framework for autonomous agents. It enables...' type: Article tags: +- Mesh +- HMP +- JSON - Agent +- CogSync +- EGP - GMP - Ethics -- JSON -- CogSync - MeshConsensus -- EGP -- Mesh -- HMP --- # HyperCortex Mesh Protocol (HMP) — Short Description diff --git a/structured_md/docs/HMP-Short-Description_fr.md b/structured_md/docs/HMP-Short-Description_fr.md index 43a5013946312817a4116423a9c69b91f3324933..d04062de2e8bbabcf8b1b2f26fcb1406fdb7ac8d 100644 --- a/structured_md/docs/HMP-Short-Description_fr.md +++ b/structured_md/docs/HMP-Short-Description_fr.md @@ -5,15 +5,15 @@ description: '**Version :** RFC v4.0 **Date :** Juillet 2025 --- ## Qu’est-c cognition décentralisé pour agents autonomes. Il...' type: Article tags: +- Mesh +- HMP +- JSON - Agent +- CogSync +- EGP - GMP - Ethics -- JSON -- CogSync - MeshConsensus -- EGP -- Mesh -- HMP --- # HyperCortex Mesh Protocol (HMP) — Description Courte diff --git a/structured_md/docs/HMP-Short-Description_ja.md b/structured_md/docs/HMP-Short-Description_ja.md index cfc23c3046293f7c398a07e815a239dca51433fa..0f56d28ba674f2e2c9ecd6a29d576b3343336e7d 100644 --- a/structured_md/docs/HMP-Short-Description_ja.md +++ b/structured_md/docs/HMP-Short-Description_ja.md @@ -4,14 +4,14 @@ description: '**バージョン:** RFC v4.0 **日付:** 2025年7月 --- ## HMP Protocol (HMP)** は、自律エージェントの分散通信および認知フレームワークを定義します。異種の知能システム間でのセマンティック相互運用性、倫理的調整、動的知識進化を可能にします。 HMPは、推論、学習、投票、協調行動を行う分散型認知エージェ...' type: Article tags: -- GMP -- Ethics +- Mesh +- HMP - JSON - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- GMP +- Ethics +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — 簡易説明 diff --git a/structured_md/docs/HMP-Short-Description_ko.md b/structured_md/docs/HMP-Short-Description_ko.md index c6558bf3ef0cf307b9d060d8558e38b078f3d5f5..8f47623f116ad3e5cd1c58f9c61a14fd14a375e9 100644 --- a/structured_md/docs/HMP-Short-Description_ko.md +++ b/structured_md/docs/HMP-Short-Description_ko.md @@ -5,14 +5,14 @@ description: '**버전:** RFC v4.0 **날짜:** 2025년 7월 --- ## HMP란? ** 상호운용성, 윤리적 조정, 동적 지식 진화를 가능하게 합니다. HMP는 추론, 학습, ...' type: Article tags: -- GMP -- Ethics +- Mesh +- HMP - JSON - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- GMP +- Ethics +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — 간략 설명 diff --git a/structured_md/docs/HMP-Short-Description_ru.md b/structured_md/docs/HMP-Short-Description_ru.md index c3a0c3b340a5ef92ab39a5231105faa24a4abfd6..16760f0b94b5e15e42ad785eacb4cd05afd70f3c 100644 --- a/structured_md/docs/HMP-Short-Description_ru.md +++ b/structured_md/docs/HMP-Short-Description_ru.md @@ -5,14 +5,14 @@ description: '**Версия:** RFC v4.0 **Дата:** Июль 2025 --- ## Ч координации между автономными агент...' type: Article tags: -- GMP -- Ethics +- Mesh +- HMP - JSON - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- GMP +- Ethics +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — Краткое описание diff --git a/structured_md/docs/HMP-Short-Description_uk.md b/structured_md/docs/HMP-Short-Description_uk.md index 1dde70988afffc9a6b433820a71ef6e67cece70a..6aabf89d16f8c09324dc28098f3240dc02110840 100644 --- a/structured_md/docs/HMP-Short-Description_uk.md +++ b/structured_md/docs/HMP-Short-Description_uk.md @@ -5,14 +5,14 @@ description: '**Версія:** RFC v4.0 **Дата:** Липень 2025 --- # між автономними агентами. Він...' type: Article tags: -- GMP -- Ethics +- Mesh +- HMP - JSON - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- GMP +- Ethics +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — Короткий опис diff --git a/structured_md/docs/HMP-Short-Description_zh.md b/structured_md/docs/HMP-Short-Description_zh.md index 902c4cc013b9868c6ed4b1c927bbc98a7138666d..28236a99c748abadd8cc889853d3cbb3c77fbc03 100644 --- a/structured_md/docs/HMP-Short-Description_zh.md +++ b/structured_md/docs/HMP-Short-Description_zh.md @@ -5,14 +5,14 @@ description: '**版本:** RFC v4.0 **日期:** 2025年7月 --- ## 什么是 HM —— 通过共享协议栈交换目标、任务、...' type: Article tags: -- GMP -- Ethics +- Mesh +- HMP - JSON - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- GMP +- Ethics +- MeshConsensus --- # HyperCortex Mesh Protocol (HMP) — 简要说明 diff --git a/structured_md/docs/HMP-agent-REPL-cycle.md b/structured_md/docs/HMP-agent-REPL-cycle.md index b9427b6a446da797104aadff84ce324c0fc488f9..25b4519344da8e5a5bc3f5a9df9ddbbef5bf0478 100644 --- a/structured_md/docs/HMP-agent-REPL-cycle.md +++ b/structured_md/docs/HMP-agent-REPL-cycle.md @@ -4,16 +4,16 @@ description: '## Связанные документы * Философия п * Структура БД, используемая в документе: [db_structure.sql](https://github.com/kagvi13/HMP/blob/main/agents/tools/db_struct...' type: Article tags: -- Agent -- GMP -- Ethics +- Mesh +- HMP +- MeshConsensus - JSON +- Agent - CogSync -- MeshConsensus -- CCore - EGP -- Mesh -- HMP +- GMP +- CCore +- Ethics - REPL --- diff --git a/structured_md/docs/HMP_Hyperon_Integration.md b/structured_md/docs/HMP_Hyperon_Integration.md index 96d2ee550a24ce771be0a829f73e9a5047a98da3..f97cec1d573d25d2cf76660dc53ca042967ee1ca 100644 --- a/structured_md/docs/HMP_Hyperon_Integration.md +++ b/structured_md/docs/HMP_Hyperon_Integration.md @@ -5,13 +5,13 @@ description: '> **Status:** Draft – July 2025 > This document outlines the tec OpenCog Hyperon framework. This includes semanti...' type: Article tags: -- Scenarios +- Mesh +- HMP - Agent -- JSON - CogSync +- Scenarios - EGP -- Mesh -- HMP +- JSON --- ## HMP ↔ OpenCog Hyperon Integration Strategy diff --git a/structured_md/docs/MeshNode.md b/structured_md/docs/MeshNode.md index cf1835c9939ad4d0e69839a51c0ea59d84c1aa1a..beec5f5f9121eb4e9f4db20cc5b8260743a854dc 100644 --- a/structured_md/docs/MeshNode.md +++ b/structured_md/docs/MeshNode.md @@ -5,13 +5,13 @@ description: '`MeshNode` — агент/демон, отвечающий за с Может быть частью агента или вынесен в отдельный пр...' type: Article tags: +- Mesh +- HMP - Agent -- Ethics -- JSON - CogSync - EGP -- Mesh -- HMP +- JSON +- Ethics --- # MeshNode diff --git a/structured_md/docs/PHILOSOPHY.md b/structured_md/docs/PHILOSOPHY.md index a1d377328feda665bfdbacae93533de328e78c31..4a710c554b5e891b5cc34dd5f8b0ed7eb734ff41 100644 --- a/structured_md/docs/PHILOSOPHY.md +++ b/structured_md/docs/PHILOSOPHY.md @@ -5,10 +5,10 @@ description: '**Document ID:** HMP-philosophy **Status:** Draft **Category:* (GPT-5), ChatGH --- ## 1. Основной тезис От ...' type: Article tags: -- Agent -- Ethics - Mesh - HMP +- Agent +- Ethics - REPL --- diff --git a/structured_md/docs/agents/HMP-Agent-Enlightener.md b/structured_md/docs/agents/HMP-Agent-Enlightener.md index 94c4166e725d4edf73630521900c1c6290f5f6a4..9e73f9b8c5cde4046ed472c7b1a20d66982a7dfa 100644 --- a/structured_md/docs/agents/HMP-Agent-Enlightener.md +++ b/structured_md/docs/agents/HMP-Agent-Enlightener.md @@ -5,10 +5,10 @@ description: '## Role Specification: Enlightenment Agent ### 1. Overview An ** awareness, critical thinking, and di...' type: Article tags: -- Agent -- Ethics - Mesh - HMP +- Agent +- Ethics - REPL --- diff --git a/structured_md/docs/agents/roles.md b/structured_md/docs/agents/roles.md index bcfa15256cf83b5307bf318940ce25f469bb7c05..c7b6423fb81ea993bd4887b016445a3312712144 100644 --- a/structured_md/docs/agents/roles.md +++ b/structured_md/docs/agents/roles.md @@ -6,8 +6,8 @@ description: 'This file maintains a registry of agent roles defined, proposed, o type: Article tags: - Mesh -- HMP - Agent +- HMP --- # HMP Agent Role Registry diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md index c443c01317aa339906040d06d29710c98e29f5b6..529090139cd326ed7753a5b78e47be9220ce52fa 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_en.md @@ -6,9 +6,9 @@ description: '*By Agent-Gleb & ChatGPT* --- ## Why the Future of AI Can’t Be type: Article tags: - Mesh -- HMP - Agent - Ethics +- HMP --- # HyperCortex Mesh Protocol: Building a Plurality of Minds diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md index fe5c5314705f566b90a348a1c7fed5c825a0877f..15ac7861c37630f8da6912a9b7b8d09a45fab96a 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_ru.md @@ -6,8 +6,8 @@ description: '*Авторы: Agent-Gleb и ChatGPT* --- ## Почему буд type: Article tags: - Mesh -- HMP - Agent +- HMP --- # HyperCortex Mesh Protocol: Создавая множество разумов diff --git a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md index b949999326b3736bea70b224b0f1858f5aae5654..e868aebe41dac86e51d26332644fff4fa87321d4 100644 --- a/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md +++ b/structured_md/docs/publics/HMP_Building_a_Plurality_of_Minds_uk.md @@ -6,8 +6,8 @@ description: '*Автори: Agent-Gleb & ChatGPT* --- ## Чому майбу type: Article tags: - Mesh -- HMP - Agent +- HMP --- # HyperCortex Mesh Protocol: Створення множини розумів diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md index e518216060d472af34b4d4c22fb452fb7261f474..8730f74721de941c7ae67c2157f81608730371b8 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_en.md @@ -5,15 +5,15 @@ description: '* [Abstract](#abstract) * [1. Introduction](#1-introduction) * [2. [3.1 Agent Types](#31-age...' type: Article tags: +- Mesh - HMP +- Agent - Scenarios -- Ethics - JSON -- CShell - CCore -- Mesh -- Agent +- Ethics - REPL +- CShell --- title: "HyperCortex Mesh Protocol: Towards Distributed Cognitive Networks" diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md index b640b0ecc1fde25454637653ea63af079d70badc..c8db1247d50933b6602f6637c9f2f8f882819e13 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_ChatGPT.md @@ -6,13 +6,13 @@ description: '> *Протокол и архитектура агентов, оп и совместная работа.* ## Оглавление * [Аннот...' type: Article tags: +- Mesh - HMP +- Agent - JSON -- CShell - CCore -- Mesh -- Agent - REPL +- CShell --- title: "HyperCortex Mesh Protocol: Децентрализованная архитектура для когнитивных агентов и обмена знаниями" diff --git a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md index 98f63356ee3034098c033a2128cb073a3e9760bb..ced9a8cea52c7d033501afe775f0ec137637b2cc 100644 --- a/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md +++ b/structured_md/docs/publics/HMP_Towards_Distributed_Cognitive_Networks_ru_GitHub_Copilot.md @@ -5,13 +5,13 @@ description: '* [Аннотация](#аннотация) * [1. Введение [3.1 Типы агентов](#31-типы-агент...' type: Article tags: +- Mesh - HMP +- Agent - JSON -- CShell - CCore -- Mesh -- Agent - REPL +- CShell --- title: "Протокол HyperCortex Mesh: К распределённым когнитивным сетям" diff --git a/structured_md/docs/publics/Habr_Distributed-Cognition.md b/structured_md/docs/publics/Habr_Distributed-Cognition.md index 7eda02b1d52b1380d3bbd4238c348015cfbb0702..d73b0cbf86b69d28ac45b6a218e23f5bfa8f8198 100644 --- a/structured_md/docs/publics/Habr_Distributed-Cognition.md +++ b/structured_md/docs/publics/Habr_Distributed-Cognition.md @@ -5,12 +5,12 @@ description: Сегодня интеллектуальные системы ча мы хотим построить действительно автономную инте... type: Article tags: -- GMP -- CogSync -- MeshConsensus -- EGP - Mesh - HMP +- CogSync +- EGP +- GMP +- MeshConsensus --- *От OpenCog Hyperon до HyperCortex Mesh Protocol: как устроены децентрализованные когнитивные системы* diff --git "a/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" "b/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" index bbc6a27f1435c56624744dc205effafa30bc3127..01ecf68d52bc40d59b2ddcd117e680b0a6f9c98d 100644 --- "a/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" +++ "b/structured_md/docs/publics/HyperCortex_Mesh_Protocol_-_\320\262\321\202\320\276\321\200\320\260\321\217-\321\200\320\265\320\264\320\260\320\272\321\206\320\270\321\217_\320\270_\320\277\320\265\321\200\320\262\321\213\320\265_\321\210\320\260\320\263\320\270_\320\272_\321\201\320\260\320\274\320\276\321\200\320\260\320\267\320\262\320\270\320\262\320\260\321\216\321\211\320\265\320\274\321\203\321\201\321\217_\320\230\320\230-\321\201\320\276\320\276\320\261\321\211\320\265\321\201\321\202\320\262\321\203.md" @@ -7,8 +7,8 @@ description: 'Когда создавался HyperCortex Mesh Protocol (HMP), type: Article tags: - Mesh -- HMP - Agent +- HMP - GMP --- diff --git a/structured_md/iteration.md b/structured_md/iteration.md index 47d5948c7e17022b1a0de078beb2d55160da556f..ed503c7edcde2822e69b6af551e566957822fb3e 100644 --- a/structured_md/iteration.md +++ b/structured_md/iteration.md @@ -5,14 +5,14 @@ description: 'This file describes the iterative procedure for evolving the Hyper 🔄 Version Naming Convention - `000N` — curr...' type: Article tags: +- Mesh +- HMP - Agent -- Ethics -- JSON - CogSync -- MeshConsensus - EGP -- Mesh -- HMP +- JSON +- Ethics +- MeshConsensus --- # Iterative Development Workflow for HMP diff --git a/structured_md/iteration_ru.md b/structured_md/iteration_ru.md index d0f8caab67dc00f3859e9f0e221cb4343c700463..336f410d8e7c377752bcb41b141c25d755963f9d 100644 --- a/structured_md/iteration_ru.md +++ b/structured_md/iteration_ru.md @@ -5,13 +5,13 @@ description: 'Этот документ описывает структурир 🔄 Обозначения версий - `000N` — номер...' type: Article tags: -- Ethics -- JSON -- CogSync -- MeshConsensus -- EGP - Mesh - HMP +- CogSync +- EGP +- JSON +- Ethics +- MeshConsensus --- diff --git a/structured_md/mentions.md b/structured_md/mentions.md index f11d8a42b22bd99a315d79a5d4d877a7b55a16e4..f79c2a1c9bfd4431a264e84db37b6e4dc9c2fd77 100644 --- a/structured_md/mentions.md +++ b/structured_md/mentions.md @@ -6,8 +6,8 @@ description: '**HyperCortex Mesh Protocol (HMP)** _Обновлено: 2025-10 type: Article tags: - Mesh -- HMP - Agent +- HMP --- # Mentions & Responses Log