(Натисніть на зображення вище, щоб переглянути відео цього уроку)
Зі зростанням використання AI-агентів зростає й потреба у протоколах, які забезпечують стандартизацію, безпеку та підтримують відкриті інновації. У цьому уроці ми розглянемо 3 протоколи, які відповідають цій потребі — Model Context Protocol (MCP), Agent to Agent (A2A) та Natural Language Web (NLWeb).
У цьому уроці ми розглянемо:
• Як MCP дозволяє AI агентах отримувати доступ до зовнішніх інструментів і даних для виконання завдань користувача.
• Як A2A забезпечує комунікацію та співпрацю між різними AI агентами.
• Як NLWeb приносить інтерфейси природною мовою на будь-який вебсайт, даючи змогу AI агентам відкривати та взаємодіяти з його вмістом.
• Визначити основну мету та переваги MCP, A2A і NLWeb у контексті AI агентів.
• Пояснити, як кожен протокол полегшує комунікацію та взаємодію між LLM, інструментами та іншими агентами.
• Розпізнати різні ролі, які кожен протокол відіграє у побудові складних агентських систем.
Model Context Protocol (MCP) — це відкритий стандарт, який забезпечує стандартизований спосіб для застосунків передавати контекст і інструменти LLM. Це створює «універсальний адаптер» до різних джерел даних і інструментів, до яких AI агенти можуть підключатися послідовно.
Розглянемо компоненти MCP, переваги порівняно з безпосереднім використанням API та приклад того, як AI агенти можуть використовувати MCP-сервер.
MCP працює на основі клієнт-серверної архітектури, де основними компонентами є:
• Хости — це застосунки з LLM (наприклад, редактор коду, як-от VSCode), які ініціюють підключення до MCP-сервера.
• Клієнти — це компоненти у застосунку хоста, що підтримують зв’язок один-до-одного з серверами.
• Сервери — легкі програми, що відкривають певні можливості.
У протоколі визначено три основні примітиви, які є функціоналом MCP-сервера:
• Інструменти (Tools): це окремі дії або функції, які AI агент може викликати для виконання дії. Наприклад, сервіс погоди може надавати інструмент “отримати погоду”, або сервер e-commerce — інструмент “купити товар”. MCP-сервери описують ім’я, опис та схему введення/виведення кожного інструменту у список можливостей.
• Ресурси (Resources): це доступні для читання дані або документи, які MCP-сервер може надавати, і клієнти можуть отримувати їх за запитом. Прикладами є вміст файлів, записи баз даних або файли журналів. Ресурси можуть бути текстовими (наприклад, код або JSON) або бінарними (зображення чи PDF).
• Підказки (Prompts): заздалегідь визначені шаблони, що пропонують рекомендовані запити, дозволяючи створювати більш складні робочі процеси.
MCP пропонує суттєві переваги для AI агентів:
• Динамічне виявлення інструментів: агенти можуть динамічно отримувати список доступних інструментів із сервера разом з описом їх функцій. На відміну від традиційних API, що часто вимагають статичного кодування інтеграцій, коли будь-які зміни API потребують оновлення коду, MCP пропонує підхід «інтегрувати один раз», що підвищує адаптивність.
• Інтероперабельність між різними LLM: MCP працює з різними LLM, надаючи гнучкість перемикання основних моделей для покращення продуктивності.
• Стандартизована безпека: MCP включає стандартний метод автентифікації, що підвищує масштабованість при додаванні доступу до нових MCP-серверів. Це простіше, ніж керувати різними ключами та типами автентифікації для традиційних API.

Уявімо, що користувач хоче забронювати політ за допомогою AI асистента на базі MCP.
Підключення: AI асистент (клієнт MCP) підключається до MCP-сервера авіакомпанії.
Виявлення інструментів: клієнт запитує MCP-сервер авіакомпанії: «Які інструменти у вас доступні?» Сервер відповідає інструментами як-от «пошук рейсів» та «бронювання рейсів».
Виклик інструменту: Користувач просить AI асистента: «Будь ласка, знайди рейс з Портленда до Гонолулу». Асистент, використовуючи свій LLM, визначає, що треба викликати інструмент «пошук рейсів» та передає відповідні параметри (відправлення, призначення) MCP-серверу.
Виконання і відповідь: MCP-сервер, виконуючи роль обгортки, робить фактичний виклик внутрішнього API бронювання авіакомпанії, потім отримує інформацію про рейси (наприклад, у форматі JSON) і передає їх назад AI асистенту.
Подальша взаємодія: AI асистент показує варіанти рейсів. Коли користувач обирає рейс, асистент може викликати інструмент «бронювання рейсу» на тому самому MCP-сервері, завершуючи бронювання.
Якщо MCP зосереджується на з’єднанні LLM з інструментами, то протокол Agent-to-Agent (A2A) робить крок далі, забезпечуючи комунікацію та співпрацю між різними AI агентами. A2A з’єднує AI агенти з різних організацій, середовищ та технологічних стеків для виконання спільного завдання.
Розглянемо компоненти та переваги A2A разом із прикладом використання в нашому додатку для подорожей.
A2A спрямований на забезпечення зв’язку між агентами та їх спільної роботи над підзавданнями користувача. Кожна частина протоколу підтримує це:
Подібно до того, як MCP-сервер надає список інструментів, Agent Card містить:
Ім’я агента.
Опис загальних завдань, які він виконує.
Список конкретних навичок з описами, щоб допомогти іншим агентам (або навіть користувачам) зрозуміти, коли і чому варто звернутися до цього агента.
Поточний URL кінцевої точки агента.
Версію та можливості агента, такі як потокова передача відповідей і push-повідомлення.
Agent Executor відповідає за передачу контексту чату користувача віддаленому агенту, який потребує цього для розуміння завдання. У сервері A2A агент використовує свій власний великий мовний модель (LLM) для обробки запитів і виконання завдань за допомогою внутрішніх інструментів.
Після завершення завдання віддаленим агентом, його результат створюється в вигляді артефакту. Артефакт містить результат роботи агента, опис виконаного завдання та текстовий контекст, який надсилається протоколом. Після відправлення артефакту з’єднання з віддаленим агентом закривається до наступного запиту.
Цей компонент використовується для обробки оновлень і передачі повідомлень. Він особливо важливий у виробничих агентських системах, щоб запобігти закриттю з’єднання між агентами до завершення завдання, особливо коли виконання займає тривалий час.
• Розширена співпраця: дає змогу агентам різних постачальників і платформ взаємодіяти, обмінюватись контекстом і працювати разом, спрощуючи автоматизацію між традиційно роз’єднаними системами.
• Гнучкість вибору моделі: кожен агент A2A може сам обирати LLM, який використовує для виконання запитів, дозволяючи оптимізувати або адаптувати модель для конкретного агента, на відміну від одного з’єднання LLM у деяких сценаріях MCP.
• Вбудована автентифікація: автентифікація інтегрована безпосередньо у протокол A2A, забезпечуючи міцну систему безпеки для взаємодії агентів.

Розширимо наш сценарій бронювання подорожей, але цього разу з використанням A2A.
Запит користувача до мультиагента: користувач взаємодіє з A2A клієнтом/агентом «Travel Agent», можливо, каже: «Будь ласка, забронюй повну поїздку в Гонолулу на наступний тиждень — включно з рейсами, готелем і орендою автомобіля».
Оркестрація Travel Agent: Travel Agent отримує це складне завдання. Використовує свій LLM щоб проаналізувати завдання і визначити, що треба звертатися до інших спеціалізованих агентів.
Міжагентська комунікація: Travel Agent використовує протокол A2A, щоб підключитися до інших агентів — наприклад, «Агент авіакомпанії», «Готельний агент», «Агент оренди автівок», створених різними компаніями.
Делегування завдань: Travel Agent відправляє цим агентам певні завдання (наприклад, «Знайди рейси до Гонолулу», «Забронюй готель», «Орендуй автомобіль»). Кожен зі спеціалізованих агентів, працюючи на власних LLM і інструментах (які можуть бути MCP-серверами), виконує свою частину бронювання.
Об’єднана відповідь: після завершення роботи всіх агентів Travel Agent збирає результати (деталі рейсів, підтвердження бронювання готелю, оренду автомобіля) і надсилає користувачу відповідь у вигляді діалогу.
Вебсайти вже давно є основним способом доступу користувачів до інформації й даних в інтернеті.
Розглянемо різні компоненти NLWeb, його переваги та приклад роботи NLWeb на прикладі нашого додатку для подорожей.
Додаток NLWeb (основний сервісний код): система, що обробляє питання природною мовою. Вона з’єднує різні частини платформи для створення відповідей. Можна уявити цю систему як двигун, що живить функції природної мови на сайті.
Протокол NLWeb: це базовий набір правил для взаємодії природною мовою з вебсайтом. Він повертає відповіді у форматі JSON (часто з використанням Schema.org). Його мета — створити просту основу для «AI Web», так само, як HTML зробив можливим обмін документами онлайн.
MCP сервер (Endpoint протоколу Model Context Protocol): кожна установка NLWeb також працює як MCP сервер. Це означає, що вона може поширювати інструменти (наприклад, метод “ask”) і дані з іншими AI системами. На практиці це робить контент і можливості сайту доступними для AI агентів, дозволяючи сайту стати частиною ширшої «екосистеми агентів».
Моделі для вбудовування (Embedding Models): ці моделі використовуються для перетворення вмісту сайту у числові представлення — вектори (embedding). Ці вектори зберігають зміст так, щоб комп’ютери могли порівнювати і шукати. Вони зберігаються у спеціальній базі даних, причому користувачі можуть обирати, яку модель embedding вони хочуть використати.
Векторна база даних (механізм пошуку): ця база зберігає embedding-вектори вмісту сайту. Коли хтось ставить запитання, NLWeb звертається до цієї бази, щоб швидко знайти найбільш релевантну інформацію. Вона повертає швидкий список можливих відповідей, відсортованих за схожістю. NLWeb працює з різними системами зберігання векторів, як-от Qdrant, Snowflake, Milvus, Azure AI Search та Elasticsearch.

Знову розглянемо наш сайт для бронювання подорожей, але тепер він працює на базі NLWeb.
Імпорт даних: існуючі каталоги продуктів (наприклад, списки рейсів, описи готелів, тури) форматуються з використанням Schema.org або завантажуються через RSS-стрічки. Інструменти NLWeb індексують ці структуровані дані, створюють embedding-вектори й зберігають їх у локальній або віддаленій векторній базі.
Запит природною мовою (користувач): користувач заходить на сайт і замість навігації меню вводить у чаті запит: «Знайди готель у Гонолулу з басейном, дружній до сімей з дітьми, на наступний тиждень».
Обробка NLWeb: додаток NLWeb отримує цей запит. Він надсилає запит у LLM для розуміння та одночасно шукає по векторній базі релевантні готелі.
Точні результати: LLM допомагає інтерпретувати результати пошуку, знаходить найкращі збіги за критеріями «дружній до сім’ї», «басейн», «Гонолулу» і форматує відповідь природною мовою. Важливо, що відповідь посилається на реальні готелі з каталогу сайту, уникаючи вигаданих даних.
Взаємодія AI агента: оскільки NLWeb виступає MCP-сервером, зовнішній AI-агент з подорожей може підключитися до цього NLWeb-інстансу сайту. AI агент тоді використовує MCP-метод ask для безпосереднього запиту сайту, наприклад: ask("Чи є в районі Гонолулу веганські ресторани, рекомендовані готелем?"). NLWeb обробить це, використовуючи базу ресторанної інформації (якщо вона завантажена), і поверне структуровану JSON-відповідь.
Приєднуйтесь до Microsoft Foundry Discord, щоб зустріти інших учнів, відвідати онлайн-консультації та отримати відповіді на ваші питання щодо AI агентів.
Застереження: Цей документ було перекладено за допомогою сервісу автоматичного перекладу Co-op Translator. Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ рідною мовою слід вважати авторитетним джерелом. Для критично важливої інформації рекомендується звертатися до професійного людського перекладу. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникли внаслідок використання цього перекладу.