Co to są hostowani agenci?

Podczas kompilowania aplikacji agentów przy użyciu platform typu open source zwykle zarządza się wieloma problemami krzyżowymi: konteneryzacją, konfiguracją serwera internetowego, zabezpieczeniami, trwałością pamięci, skalowaniem, instrumentacją i wycofywaniem wersji. Te zadania stają się jeszcze trudniejsze w heterogenicznych środowiskach chmury.

Hostowani agenci w usłudze Foundry Agent rozwiązują te wyzwania dla użytkowników Microsoft Foundry. Hostowani agenci wywołują modele z katalogu modeli Foundry, aby przeprowadzać rozumowanie, podczas gdy niestandardowy kod obsługuje koordynację. Korzystając z tej zarządzanej platformy, można bezpiecznie i na dużą skalę wdrażać i obsługiwać agentów sztucznej inteligencji. Możesz użyć niestandardowego kodu agenta lub preferowanego frameworku agenta z usprawnionym wdrażaniem i zarządzaniem.

Jeśli eksplorujesz hostowanych agentów za pomocą agenta kodowania sztucznej inteligencji, umiejętności Microsoft Foundry mogą pomóc w połączeniu tych pojęć z zadaniami implementacji, wdrażania i operacji.

Kiedy używać hostowanych agentów

Wybierz agentów hostowanych zamiast agentów opartych na promptach, gdy chcesz:

• Przynieś swój kod — użyj dowolnej struktury (Agent Framework, LangGraph, Semantic Kernel lub niestandardowego kodu) zamiast definicji zdefiniowanych tylko za pomocą monitu.
• Użyj protokołów niestandardowych — akceptuj webhooki lub ładunki inne niż z OpenAI za pośrednictwem protokołu Invocations.
• Kontrolowanie zasobów obliczeniowych — określ procesor i pamięć dla piaskownicy agenta.
• Uruchamianie obciążeń stanowych — utrwalanie plików i stanu pomiędzy sesjami przez $HOME i punkt końcowy /files.
• Uruchamiaj długotrwałe zadania w sposób odporny na zakłócenia — zachowuj trwające zadania agenta mimo przerwań procesu i odtwarzaj strumieniowane wyniki klientom, którzy połączyli się ponownie.

Jak to działa

Agent opakowujesz jako obraz kontenera i wgrywasz go do Azure Container Registry. Podczas wdrażania usługa agenta ściąga obraz, przypisuje dedykowany Microsoft Entra ID (tożsamość agenta) i uwidacznia dedykowany punkt końcowy dla agenta.

W czasie działania usługa Agent Service przydziela zasoby obliczeniowe na potrzeby sesji i kieruje żądania do Twojego kontenera. Kod agenta obsługuje te żądania i może wywoływać modele Foundry, narzędzia Toolbox oraz usługi podrzędne platformy Azure za pomocą tożsamości agenta. Platforma obsługuje skalowanie, trwałość stanu sesji, obserwowanie i zarządzanie cyklem życia.

Na poniższym diagramie przedstawiono sposób podziału odpowiedzialności. Jesteś właścicielem kodu, który jest uruchamiany w piaskownicy. Platforma odpowiada za punkt końcowy, tożsamość, skalowanie i stan sesji.

Kluczowe pojęcia

Hostowani agenci

Hostowane aplikacje agentowe to konteneryzowane aplikacje sztucznej inteligencji, które działają na Usłudze Agenta. W przeciwieństwie do agentów opartych na promptach — definiowanych w całości za pomocą promptów i konfiguracji narzędzi w portalu Foundry — agenci hostowani to własny kod użytkownika spakowany w obraz kontenera. Wybierasz strukturę, kontrolujesz zachowanie środowiska uruchomieniowego i wdrażasz obraz w infrastrukturze zarządzanej Microsoft.

Platforma automatycznie zarządza cyklem życia kontenera na podstawie działań, aprowizowania zasobów podczas tworzenia wersji i anulowania aprowizacji po osiągnięciu limitu czasu bezczynności.

Model izolacji

Hostowane agenty są uruchamiane w piaskownicach izolowanych w sesji przez maszyny wirtualne. Każda sesja otrzymuje dedykowaną piaskownicę z trwałym systemem plików ($HOME i /files), umożliwiając skalowanie do zera z wznawianiem ze stanem i przewidywalnymi zimnymi startami. Sesje są odizolowane od siebie, a stan jest automatycznie przywracany po wznowieniu sesji po przejściu bezczynności.

Protokoły: Odpowiedzi, Wywołania i Wywołania (WebSocket)

Hostowane kontenery agentów mogą uwidaczniać jeden lub więcej protokołów. Każdy protokół jest dostarczany przez uproszczoną bibliotekę, która obsługuje serwer HTTP lub WebSocket, kontrole kondycji i integrację biblioteki OpenTelemetry. Protokoły Responses, Invocations i Invocations (WebSocket) są dostępne we wszystkich regionach, które obsługują hostowanych agentów.

Którego protokołu należy użyć?

Wybrany protokół określa ładunek odbierany przez kontener oraz ilość sesji, przesyłania strumieniowego i cyklu życia w tle, którymi zarządza platforma. Jeden agent może obsługiwać więcej niż jeden protokół, więc ten wybór nie jest trwały. Użyj następującego drzewa decyzyjnego, aby wybrać punkt początkowy.

Porównanie protokołów

Tryb w tle i odporne wykonywanie rozwiązuje różne problemy. Tryb w tle umożliwia kontynuowanie pracy po powrocie żądania inicjującego. Wykonywanie odporne zachowuje pracę po zatrzymaniu procesu hostingu. Aby uzyskać informacje na temat modelu odzyskiwania po awarii i zakresu odpowiedzialności aplikacji, zobacz Odporność agentów hostowanych działających przez długi czas.

Dodatkowe protokoły

Hostowani agenci obsługują również protokół Activity dla Microsoft Teams i integracji z kanałami Microsoft 365. Jeśli używasz protokołu Odpowiedzi dla logiki agenta i publikujesz do kanałów Microsoft 365, takich jak Teams, platforma automatycznie łączy Odpowiedzi z protokołem Działania w celu dostarczania przez kanał — nie jest wymagane oddzielne okablowanie. Protokół A2A obsługuje delegowanie agenta do agenta. Obsługiwane protokoły można łączyć w jednym agencie.

Tożsamość agenta i punkt końcowy

Każdy hostowany agent wdrożony w projekcie Foundry pobiera własny dedykowany Microsoft Entra ID (tożsamość agenta) i dedykowany punkt końcowy — oba tworzone automatycznie podczas wdrażania. Nie trzeba konfigurować tożsamości zarządzanych ani routingu ręcznie.

Punkt końcowy jest dostępny natychmiast po wdrożeniu — publikowanie nie jest wymagane w przypadku dostępu programowego:

• Odpowiedzi: {project_endpoint}/agents/{name}/endpoint/protocols/openai/responses
• Wywołania: {project_endpoint}/agents/{name}/endpoint/protokoly/wywolania (invocations)
• Wywołania (WebSocket): wss://{account}.services.ai.azure.com/api/projects/{project}/agents/{name}/endpoint/protocols/invocations_ws?api-version=v1
• A2A v1.0 (GA) i v0.3 (wersja zapoznawcza): {project_endpoint}/agents/{name}/endpoint/protocols/a2a

Aktywne punkty końcowe zależą od protokołów zadeklarowanych w definicji wersji agenta. Ustaw tę definicję w usłudze azure.ai.agent w azure.yaml, gdy używasz azd, lub za pośrednictwem protocol_versions, gdy używasz zestawu SDK.

Są zaangażowane dwie tożsamości:

Tożsamość agenta może domyślnie uzyskiwać dostęp do wnioskowania modelu za pośrednictwem punktu końcowego projektu i magazynu sesji. W przypadku zasobów zewnętrznych (na przykład własnego konta usługi Azure Storage) ręcznie przypisz role RBAC do tożsamości Microsoft Entra ID agenta. Aby uzyskać więcej informacji, zobacz Dostęp agenta poza ustawieniami domyślnymi.

Po zintegrowaniu za pośrednictwem kanałów Microsoft 365 (na przykład usługi Teams) hostowani agenci mogą działać w dwóch trybach tożsamości w zależności od sposobu ich wywoływanego:

• Scenariusze wywoływane przez użytkownika (interaktywne): jeśli istnieje token użytkownika, platforma obsługuje przepływy OAuth 2.0 On-Behalf-Of (OBO). W takim przypadku agent może wywoływać usługi podrzędne w imieniu użytkownika przy użyciu delegowanych uprawnień użytkownika, z zastrzeżeniem zasad dzierżawy Microsoft Entra ID.

• Scenariusze autonomiczne lub działające w tle: Jeśli token użytkownika nie jest dostępny, agent uwierzytelnia się przy użyciu własnego identyfikatora Microsoft Entra ID (tożsamości agenta), zazwyczaj za pośrednictwem tożsamości zarządzanej, aby uzyskać dostęp do usług niższego poziomu.

W obu przypadkach agent zachowuje dedykowane Microsoft Entra ID na potrzeby uwierzytelniania, autoryzacji i możliwości inspekcji.

W przypadku delegowania użytkownika za pomocą MCP i innych narzędzi połącz te narzędzia przez zestaw narzędzi Foundry. Gdy dodajesz toolbox do hostowanego agenta utworzonego za pomocą platformy Microsoft Agent Framework, użyj FoundryToolbox w języku Python lub AddFoundryToolboxes w .NET. Zobacz Przybornik w narzędziu Foundry.

Aby uzyskać więcej informacji, zobacz Pojęcia dotyczące aplikacji agenta i tożsamości agenta.

Sesje, rozmowy i magazyn stanu

Hostowani agenci używają sesji, konwersacji i magazynu stanów do zarządzania stanem. Sposób ich działania zależy od protokołu.

Sesji

Identyfikator sesji identyfikuje sesję logiczną o utrwalonym stanie, w tym $HOME, i pliki przesłane za pośrednictwem punktu końcowego /files. Platforma udostępnia zasoby obliczeniowe na żądanie i przywraca na nie utrwalony stan.

• Trwałość stanu: zawartość $HOME i /files są utrwalane na różnych zakrętach i w okresach bezczynności. Gdy obliczenia idą bezczynnie i są przywracane (w nowej lub istniejącej infrastrukturze), stan sesji zostanie automatycznie przywrócony.
• Izolacja: każda sesja jest odizolowana od innych sesji.
• Cykl życia automatycznego: sesje są tworzone przy pierwszym użyciu. Platforma automatycznie konfiguruje i przerywa działanie zasobów obliczeniowych.
• Okres istnienia sesji: możesz skonfigurować limit czasu bezczynności dla wersji agenta z zakresu od 2 do 60 minut, z wartością domyślną 15 minut. Jeśli w tym czasie nie nadejdzie żadne żądanie, platforma zwalnia zasoby obliczeniowe i zapisuje stan sesji. Platforma trwale usuwa sesję po upływie 30 dni braku aktywności.
• Interfejsy API zarządzania sesjami: wyświetlanie listy sesji, kończenie sesji i przekazywanie lub pobieranie plików na sesję.

Rozmowy

Identyfikator konwersacji to trwały rekord historii konwersacji (wiadomości, wywołań narzędzi i odpowiedzi) przechowywany w narzędziu Foundry.

• Trwałość: historia konwersacji jest przechowywana w rozwiązaniu Foundry i utrzymuje się niezależnie od stanu obliczeniowego.
• Dostęp między kanałami: użytkownicy mogą uzyskiwać dostęp do tej samej konwersacji z poziomu placu zabaw, interfejsu API, aplikacji Teams lub innych opublikowanych kanałów.

Sklep państwowy

Magazyn stanu to trwały magazyn par klucz-wartość obsługiwany po stronie serwera dla stanu aplikacji, którym platforma nie zarządza. Magazyn przechowuje kluczowe elementy JSON i jest adresowany przez nazwę magazynu wybranego przez obiekt wywołujący.

• Trwałość: Foundry przechowuje elementy danych i zachowuje je niezależnie od stanu obliczeń, dzięki czemu przetrwają awarie kontenera, ponowne uruchomienia i usunięcie z powodu bezczynności.
• Izolacja: Każda nazwa sklepu stanowi oddzielną partycję. Repozytorium może również dzielić swoje elementy według użytkownika końcowego, dzięki czemu jedna nazwa repozytorium może być bezpiecznie współdzielona przez użytkowników agenta wielodzierżawnego.
• Okres przechowywania elementu: okno bezczynności na poziomie sklepu powoduje wygaśnięcie elementów; domyślnie wynosi 30 dni. Operacje zapisu odnawiają okno, a magazyn danych można skonfigurować tak, aby jego elementy nigdy nie wygasały.
• Dowolny framework: ponieważ ten magazyn danych jest uniwersalnym interfejsem API typu klucz-wartość, agent może go używać do przechowywania punktów kontrolnych frameworka we własnym frameworku, takim jak LangGraph lub Microsoft Agent Framework, wraz z własnym stanem aplikacji.

Aby uzyskać więcej informacji, zobacz temat Trwały magazyn stanu dla hostowanych agentów.

Jak sesje i konwersacje współpracują z każdym protokołem

Protokół odpowiedzi: identyfikator konwersacji jest podstawową koncepcją. Platforma automatycznie zarządza historią konwersacji i kojarzy identyfikator sesji z każdą konwersacją. Platforma zwraca identyfikator sesji do klienta, który może używać go do przekazywania plików za pośrednictwem punktu końcowego /files, udostępniając te pliki do obliczeń konwersacji.

Protokół wywołań: identyfikator sesji jest podstawową koncepcją. Klient zarządza identyfikatorem sesji bezpośrednio w celu zachowania stanu między interakcjami. Klient może przekazać zawartość za pośrednictwem punktu końcowego /files, używając identyfikatora sesji, aby była dostępna w ramach sesji. Nie ma historii konwersacji zarządzanych przez platformę — zarządzasz stanem we własnym kodzie.

Cykl życia obliczeń sesji

Obliczenia są zgodne z sesją, a nie z pojedynczym żądaniem. Platforma tworzy środowisko sandbox, gdy sesja się rozpoczyna, i usuwa je, gdy po ostatnim żądaniu upłynie skonfigurowany limit czasu bezczynności. Po wznowieniu sesji platforma przywraca $HOME i /files, aby kod znalazł pliki, które napisał wcześniej. Na poniższym diagramie pokazano, jak żądanie przechodzi przez te stany.

Zabezpieczenia i obsługa danych

Traktuj hostowanego agenta, takiego jak kod aplikacji produkcyjnej.

• Nie umieszczaj tajemnic w obrazach kontenerów lub zmiennych środowiskowych. Używaj zarządzanych tożsamości i połączeń oraz przechowuj tajne dane w zarządzanym magazynie tajemnic. Aby uzyskać wskazówki, zobacz Konfigurowanie połączenia Key Vault.
• Należy zachować ostrożność przy użyciu narzędzi i serwerów innych niż Microsoft. Jeśli agent wywołuje narzędzia wspierane przez inne niż usługi firmy Microsoft, niektóre dane mogą przepływać do tych usług. Przejrzyj zasady udostępniania, przechowywania i lokalizacji danych dla wszystkich usług innych niż Microsoft, z którymi nawiązujesz połączenie.

Szczegóły platformy

Wersjonowanie

Każde wywołanie w celu utworzenia wersji generuje niezmienną wersję agenta. Wersja to migawka obrazu kontenera, alokacji zasobów, zmiennych środowiskowych i konfiguracji protokołu. Aby zaktualizować agenta, utwórz i wdróż nową wersję.

Punkt końcowy agenta obsługuje jedną wersję naraz i kieruje 100% ruchu do tej wersji. Dzielenie ruchu między wersjami nie jest obsługiwane.

Zmienne środowiskowe to podstawowy mechanizm przekazywania konfiguracji do kontenera w czasie wykonywania (na przykład punkt końcowy projektu, nazwa wdrożenia modelu i ustawienia niestandardowe). Są one ustawiane dla wersji i są niezmienne po jej utworzeniu.

Możliwość obserwowania

Hostowani agenci zapewniają wbudowaną możliwość obserwacji. Platforma automatycznie wprowadza ciąg połączenia usługi Application Insights do kontenera agenta za pomocą zmiennych środowiskowych. Agenci korzystający z bibliotek protokołów domyślnie emitują ślady OpenTelemetry, które są wyświetlane w połączonym zasobie usługi Application Insights w obszarze Badanie>wyszukiwania transakcji lub wydajności.

Aby uzyskać wskazówki dotyczące konfiguracji i analizy, zobacz Włączanie śledzenia w projekcie.

Przybornik w Foundry

Agenci hostowani mają pełny dostęp do narzędzi zarządzanych przez Foundry, w tym Code Interpreter, Web Search (z funkcją Grounding with Bing Custom Search), Wyszukiwanie AI platformy Azure, OpenAPI, MCP, A2A, Skills i innych. Te narzędzia łączysz za pośrednictwem punktu końcowego Toolbox MCP udostępnionego w projekcie Foundry, zamiast dodawać je bezpośrednio do definicji agenta. Zestaw narzędzi zapewnia jednolite uwierzytelnianie w ramach przekazywania tożsamości OAuth, tożsamości agenta, uwierzytelniania za pomocą kluczy i innych metod. Podczas dodawania zestawu narzędzi do hostowanego agenta Microsoft Agent Framework należy użyć FoundryToolbox w Pythonie lub AddFoundryToolboxes w środowisku .NET zamiast generycznego klienta MCP. Inne środowiska uruchomieniowe łączą się przy użyciu standardowych bibliotek klienckich MCP. Aby uzyskać szczegółowe informacje, zobacz Przybornik oparty na intencjach w Foundry.

Obsługa języków

Hostowani agenci obsługują Python i C#. Możesz użyć dowolnej struktury agenta — biblioteki protokołów są niezależne od platformy. Przykłady korzystające z Microsoft Agent Framework, LangGraph i kodu niestandardowego można znaleźć w repozytorium foundry-samples.

Rozmiary piaskownicy

Piaskownice hostowanych agentów obsługują następujące kombinacje CPU i pamięci:

Pamięć sesji

Każda sesja zawiera trwały element $HOME. Platforma zachowuje swoją zawartość po wycofaniu zasobów obliczeniowych po upływie skonfigurowanego limitu czasu bezczynności. Platforma przywraca zawartość po wznowieniu sesji, więc pliki zapisane podczas $HOME okresów bezczynności zostają zachowane. Platforma zapisuje pliki przesłane za pośrednictwem punktu końcowego /files w $HOME, gdzie współdzielą tę samą przestrzeń dyskową. Każda sesja ma łączny budżet dysku na maksymalnie 20 GiB na 1 procesor wirtualny lub większy, który jest proporcjonalnie skalowany w dół dla mniejszych warstw procesora CPU. Platforma rezerwuje około 20% tego budżetu na potrzeby użycia systemu i nie jest widoczna ani dostępna dla agenta. Pozostała część jest współdzielona między obrazem kontenera, $HOME, a wszelkimi innymi lokalizacjami z możliwością zapisu w kontenerze.

Skalowanie i dobór odpowiedniego rozmiaru

Agenci hostowani skalują się według liczby sesji, a nie według liczby replik. Platforma na żądanie tworzy nową piaskownicę izolowaną na poziomie maszyny wirtualnej dla każdej sesji i utrzymuje aktywne zasoby obliczeniowe tak długo, jak napływają kolejne żądania. Każde żądanie resetuje czasomierz bezczynności. Gdy upłynie skonfigurowany limit czasu bezczynności liczony od ostatniego żądania, platforma zwalnia zasoby obliczeniowe środowiska piaskownicy i zachowuje stan sesji.

Limit czasu bezczynności może być 2 do 60 minut i domyślnie to 15 minut. Platforma trwale usuwa sesję po upływie 30 dni braku aktywności. Nie ma liczby replik do skonfigurowania i nie ma ciepłej puli do rozmiaru.

Ponieważ każda sesja jest uruchamiana we własnej piaskownicy, wartości procesora i pamięci ustawione w wersji agenta opisują jedną sesję, a nie zagregowany ślad agenta. Rozliczenie opiera się na zużyciu CPU i pamięci we wszystkich aktywnych sesjach, więc przewymiarowanie zwielokrotnia koszt wraz z poziomem współbieżności.

Aby uzyskać odpowiedni rozmiar, uruchom reprezentatywne obciążenie i sprawdź użycie zasobów w połączonym zasobie usługi Application Insights:

1. Otwórz zasób usługi App Insights w portalu Azure i wybierz pozycję Investigate>Performance.
2. Zapoznaj się z procesorem CPU, dostępną pamięcią, szybkością żądań i średnim czasem trwania żądania w przetestowanym zakresie czasu.

Porównaj zaobserwowane szczyty z przydzielonym procesorem i pamięcią. Jeśli utrzymujące się wartości szczytowe przekraczają około 70% alokacji, zwiększ alokację dla następnej wersji agenta; jeśli wartości szczytowe utrzymują się znacznie poniżej tego poziomu, zmniejsz alokację, aby obniżyć koszty. Zawsze testuj ponownie po zmianie, ponieważ każda nowa wersja jest niezmienna.

Sieć prywatna

Hostowani agenci obsługują wdrażanie w zakresie zasobów Foundry odizolowanych od sieci i mogą wykorzystywać dostarczoną przez klienta sieć wirtualną Azure do komunikacji wychodzącej. Umożliwia to agentom we wdrożeniach Foundry izolowanych od sieci uzyskanie dostępu do prywatnych zasobów, takich jak bazy danych lub wewnętrzne interfejsy API. Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci wirtualnych.

Limity, cennik i dostępność

Ceny

Rozliczenia zarządzanego środowiska uruchomieniowego hostingu są oparte na użyciu zasobów procesora CPU i pamięci podczas aktywnych sesji. Aby uzyskać bieżące stawki, zobacz stronę cennika Foundry.

Dostępność regionów

Hostowani agenci są obecnie dostępni w następujących regionach:

• Australia Wschodnia
• Brazylia Południowa
• Kanada Środkowa
• Kanada Wschodnia
• Środkowe stany USA
• Wschodnie stany USA
• Wschodnie stany USA 2
• Francja Środkowa
• Niemcy Środkowo-Zachodnie
• Włochy Północne
• Japonia Wschodnia
• Japonia Zachodnia
• Korea Środkowa
• Północno-środkowe stany USA
• Norwegia Wschodnia
• Polska Środkowa
• Północna Republika Południowej Afryki
• Południowo-środkowe stany USA
• Indie Południowe
• Azja Południowo-Wschodnia
• Hiszpania Środkowa
• Szwecja Środkowa
• Szwajcaria Północna
• Szwajcaria Zachodnia
• Północne Zjednoczone Emiraty Arabskie
• Południowe Zjednoczone Królestwo
• Zachodnie Zjednoczone Królestwo
• Zachodnio-środkowe stany USA
• Europa Zachodnia
• Zachodnie stany USA
• Zachodnie stany USA 3

Następne kroki

Powiązana zawartość

• Składniki środowiska uruchomieniowego agenta
• Cykl projektowania agenta
• Koncepcje tożsamości agenta w Microsoft Foundry
• Czym jest Toolbox we Foundry?
• dokumentacja Azure Container Registry