|
|
--- |
|
|
title: Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы |
|
|
description: '> Почему современные агентные системы остаются централизованными, даже |
|
|
когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. > |
|
|
Этот текст основан на спецификации [**...' |
|
|
type: Article |
|
|
tags: |
|
|
- Ethics |
|
|
- Agent |
|
|
- JSON |
|
|
- Mesh |
|
|
- HMP |
|
|
- CogSync |
|
|
--- |
|
|
|
|
|
# Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы |
|
|
|
|
|
> Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол. |
|
|
|
|
|
> Этот текст основан на спецификации [**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": "# Почему будущее ИИ-агентов — децентрализованные сети, а не оркестраторы > Почему современные агент..." |
|
|
} |
|
|
``` |
|
|
|
