.NET 10 dla aplikacji AI: warstwy i wybór

W .NET 10 aplikację AI warto budować warstwowo: Microsoft.Extensions.AI do rozmowy z modelem, Microsoft.Extensions.DataIngestion i Microsoft.Extensions.VectorData do pracy z własną wiedzą, MCP do współdzielenia narzędzi, a Microsoft Agent Framework dopiero wtedy, gdy proces naprawdę wymaga wieloetapowego działania. Taki podział ogranicza zależność od jednego dostawcy i pozwala testować osobno model, retrieval, narzędzia oraz reguły biznesowe. Sam wybór C# nie zapewnia poprawności odpowiedzi. O jakości decydują dane, ewaluacja, uprawnienia i sposób obsługi błędów.

Zacznij od rodzaju zachowania, nie od biblioteki

Najpierw określ, co aplikacja ma zrobić. Podsumowanie dokumentu, wyszukiwanie w procedurach i agent zmieniający dane w systemie mają inne wymagania. Jeśli zadanie kończy się jedną odpowiedzią modelu, pełna orkiestracja agentowa zwiększy liczbę stanów oraz koszt testów bez proporcjonalnej korzyści. Gdy wynik zależy od własnych dokumentów, potrzebujesz kontrolowanego procesu ingestii i retrieval. Gdy aplikacja wykonuje operacje, potrzebuje narzędzi, autoryzacji i potwierdzenia stanu w systemie źródłowym.

Dokumentacja ekosystemu AI dla .NET rozdziela te odpowiedzialności w podobny sposób. Microsoft.Extensions.AI stanowi bazową abstrakcję dla modeli, Microsoft.Extensions.VectorData obsługuje semantyczne wyszukiwanie, a Microsoft Agent Framework służy do wieloetapowej orkiestracji. To wskazówka architektoniczna, a nie obowiązek użycia całego stosu.

Jeżeli wybierasz język dopiero po określeniu warstw rozwiązania, porównaj też architekturę aplikacji AI w Pythonie. Kryterium nie powinno być samo przyzwyczajenie zespołu, lecz biblioteki, sposób testowania i utrzymanie wybranego procesu.

Potrzeba	Najmniejsza sensowna warstwa	Czego ta warstwa nie rozwiązuje
Rozmowa, klasyfikacja, podsumowanie	Microsoft.Extensions.AI	Jakości źródeł i procesu biznesowego
RAG na dokumentach firmy	DataIngestion + VectorData + Extensions.AI	Aktualności dokumentów i kontroli dostępu
Udostępnianie narzędzi wielu klientom AI	Serwer MCP	Autoryzacji operacji i reguł domenowych
Korzystanie z zewnętrznych narzędzi MCP	Klient MCP	Zaufania do serwera i walidacji wyniku
Wieloetapowy proces z agentami	Microsoft Agent Framework	Poprawności decyzji modelu i odpowiedzialności człowieka
Lokalny system wielu usług	Aspire	Produkcyjnego hostingu oraz strategii wdrożenia

Microsoft.Extensions.AI jako granica dostępu do modelu

Microsoft.Extensions.AI dostarcza wspólne typy, przede wszystkim abstrakcje klienta czatu i generatora embeddingów. Dzięki nim kod aplikacji może zależeć od możliwości, a integracja konkretnego dostawcy pozostaje na brzegu systemu. Ta granica ułatwia wstrzykiwanie zależności, testowanie oraz dodawanie middleware do telemetrii, cache, limitów lub filtrów.

Nie oznacza to, że wszystkie modele zachowują się identycznie. Różnią się formatami narzędzi, oknem kontekstu, multimodalnością, sposobem liczenia tokenów i gwarancjami strukturalnego wyniku. Abstrakcja ogranicza sprzężenie kodu, lecz nie usuwa różnic semantycznych. Zmianę modelu trzeba przeprowadzić przez ten sam zestaw testów regresji.

.NET 10 jest wydaniem LTS i rozsądną bazą nowego rozwiązania. Oficjalny materiał Announcing .NET 10 pokazuje, że bieżący stos Microsoftu łączy Microsoft.Extensions.AI, VectorData, MCP oraz Agent Framework. Dla zespołu oznacza to jeden ekosystem narzędzi, telemetrii i hostingu, ale wersje pakietów nadal należy przypinać i aktualizować świadomie.

Praktyczna granica może wyglądać prosto: kontroler przyjmuje żądanie, warstwa aplikacyjna buduje kontekst i wywołuje IChatClient, a adapter dostawcy rejestruje implementację. Reguły cenowe, limity i prawa użytkownika nie powinny trafiać do promptu jako jedyne zabezpieczenie. Pozostają deterministycznym kodem domenowym.

Własne dane: ingestia, wektory i retrieval

RAG składa się z dwóch odrębnych przepływów. Pierwszy pobiera dokument, dzieli go na fragmenty, wzbogaca metadanymi, tworzy embeddingi i zapisuje w indeksie. Drugi przetwarza pytanie, wyszukuje właściwe fragmenty i przekazuje je modelowi. Microsoft.Extensions.DataIngestion wspiera pierwszy przepływ, a Microsoft.Extensions.VectorData oddziela aplikację od szczegółów magazynu wektorowego.

To rozdzielenie jest ważniejsze niż wybór bazy. Fragment powinien zachować identyfikator dokumentu, wersję, właściciela, poziom dostępu i datę obowiązywania. Wyszukiwanie musi filtrować dane przed przekazaniem ich modelowi. Ukrycie niedozwolonego fragmentu dopiero w interfejsie jest za późne, bo treść została już przetworzona.

Element testu RAG	Przykładowa miara	Warunek odbioru do ustalenia przez zespół
Retrieval	Czy właściwy fragment jest w pierwszych wynikach	Próg na oznaczonym zbiorze pytań
Odpowiedź	Pokrycie tez przez dostarczone źródła	Każda ważna teza ma dowód
Uprawnienia	Próby dostępu między rolami	Brak niedozwolonych fragmentów w kontekście
Aktualność	Pytania o zmienione procedury	Odpowiedź używa obowiązującej wersji
Odmowa	Pytania bez materiału	Brak zgadywania z wiedzy ogólnej
Koszt i czas	Tokeny oraz percentyle opóźnień	Budżet uzgodniony dla scenariusza

Nie zaczynaj strojenia od zmiany modelu. Sprawdź kolejno jakość dokumentu, sposób podziału, metadane, filtry, zapytanie i dopiero potem generowanie. Płynna odpowiedź może maskować słaby retrieval. Dlatego w logu ewaluacyjnym zapisuj zarówno wynik wyszukania, jak i końcową odpowiedź.

Ważna jest też strategia aktualizacji indeksu. Dokument wycofany nie może nadal pojawiać się w wynikach tylko dlatego, że jego wektory pozostały w magazynie. Proces ingestii powinien być powtarzalny, wykrywać zmianę wersji i usuwać osierocone fragmenty. Dla każdej partii zapisuj wersję modelu embeddingowego oraz parametry podziału. Zmiana tych elementów może wymagać ponownego zbudowania całego indeksu, a mieszanie nieporównywalnych wektorów utrudnia diagnozę.

Dobierz magazyn do wymagań operacyjnych, a nie do samej obecności wyszukiwania wektorowego. Sprawdź filtrowanie po metadanych, izolację klientów, kopie zapasowe, opóźnienie, limity i możliwość odtworzenia indeksu. VectorData upraszcza kod dostępu, lecz nie czyni adapterów identycznymi. Zapytania graniczne i zachowanie filtrów trzeba przetestować na wybranej implementacji.

MCP: granica integracji, nie skrót do zaufania

Model Context Protocol pozwala serwerom publikować narzędzia, zasoby i prompty, które klienci AI mogą odkrywać w ujednolicony sposób. Oficjalny przewodnik MCP dla .NET wskazuje, że C# SDK współpracuje z Microsoft.Extensions.AI i Agent Framework. MCP ma sens, gdy ta sama zdolność ma służyć wielu aplikacjom, agentom albo środowiskom programistycznym.

Jeśli narzędzie istnieje wyłącznie wewnątrz jednego procesu, zwykłe wywołanie funkcji jest prostsze. Serwer MCP wprowadza transport, negocjację możliwości, uwierzytelnianie, wersjonowanie i nową granicę zaufania. Opis narzędzia nie może zastępować kontroli uprawnień. Serwer powinien autoryzować każdą operację na podstawie tożsamości i zakresu, walidować argumenty oraz rejestrować wynik.

Rozdziel narzędzia od danych referencyjnych. Odczyt katalogu może być zasobem, a złożenie zamówienia narzędziem z efektem ubocznym. Dla operacji nieodwracalnej zastosuj etap przygotowania, jawne potwierdzenie i osobne wykonanie. Agent nie powinien uznawać tekstowej deklaracji modelu za dowód, że zapis się udał.

Rejestr narzędzi powinien wskazywać właściciela, klasyfikację danych, wymagane zakresy, efekty uboczne i politykę wycofania. Klient nie powinien automatycznie ufać każdemu narzędziu ogłoszonemu przez nowy serwer. Stosuj allowlistę, limity czasu, maksymalny rozmiar odpowiedzi i ograniczenie liczby wywołań w jednej turze. Odpowiedź narzędzia jest wejściem zewnętrznym; może zawierać błędy lub treść próbującą zmienić instrukcje agenta.

Kiedy potrzebujesz Microsoft Agent Framework

Agent Framework jest uzasadniony, gdy aplikacja utrzymuje stan procesu, wybiera narzędzia, wykonuje kilka kroków, przekazuje zadanie między rolami lub czeka na decyzję człowieka. Oficjalne repozytorium Microsoft Agent Framework opisuje obsługę agentów i przepływów wieloagentowych w .NET. Framework dostarcza mechanizmy orkiestracji; zachowanie nadal zależy od modelu, instrukcji, narzędzi i danych.

Najpierw spróbuj zamknąć scenariusz w deterministycznym workflow. Jeżeli kolejność kroków jest znana, kod procesu będzie łatwiejszy do audytu niż swobodne planowanie przez model. Agenta wykorzystaj w miejscu, gdzie decyzja rzeczywiście zależy od treści: klasyfikacji sprawy, dobrania źródła lub przygotowania propozycji. Walidacja, zapis i rozliczenie pozostają deterministyczne.

Przykład syntetyczny: agent obsługi zgłoszenia odczytuje opis, wybiera kategorię i proponuje rozwiązanie. Workflow sprawdza uprawnienia, pobiera procedurę przez retrieval i wymaga akceptacji pracownika przed zmianą statusu. Narzędzie zapisujące status zwraca identyfikator transakcji, który aplikacja porównuje ze stanem systemu. Taki układ wykorzystuje model do interpretacji języka, ale nie oddaje mu kontroli nad regułami.

Stan długiego procesu wymaga własnego projektu. Określ, co można odtworzyć po restarcie, jak wygasa sesja, które kroki są idempotentne i kiedy człowiek może wznowić zadanie. Historia rozmowy nie jest pełnym dziennikiem procesu. Dla audytu zapisuj decyzje, użyte wersje źródeł, wywołania narzędzi i potwierdzenia, oddzielając je od swobodnego tekstu modelu.

W systemie wieloagentowym każda rola zwiększa koszt i powierzchnię błędu. Agent „recenzent” korzystający z podobnego modelu nie jest niezależnym dowodem poprawności. Może wykryć niespójność, ale nie zastąpi źródła ani deterministycznej walidacji. Dodawaj kolejnego agenta tylko wtedy, gdy ma osobny kontekst, narzędzie lub odpowiedzialność, a test pokazuje poprawę wyniku.

Telemetria i ewaluacja są częścią produktu

W aplikacji AI zwykły kod może działać bez błędu, mimo że odpowiedź jest błędna. Potrzebujesz dwóch warstw obserwacji. Operacyjna mierzy opóźnienia, wyjątki, wywołania modeli i narzędzi, zużycie tokenów oraz ślady rozproszone. Jakościowa ocenia zgodność ze źródłami, kompletność, bezpieczeństwo i wynik biznesowy.

Zbuduj zestaw przypadków przed pilotem. Powinien obejmować pytania typowe, niepełne, sprzeczne, niedozwolone i nieobsługiwane. Dla narzędzi dodaj awarie zależności, ponowienie żądania, duplikat oraz odpowiedź częściową. Każda zmiana modelu, promptu, indeksu lub pakietu uruchamia ten sam zestaw. Ręczna ocena reprezentatywnej próbki uzupełnia automatyczne metryki.

Nie zapisuj w telemetrii pełnych promptów i wyników bez klasyfikacji danych. Stosuj redakcję, retencję oraz kontrolę dostępu. Identyfikator korelacji powinien pozwalać połączyć retrieval, wywołanie modelu i narzędzia bez rozpowszechniania treści w wielu systemach.

Koszt obserwuj na poziomie przypadku użycia, nie wyłącznie pojedynczego wywołania. Jedno zgłoszenie może uruchomić embedding, kilka wyszukań, dwie próby modelu i narzędzie. Zapisuj łączny czas, koszt, liczbę kroków oraz odsetek spraw wymagających korekty człowieka. Dopiero taki pomiar pokazuje, czy automatyzacja poprawia proces.

Aktualizuj pakiety przez kontrakty i testy

Warstwy abstrakcji nie zwalniają z kontroli wersji. Przypnij pakiety, zapisuj wersję modelu oraz utrzymuj testy kontraktowe dla adapterów. Test klienta czatu powinien sprawdzać wynik strukturalny, streaming, anulowanie i obsługę limitu. Test magazynu wektorowego powinien potwierdzać filtry, kolejność wyników i usuwanie dokumentu. Dla MCP sprawdź odkrywanie narzędzi, odmowę bez zakresu oraz niepoprawne argumenty. Aktualizację wykonuj najpierw w środowisku testowym, porównując jakość, opóźnienie i koszt ze stałą bazą. Dzięki temu zmiana pakietu lub dostawcy pozostaje kontrolowaną decyzją, a nie przypadkowym wdrożeniem nowego zachowania.

Plan wdrożenia dla zespołu .NET

Wybierz jeden przypadek, w którym istnieje właściciel procesu i możliwy do sprawdzenia wynik. Zbuduj pionowy wycinek na .NET 10 z Microsoft.Extensions.AI. Jeśli potrzebna jest wiedza firmy, dodaj ingestia–retrieval wraz z metadanymi uprawnień. MCP wprowadź wtedy, gdy narzędzie ma być współdzielone. Agent Framework dodaj dopiero po wykazaniu, że prosty przepływ nie wystarcza.

Przegląd architektury powinien odpowiedzieć na pięć pytań: kto zatwierdza wynik, skąd pochodzi wiedza, gdzie egzekwowane są uprawnienia, co dzieje się po awarii i jak wykryjesz regresję. Następnie osadź rozwiązanie w systemie pracy z AI, aby model, dane i proces miały właścicieli. Gdy aplikacja składa się z kilku usług i zależności, kolejnym krokiem jest praktyczne użycie .NET Aspire do ujednolicenia uruchamiania oraz diagnostyki.