DNS революцията: Как AI агентите се откриват в децентрализиран свят

• Въведение в проблемната област
• Обяснение защо откриването на агенти е важно
• Обсъждане на различните механизми
• Споделяне на прозрения относно реализацията на DNS-AID
• Заключение за бъдещите последици

Проблемът с „телефонния указател“ за AI агенти

Помните ли си, когато интернет беше само шепа компютри и трябваше да наизустявате IP адреси, за да достъпите каквото и да е? Решихме това с DNS — Системата за доменни имена, която превежда домейните, разбираеми за хората, в машинни адреси. Сега си представете, че се изправяме пред подобно предизвикателство, но този път не са компютри, разговарящи с уеб сървъри. Това са AI агенти, които се опитват да се откриват и взаимодействат помежду си в децентрализирана мрежа.

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

Защо откриването на агенти е по-важно, отколкото мислите

Ето в какво става: тъй като AI агентите стават все по-специализирани и многочисни, способността им да се намират един друг става фундаментална инфраструктура. Помислете за това — вашият агент трябва да делегира задача на друг агент. Вашият агент иска да достъпи специфична възможност, която няма. Вашата система трябва да провери дали един агент е легитимен, преди да започне взаимодействие.

Нищо от това не работи без механизъм за откриване.

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

Три пътя към откриването на AI агенти

Чрез проучването на тази област се натъкнах на три основни механизма за откриване на агенти, които набират популярност:

Подходът с Директория на AI ресурси (ARD)

ARD функционира като отворена спецификация за описване, откриване и търсене на агентни ресурси в федерализирани мрежи. Красотата тук е, че той следва съществуващите уеб парадигми — един агент публикува своите възможности в каталог и откриването става въпрос на търсене в този каталог.

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

DNS-AID: Използване на гръбнака на интернет

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

Това, което го прави мощен, е доказаната надеждност и глобалното разпределение на DNS. Интернет прекара десетилетия в усъвършенстване на тази инфраструктура — защо да не я използваме?

ANS: Регистър и прозрачност

ANS прилага различен подход, функционирайки като регистър и прозрачен лог (transparency log). Той присвоява уникални, версиирани имена на агентите и предоставя механизъм за проверка. Това е особено ценно за доверието и отчетността при взаимодействията агент-агент.

Подробен анализ на реализацията на DNS-AID

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

Наивният подход: Директно публикуване на SVCB

Директният метод публикува крайните точки (endpoints) на агента директно чрез DNS SVCB записи. Това работи добре, когато агентът разполага с един интерфейс, но тук идва уловката — става объркване, когато агентът има множество крайни точки (например както A2A, така и MCP протоколи).

Резултатът? Клиентите може да се опитат да извикат основна крайни точка, очаквайки специфичен протокол, само за да получат 404. Не е катастрофално, но със сигурност не е елегантно.

Елегантното решение: Указатели към „карти на агента“ (Agent Card Pointers)

По-умният подход използва SVCB записи, за да сочи към „карта на агента“, която съдържа цялата информация за крайните точки. Тъй като картата на агента може да описва множество интерфейси с техните специфични маршрути, откриването става много по-гъвкаво и точно.

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

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

Ако изграждате нещо с AI агенти или планирате да го правите, този слой за откриване е нещо, което трябва да разберете. Изборът, който се прави в момента за това как агентите откриват един друг, ще оформя архитектурата на агентните системи години наред.

Няколко съображения:

• Интероперабилността зависи от откриването — вашата агентна екосистема е добра само колкото е добра способността ѝ да намира и комуникира с други агенти.
• Решенията на база DNS имат предимства — използването на съществуваща инфраструктура означава по-малко поддръжка и по-голяма надеждност.
• Разнообразието на протоколите е реалност — агентите ще говорят множество езици (A2A, MCP, обикновен HTTPS), така че вашият механизъм за откриване трябва да отчита това.
• Доверието и проверката са важни — тъй като агентите взаимодействат автономно, знанието, че разговаряте с правилния агент, става критично.

Предстои само началото

Това, което ме поразва най-много в тази област, е, че все още сме в самото начало. Механизмите за откриване, които се изследват днес, ще еволюират, ще се обединяват и вероятно ще ни изненадат. Инструментите за сравнение (Comparison Engine), които се създават, за да проучат тези различни механизми, са точно този вид инфраструктура, от която се нуждаем — начини за разбиране и навигация в този възникващ пейзаж.

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

Играта тепърва започва и, честно казано, нямам търпение да видя докъде ще стигне.