Источник: HMPv5_Overview_Ru.md

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

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

Этот текст основан на спецификации HMP v5.0 (HyperCortex Mesh Protocol) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде.
Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения.

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

При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.

1. Зачем вообще понадобился HMP v5.0

За последние пару лет агентные архитектуры на базе ИИ стали выглядеть достаточно зрелыми. AutoGPT, CrewAI, LangGraph, различные swarm-подходы показали, что задачу можно разбивать на роли, распределять ответственность и получать результат, который внешне напоминает коллективную работу.

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

В большинстве случаев речь идёт не о сети агентов, а о централизованном агенте с единым центром координации:

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

Даже если в системе используется несколько агентов, они остаются частями одной программы и одной логики управления. Их автономия ограничена рамками этого центра.

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

Важно сразу уточнить: проблема здесь не в LLM и не в конкретных моделях.

Память, планирование и рассуждение действительно могут быть реализованы вне LLM — с помощью внешних хранилищ, планировщиков, инструментов анализа. Однако все эти компоненты, как правило, остаются жёстко связанными с одним центром управления.

В результате мы получаем агента, который:

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

Такой агент хорошо работает как замкнутая система, но плохо масштабируется в распределённой среде, где:

агенты принадлежат разным владельцам;
используют разные архитектуры;
имеют разные цели и жизненные циклы;
не подчиняются общему управляющему центру.

Именно в этот момент и проявляется ограничение централизованного подхода.

1.2 Почему «распределённые ИИ» не заменяют децентрализованную координацию

Существует ряд проектов, которые позиционируются как распределённые или децентрализованные ИИ-системы. Среди них — как когнитивные архитектуры, так и инфраструктурные решения, решающие важные и самостоятельные задачи:

OpenCog Hyperon — когнитивная архитектура с распределённым исполнением и формальными механизмами рассуждений;

Показательно, что такие проекты, как OpenCog Hyperon, фокусируются прежде всего на внутренней когнитивной согласованности и формальных механизмах рассуждений.

Это делает их ценными для построения сложных когнитивных систем, однако оставляет за пределами их фокуса задачу децентрализованного взаимодействия автономных агентов с разными моделями мышления.
проекты, относимые к условному классу DeAI (децентрализованный или распределённый ИИ), которые можно условно разделить на несколько групп:
- Системы распределённого инференса и обучения
  (наиболее близкие к буквальному смыслу «распределённый ИИ»):
- Агентные и когнитивные системы с распределённым исполнением:
  - Gonka;
  - 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 Почему «общий формат знаний» — тупик

Ещё одно интуитивное решение — договориться о едином формате знаний или общей онтологии.

На практике это почти всегда приводит к одному из двух сценариев:

формат оказывается слишком общим и теряет практическую ценность;
формат становится слишком жёстким и тормозит развитие системы.

Кроме того, единый формат подразумевает единое понимание смысла. А это уже не только техническая, но и когнитивная проблема.

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-контейнера.
Она не отражает всех возможных полей и расширений, а показывает лишь логическое разделение структуры:

{
  "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 сознательно разделяет эти этапы:

обнаружение (discovery);
обмен контейнерами (MCE);
интерпретацию полученных артефактов и создание новых контейнеров;
формирование доверия — или отказ от него.

Важно, что третий и четвёртый этапы выполняются на стороне агента и относятся к его внутреннему когнитивному циклу.
Первые два этапа, напротив, могут быть реализованы без предположений о модели мышления агента и не требуют согласованной когнитивной логики.

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

HMPv5_Overview_Ru