Dema wieloagentowe są teraz wszędzie.
Problem polega na tym, że wiele z nich zatrzymuje się tuż przed częścią, która boli w prawdziwym życiu: kształt wdrożenia, okablowanie usług, stan zdrowia, telemetria, granice wykonawcze i zwykły chaos systemów rozproszonych.
Dlatego nowy przykład Aspire + Microsoft Agent Framework jest wart uwagi.
Nie, interesującą częścią nie jest scenariusz konsjerża ośrodka narciarskiego.
Interesującą częścią jest to, że przykład pokazuje znacznie bardziej realistyczny wzorzec budowania rozproszonego systemu agentowego z:
- niestandardowymi hostowanymi agentami
- agentami promptowymi
- wieloma środowiskami wykonawczymi
- referencjami usług
- żywymi źródłami danych
- obserwowalnością i strukturą wdrożenia
To jest prawdziwa historia.
To więcej niż „agent, który używa narzędzi"
Architektura w przykładzie wykracza poza znajomy model agenta z pojedynczą pętlą.
Masz:
- agentów specjalistycznych z wąskimi odpowiedzialnościami
- agentów doradczych, którzy ich orkiestrują
- zasoby zarządzane przez Foundry
- usługi .NET, Python i Go w tym samym grafie
- punkty wejścia głosowe i czatowe
To znacznie bliższe temu, jak poważne systemy agentowe będą faktycznie wyglądać w praktyce.
I tutaj Aspire nagle staje się bardzo ważne.
Aspire robi trudną część, którą ludzie zwykle trzymają w głowach
To, co lubię najbardziej, to nawet nie logika agenta. To fakt, że graf aplikacji jest jawny.
Aspire jest używane do opisania:
- które usługi istnieją
- od czego zależą
- jakich wdrożeń modeli potrzebują
- jakiego środowiska wykonawczego używa każda usługa
- jakie relacje zdrowia i wdrożenia istnieją
To ma znaczenie, ponieważ rozproszone systemy agentowe szybko robią się nieuporządkowane. Jeśli topologia istnieje tylko w głowach ludzi i przypadkowych dokumentach konfiguracyjnych, twój system staje się natychmiast kruchy.
Umieszczenie tej topologii w AppHost to ogromny krok w kierunku czegoś odtwarzalnego.
Agenci specjaliści jako narzędzia to wciąż wzorzec do obserwowania
Jedną z moich ulubionych części architektury jest sposób, w jaki agenci specjaliści są udostępniani jako wywoływalne możliwości dla orkiestratora.
Ten wzorzec pojawia się nie bez powodu. Daje ci:
- separację odpowiedzialności
- lepsze granice domenowe
- jaśniejszą obserwowalność
- łatwiejszą wymianę jednego specjalisty bez przepisywania wszystkiego
Dla zespołów .NET to znacznie zdrowszy model mentalny niż budowanie gigantycznego wszechwiedzącego agenta i liczenie, że instrukcje prompta utrzymają go stabilnym.
Moje zdanie
Ważną rzeczą, którą ten przykład udowadnia, nie jest to, że aplikacje wieloagentowe są możliwe. Już to wiedzieliśmy.
Udowadnia, że stos Microsoftu zaczyna oferować spójną odpowiedź na następne pytanie:
jak budować systemy wieloagentowe, które wciąż są operable?
Aspire dla grafu. Agent Framework dla abstrakcji wykonawczych. Foundry dla zarządzanych zasobów AI i hostingu. Ta kombinacja zaczyna wydawać się mniej eksperymentalna, a bardziej jak prawdziwa historia platformy.
To jest to, co bym tutaj obserwował.
Oryginalny wpis: Distributed multi-agent systems with Aspire and Microsoft Agent Framework
