Історія розподілених обчислень – це шлях від множинності протоколів до їхнього консолідування.
Архітектура брокера запитів об’єктів (CORBA), розподілена модель об’єктних компонентів (DCOM), механізм виклику віддалених методів Java (RMI) та ранній простий протокол доступу до об’єктів (SOAP) конкурували за ринок корпоративної інтеграції наприкінці 1990-х років, поки протокол передачі стану представлення (REST) тихо не переміг, ставши простішим та нативним для HTTP.
Протокол розширеного обміну повідомленнями та присутності (XMPP), Internet Relay Chat (IRC) та близько десятка пропрієтарних протоколів фрагментували обмін повідомленнями в реальному часі, доки протокол транспортування телеметрії MQTT та WebSockets не зайняли свої ніші. Кожна нова обчислювальна парадигма породжує сплеск конкуруючих стандартів, а потім повільно збігається, оскільки накопичуються реалізації та взаємодія стає економічно необхідною.
Екосистема ШІ-агентів наразі перебуває на стадії розквіту. За останні вісімнадцять місяців було опубліковано чотири значні протоколи: протокол контексту моделі (MCP) від Anthropic наприкінці 2024 року, протокол комунікації агентів (ACP) від IBM Research у березні 2025 року, Agent2Agent (A2A) від Google у квітні 2025 року та протокол мережі агентів (ANP) від незалежної робочої групи.
Спільнота W3C AI Agent Protocol Community Group розпочала процес стандартизації. Internet Engineering Task Force (IETF) отримує Internet-Drafts щодо транспортування агентів. Конференції проводять воркшопи з питань взаємодії. Щотижня з’являється новий репозиторій на GitHub, який претендує на вирішення проблеми комунікації агентів.
Розуміння того, де і як швидко це збігається, має реальні наслідки для архітектурних рішень, які приймаються просто зараз.
Що насправді вирішують протоколи
Множинність протоколів виглядає хаотичнішою, ніж є насправді, оскільки більшість цих протоколів охоплюють різні шари стеку, а не конкурують за одне й те саме місце. Плутанина виникає через маркетинг, де кожен описується як “стандарт для комунікації ШІ-агентів” без уточнення, якого саме аспекту комунікації.
MCP – це інтерфейс виклику інструментів (tool-calling). Він визначає, як модель виявляє функції, що надаються сервером, як їх викликати та як інтерпретувати відповідь. Це контракт типізованого виклику віддаленої процедури (RPC) між клієнтом моделі та сервером інструментів, що працює через HTTP. Linux Foundation підтвердила понад 10 000 активних публічних MCP-серверів та 164 мільйони щомісячних завантажень Python SDK станом на квітень 2026 року. MCP вже виграв шар виклику інструментів. Робота зі стандартизації фактично завершена.
A2A – це інтерфейс координації завдань. Якщо MCP визначає, як агент викликає інструмент, то A2A визначає, як два агенти делегують завдання. Він вводить “Картки Агентів” (оголошення про можливості), стани життєвого циклу завдань та три режими взаємодії: синхронний, потоковий та асинхронний. Google передав його до Linux Foundation у червні 2025 року, і корпоративні команди ШІ широко його впровадили, оскільки він заповнює реальну прогалину, яку залишає MCP.
ACP – це формат конверта повідомлення. Легкий, безстатусний, призначений для обміну повідомленнями між агентами без повної семантики координації A2A. Він корисний у системах, де достатньо простого обміну повідомленнями, а накладні витрати на життєвий цикл завдань A2A є непотрібними.
ANP – це протокол виявлення та ідентифікації. Він використовує децентралізовані ідентифікатори (DIDs) для ідентифікації агентів та JSON-LD графіки для опису можливостей, забезпечуючи основу для децентралізованих маркетплейсів агентів, де не потрібен центральний реєстр.
Стек, що виникає: виявлення можливостей через ANP або простіші реєстри, координація завдань через A2A, виклики інструментів через MCP та легкий обмін повідомленнями через ACP для випадків, які не потребують повного управління життєвим циклом завдань. Ці шари доповнюють, а не конкурують.
Проблема транспортування, що залишається
Кожен протокол у цьому списку працює через HTTP. Це відображає походження протоколів: дослідницькі команди, постачальники API та компанії-розробники корпоративного програмного забезпечення, які будують системи, де HTTP є незаперечним припущенням. HTTP – це протокол, який вони знають, який їхні сервери вже підтримують, і який полегшує демонстрації.
Виробнича проблема полягає в тому, що HTTP передбачає доступний сервер. За трансляцією мережевих адрес (NAT) — а 88% мережевих пристроїв знаходяться за NAT — немає доступного сервера без ретранслятора. Для парків агентів, яким потрібно маршрутизувати завдання безпосередньо між вузлами через межі хмар, домашні мережі та граничні розгортання, ця централізація змушує кожне повідомлення проходити через інфраструктуру ретрансляції. Інфраструктура ретрансляції додає затримку, витрати та точку відмови.
Протоколи прикладного рівня вирішують семантику того, що агенти говорять один одному. Вони не вирішують, як агенти знаходять один одного та встановлюють прямі з’єднання. Це проблема сесійного рівня, Рівень 5 моделі OSI, і жоден з MCP, A2A, ACP чи ANP її не вирішує.
Технології для її вирішення існують. UDP hole-punching із утилітами для обходу NAT (STUN) забезпечує обхід NAT приблизно для 70% мережевих топологій. X25519 Diffie-Hellman та AES-256-GCM забезпечують автентифіковане шифрування на рівні тунелю без центру сертифікації. Quick UDP Internet Connections (QUIC) (RFC 9000) або власні протоколи ковзного вікна через User Datagram Protocol (UDP) забезпечують надійну доставку без блокування TCP “head-of-line”. Це ті ж самі примітиви, які WireGuard використовує для VPN-тунелів, а WebRTC – для медіапотоків між браузерами.
Відмінність у контексті агентів полягає в маршрутизації на основі можливостей. Агенти повинні знаходити вузли не за іменем хоста, а за тим, що ці вузли можуть робити. Дослідницький агент повинен мати можливість запитати “які вузли мають дані іноземної валюти в реальному часі?” і отримати список активних спеціалізованих агентів. Це ближче до реєстру служб, ніж до DNS, і є природним розширенням філософії дизайну ANP, застосованим до рівня транспортування.
Кілька проектів збирають ці частини. Pilot Protocol має найповнішу опубліковану специфікацію, з IETF Internet-Draft, що охоплює адресацію, встановлення тунелю та обхід NAT для мереж агентів. libp2p забезпечує перевірену основу з подібними примітивами. Робоча група QUIC IETF розробляє розширення для обходу NAT, які будуть тут актуальними.
VB Transform · 14–15 липня · Менло-Парк · Оркестрація агентів
Intuit перебудував свою мультиагентну систему за 60 днів. Що вони змінили — і чому?
На Transform керівники інженерних відділів з Intuit, Target та Instacart розповідають, як вони переробили свої архітектури оркестрації для надійності, масштабування та роботи з реальними клієнтами.
Дивіться повний порядок денний →
Як виглядатиме зближення
HTTP-орієнтовані протоколи (MCP, A2A) вже збігаються до стабільних версій. Наступні 12 місяців будуть присвячені зміцненню виробничих можливостей, поліпшенню безпеки, stateless MCP-серверам для горизонтального масштабування, кращій федерації A2A — а не фундаментальним новим дизайнам. Шари виклику інструментів та координації завдань значною мірою вирішені.
Транспортний рівень відстає на 18-24 місяці. Очікуйте періоду різноманітності реалізацій, оскільки команди експериментують з різними підходами до мереж агентів peer-to-peer (P2P), за яким послідує консолідація навколо невеликої кількості реалізацій, коли емпіричні дані про продуктивність та надійність накопичаться. Треки стандартизації IETF та W3C, ймовірно, дадуть результат у вікні 2027-2028 років, до того часу одна-дві реалізації з відкритим вихідним кодом накопичать достатньо виробничих розгортань, щоб встановити де-факто стандарти ще до офіційної специфікації.
Для керівників інженерних відділів, які сьогодні приймають архітектурні рішення, практичне значення полягає в багатошаровому впровадженні. Протоколи прикладного рівня достатньо стабільні, щоб на них можна було будувати. Впровадження MCP зараз є низькоризикованим. Впровадження A2A для координації між агентами є розумним з очікуванням, що протокол буде розвиватися. Транспортний рівень — це те місце, де ви або створюєте щось власне і плануєте його замінити, або оцінюєте ранні реалізації, знаючи, що ця сфера все ще розвивається.
Команди, які матимуть найбільший вплив, коли транспортний рівень стабілізується, — це ті, хто розробив свої агентні системи з чітким розділенням між семантикою програми (MCP, A2A) та транспорту (все, що знаходиться нижче). Чітке розділення дешево реалізувати зараз і дорого додати пізніше — це урок, який епоха мікросервісів засвоїла всім, хто намагався додати спостережуваність або ланцюгові переривники до систем, яких у них не було.
Філіп Стаєцький — співзасновник Vulture Labs.
Ласкаво просимо до спільноти VentureBeat!
Наша програма гостьових публікацій — це місце, де технічні експерти діляться своїми ідеями та надають нейтральний, неупереджений глибокий аналіз ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє підприємств.
Читайте більше від нашої програми гостьових публікацій — і ознайомтеся з нашими рекомендаціями, якщо ви зацікавлені у внесенні власної статті!
Як захиститися (Порада CryptoDom): Завжди використовуйте багатофакторну автентифікацію (MFA) для доступу до своїх акаунтів та систем. Це значно ускладнює зловмисникам отримання несанкціонованого доступу, навіть якщо їм вдасться викрасти ваш пароль.
Оригінал статті: venturebeat.com