Foundry Agent Service, agenci bez kodu i z kodem

Foundry Agent Service, agenci bez kodu i z kodem

Foundry Agent Service to zarządzana platforma do budowania i uruchamiania agentów w chmurze Microsoftu. Daje dwie drogi, które warto rozróżnić na starcie, bo prowadzą do zupełnie innego rodzaju pracy.

Pierwsza to agent opisany konfiguracją: wybierasz model, piszesz instrukcje, podpinasz narzędzia i dostawca go uruchamia. Nie ma kodu do utrzymania ani kontenerów do skalowania. Druga to agent, którego piszesz sam, pakujesz jako obraz kontenera i oddajesz do uruchomienia, a dostawca zapewnia adres, skalowanie, tożsamość i obserwowalność.

Zmiana nazwy, o którą warto zahaczyć

Produkt nosił wcześniej nazwę wiążącą go z platformą Azure AI Foundry, a dokumentacja mówi dziś o Microsoft Foundry. Zmiana jest kosmetyczna w sensie technicznym i myląca przy wyszukiwaniu, bo starsze materiały i nowsze używają różnych określeń dla tej samej rzeczy.

Praktycznie znaczy to jedno: szukając dokumentacji, sprawdź datę i trafiaj na strony pod bieżącą nazwą. Materiały opisujące ten produkt sprzed zmiany są nadal w większości aktualne co do zasad, natomiast nazwy zasobów i ścieżek bywają inne.

Warto też odnotować rzecz, która przy porównaniach z konkurencją ma znaczenie. Ta usługa idzie w przeciwną stronę niż agenci w Bedrock, gdzie odpowiednik trafił do trybu utrzymania i zamknął się dla nowych klientów. Tutaj wariant bez kodu pozostaje wspierany obok wariantu z kodem.

Agent opisany promptem

To jest droga dla przypadków, w których agent ma coś sprawdzić, coś podsumować i wywołać dwa narzędzia, a cała logika mieści się w instrukcjach.

Definicja składa się z trzech rzeczy: modelu z katalogu, instrukcji opisujących cel i ograniczenia oraz zestawu narzędzi. Można to zrobić w interfejsie graficznym albo programistycznie, i ta druga droga jest lepsza, bo definicja trafia do repozytorium i przechodzi przegląd jak każdy inny kod.

Zaleta jest wyraźna i warto ją nazwać. Nie utrzymujesz procesu, nie płacisz za moc obliczeniową w oczekiwaniu i nie masz kontenera do łatania. Skalowanie dzieje się samo, a rachunek wynika z wywołań modelu i użytych narzędzi.

Granica też jest wyraźna. Kształt przepływu jest ustalony, więc wszystko, co wymaga rozgałęzienia zależnego od Twojej logiki biznesowej albo wywołania własnego kodu w środku przebiegu, wypada poza ten wariant. Wtedy właściwa jest druga droga.

Praktyczna rada: zacznij tutaj nawet wtedy, gdy podejrzewasz, że skończysz gdzie indziej. Agent opisany promptem powstaje w godzinę i pokazuje, czy pomysł w ogóle działa, zanim zainwestujesz w infrastrukturę.

Agent z własnym kodem

Drugi wariant przyjmuje kod napisany dowolnym zestawem: wewnętrznym frameworkiem dostawcy, agentami LangChaina, zestawem OpenAI, zestawem Anthropic albo Twoją własną pętlą.

To jest rzecz warta podkreślenia, bo odróżnia tę usługę od zamkniętych rozwiązań. Platforma nie narzuca sposobu pisania agenta, tylko dostarcza to, co i tak byś budował: adres z uwierzytelnianiem, automatyczne skalowanie, osobną tożsamość dla każdego agenta, trwałość stanu sesji i śledzenie przebiegów.

Pakujesz kod jako obraz kontenera albo jako archiwum źródeł, z którego platforma sama zbuduje obraz. Ta druga możliwość skraca drogę przy prostszych przypadkach.

Pod spodem Twój kod woła wspólne API odpowiedzi na punkcie końcowym projektu, żeby dostać model i narzędzia platformy. To jest ten sam punkt, z którego korzysta wariant bez kodu, więc oba dzielą zestaw narzędzi i sposób rozliczania modelu.

Warto znać jeszcze jedną możliwość, najrzadziej opisywaną. Jeśli Twój agent działa już gdzie indziej i nie chcesz go przenosić, możesz wołać to samo API odpowiedzi ze swojego procesu. Dostajesz modele i narzędzia platformy bez oddawania kodu do uruchomienia, co bywa właściwym kompromisem przy istniejącej aplikacji.

Narzędzia i skrzynka narzędziowa

Zestaw wbudowany obejmuje wyszukiwanie w sieci, wyszukiwanie w plikach, pamięć, wykonywanie kodu oraz łączenie z serwerami zgodnymi z protokołem opisanym w rejestrze MCP. Do tego dochodzą narzędzia własne i integracje z usługami tego dostawcy.

Część z nich, w tym pamięć i wyszukiwanie w sieci, jest w zapowiedzi publicznej. To jest informacja do sprawdzenia przed oparciem na nich procesu produkcyjnego, bo dostępność bywa też ograniczona regionalnie.

Ciekawszym elementem jest skrzynka narzędziowa, czyli zdefiniowany raz zestaw narzędzi wystawiony przez jeden punkt zgodny z tym protokołem. Konsekwencja praktyczna jest taka, że dowolny agent rozumiejący ten protokół może z niego skorzystać, niezależnie od tego, w czym został napisany i gdzie działa.

Skrzynka ma wersje, więc zmiana zestawu narzędzi nie wchodzi od razu wszystkim. Tworzysz nową wersję, testujesz, ustawiasz jako domyślną. To jest mechanizm, którego brak przy własnym wdrożeniu boli przy pierwszej zmianie schematu narzędzia w działającym systemie.

Uwierzytelnianie do narzędzi obsługuje kilka trybów, w tym działanie w imieniu użytkownika. To ostatnie rozwiązuje realny problem: agent sięgający po dane w imieniu konkretnej osoby powinien mieć jej uprawnienia, a nie uprawnienia aplikacji.

Wspólne API odpowiedzi

Warto poświęcić temu osobną sekcję, bo to jest element spinający całość i najczęściej pomijany przy pierwszym czytaniu.

Oba rodzaje agentów, a także kod działający poza platformą, korzystają z tego samego punktu końcowego. Przez niego wołasz model i przez niego dostajesz narzędzia platformy.

Konsekwencja praktyczna jest taka, że wybór wariantu przestaje być decyzją nieodwracalną. Agent napisany dziś jako kod uruchamiany u siebie, wołający to API, da się jutro spakować w kontener i oddać platformie do uruchomienia, bez przepisywania logiki. Zmienia się miejsce działania, nie kod.

To odróżnia ten układ od rozwiązań, w których wariant bez kodu i wariant z kodem to dwa osobne światy z osobnymi pojęciami. Tutaj różnica dotyczy hostingu, a nie sposobu rozmawiania z modelem.

Druga konsekwencja dotyczy migracji. Jeśli masz działającą aplikację z własną pętlą, pierwszym krokiem nie musi być przenoszenie jej gdziekolwiek. Wystarczy przestawić wywołania modelu na ten punkt końcowy, żeby dostać dostęp do narzędzi platformy i śledzenia, a decyzję o hostingu odłożyć.

Warto natomiast pamiętać, że to jest wiązanie się z dostawcą na poziomie wywołań modelu. Cienka warstwa własna wokół tych wywołań kosztuje kilka godzin i zostawia otwartą drogę wyjścia, co przy decyzji na lata bywa warte tej pracy.

Kiedy to jest właściwy wybór

Trzy warunki warto sprawdzić, zanim zaczniesz, bo poza nimi lepsze są prostsze rozwiązania.

Pierwszy: jesteś już w tej chmurze. Wartość leży w rzeczach, które splatają się z resztą infrastruktury: tożsamość, uprawnienia, sieć wirtualna, rozliczenie. Zespół pracujący gdzie indziej dostaje z tego głównie kolejnego dostawcę do obsłużenia.

Drugi: agent ma być narzędziem firmowym, a nie funkcją w produkcie. Warstwa publikowania, dystrybucji w narzędziach do pracy zespołowej i rejestru tożsamości jest zaprojektowana pod agentów wewnętrznych, a przy funkcji w aplikacji dla klientów zewnętrznych zwykle nie ma zastosowania.

Trzeci: potrzebujesz zaplecza, którego nie chcesz budować. Tożsamość na agenta, izolacja sesji i trwałość stanu to kilka tygodni pracy, a jeśli Twój przypadek ich nie wymaga, prostsza droga wystarczy.

Gdy którykolwiek warunek nie jest spełniony, warto rozważyć wołanie modeli bezpośrednio i własną pętlę. Agent z trzema narzędziami i bez wymogów co do tożsamości nie potrzebuje platformy tej klasy, a jej wprowadzenie dokłada elementów do skonfigurowania przed pierwszą odpowiedzią.

Foundry Agent Service kontra alternatywy

Rozróżnienie między dwoma pierwszymi wierszami jest tu najważniejsze i sprowadza się do jednego pytania: czy Twój agent potrzebuje kodu w środku przebiegu. Jeśli nie, pierwszy wiersz oszczędza całą warstwę infrastruktury. Jeśli tak, drugi daje kontrolę bez rezygnacji z zaplecza.

Trzeci wiersz warto znać przy porównaniach, bo pokazuje, że ścieżki dużych dostawców się rozeszły. Jeden wygasza wariant bez kodu, drugi utrzymuje oba.

Ostatni wiersz zostaje dla zespołów, dla których wiązanie się z chmurą jest problemem. Warto wtedy policzyć, ile z tego, co usługa daje, faktycznie byście budowali: tożsamość na agenta, izolacja sesji, trwałość stanu i śledzenie to zwykle kilka tygodni pracy.

Cykl życia, wersje i publikowanie

Ta część bywa niedoceniana, a przy agentach w firmie decyduje o tym, czy dają się utrzymywać.

Wersjonowanie działa automatycznie: kolejne zmiany agenta zapisują się jako wersje, do których można wrócić i które da się porównać. To jest odpowiednik historii zmian, którego przy własnym wdrożeniu trzeba się dorobić.

Publikowanie przenosi agenta do zasobu ze stabilnym punktem końcowym, dziedziczącego uprawnienia projektu. Dopiero opublikowany agent nadaje się do wołania z aplikacji, a testowy zostaje testowym.

Dystrybucja obejmuje udostępnienie agenta w narzędziach do pracy zespołowej tego dostawcy oraz w rejestrze tożsamości. To jest droga sensowna przy agentach wewnętrznych, gdzie odbiorcą jest pracownik, a nie klient zewnętrzny.

Do tego dochodzi warstwa oceny i śledzenia. Ślady pokazujące każde wywołanie modelu i każde wywołanie narzędzia są tu wbudowane, a nie dokładane osobno, co przy diagnozowaniu złych odpowiedzi jest różnicą między godziną a dniem.

Zabezpieczenia i tożsamość

Trzy elementy warto znać, bo rozwiązują problemy trudne do zrobienia dobrze samodzielnie.

Osobna tożsamość dla każdego agenta oznacza, że agent działa pod własnym kontem, a nie pod współdzielonym kluczem aplikacji. Uprawnienia nadajesz mu punktowo, a przy nadużyciu wyłączasz jego konto, a nie całą integrację.

Izolacja sieciowa pozwala uruchomić agenta wewnątrz Twojej sieci wirtualnej. Przy wariancie z własnym kodem każda sesja działa w odizolowanym środowisku podłączonym do tej sieci, co ma znaczenie przy wymogach dotyczących lokalizacji danych.

Filtry treści są wpięte w przebieg i obejmują wykrywanie wstrzyknięć, w tym tych przychodzących z treści pobranej z zewnątrz. To jest ta sama warstwa, którą opisałem szerzej przy filtrach treści tej chmury, i przy agentach ma większe znaczenie niż przy zwykłym czacie, bo agent czyta dokumenty i wyniki narzędzi.

Typowe błędy

Pierwszy to wybór wariantu z własnym kodem przy przypadku, który obsłuży wariant opisany promptem. Dokładasz wtedy kontener do utrzymania i koszt mocy obliczeniowej bez żadnego zysku.

Drugi to definiowanie agenta wyłącznie w interfejsie graficznym. Definicja zostaje wtedy poza repozytorium, bez historii zmian i bez przeglądu, a przy pytaniu, kto zmienił instrukcję, nie ma odpowiedzi.

Trzeci to opieranie procesu produkcyjnego na narzędziach będących w zapowiedzi publicznej bez sprawdzenia ich statusu i dostępności regionalnej.

Czwarty to pominięcie działania w imieniu użytkownika tam, gdzie agent sięga po dane osobowe. Agent z uprawnieniami aplikacji widzi więcej, niż powinien widzieć w kontekście konkretnej rozmowy.

Piąty to wołanie agenta testowego z aplikacji zamiast opublikowanego. Zmiana w trakcie pracy wchodzi wtedy natychmiast na produkcję.

Szósty to liczenie kosztu wyłącznie z wywołań modelu. Przy wariancie z własnym kodem dochodzi moc obliczeniowa kontenera, a przy narzędziach ich osobne rozliczenie.

FAQ

Czym różnią się dwa rodzaje agentów?

Tym, kto pisze logikę przebiegu. Agent opisany promptem powstaje z konfiguracji i uruchamia go dostawca, bez kodu i kontenerów. Agent z własnym kodem to Twój program w kontenerze, któremu platforma daje adres, skalowanie, tożsamość i obserwowalność.

Czy mogę użyć LangGraph albo zestawu OpenAI?

Tak, wariant z własnym kodem przyjmuje agentów napisanych tymi bibliotekami, zestawem Anthropic oraz własną pętlą. Kod woła wspólne API odpowiedzi po modele i narzędzia platformy, więc nie wiążesz się ze sposobem pisania agenta.

Czy muszę przenosić kod do tej chmury?

Nie. Jeśli agent działa już gdzie indziej, możesz wołać to samo API odpowiedzi ze swojego procesu i dostać modele oraz narzędzia platformy bez oddawania kodu do uruchomienia.

Czym jest skrzynka narzędziowa?

Zestawem narzędzi zdefiniowanym raz i wystawionym przez jeden punkt zgodny z protokołem opisanym w rejestrze MCP. Dowolny agent rozumiejący ten protokół może z niego korzystać, a wersjonowanie sprawia, że zmiana zestawu nie wchodzi wszystkim natychmiast.

Jak liczyć koszty?

Wariant opisany promptem rozlicza wywołania modelu i użycie narzędzi. Wariant z własnym kodem dokłada do tego moc obliczeniową kontenera. Warto policzyć jeden realny przebieg, bo liczba kroków agenta zwykle dominuje w rachunku bardziej niż stawka za pojedyncze wywołanie.

Dokumentacja stoi na stronie usługi, a katalog narzędzi w osobnym dokumencie.