Rejestratory agentów informują o tym, co istnieje, a nie o tym, czy nadal można im ufać.
Czteroczęściowa struktura dla rejestrów umiejętności agentów obejmująca istnienie, przydatność, status oraz pochodzenie, plus prosty test ostatniej weryfikacji, który można przeprowadzić już dziś.
Załóżmy, że agent podczas rutynowej operacji wyszukuje narzędzie po nazwie, wywołuje je, otrzymuje sensowną odpowiedź i kontynuuje pracę. Operacja kończy się sukcesem, a to jest właśnie niepokojące, ponieważ nikt w zespole nigdy nie sprawdził tej funkcjonalności. Rejestry i usługi odkrywania powinny mieć pod kontrolą takie sytuacje, a w ciągu zaledwie jednego tygodnia pojawiło się kilka produktów i specyfikacji, które wszystkie twierdzą, że stanowią tę warstwę kontroli.
Żaden z nich nie jest błędny, ale razem odpowiadają jedynie na połowę informacji, których zespół potrzebuje przed użyciem nowej funkcjonalności przez agenta. Ten artykuł dzieli problem na cztery konkretne pytania, pokazuje, które z nich potrafią odpowiedzieć obecne rejestratory, oraz dostarcza praktycznych sposobów weryfikacji oraz krótkiej listy działań dotyczących tych, które pozostają nierozwiązane.
Co trafiło do warstwy rejestru
Podane poniżej informacje odzwierciedlają stan rzeczy w momencie pisania tekstu; przed skorzystaniem z konkretnych funkcji lub numerów wersji sprawdź aktualną dokumentację.
AWS Agent Registry
Agent Registry w AWS jest teraz dostępny powszechnie. Można go traktować jako prywatny katalog z wbudowanymi mechanizmami zarządzania, który może przechowywać agenty, serwery MCP, karty agentów A2A, umiejętności oraz dowolne niestandardowe zasoby. W projekcie celowo oddzielono dwa poziomy funkcjonowania: kuratorzy pracują na poziomie zarządzania, gdzie wpisy są zatwierdzane lub odrzucane; użytkownicy korzystają z poziomu wyszukiwania, który pokazuje wyłącznie zatwierdzone wpisy. Każdy rekord przechodzi przez pięć stanów (projekt, w oczekiwaniu, zatwierdzony, odrzucony, przestarzały). Przejścia pomiędzy tymi stanami są sterowane zdarzeniami EventBridge, a CloudTrail prowadzi rejestr audytowy.
Wraz z pełną dostępnością pojawiła się obsługa infrastruktury w formie kodu (CloudFormation, CDK i Terraform), możliwość udostępniania zasobów między kontami za pośrednictwem RAM oraz automatyczne wykrywanie w całej organizacji agentów już działających na AgentCore. Tę funkcję wykrywania łatwo przeoczyć, a istnieje ona dlatego, że niesledzone „cienie” agentów stały się prawdziwym problemem w zarządzaniu zasobami. Wśród firm, które ją przyjęły, znajdują się Southwest, PepsiCo, Syngenta, Amdocs i Sony, co wskazuje, że nabywcy przeszli już poza fazę testów pilotażowych. AWS opisuje ten projekt szczegółowo na swoim blogu poświęconym uczeniu maszynowemu.
Agentic Resource Discovery (ARD)
Obok niego istnieje specyfikacja wspierana przez kilku dostawców, która adresuje ten sam problem. Agentic Resource Discovery została stworzona przez osoby z Google, Microsoft i Hugging Face i opublikowana pod licencją Apache 2.0, przy czym do jej tworzenia przyczynili się również NVIDIA, Salesforce i Databricks. Artykuł na The New Stack przedstawia ją jako odpowiednik DNS dla agentów. Jej interfejs jest celowo prosty – komunikacje odbywają się w formacie JSON-LD przez protokół REST. Obowiązkowy jest dokładnie jeden endpoint, POST /search, i do niego wysyła się zapytanie zawierające opis zadania, a nie nazwę zasobu. Endpunkty do przeglądania są opcjonalne. Funkcja federacji umożliwia firmie utrzymanie prywatności własnego katalogu, jednocześnie przekazując zapytania do zewnętrznych rejestrów, którym zaufała. W chwili pisania ten dokument znajduje się w wersji 0.91, jego model zarządzania jest nadal otwarty, a W3C wymieniane jest jako jedno z możliwych miejsc jego przechowywania.
Ciągła weryfikacja jako produkt
Trzecim projektem, który się pojawił, była firma AIR – startup, który działał w ukryciu i zebrał 50 milionów dolarów podczas dwóch rund finansowania początkowego (Sequoia finansowało pierwszą, a Greenoaks drugą). Ich działalność polega na sprawdzaniu pluginów, umiejętności oraz serwerów MCP, które używają agenci. Jedna z ich statystyk jest godna uwagi: około 27% umiejętności i dodatków pochodzących z otwartych źródeł, które obecnie oceniają, zostaje odrzuconych.
Gdy w ciągu kilku dni trzy projekty skupiają się na tym samym obszarze, zazwyczaj oznacza to, że branża doszła do konsensusu co do tego, gdzie znajduje się brakujący element.
Dlaczego odkrywanie nie jest zadaniem MCP
MCP nigdy nie twierdził, że rozwiązuje problem odkrywania narzędzi. Określa on mechanizm wywoływania narzędzia po tym, jak agent już zdecydował, które ma użyć. A2A pełni podobną funkcję w przypadku rozmów pomiędzy agentami, którzy już o sobie wiedzą. W obu przypadkach zakłada się, że lokalizacja i wybór odpowiedniej funkcjonalności nastąpiły wcześniej. Jeśli chcesz ponownie zapoznać się z tym podziałem, sprawdź jak Model Context Protocol umożliwia agentom odkrywanie i wywoływanie narzędzi.
To, co się zmieniło, to objętość. Podłączanie serwerów MCP ręcznie jest do zarządzania przy użyciu kilkunastu narzędzi. Gdy jest ich ponad tysiąc, należących do różnych zespołów wewnętrznych, dostawców usług SaaS oraz platform chmurowych, agent ograniczony do sztywnej listy w swojej konfiguracji ledwo może być uznany za agenta; jest bardziej podobny do stałego skryptu, który przypadkowo wywołuje model. Mechanizm odkrywania umożliwia zmianę zestawu możliwości w trakcie działania. Ta sama cecha oznacza, że nikt nie sprawdził tego zestawu, a niewiele zespołów wzięło pod uwagę ten kompromis przy ustalaniu cen.
Kolejne wyzwanie wynika z sposobu rozszerzania agentów. Badacze, którzy przeanalizowali źródła kodu jedenaście narzędzi do tworzenia aplikacji, obejmujących około czterech milionów linijek kodu dotyczących takich narzędzi jak OpenHands, Gemini CLI, Codex CLI i Claude Code (arXiv 2609.00006), stwierdzili, że umiejętności w formacie SKILL.md prześcignęły tam MCP: dziewięć z tych jedenaście narzędzi obsługuje umiejętności, a osiem – MCP. Zatem najszybciej rozprzestrzeniającym się mechanizmem rozszerzania jest plik Markdown pełen instrukcji, które agent będzie wykonywać. Takie pliki nie posiadają mechanizmu podpisywania ani praktycznie żadnego systemu wersjonowania, więc informacja z rejestru wskazująca na konkretny plik niewiele mówi o tym, co agent będzie robił w przyszłości.
Cztery pytania, na które powinien odpowiedzieć rejestr
Każdy raz, gdy agent ma zamiar użyć funkcji, która nie była mu niedawno dostępna, potrzebne są cztery odrębne odpowiedzi. Brzmią one podobnie, ale dotyczą różnych problemów, a ich rozróżnienie pokazuje, co dany produkt faktycznie robi w porównaniu z tym, po co jest kupowany.
Istnienie: czy istnieje coś, co to robi?
Czy istnieje jakaś funkcja, która może wykonać to zadanie, i gdzie jest ona hostowana? To właśnie ma za zadanie metoda POST /search w ARD, a mechanizm odkrywania usług AWS radzi sobie z tym doskonale. Problem jest rzeczywisty i w praktyce jest już niemal rozwiązany.
Odpowiedniość: który kandydat nadaje się do tego zadania?
Wyszukiwanie zwraca kilka kandydatów, więc który powinien wybrać agent? Sami autorzy ARD twierdzą, że porównanie z DNS tutaj nie działa: zapytanie daje kandydatów, a nie jeden autorytatywny adres, przy czym każda usługa stosuje własne zasady zaufania i rankingu. Pozostawienie tego otwartego jest rozsądne dla młodej specyfikacji. Nie jest to jednak rozsądne w przypadku Twojej implementacji, ponieważ ranking jest dokładnie tym miejscem, gdzie atakujący chciałby się wtrącić, podobnie jak przy zatruwaniu silników wyszukiwania lub typosquattingu w rejestrach pakietów.
Status: czy jest obecnie zatwierdzony?
Tutaj AWS wykazuje największą siłę: stany cyklu życia w połączeniu z wydarzeniami zapewniają dobrze sformułowaną odpowiedź, bardziej rozwiniętą niż cokolwiek innego w tych systemach. Słabością jest to, że zatwierdzenia mogą ulegać przestarzeniu. Załóżmy, że dana pozycja została wykryta automatycznie, zatwierdzona w marcu, a następnie zignorowana. Do września system nadal będzie ją traktował z takim samym przekonaniem, jakby kurator sprawdził ją dziś rano.
Pochodzenie: kto to napisał i co się zmieniło?
Kto stworzył tę funkcjonalność, co zmieniło się od ostatniego sprawdzenia oraz co jest ładowane podczas uruchamiania? Żadne z aktualnych wydań nie odpowiada na te pytania, a to właśnie stanowi podstawę finansowania AIR. Ich argument, który pozostaje aktualny, brzmi, że weryfikacja musi być ciągła, a nie jednorazowa. Umiejętność, która przeszła weryfikację miesiąc temu, może stać się szkodliwa po aktualizacji zależności lub przejęciu konta administratora, przy czym jej wpis w katalogu pozostaje dokładnie taki sam. Badania akademickie wskazują na to samo. Najnowsze badania nad podstawami agentów opartych na umiejętnościach (arXiv 2608.29596) opisują cykl życia składający się z dziewięciu etapów i umieszczają publiczne rejestry, platformy handlowe oraz przeciwników w centrum architektury, zamiast traktować je jako elementy dodatkowe.
Problemy związane z wyszukiwaniem versus problemy łańcucha dostaw
Pierwsze dwa pytania dotyczą wyszukiwania. Ostatnie dwa dotyczą łańcucha dostaw, a branża już kiedyś miała do czynienia z tym problemem w przypadku rozszerzeń przeglądarki, obrazów bazowych kontenerów oraz pakietów npm. W każdym z tych przypadków katalogi istniały na długo przed tym, jak ktokolwiek mógł zagwarantować zawartość w nich, a incydenty bezpieczeństwa koncentrowały się właśnie w tym okresie.
Ostatnia zweryfikowana próba
To sprawdzenie jest celowo proste, ponieważ odpowiedź ma większe znaczenie niż sama platforma. Weź swój obecny wykaz możliwości agentów – czy to odpowiedni rejestr, czy zwykła tabela – i wybierz dowolną pozycję. Następnie poszukaj dwóch dat:
- Kiedy została ona zatwierdzona?
- Kiedy ostatnio ktoś, osoba lub zautomatyzowana procedura, porównał ją ze źródłem?
Gdy te daty są identyczne, masz do czynienia z katalogiem, a nie z płaszczyzną sterowania. Pierwsza odnotowuje decyzję podjętą w przeszłości; druga odzwierciedla obecną rzeczywistość. Zlicz dni pomiędzy tymi dwoma datami – tyle czasu funkcja, którą ktoś zatwierdził, a potem zapomniał o niej, mogła być swobodnie modyfikowana bez żadnej reakcji. Biorąc pod uwagę, że około jednej czwartej umiejętności dostępnych publicznie nie przechodzi podstawowej weryfikacji, ta liczba stanowi wiarygodną miarę rzeczywistego ryzyka.
wiele zespołów nie ma drugiej daty do pokazania. To właśnie ta brakująca informacja jest prawdziwym problemem – chodzi nie o złą wartość, lecz o brakujące pole.
Co robić w tym kwartale
Praktyczny plan składa się z trzech części, ułożonych według stopnia wymaganej pracy.
- Przyjmij rejestr. Inwentaryzacja stanowi poważny problem, a nieśledzony agent jest bardziej niebezpieczny niż nieśledzona subskrypcja SaaS, ponieważ działa samodzielnie. Zespoły już pracujące na Bedrocku powinny dokładnie rozważyć opcję AWS; ci, którzy potrzebują federacji i neutralności dostawcy, mogą wolać ARD.
- Dodaj pole, którego brakuje w rejestrze. Przypisz każdej pozycji datę ostatniej weryfikacji, którą aktualizuje zautomatyzowany proces, a nie człowiek. Zdecyduj z góry, co powinno uruchomić procedurę aktualizacji: wygaśnięcie, kwarantanna czy alert. Każda z tych opcji jest lepsza od obecnego typowego zachowania, przy którym przestarzała pozycja pozostaje aktywna przez nieskończony czas.
Cennym uzupełnieniem tego planu jest warstwa kontroli w czasie wykonywania, która decyduje, co dana odkryta funkcjonalność może faktycznie robić; uprawnienia, bariery zatwierdzenia i poziomy ryzyka dla agentów omawia ten aspekt.
Główne wnioski
- Rejestry oraz specyfikacje mechanizmów odkrywania teraz dosyć dobrze odpowiadają na pytania „co istnieje” oraz „czy jest to zatwierdzone”.