Microsoft Foundry Agent Service: architektura, komponenty i cennik (platforma agentowa Azure)

Microsoft Foundry Agent Service: architektura, komponenty i cennik (platforma agentowa Azure)

Jeśli porównujesz wybór platformy agentowej między chmurami, to jest część poświęcona Azure. Ten sam rozkład dla AWS mamy w Amazon Bedrock AgentCore, a dla Google w Czym jest Vertex AI. Tutaj skupiamy się na samym Microsoft Foundry Agent Service.

Nazewnictwo, uporządkowane

Więcej niejasności zjadziesz w nazwach niż w technologii, więc ustalmy to najpierw. Stan na październik 2026:

Jeden koncept, który jest najbardziej mylący: Foundry Agent Service to runtime, na którym wdrażasz, a Microsoft Agent Framework to SDK, w którym budujesz. To nie ten sam produkt i nie musisz używać ich razem. MAF jest otwartoźródłowy i działa wszędzie; Foundry Agent Service po prostu dobrze go hostuje. Możesz też budować agentów “natywnych dla Foundry” bez użycia MAF. Wracamy do tego podziału niżej, bo to on też kształtuje rachunek.

Dla odniesienia źródła: strona produktowa Foundry Agent Service, strona cennika Foundry Agent Service oraz zapowiedź Microsoft Agent Framework.

Do czego służy Foundry Agent Service

Foundry Agent Service to nowoczesne API, runtime i platforma deweloperska do przeprowadzenia agenta od prototypu do produkcji, obsługiwana z zabezpieczeniami, obserwowalnością i nadzorem klasy enterprise z Foundry. Osiągnęła ogólną dostępność w 2026 roku.

Są dwa sposoby uruchomienia na niej agenta i różnica ma znaczenie zarówno dla architektury, jak i dla kosztu:

• Agenci natywni dla Foundry. Budujesz agenta z promptów i workflow bezpośrednio w SDK Foundry albo w portalu Foundry. Microsoft nie pobiera dodatkowej opłaty za tworzenie ani uruchamianie takich agentów - płacisz tylko za to, co zużywają (tokeny modelu i ewentualne narzędzia).
• Agenci hostowani. Przynosisz agenta zbudowanego w zewnętrznym otwartoźródłowym frameworku - Microsoft Agent Framework albo LangGraph - i uruchamiasz go na w pełni zarządzanym runtime Foundry, w dedykowanym dla klienta kontenerze z wbudowanym skalowaniem, obserwowalnością, bezpieczeństwem i nadzorem. To bezpośredni odpowiednik modelu AgentCore “przynieś swój framework, uruchom go na zarządzanej, izolowanej infrastrukturze” i jest rozliczany według zużycia kontenera.

Microsoft opisuje ścieżkę hostowaną jako “wdrożenie jedną komendą do agentów hostowanych, runtime zarządzany z izolacją sesji, autoskalowaniem i zerowym kosztem bezczynności”. Ich deklaracja i kształt z izolacją sesji oraz autoskalowaniem do zera zgadza się z tym, co wynika z modelu cennika; potraktuj zdanie o “zerowym koszcie bezczynności” jako ujęcie dostawcy, a nie gwarancję, realny koszt może zależeć od szczegółów Twojej implementacji.

Natywni vs hostowani: wybór, który kształtuje rachunek

Ponieważ agenci natywni i hostowani są rozliczani zupełnie inaczej, wybór między nimi to pierwsza decyzja kosztowa, a nie szczegół implementacji.

Praktyczny wniosek: jeśli agent jest prosty, tryb natywny utrzymuje koszt platformy na zerze i płacisz tylko za tokeny i narzędzia. W momencie, gdy potrzebujesz kontroli prawdziwego frameworka - workflow wielu agentów, człowiek w pętli, własna orkiestracja - przechodzisz na tryb hostowany i bierzesz na siebie zużycie kontenera. To realne rozwidlenie architektoniczne i warto podjąć je świadomie, a nie domyślnie.

Ile kosztuje Foundry Agent Service - cennik i model kosztów

Foundry Agent Service jest rozliczany według zużycia, w tym samym duchu co AgentCore: brak opłaty licencyjnej za “platformę”, płacisz za części, których używasz. Koszt ma trzy warstwy.

Warstwy kosztów

1. Warstwa orkiestracji jest darmowa dla agentów natywnych. Tworzenie i uruchamianie natywnych agentów Foundry (prompty i workflow) nie niesie opłaty platformowej. To realna różnica wobec runtime, gdzie każda sekunda pracy agenta jest płatna.
2. Modele to miejsce, gdzie ląduje większość wydatków. Zużycie tokenów rozliczane jest przez Foundry Models, na osobnej stronie cennika, według wybranego modelu. Jak na każdej platformie agentowej, przy realnym ruchu to zwykle największa pozycja.
3. Agenci hostowani i narzędzia są mierzone dodatkowo. Agenci hostowani rozliczają zużycie kontenera per vCPU-godzina i GiB-godzina. Narzędzia i wiedza to osobne opłaty.

Stawki per komponent

Oto kluczowa część i zarazem haczyk. Komponenty i ich jednostki rozliczeniowe, według strony cennika Foundry Agent Service (stan na październik 2026):

Jak czytać kształt kosztów

Nawet z ukrytymi liczbami kształt jest jasny i odzwierciedla pozostałe chmury:

• Przy niskim ruchu agenci natywni plus skromny wydatek na tokeny mogą być naprawdę tani - darmowa warstwa orkiestracji robi tu realną robotę. Agenci hostowani to zmieniają, bo zużycie kontenera biegnie zawsze, gdy agent jest uruchomiony.
• Przy realnym ruchu dominują tokeny modelu, dokładnie tak jak w AgentCore i Vertex. Warstwa platformy, natywna czy hostowana, jest zwykle mniejszością rachunku.
• Narzędzia i wiedzę łatwo niedoszacować. Magazyn wektorowy File Search, sesje Code Interpreter, transakcje Web Search, a zwłaszcza osobno licencjonowane konektory (Fabric, SharePoint, grounding Bing, Foundry IQ) sumują się i są rozliczane osobno od samego agenta.

Wniosek FinOps jest ten sam, do którego wciąż dochodzimy przy agentach: koszt platformy per agent rzadko jest problemem. Są nim wydatek na tokeny i rozproszone zasoby narzędzi/wiedzy. To ten sam mechanizm rozdrobnienia, który opisaliśmy w agent sprawl - koszt bierze się z mnożenia zasobów, nie z pojedynczej usługi.

Jak wypada wobec AgentCore i Vertex

Krótka wersja, bo to oczywiste następne pytanie: wszystkie trzy główne chmury oferują teraz ten sam rdzeń wzorca - zarządzany, izolowany runtime, na który przynosisz swój framework i wdrażasz agenta bez stawiania własnej infrastruktury. AgentCore (Strands, LangGraph i inne), platforma agentowa Vertex oraz Foundry Agent Service (Microsoft Agent Framework, LangGraph) zbiegają się do tego kształtu.

Różnice są w szczegółach, które ważą przy decyzji: przejrzystość cennika (AWS publikuje stawki, Azure trzyma je za kalkulatorem), historia frameworka (każda chmura promuje własne SDK pierwszej strony, wspierając przy tym LangGraph) oraz grawitacja ekosystemu (w której chmurze już żyją twoje dane, tożsamość i narzędzia). Pełne porównanie trójstronne to osobny materiał - i ten, którego większość zespołów faktycznie potrzebuje przed podjęciem decyzji. Jeśli tam właśnie jesteś, rozkłady dla AWS i Google podlinkowane wyżej są pozostałymi dwiema nogami tego porównania.

Gdzie Foundry dla zespołu w Azure

Jeśli jesteś już w Azure, Foundry Agent Service to ścieżka najmniejszego oporu dla agentów produkcyjnych - a decyzje warte przemyślenia wcześnie to:

• Natywni vs hostowani vs Agent Framework. To rozwidlenie ustawia zarówno architekturę, jak i bazę kosztową. Rozstrzygnij je wobec faktycznego obciążenia, a nie demo.
• Wymiarowanie wydatku na model. Tokeny to największa zmienna. Wymiarowanie ich wobec realnego wolumenu sesji to różnica między budżetem, który się trzyma, a takim, który nie.
• Nadzór nad narzędziami i wiedzą. Konektory, kolekcje File Search i źródła groundingu są rozliczane osobno i łatwo się rozrastają. Konsoliduj, gdzie możesz.

Kiedy warto zaangażować zewnętrznego partnera

• Model kosztów. Rozliczanie według zużycia w podziale na natywnych, hostowanych, modele i narzędzia - ze stawkami per jednostka za logowaniem - trudno oszacować bez przerobienia kalkulatora dla twojego regionu i wolumenu. To ono kształtuje budżet.
• Decyzja natywni-vs-hostowani-vs-MAF. To wybór architektoniczny z długim ogonem utrzymania, a nie jednorazowe wdrożenie.
• Porównanie międzychmurowe. Jeśli naprawdę wybierasz między AgentCore, Vertex i Foundry, właściwa odpowiedź zależy od tego, gdzie już leżą twoje dane i tożsamość, w nie mniejszym stopniu niż od samych platform.

Podsumowanie

Microsoft Foundry Agent Service to zarządzana platforma Azure do uruchamiania agentów AI na produkcji - trzecia noga obok AWS AgentCore i platformy agentowej Google Vertex. Trzy rzeczy do zapamiętania:

1. Najpierw nazwy. Microsoft Foundry (dawniej Azure AI Foundry) to platforma, Foundry Agent Service to runtime agentów, a Microsoft Agent Framework to otwartoźródłowe SDK (połączone Semantic Kernel i AutoGen). Runtime i SDK to nie to samo.
2. Natywni vs hostowani to rozwidlenie kosztów. Agenci natywni nie niosą opłaty platformowej; agenci hostowani rozliczają zużycie kontenera per vCPU-godzina i GiB-godzina. Tokeny modelu i narzędzia są dodatkowe w obu przypadkach.
3. Azure ukrywa liczby. W odróżnieniu od AWS stawki per jednostka są za kalkulatorem i logowaniem - więc wymiarowanie agenta w Azure wymaga więcej pracy, a ta nieprzejrzystość jest sama w sobie punktem do rozważenia przy porównaniu chmur.

Najczęstsze pytania o Foundry Agent Service

Wybierasz między agentami natywnymi a hostowanymi w Foundry?

Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom w Azure wybrać między agentami natywnymi dla Foundry a hostowanymi, wymiarować realny wydatek na modele i narzędzia oraz zdecydować między AgentCore, Vertex i Foundry, gdy wybór jest jeszcze otwarty.

Umów rozmowę Wyślij wiadomość