| # Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы | |
| > Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. | |
| > Этот текст основан на спецификации [**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) |