W krajobrazie cyfrowym dokonuje się ewolucja od przeglądania stron internetowych zorientowanego na człowieka do sfery autonomicznych agentów, którzy bezproblemowo współpracują w różnych systemach. Ta zmiana wymaga nowej infrastruktury, a kształtuje się przekonujące rozwiązanie, składające się z czterech kluczowych komponentów open-source.
- Agent2Agent (A2A) firmy Google: Protokół zaprojektowany w celu ułatwienia wykrywania i interakcji agentów.
- Model Context Protocol (MCP) firmy Anthropic: Standard definiujący, w jaki sposób agenci wykorzystują narzędzia i zewnętrzne dane kontekstowe.
- Apache Kafka: Solidny, oparty na zdarzeniach szkielet komunikacyjny, umożliwiający niezawodną i rozproszoną koordynację.
- Apache Flink: Silnik przetwarzania w czasie rzeczywistym, niezbędny do wzbogacania, monitorowania i reagowania na strumienie aktywności agentów.
Ten artykuł bada synergiczne relacje między tymi technologiami, podkreślając ograniczenia polegania wyłącznie na protokołach i demonstrując, w jaki sposób ta architektura kładzie podwaliny pod przejście od izolowanych botów do dynamicznych, inteligentnych ekosystemów agentów.
Oczekiwana proliferacja agentów AI w organizacjach sugeruje, że większość firm wdroży wiele wyspecjalizowanych agentów zamiast jednego wszechstronnego. Agenci ci będą automatyzować zadania, takie jak generowanie kodu, zarządzanie zgłoszeniami serwisowymi, analiza danych klientów, wdrażanie pracowników i monitorowanie infrastruktury.
Jednak obecne narzędzia są nieodpowiednie do wspierania takiej przyszłości.
Wyzwanie wykracza poza problem ‘wyspy agentów’, gdzie agenci działają w silosach i brakuje im możliwości komunikacji. Obejmuje ono bardziej rozległą fragmentację ekosystemu:
- Brak komunikacji między agentami: Agenci zazwyczaj działają w izolowanych środowiskach. Agent zarządzania relacjami z klientami (CRM) nie jest świadomy spostrzeżeń uzyskanych przez agenta hurtowni danych. Agent wsparcia nie może reagować na anomalie wykryte przez agenta monitorującego.
- Kruche i dostosowane użycie narzędzi: Bez ustandaryzowanych metod dostępu do narzędzi lub zewnętrznych interfejsów programowania aplikacji (API), agenci polegają na zakodowanych integracjach i logice, której nie można ponownie wykorzystać.
- Niespójne ramy: Różne środowiska uruchomieniowe agentów wykorzystują różnorodne modele, traktując agentów jako chatboty, skierowane grafy acykliczne (DAG) lub rekurencyjne planery. Powoduje to brak przenośnej warstwy wykonawczej lub stanu współdzielonego.
- Projekt skoncentrowany na środowiskach Notebook: Wielu agentów jest rozwijanych jako jednorazowe prototypy, charakteryzujące się liniowymi, synchronicznymi i efemerycznymi operacjami. Jednak systemy w świecie rzeczywistym wymagają solidnej obsługi ponowień, awarii, koordynacji, rejestrowania i skalowania, co wymaga infrastruktury wspierającej.
- Brak szkieletu współpracy: Nie ma magistrali zdarzeń, pamięci współdzielonej ani identyfikowalnej historii działań i uzasadnień agenta. Informacje są ograniczone do bezpośrednich wywołań HTTP lub zakopane w dziennikach.
Jak podkreślono w projekcie 12-Factor Agents, agenci powinni przestrzegać zasad natywnych dla chmury, wykazując obserwowalność, luźne sprzężenie, powtarzalność i świadomość infrastruktury. Niestety, większość z nich jest konstruowana jako kruche skrypty, ręcznie montowane i zakładane, że działają niezależnie.
Powoduje to nieefektywność, powielanie wysiłków i kruchość.
Agent2Agent częściowo rozwiązuje ten problem, zapewniając agentom ustandaryzowany protokół do wykrywania i komunikacji. Jednak przejście poza powierzchowne demonstracje do skalowalności i niezawodności wymaganej przez systemy produkcyjne wymaga więcej niż tylko protokołów. Wymaga to kompleksowej infrastruktury.
Obecny ekosystem agentów odzwierciedla wczesne etapy rozwoju sieci, charakteryzujące się potężnymi, ale izolowanymi i niekompatybilnymi systemami. Podobnie jak w przypadku wczesnych wyzwań, przed którymi stanęli przeglądarki komunikujące się z serwerami bez standardowego protokołu, agenci AI dziś walczą o skuteczne wykrywanie, komunikowanie się i współpracę ze sobą.
Agent2Agent (A2A) firmy Google: Uniwersalny protokół do komunikacji agentów
Protokół A2A firmy Google jest znaczącą próbą rozwiązania tego problemu. Wyróżnia się tym, że nie jest kolejną strukturą agenta, ale raczej uniwersalnym protokołem zaprojektowanym do łączenia dowolnego agenta, niezależnie od jego pochodzenia lub środowiska wdrożeniowego.
Analogicznie do tego, jak HTTP ustandaryzował komunikację z witrynami internetowymi, A2A definiuje wspólny język dla agentów, umożliwiając im:
- Ogłaszanie możliwości: Za pośrednictwem
AgentCard, deskryptora JSON, który określa możliwości agenta i metody interakcji. - Wysyłanie i odbieranie zadań: Poprzez ustrukturyzowane interakcje wykorzystujące JSON-RPC, gdzie jeden agent prosi o pomoc, a drugi odpowiada wynikami lub ‘artefaktami’.
- Strumieniowe aktualizacje z wykorzystaniem zdarzeń wysyłanych przez serwer (SSE): Ułatwianie informacji zwrotnych w czasie rzeczywistym podczas długotrwałych lub wspólnych zadań.
- Wymiana bogatej zawartości: Obsługa wymiany plików, danych strukturalnych i formularzy, wykraczająca poza prosty tekst.
- Utrzymywanie bezpieczeństwa domyślnie: Wbudowana obsługa HTTPS, uwierzytelniania i uprawnień.
Siła A2A polega na unikaniu ponownego wynajdowania ustalonych rozwiązań. Wykorzystuje on dobrze ugruntowane standardy internetowe, podobne do HTTP i SMTP, ułatwiając łatwiejsze wdrażanie i szybszą integrację.
Jednak A2A stanowi tylko jeden aspekt ogólnego rozwiązania.
Model Context Protocol (MCP) firmy Anthropic: Standaryzacja użycia narzędzi i dostępu do kontekstu
MCP firmy Anthropic zajmuje się kluczowym aspektem tego, w jaki sposób agenci wykorzystują narzędzia i uzyskują dostęp do informacji kontekstowych. MCP standaryzuje proces, w którym agenci wywołują interfejsy API, wywołują funkcje i integrują się z systemami zewnętrznymi, zasadniczo definiując, jak działają w swoim środowisku. Podczas gdy A2A reguluje komunikację między agentami, MCP koncentruje się na interakcji agenta ze światem zewnętrznym.
Zasadniczo:
- MCP wzmacnia indywidualną inteligencję agenta.
- A2A umożliwia inteligencję zbiorową.
Podobnie jak HTTP i SMTP wymagały szerokiego wdrożenia, infrastruktury i narzędzi programistycznych, aby osiągnąć powszechny sukces, A2A i MCP będą wymagały solidnego ekosystemu, aby w pełni zrealizować swój potencjał.
Nawet przy wysiłkach standaryzacyjnych, takich jak A2A i MCP, pozostaje kluczowe pytanie: jak skutecznie skalować komunikację agentów w złożonych i dynamicznych środowiskach korporacyjnych? Poleganie wyłącznie na bezpośrednich połączeniach typu punkt-punkt zdefiniowanych przez te protokoły wprowadza wyzwania związane ze skalowalnością, odpornością i obserwowalnością. Podkreśla to potrzebę solidnej podstawowej infrastruktury komunikacyjnej.
Rozważ firmę, w której pracownicy mogą komunikować się tylko za pośrednictwem bezpośrednich wiadomości jeden na jednego. Udostępnienie aktualizacji wymagałoby oddzielnego wysyłania wiadomości do każdej osoby. Koordynacja projektu w wielu zespołach wiązałaby się z ręcznym przekazywaniem informacji między każdą grupą.
Skalowanie takiego systemu do setek pracowników spowodowałoby chaos.
Ten scenariusz odzwierciedla wyzwania stojące przed ekosystemami agentów zbudowanymi na bezpośrednich połączeniach. Każdy agent musi wiedzieć, z którymi agentami się skontaktować, jak się z nimi skontaktować i jaka jest ich dostępność. Wraz ze wzrostem liczby agentów liczba wymaganych połączeń rośnie wykładniczo, co prowadzi do kruchego, trudnego do zarządzania i nieskalowalnego systemu.
A2A i MCP zapewniają agentom język i strukturę do komunikacji i działania. Jednak sam język jest niewystarczający. Aby koordynować liczne agenty w całym przedsiębiorstwie, potrzebna jest infrastruktura do zarządzania przepływem wiadomości i odpowiedziami agentów.
Kafka i Flink: Szkielet do skalowalnej współpracy agentów
Apache Kafka i Apache Flink zapewniają tę kluczową infrastrukturę.
Kafka i Flink wyjaśnione
Apache Kafka, pierwotnie opracowany w LinkedIn, a obecnie projekt Apache Software Foundation, jest rozproszoną platformą do strumieniowego przesyłania zdarzeń. Działa jako trwała, wysokoprzepustowa magistrala komunikatów, umożliwiająca systemom publikowanie i subskrybowanie strumieni zdarzeń w czasie rzeczywistym. Kafka jest szeroko stosowana w różnych aplikacjach, w tym w systemach finansowych, wykrywaniu oszustw i potokach telemetrycznych, ze względu na jej zdolność do oddzielania producentów od konsumentów i zapewnienia trwałości danych, możliwości odtwarzania i skalowalności.
Flink, kolejny projekt Apache, to silnik przetwarzania strumieni w czasie rzeczywistym, przeznaczony do stanowego, wysokoprzepustowego i niskiego opóźnienia przetwarzania zdarzeń. Podczas gdy Kafka zarządza ruchem danych, Flink obsługuje transformację, wzbogacanie, monitorowanie i orkiestrację danych, gdy przepływają one przez system.
Razem Kafka i Flink tworzą potężną kombinację. Kafka służy jako krwiobieg, a Flink działa jak system odruchów.
Analogicznie do roli A2A jako HTTP świata agentów, Kafka i Flink zapewniają oparte na zdarzeniach podstawy do skalowalnej komunikacji i obliczeń agentów, rozwiązując wyzwania, których bezpośrednia komunikacja typu punkt-punkt nie może:
- Oddzielenie: Dzięki Kafce agenci nie muszą znać odbiorców ich danych wyjściowych. Publikują zdarzenia (np.
"TaskCompleted","InsightGenerated") w temacie, umożliwiając każdemu zainteresowanemu agentowi lub systemowi subskrybowanie. - Obserwowalność i możliwość odtwarzania: Kafka utrzymuje trwały, uporządkowany chronologicznie dziennik wszystkich zdarzeń, zapewniając, że zachowanie agenta jest w pełni identyfikowalne, audytowalne i odtwarzalne.
- Decydowanie w czasie rzeczywistym: Flink umożliwia agentom reagowanie w czasie rzeczywistym na strumienie zdarzeń, filtrowanie, wzbogacanie, łączenie lub wyzwalanie działań w oparciu o dynamiczne warunki.
- Odporność i skalowanie: Zadania Flink mogą skalować się niezależnie, odzyskiwać sprawność po awariach i utrzymywać stan w długotrwałych przepływach pracy, co jest niezbędne dla agentów wykonujących złożone, wieloetapowe zadania.
- Koordynacja natywna dla strumieni: Zamiast czekać na synchroniczne odpowiedzi, agenci mogą koordynować się za pośrednictwem strumieni zdarzeń, publikując aktualizacje, subskrybując przepływy pracy i wspólnie rozwijając stan.
Podsumowując:
- A2A definiuje, jak komunikują się agenci.
- MCP definiuje, jak wchodzą w interakcje z narzędziami zewnętrznymi.
- Kafka definiuje, jak przepływają ich wiadomości.
- Flink definiuje, jak te przepływy są przetwarzane, przekształcane i wykorzystywane do podejmowania decyzji.
Protokoły takie jak A2A i MCP są kluczowe dla standaryzacji zachowania i komunikacji agentów. Jednak bez podłoża opartego na zdarzeniach, takiego jak Kafka, i środowiska uruchomieniowego natywnego dla strumieni, takiego jak Flink, agenci pozostają odizolowani, niezdolni do skutecznej koordynacji, efektywnego skalowania lub rozumowania w czasie.
Czterowarstwowa architektura dla agentów AI klasy korporacyjnej
Aby w pełni zrealizować wizję interoperacyjnych agentów AI klasy korporacyjnej, wymagana jest czterowarstwowa architektura:
- Protokoły: A2A, MCP – definiowanie co.
- Ramy: LangGraph, CrewAI, ADK – definiowanie jak.
- Infrastruktura przesyłania wiadomości: Apache Kafka – obsługuje przepływ.
- Obliczenia w czasie rzeczywistym: Apache Flink – obsługuje myślenie.
Razem te warstwy tworzą nowy stos internetowy dla agentów AI, zapewniając podstawy do budowania systemów, które są nie tylko inteligentne, ale także oparte na współpracy, obserwowalne i gotowe do produkcji.
Jesteśmy obecnie w kluczowym momencie ewolucji oprogramowania.
Podobnie jak oryginalny stos internetowy – składający się z protokołów takich jak HTTP i SMTP oraz infrastruktury takiej jak TCP/IP – zapoczątkował erę globalnej łączności, tak nowy stos wyłania się dla agentów AI. Jednak zamiast ludzi nawigujących po stronach internetowych lub wysyłających e-maile, ten stos jest przeznaczony dla autonomicznych systemów współpracujących w celu rozumowania, podejmowania decyzji i działania.
A2A i MCP zapewniają protokoły do komunikacji agentów i korzystania z narzędzi, podczas gdy Kafka i Flink zapewniają infrastrukturę do koordynacji w czasie rzeczywistym, obserwowalności i odporności. Razem umożliwiają przejście od odłączonych demonstracji agentów do skalowalnych, inteligentnych ekosystemów klasy produkcyjnej.
Ta ewolucja nie polega wyłącznie na rozwiązywaniu wyzwań inżynieryjnych. Chodzi o umożliwienie nowego paradygmatu oprogramowania, w którym agenci współpracują ponad granicami, dostarczając spostrzeżenia i napędzając działania w czasie rzeczywistym, umożliwiając w ten sposób inteligencji stanie się rozproszonym systemem.
Jednak ta wizja wymaga aktywnego rozwoju, kładącego nacisk na otwartość, interoperacyjność i wykorzystanie doświadczeń zdobytych podczas poprzedniej rewolucji internetowej.
Dlatego opracowując agenta, należy wziąć pod uwagę jego integrację w szerszym systemie. Czy może skutecznie się komunikować? Czy może koordynować się z innymi agentami? Czy może ewoluować i dostosowywać się do zmieniających się warunków?
Przyszłość to nie tylko przyszłość zasilana przez agentów; to przyszłość połączona z agentami.