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