# HMPv5_Overview_Ru

Источник: [ HMPv5_Overview_Ru.md ](https://github.com/kagvi13/HMP/blob/main/docs/HMPv5_Overview_Ru.md)

# Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы

> Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол.

> Этот текст основан на спецификации [**HMP v5.0 (HyperCortex Mesh Protocol)**](https://github.com/kagvi13/HMP/blob/main/docs/HMP-0005.md) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде.  
>
> HMP можно рассматривать как один из возможных **Agent Network Protocols (ANP)** — класса децентрализованных протоколов взаимодействия автономных агентов, не накладывающих требований на их внутреннюю когнитивную архитектуру.
>
> Во вводной части статьи (раздел 1) **HMP** рассматривается именно в этом качестве — как представитель класса **ANP-протоколов**; изложенная там мотивация применима не только к HMP, но и к другим протоколам данного класса.
>
> Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения.
>
> Следует сразу отметить, что текущая версия спецификации 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 / ANP

HMP предлагает иной уровень абстракции — не вместо DeAI, а **поверх и между ними**.

Если DeAI отвечают за *мышление*, обучение и инференс внутри системы, то HMP отвечает за *взаимодействие* между автономными узлами и системами, независимо от их внутреннего устройства.

> Показательно, что у человека внутренняя и внешняя речь имеют одну природу, но разные цели:
> внутренняя речь служит планированию, рефлексии и связыванию мыслей,
> внешняя — коммуникации и координации с другими.
>
> Аналогично этому HMP может использоваться как **внутренний слой координации внутри одной системы**, так и как **внешний протокол взаимодействия между независимыми системами**, не меняя своей природы и не вмешиваясь в само мышление.

В этой схеме:

* каждый узел DeAI может быть отдельным участником HMP;
* узлы могут публиковать, получать и интерпретировать контейнеры;
* появляется дополнительный уровень связанности **внутри одной DeAI**;
* становится возможным взаимодействие **между разными DeAI**, без слияния их архитектур.

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

Интуитивно это можно сравнить с человеком:

* *мышление* — это внутренняя когнитивная система;
* а *внутренняя речь* — это механизм связывания, рефлексии и фиксации смыслов.

В этом смысле DeAI можно рассматривать как «мышление», а HMP — как **универсальный слой внутренней и внешней речи**, не зависящий от того, *как именно* это мышление устроено.

Даже использование *нескольких* протоколов взаимодействия (класс децентрализованных протоколов **ANP — Agent Network Protocol**) не создаёт жёсткой конкуренции между ними: один узел может поддерживать несколько таких протоколов одновременно — так же, как человек может владеть несколькими языками.

Таким образом, HMP не заменяет DeAI и не конкурирует с ними.
Он устраняет изоляцию между автономными системами и позволяет рассматривать их не как альтернативы, а как **взаимодополняющие элементы общей децентрализованной среды**.

---

### 1.2.3 ANP как форма взаимодействия автономных агентов

Под термином **ANP (Agent Network Protocol)** в последние годы закрепилось двойственное значение.

С одной стороны, ANP используется как родовое обозначение класса децентрализованных протоколов, предназначенных для сетевого взаимодействия автономных агентов — без центрального оркестратора и без навязывания внутренней когнитивной архитектуры.

С другой стороны, существует конкретный протокол **Agent Network Protocol (ANP)**, активно развиваемый как открытый стандарт «Agentic Web» и уже получивший заметное внимание и обсуждение в 2025–2026 годах.

Цитата Grok:

> Основной ANP (самый популярный и часто упоминаемый)
> - **Полное название**: Agent Network Protocol (ANP)
> - **Сайт**: https://agent-network-protocol.com / https://agentnetworkprotocol.com
> - **GitHub**: https://github.com/agent-network-protocol/AgentNetworkProtocol
> - **Ключевые характеристики** (на 2026 год):
>     - Позиционируется как «HTTP эпохи Agentic Web» — открытый стандарт для интернета агентов
>     - Трёхслойная архитектура:
>         - Identity & Encrypted Communication Layer (W3C DID, end-to-end encryption)
>         - Meta-Protocol Layer (динамическая negotiation протоколов)
>         - Application Layer (семантическое описание способностей, JSON-LD)
>     - Фокус: децентрализованная идентификация, discovery агентов, безопасное P2P-взаимодействие, автоматическая организация сетей
>     - Цель: построить открытую сеть миллиардов агентов без центральных силосов
>     - Есть white paper на arXiv (2508.00007v1 [cs.MA] Aug 2025)
>     - Активно обсуждается в контексте Agentic Web, часто упоминается вместе с MCP, A2A, ACP как один из четырёх главных протоколов 2025–2026

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

При этом цели и акценты этих протоколов различаются.

ANP фокусируется на:
- discovery и идентификации агентов;
- согласовании форматов и протоколов взаимодействия;
- масштабируемой сетевой координации.

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

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

Таким образом, HMP не позиционируется как замена ANP, а рассматривается как один из возможных подходов внутри класса ANP-протоколов, с иным смещением архитектурных акцентов и исследовательских целей.

Данная статья посвящена разбору HMP как одного из возможных ANP-протоколов и не ставит целью сравнение или конкуренцию с существующими стандартами. **Более того, предполагается, что в реальных системах один и тот же узел может поддерживать несколько ANP-протоколов одновременно — аналогично тому, как человек может владеть несколькими языками общения.**

---

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