AI Agents | The .NET Blog

Microsoft Agent Framework Część 3: Od narzędzi do przepływów pracy — klocki zatrzaskują się na miejscu

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Ten post został przetłumaczony automatycznie. Aby zobaczyć oryginalną wersję, kliknij tutaj.

Jeśli śledzisz serię Building Blocks for AI w .NET, wiesz: Część 1 dała nam IChatClient (uniwersalny interfejs modelu), a Część 2 — Microsoft.Extensions.VectorData (wyszukiwanie semantyczne i RAG). Oba są podstawowe i przydatne same w sobie. Ale tutaj wszystko zaczyna się łączyć.

Część 3 dotyczy Microsoft Agent Framework — i szczerze, to właśnie ten kawałek czekałem, żeby zobaczyć w .NET. Wersja 1.0 wyszła w kwietniu. API jest stabilne. Czas budować prawdziwych agentów.

Czym tak naprawdę jest agent (vs. chatbot)

Zanim wejdziemy w kod, wyjaśnijmy to rozróżnienie. Chatbot odbiera input, wywołuje model, zwraca output. Prosta pętla.

Agent ma autonomię. Może rozumować nad zadaniem, zdecydować, które narzędzia użyć, wywołać je, ocenić wyniki i zdecydować, co zrobić dalej — wszystko bez pisania eksplicitnej logiki krok po kroku dla każdego scenariusza. Dajesz mu narzędzia i instrukcje, a on sam zajmuje się orkiestracją.

Pomyśl tak: IChatClient to jak prowadzenie rozmowy. Agent to jak delegowanie listy zadań komuś.

Twój pierwszy agent w 10 liniach

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

Metoda rozszerzająca .AsAIAgent() jest mostem. Ten sam wzorzec co .AsIChatClient() z MEAI — opakowuje SDK dostawcy w stabilną abstrakcję. Działa z Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry lub lokalnymi modelami.

Streaming też działa:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Dawanie narzędzi agentowi

Tu agenci przestają być wyszukanymi chatbotami. Narzędzia to funkcje, które model może zdecydować się wywołać na podstawie tego, o co prosi użytkownik. Nie potrzebujesz logiki routingu — model sam to rozgryzie.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Dwie rzeczy do zanotowania. Po pierwsze, AIFunctionFactory pochodzi z MEAI — ta sama fabryka narzędzi, której używałbyś z normalnym IChatClient. Jeśli masz już zdefiniowane narzędzia dla scenariuszy czatowych, działają tu też.

Po drugie, atrybuty Description mają ogromne znaczenie. To dzięki nim model rozumie, co narzędzie robi i kiedy go użyć. Traktuj je jako dokumentację dla twojej AI, nie dla ludzi.

Sesje: Rozmowy, które naprawdę pamiętają

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Bez sesji każde wywołanie RunAsync jest bezstanowe. Z sesją agent wie, o którym żarcie mówisz. AgentSession zachowuje historię rozmowy między turami.

Dla bezstanowych usług produkcyjnych sesje serializują się czysto:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... przechowaj gdzieś ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

To kluczowe, jeśli twój agent działa w środowisku serverless lub poziomo skalowanym.

AIContextProvider: Trwała pamięć między sesjami

Sesje zachowują historię rozmowy wewnątrz sesji. Ale co z wiedzą o użytkowniku między sesjami? AIContextProvider to obsługuje.

Ma dwa haki:

ProvideAIContextAsync — wykonuje się przed każdą interakcją, wstrzykuje kontekst do agenta
StoreAIContextAsync — wykonuje się po każdej interakcji, pozwala na uczenie i utrwalanie

Wzorzec jest elegancki: możesz układać wiele dostawców w stos — jeden dla preferencji użytkownika, jeden dla ostatnich interakcji, jeden który odpytuje twój store VectorData o odpowiednie dokumenty. Ten ostatni to dokładnie wzorzec RAG z Części 2, teraz wykonywany automatycznie przy każdym wywołaniu agenta.

Przepływy multiagentowe

Tutaj framework zasługuje na swoją nazwę. Zawiera oparty na grafach system przepływów pracy, gdzie egzekutory (agenci, funkcje, cokolwiek) łączą się przez krawędzie.

Kilka natywnie obsługiwanych wzorców:

Sekwencyjny: Wyjście Agenta A zasila Agenta B
Współbieżny (fan-out/fan-in): Dyspatchuje do wielu agentów równolegle, zbiera wyniki
Warunkowe routowanie: Kieruje pracę do różnych agentów w zależności od wyjścia
Pętle pisarz-krytyk: Jeden agent pisze, drugi ocenia, pętla do zatwierdzenia
Pod-przepływy: Hierarchiczne komponowanie przepływów

Przykład pisarz-krytyk:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Czyste, czytelne, i routowanie oparte na warunkach oznacza, że logiki pętli nie piszesz sam.

Human-in-the-Loop

Nie wszystko powinno działać w pełni autonomicznie. Dla wrażliwych operacji — zapisów do bazy danych, transakcji finansowych, wysyłania komunikatów — chcesz, żeby człowiek zatwierdził przed wykonaniem przez agenta.

Framework ma wbudowane wsparcie dla tego poprzez FunctionApprovalRequestContent i FunctionApprovalResponseContent. Agent proponuje wywołanie narzędzia, twój kod aplikacji przedstawia je użytkownikowi, a odpowiedź decyduje, czy wykonanie postępuje.

To właściwy sposób myślenia o agentach w środowiskach korporacyjnych: nie w pełni autonomiczni, ale autonomia z barierkami.

Pełny obraz

Jeśli cofniesz się o krok:

MEAI daje ci uniwersalny interfejs do dowolnego modelu
VectorData daje twoim agentom dostęp do wiedzy organizacji przez wyszukiwanie semantyczne
Agent Framework orkiestruje wszystko — używa IChatClient pod spodem, komponuje się z dostawcami kontekstu, koordynuje przez przepływy

Każda część została zaprojektowana, by komponować się z innymi. Sprawdź oryginalny post Jeremy’ego Liknessa i repozytorium GitHub Agent Framework dla pełnych przykładów.

Podsumowanie

Post Część 3 Microsoft Agent Framework zamyka pętlę serii Building Blocks. Dla deweloperów .NET chcących budować agentów AI — nie tylko chatboty, ale prawdziwych agentów używających narzędzi, pamiętających rzeczy i koordynujących — to jest twoja droga naprzód.

Stabilny release 1.0 oznacza, że możesz budować na tym w produkcji. Jeśli czekałeś, żeby wskoczyć w tworzenie agentów w .NET, ten moment jest teraz.

SQL MCP Server na Azure App Service — bez kontenerów

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Ten post został przetłumaczony automatycznie. Aby zobaczyć oryginalną wersję, kliknij tutaj.

Szczerze mówiąc: za każdym razem, gdy w tutorialu widzę „wymaga kontenera", coś we mnie wzdycha. Kontenery są świetne — dopóki twój zespół nie ma strategii kontenerowej, a funkcja, która wydawała się prosta, nagle blokuje się na nieoczekiwanej złożoności orkiestracji, której nikt nie zaplanował.

Dlatego to przykuło moją uwagę. SQL MCP Server może teraz działać na Azure App Service — bez Dockera, bez Kubernetes, tylko z tym samym plikiem konfiguracyjnym Data API Builder (DAB), który eksponuje twoją bazę danych SQL przez MCP, REST i GraphQL.

Czym jest SQL MCP Server?

Krótkie wprowadzenie, jeśli jeszcze nie kojarzysz. SQL MCP Server siedzi pomiędzy twoim agentem AI a bazą danych SQL. Zamiast dawać agentowi bezpośredni dostęp do bazy (kiepski pomysł), eksponuje twoje tabele i widoki jako warstwę abstrakcji — encje z zdefiniowanymi uprawnieniami.

Zbudowany na Data API Builder, co oznacza, że jeden plik konfiguracyjny zarządza MCP i REST i GraphQL jednocześnie. Agent komunikuje się z endpointem MCP. Tradycyjna aplikacja komunikuje się z REST lub GraphQL. Ta sama konfiguracja, to samo środowisko uruchomieniowe, różne powierzchnie.

To naprawdę przydatne — nie musisz utrzymywać dwóch oddzielnych warstw API.

Problem z kontenerami (i rozwiązanie)

Pierwotny model wdrożenia SQL MCP Server używał kontenerów. Działa dobrze w wielu zespołach — ale nie we wszystkich. Wiele zespołów .NET standardyzuje na Azure App Service lub maszynach wirtualnych. Wymaganie środowiska uruchomieniowego kontenerów tylko po to, żeby wyeksponować endpoint SQL, dodaje tarcia, o które nikt nie prosił.

Nowy przewodnik pokazuje, jak całkowicie pominąć kontener. Wszystko działa przez polecenie dab start, hostowane na App Service jako standardowy proces webowy .NET 8.

# Zainstaluj Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Zainicjuj konfigurację
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Dodaj encję
dab add products --source dbo.products --permissions "authenticated:*"

# Skonfiguruj dostawcę uwierzytelniania App Service
dab configure --runtime.host.authentication.provider AppService

# Uruchom serwer
dab start

W tym momencie masz MCP pod /mcp, REST i GraphQL z tego samego procesu — i nic nie działa w kontenerze.

Uwierzytelnianie bez wspólnych kluczy API

To jest ta część, którą cenię najbardziej. Wdrażając na App Service, konfigurujesz Microsoft Entra ID jako dostawcę uwierzytelniania. Żadnych wspólnych sekretów w plikach konfiguracyjnych, żadnych kluczy API do rotacji.

Ciąg połączenia pozostaje w zmiennych środowiskowych App Service (nie w dab-config.json), a endpoint MCP jest chroniony uwierzytelnianiem platformy. Jeśli twoje obciążenia Azure są już zintegrowane z Entra ID, to naturalnie pasuje.

Do lokalnego developmentu przełącz się na tryb Simulator i transport STDIO. Wróć do trybu AppService przed wdrożeniem. Czysto i jednoznacznie.

Wdrożenie na App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Następnie wdróż swój projekt DAB metodą wdrożenia kodu, której twój zespół już używa. Kluczowy szczegół: to wdrożenie kodu, nie kontenera.

Dlaczego to ważne dla deweloperów .NET

Jeśli budujesz agentów AI w .NET, prędzej czy później agent będzie musiał komunikować się z bazą danych. SQL MCP Server daje ci ustrukturyzowany sposób, żeby to zrobić — bez eksponowania surowych ciągów połączenia.

Sprawdź pełny przewodnik w oryginalnym poście i przykładowym repozytorium na GitHub.

Podsumowanie

SQL MCP Server na App Service to praktyczny wybór dla zespołów .NET, które chcą dać agentom ustrukturyzowany dostęp do danych SQL bez strategii kontenerowej. Wypróbuj — twoi agenci docenią czysty interfejs API.

Aktualizacja Visual Studio z kwietnia: integracja Cloud Agent dla przepływów pracy .NET

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

Ten post został automatycznie przetłumaczony. Oryginalna wersja dostępna jest tutaj.

Visual Studio April Update: Cloud Agent Integration for .NET Workflows zasługuje na bliższe przyjrzenie się, jeśli budujesz lub obsługujesz systemy .NET w dużej skali.

Z mojej perspektywy ważne jest nie tyle główna funkcja, ile to, jak szybko zespół może zamienić ją w bezpieczniejszy, powtarzalny przepływ pracy inżynieryjnej.

Dlaczego ma to znaczenie dla zespołów .NET

Większość zespołów balansuje między szybkością dostarczania, spójnością platformy a zarządzaniem. Ta aktualizacja jest przydatna, ponieważ daje bardziej konkretną ścieżkę poprawy jednego z tych ograniczeń bez przepisywania wszystkiego od nowa.

Praktyczne kolejne kroki

Zwaliduj funkcję w małym pilocie .NET z danymi zbliżonymi do produkcyjnych.
Dodaj wyraźne punkty kontrolne wycofania i obserwowalności przed szerszym wdrożeniem.
Zapisz wzorzec implementacji w swoich wewnętrznych szablonach, aby inne zespoły mogły go ponownie wykorzystać.

Źródło

Oryginalny artykuł: https://devblogs.microsoft.com/visualstudio/visual-studio-april-update-cloud-agent-integration/

Zarządzanie wywołaniami narzędzi MCP w .NET z Agent Governance Toolkit