MCP, A2A и DNS-AID: стандартите зад новото поколение свързани AI системи

В началото на масовото използване на генеративен AI повечето системи работеха като отделни чат интерфейси. Потребителят задаваше въпрос, моделът генерираше отговор и взаимодействието приключваше в рамките на един разговор.

Днес развитието е насочено към AI приложения и агенти, които могат да използват фирмени данни, да извикват инструменти, да изпълняват конкретни задачи и да си сътрудничат с други специализирани системи. За да бъде това възможно без разработването на различна интеграция за всяка комбинация от продукт и доставчик, са необходими общи правила за свързване.

Тук се появяват Model Context Protocol (MCP), Agent-to-Agent Protocol (A2A) и DNS for AI Discovery (DNS-AID). Те не решават един и същ проблем и не трябва да се разглеждат като конкуренти. Всеки от тях заема различно място в архитектурата на една свързана AI система.

Три различни слоя в една обща среда

Най-лесният начин да се разбере ролята на трите технологии е чрез три практически въпроса:

• MCP: Как AI приложението да използва конкретен инструмент или източник на данни?
• A2A: Как един независим AI агент да възложи задача на друг агент и да получи резултат?
• DNS-AID: Как дадена организация да публикува къде се намира нейният агент или MCP услуга и по какъв протокол може да бъде достигната?

В една бъдеща фирмена архитектура трите слоя могат да работят последователно. DNS-AID помага за откриването на подходящ endpoint. A2A управлява комуникацията и задачата между независими агенти. Агентът, който изпълнява задачата, може на свой ред да използва MCP, за да достигне до разрешени инструменти, документи и API.

Откриването, комуникацията и достъпът до инструменти са отделни отговорности. Това разделение прави архитектурата по-разбираема и позволява всеки слой да бъде защитен и развиван самостоятелно.

Какво представлява MCP?

Model Context Protocol е отворен протокол за стандартизирана връзка между AI приложения и външни възможности. Един MCP сървър може да предоставя ресурси, инструменти и готови prompt шаблони, а клиентът може да открива и използва само заявените и разрешени функции.

Вместо всяко AI приложение да изгражда отделна интеграция за файлово хранилище, календар, CRM, база данни или вътрешно API, съответната система може да предостави ясно описани възможности чрез MCP.

Примерна вътрешнофирмена система може да изложи инструменти за:

• търсене на клиент по разрешени полета;
• извличане на документи от конкретен проект;
• проверка на свободни часове;
• създаване на чернова на задача;
• получаване на обобщени показатели от бизнес система.

Официалната архитектура на MCP използва модел host–client–server. Host приложението управлява връзките и решенията за достъп, като всеки клиент поддържа отделна сесия с конкретен MCP сървър. Това позволява различните сървъри да останат изолирани и да получават само контекста, необходим за съответната операция.

MCP не превръща автоматично всяка интеграция в сигурна. Приложението трябва да налага идентичност, разрешения, минимален обхват на достъпа, валидиране на входа и изхода и човешко потвърждение за чувствителни действия.

Какво представлява A2A?

Agent-to-Agent Protocol е насочен към комуникацията между независими AI агенти. Те могат да бъдат разработени от различни организации, да използват различни модели и програмни рамки и въпреки това да си възлагат задачи чрез общ протокол.

При A2A агентът не е длъжен да разкрива своята вътрешна памет, prompt-и или инструментите, с които работи. Той публикува своите възможности, приема задача и връща статус, съобщения или готови резултати. Протоколът поддържа и по-продължителни операции, при които задачата не приключва с един незабавен отговор.

Например основен фирмен агент може да получи заявка за подготовка на управленски отчет. Вместо сам да изпълнява всяка стъпка, той може да възложи:

• извличането на финансови показатели на специализиран финансов агент;
• проверката на изпълнените задачи на проектен агент;
• обобщаването на клиентската комуникация на CRM агент;
• подготовката на крайния документ на агент за отчети.

A2A определя начина, по който тези агенти обменят задачи и резултати. Всеки от тях може вътрешно да използва MCP за връзка със собствените си инструменти.

Какво добавя DNS-AID?

Преди два агента да комуникират, единият трябва да разбере къде се намира другият и какъв протокол поддържа. Централен каталог може да реши този проблем, но създава зависимост от конкретен оператор и не е естествено свързан с идентичността на организацията.

DNS-AID предлага различен подход: организациите да публикуват информация за агентни услуги в собственото си DNS пространство. Проектът използва съществуващи DNS механизми и структурирани имена, чрез които клиент може да открие endpoint, използван протокол и свързани метаданни.

Идеята е сходна с начина, по който домейните вече насочват към уебсайтове, имейл услуги и други интернет ресурси. Организацията управлява записите под собствения си домейн, а стандартната DNS инфраструктура осигурява разпределено откриване и кеширане.

DNSSEC може да добави криптографска проверка, че полученият DNS отговор не е бил подменен по пътя. Това обаче не означава, че откритият агент е автоматично надежден или че клиентът има право да използва неговите функции.

Към 28 август 2026 г. DNS-AID трябва да се разглежда като развиваща се технология. Проектът е обявен под Linux Foundation, а техническото предложение е публикувано като IETF Internet-Draft. Форматът и практиките могат да бъдат променяни преди евентуалното му утвърждаване като стандарт.

Как трите технологии работят заедно

Да разгледаме пример с компания, която използва основен AI асистент за работа с клиенти и вътрешни процеси.

1. Асистентът трябва да намери външен агент, който може да провери статуса на доставка.
2. Чрез DNS-AID той открива публикуваната услуга и поддържания от нея протокол.
3. Чрез A2A изпраща задача към агента за доставки и получава идентификатор и статус на задачата.
4. Агентът за доставки използва собствен MCP клиент, за да извика разрешен инструмент към логистичната система.
5. Резултатът се връща чрез A2A към основния асистент.
6. Фирмената система показва информацията на служителя или изисква потвърждение преди следващо действие.

Тази схема позволява отделните системи да останат независими. Логистичният агент не е необходимо да разкрива своята база данни или вътрешна логика, а основният асистент не трябва да познава техническите подробности на всяка използвана услуга.

Защо отворените протоколи имат значение за бизнеса

При липса на общи стандарти всяка интеграция се разработва като отделна връзка между две конкретни системи. С увеличаването на броя на инструментите и агентите броят на тези връзки нараства, а поддръжката става по-скъпа.

Общите протоколи могат да донесат няколко практически предимства:

• по-малка зависимост от един доставчик – компонентите могат да се заменят, ако поддържат същия договор;
• по-бързо добавяне на нови възможности – не е необходимо всяка връзка да започва от нулата;
• ясни граници – инструментите, агентите и откриването имат отделни роли;
• по-добра наблюдаемост – заявките и задачите могат да се проследяват на определени точки;
• постепенно развитие – фирмата може да започне с една MCP интеграция и да добавя A2A или DNS-базирано откриване само когато има реална нужда.

Стандартът не заменя сигурността

Съвместимостта между системите не е равнозначна на доверие. Публикуван endpoint може да бъде открит, но достъпът до него трябва да бъде защитен чрез подходяща идентификация и авторизация. MCP, A2A и DNS-AID не премахват необходимостта от стандартните мерки за сигурност.

При реално внедряване трябва да бъдат определени:

• кои агенти и клиенти са разрешени;
• до кои инструменти и данни може да достигне всеки от тях;
• как се издават, ограничават и отнемат права;
• кои действия изискват човешко одобрение;
• как се валидират получените резултати;
• как се регистрират задачите и извикванията на инструменти;
• как се реагира при компрометиран endpoint или външен доставчик.

Официалната MCP спецификация включва OAuth-базиран модел за HTTP авторизация и изисква токените да бъдат предназначени за конкретния ресурс. A2A също предвижда удостоверяване, описание на възможностите и контролирано взаимодействие. DNSSEC може да потвърди целостта на DNS отговора, но не заменя приложната авторизация.

Нужни ли са тези технологии на всеки бизнес?

Не всяка фирмена система се нуждае от много агенти и публично DNS откриване. За приложение, което използва един AI модел и няколко вътрешни функции, добре защитено собствено API може да бъде напълно достатъчно.

MCP има практическа стойност, когато множество AI приложения трябва да използват едни и същи инструменти по последователен начин. A2A става полезен, когато независими агенти с различни отговорности трябва да координират по-сложни или продължителни задачи. DNS-AID е интересен при междусистемно или междуорганизационно откриване, особено когато централен регистър не е желан.

Правилният подход е технологията да следва реалния бизнес процес. Въвеждането на агентна архитектура само защото е актуална може да добави повече сложност, отколкото стойност.

Свързаното бъдеще на AI системите

MCP, A2A и DNS-AID показват посоката, в която се развива екосистемата: от изолирани AI чатове към модулни системи, в които модели, инструменти и агенти могат да работят заедно чрез общи договори.

MCP предоставя стандартизиран достъп до конкретни възможности. A2A позволява координация между независими агенти. DNS-AID изследва децентрализиран начин тези услуги да бъдат публикувани и откривани чрез инфраструктура, която интернет вече използва.

Най-важният резултат не е агентът да бъде свързан с възможно най-много системи. Целта е всяка връзка да има ясна причина, минимални права, проследимо действие и измерима стойност за бизнеса.