Kong udostępnił Kong AI Gateway 2.0, co stanowi kolejny krok w przejściu od prostego proxy LLM w stronę szerszej płaszczyzny kontroli modeli, agentów, narzędzi i wydatków na sztuczną inteligencję.
Wersja z 1 września wprowadza kilka funkcji ważnych dla zespołów już korzystających z produkcyjnych obciążeń AI: łączenie serwerów MCP w celu kontrolowanego dostępu do narzędzi, dynamiczne zarządzanie kosztami uwzględniające różne modalności, szerszy zasięg modeli i dostawców, zasady sztucznej inteligencji uwzględniające tożsamość oraz natywne uwierzytelnianie IAM dla Amazon Bedrock AgentCore. Kong twierdzi również, że produkt jest teraz dostępny w Kong Konnect bez obsługi wersji beta.
To połączenie to nowość. Kategoria bramy AI nie polega już tylko na przyjmowaniu żądania w stylu OpenAI, przekazywaniu go dostawcy i rejestrowaniu odpowiedzi. Klienci korporacyjni coraz częściej chcą, aby brama decydowała o tym, kto może wywołać jaki model, do jakich narzędzi agent może dotrzeć, w jaki sposób należy mierzyć wydatki i w jaki sposób te decyzje odnoszą się do systemów tożsamości już używanych przez firmę.
Co zmieniło się w Kong AI Gateway 2.0
Najbardziej godnym uwagi dodatkiem jest łączenie serwerów MCP. MCP, czyli Model Context Protocol, stał się powszechnym sposobem udostępniania narzędzi i zasobów agentom AI. Łączenie serwerów MCP w warstwie bramy zapewnia zespołom ds. platform miejsce do agregowania i zarządzania połączeniami narzędzi, zamiast pozostawiania każdemu zespołowi aplikacji okablowania i nadzorowania integracji własnych agentów.
To znaczący kierunek produktu. W miarę jak agenci przechodzą od wersji demonstracyjnych do wewnętrznych przepływów pracy, ryzyko jest mniejsze w przypadku modelu, który źle odpowie na jedno pytanie, a w większym w przypadku połączenia modelu ze zbyt wieloma narzędziami przy zbyt małym nadzorze. Brama, która może pakietować i kontrolować dostęp MCP, jest bliższa problemowi operacyjnemu: którzy agenci mogą uzyskać dostęp do jakich systemów, w ramach czyjej tożsamości i w ramach jakich granic polityki.
Kong dodał także dynamiczne zarządzanie kosztami uwzględniające modalność. Ma to znaczenie, ponieważ wycena sztucznej inteligencji nie jest już oparta na pojedynczym liczniku tokenowym. Tekst, obraz, dźwięk, wideo, wywołania narzędzi, kontekst w pamięci podręcznej i tryby rozumowania mogą wiązać się z różnymi kosztami w zależności od dostawcy. Warstwa kontroli kosztów, która rozumie modalność, może zapewnić zespołom dokładniejsze limity i reguły routingu niż ogólny licznik żądań.
W tej wersji rozszerza się także zakres modeli i dostawców oraz dodaje zasady sztucznej inteligencji uwzględniające tożsamość. Natywne uwierzytelnianie IAM firmy Kong dla Amazon Bedrock AgentCore jest szczególnie istotne, ponieważ Bedrock AgentCore staje się jednym z miejsc, w których przedsiębiorstwa uruchamiają agentów i zarządzają nimi. Połączenie zasad dotyczących bram z tożsamością w chmurze zmniejsza rozbieżność między kontrolami specyficznymi dla sztucznej inteligencji a systemami dostępu, które firmy już kontrolowały.
Dlaczego ma to znaczenie dla programistów i zespołów platform
Dla programistów praktyczny efekt jest taki, że brama staje się częścią architektury aplikacji, a nie tylko dodatkiem do infrastruktury. Zespół tworzący wewnętrznego agenta wsparcia, asystenta kodowania lub przepływ pracy w ramach analizy danych może teraz potrzebować reguł bramy dotyczących dostępu do modelu, dostępu do narzędzi, progów budżetowych i propagacji tożsamości, zanim aplikacja trafi do środowiska produkcyjnego.
Może to zwiększyć koszty konfiguracji, ale rozwiązuje również problem rzeczywistej awarii. Bez wspólnej warstwy bramy wybór modelu, poświadczenia dostawcy, uprawnienia narzędzi i kontrola wydatków zwykle rozprzestrzeniają się na kod aplikacji, klucze CI, opakowania SDK i pulpity nawigacyjne specyficzne dla zespołu. Ta fragmentacja utrudnia badanie incydentów i wykonywanie migracji modeli.
Wydanie Konga jest także sygnałem dla dostawców tworzących warstwy API kompatybilne z OpenAI i wielomodelowe produkty API. Stawką staje się sama kompatybilność. Klienci coraz częściej oczekują zarządzania wokół żądania: egzekwowania zasad, analityki użycia, dostępu na poziomie zespołu, kontroli budżetu, routingu awaryjnego i widoczności modelu/dostawcy.
Dla użytkowników Model Gate połączenie jest bezpośrednie. Ujednolicone fakturowanie, zarządzanie kluczami API, analityka użycia i kontrola zespołowa stają się bardziej wartościowe, gdy dostęp do modelu jest tylko jedną częścią przepływu pracy. Gdy agenci uzyskają dostęp do narzędzi za pośrednictwem interfejsów w stylu MCP, bramy będą musiały reprezentować nie tylko, który model został wywołany, ale także zaangażowany zespół, klucz, pakiet narzędzi i kontekst polityki.
Zmienia się punkt odniesienia dla konkurencji
Kong nie jest osamotniony w tym kierunku. Ostatnie ruchy na rynku pokazują, że dostawcy infrastruktury AI skupiają się na tym samym szerszym problemie: sztuczna inteligencja w przedsiębiorstwie potrzebuje regulowanej ścieżki między użytkownikami, modelami, agentami, narzędziami i wydatkami. Produkty Gateway są oceniane w mniejszym stopniu pod kątem możliwości normalizacji formatów żądań, a bardziej pod kątem tego, czy mogą wspierać kontrolę produkcji.
Wywiera to presję na kupujących, aby zadawali ostrzejsze pytania. Czy bramka rozumie ceny i warunki specyficzne dla dostawcy? Czy administratorzy mogą ustalać zasady według zespołu lub tożsamości? Czy może kierować między dostawcami bez utraty możliwości kontroli?Czy może zarządzać narzędziami agenta, a nie tylko modelować punkty końcowe? Czy może ujawnić dane dotyczące użytkowania i kosztów w sposób, w jaki mogą to wykorzystać finanse, bezpieczeństwo i inżynieria?
Te pytania nie są już teoretyczne. Modele o długim kontekście, wywołania narzędzi agentów i obciążenia multimodalne mogą szybko zmieniać profile kosztów. Przepływ pracy, który podczas testowania wygląda na tani, może stać się kosztowny, gdy do produkcji wejdą powtarzające się konteksty, dane wejściowe obrazu lub pętle agentów wymagające dużej liczby narzędzi. Brama, która nie potrafi rozróżnić tych wzorców, może nadal scentralizować dostęp, ale nie zapewni operatorom wystarczającej kontroli.
Co pozostaje niepewne
W ogłoszeniu ustala się ogólną dostępność i wymienia kluczowe funkcje, ale faktyczne przyjęcie będzie zależeć od szczegółów implementacji: sposobu, w jaki zespoły konfigurują pakiety MCP, stopnia szczegółowości zasad uwzględniających tożsamość, sposobu kontroli kosztów u różnych dostawców i tego, jaką widoczność operacyjną uzyskają klienci w praktyce.
Jest też zbyt wcześnie, aby wiedzieć, czy przedsiębiorstwa ujednolicą zarządzanie agentami w jednej bramie AI lub podziel odpowiedzialność na platformy chmurowe, narzędzia bezpieczeństwa, platformy programistyczne i dostawców obserwowalności. AWS, platformy hostingowe, dostawcy IDE i autonomiczni dostawcy bram starają się posiadać części tej samej powierzchni kontrolnej.
Mimo to kierunek jest jasny. Kong AI Gateway 2.0 traktuje ruch AI jako zarządzany system przedsiębiorstwa, a nie strumień wywołań modelowych. Dla programistów i firm korzystających z modelowych interfejsów API oznacza to, że decyzje dotyczące bram stają się decyzjami dotyczącymi architektury: wpływają na koszty, bezpieczeństwo, wybór modelu, dostęp do narzędzi i niezawodność przepływów pracy agentów.