| | --- |
| | title: Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы |
| | description: '> Почему современные агентные системы остаются централизованными, даже |
| | когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. > |
| | Этот текст основан на спецификации [**...' |
| | type: Article |
| | tags: |
| | - Ethics |
| | - CogSync |
| | - JSON |
| | - Mesh |
| | - Agent |
| | - HMP |
| | --- |
| | |
| | # Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы |
| |
|
| | > Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. |
| |
|
| | > Этот текст основан на спецификации [**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) |
| |
|
| | --- |
| | > ⚡ [AI friendly version docs (structured_md)](../index.md) |
| |
|
| |
|
| | ```json |
| | { |
| | "@context": "https://schema.org", |
| | "@type": "Article", |
| | "name": "Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы", |
| | "description": "# Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы > Почему современные агент..." |
| | } |
| | ``` |
| |
|
