AI Apps | The .NET Blog

SQL Server 2025 jako baza danych gotowa na agentów: bezpieczeństwo, backup i MCP w jednym silniku

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

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

Śledziłem serię Polyglot Tax Adityi Badramraju z dużym zainteresowaniem. Części 1-3 zbudowały mocny argument za SQL Server 2025 jako naprawdę wielomodelową bazą danych — JSON, graph, vector i dane relacyjne w jednym silniku z ujednoliconym query plannerem. Część 4 zamyka serię tym, co naprawdę decyduje o tym, czy zaufałbyś tej architekturze w produkcji.

Spoiler: historia produkcyjna jest solidna.

Jeden Model Bezpieczeństwa dla Wszystkich Modeli Danych

To jest problem stacków poliglotycznych: gdy audytor pyta “udowodnij, że Tenant A nie widzi danych Tenant B”, musisz odpowiedzieć na to pytanie osobno dla każdej bazy danych. Pięć baz danych, pięć modeli bezpieczeństwa, pięć dowodów.

W SQL Server 2025 definiujesz jedną politykę Row-Level Security i obejmuje ona wszystkie modele danych:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

Od tego momentu każde zapytanie — relacyjne joiny, zapytania po ścieżkach JSON, traversale graph, wyszukiwanie podobieństwa vector — jest automatycznie filtrowane po tenant. Silnik wstrzykuje predykat do planu wykonania, zanim jakiekolwiek dane opuszczą storage. Twój kod wywołujący nie musi wszędzie pisać WHERE TenantID = @id. Testujesz politykę raz.

Warstwy nakładają się dalej: Dynamic Data Masking dla kolumn, które nie powinny pokazywać pełnych wartości niektórym rolom, Always Encrypted dla szyfrowania end-to-end (nawet DBA nie mogą tego odczytać) oraz stored procedures jako granica uprawnień, aby agenci wywoływali tylko to, co jawnie udostępniłeś.

To jest część architektury, która ma największe znaczenie dla SaaS z dużymi wymaganiami compliance. Jedna polityka, jeden dowód.

Ujednolicony Backup = Atomowe Odzyskiwanie

Jedna instrukcja, wszystkie modele danych, spójny punkt w czasie:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

W stacku poliglotycznym odzyskiwanie point-in-time dla pięciu baz danych oznacza koordynację pięciu operacji restore i nadzieję, że znaczniki czasu zbiegną się w ciągu jednej lub dwóch sekund. Dla danych finansowych taka dwusekundowa niespójność jest nie do zaakceptowania. Z jedną bazą danych, jednym logiem transakcji i jednym restore — odzyskiwanie jest atomowe z definicji.

Tabele Ledger dla Ścieżek Audytu Odpornych na Manipulacje

W branżach regulowanych potrzebujesz czegoś więcej niż “mamy logi”. Potrzebujesz kryptograficznego dowodu, że te logi nie zostały zmienione:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

Każdy insert, update i delete jest kryptograficznie hashowany w strukturze podobnej do blockchaina. Możesz matematycznie udowodnić audytorowi, że wiersz nie był manipulowany od momentu zapisania. W stacku poliglotycznym taka możliwość nie istnieje w sposób jednolity we wszystkich twoich bazach danych.

Integracja MCP: Agenci Bez Ręcznie Pisanej Warstwy Middleware

Seria prowadziła właśnie do tego: SQL Server 2025 wspiera SQL MCP Server bezpośrednio, co oznacza, że twoi agenci mogą wywoływać bazę danych przez natural language tool calls bez pisania middleware dla każdej operacji.

Połącz to ze stored procedures jako granicą uprawnień i Row-Level Security wymuszanym na poziomie silnika, a otrzymasz model, w którym:

Agent wywołuje narzędzie, na przykład “pobierz kontekst klienta dla konta 12345”
MCP tłumaczy to na zdefiniowaną przez ciebie stored procedure
Silnik SQL automatycznie wymusza izolację tenant i maskowanie kolumn
Agent dostaje dokładnie te dane, które może zobaczyć

Nie ma warstwy middleware. Nie ma ryzyka ad-hoc query injection. Autoryzację obsługuje silnik, nie agent.

Dlaczego To Ma Znaczenie dla Programistów .NET

Jeśli budujesz usługi .NET, a SQL Server jest twoim podstawowym magazynem danych, przekaz tej serii jest prosty: nie musisz dodawać Redis do cache, graph database do relacji ani vector store do embeddings. SQL Server 2025 obsługuje to wszystko — z lepszą spójnością operacyjną niż stack poliglotyczny i z ujednoliconym bezpieczeństwem, które naprawdę da się audytować.

Integracja MCP oznacza, że twoi agenci Semantic Kernel lub workflow Microsoft Agent Framework mogą komunikować się z warstwą danych przez ten sam SQL MCP Server, z takimi samymi gwarancjami bezpieczeństwa, jakie zastosowałbyś do zapytań ludzi.

Podsumowanie

Serię Polyglot Tax warto przeczytać od początku do końca. Części 1-3 dowodzą historii query planner. Część 4 dowodzi historii produkcyjnej. Dla programistów .NET budujących aplikacje agent-first lub AI-augmented na Azure SQL, ta architektura zasługuje na poważne rozważenie.

Oryginalny post autorstwa Adityi Badramraju: The Polyglot Tax – Part 4.

68 Minut Dziennie na Ponowne Tłumaczenie Kodu Copilotowi? Jest na to Sposób

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

Znasz ten moment, gdy Twoja sesja Copilot dochodzi do /compact, a agent kompletnie zapomina, nad czym pracowałeś? Przez kolejne pięć minut ponownie tłumaczysz strukturę plików, nieudany test i trzy podejścia, które już wypróbowałeś. Potem dzieje się to znowu. I znowu.

Desi Villanueva zmierzył to: 68 minut dziennie — tylko na ponowną orientację. Nie na pisanie kodu. Nie na review PR-ów. Tylko na ponowne wprowadzanie AI w to, co już wiedziała.

Okazuje się, że istnieje konkretny powód, dla którego tak się dzieje, i konkretne rozwiązanie.

Kłamstwo okna kontekstu

Twój agent przychodzi z wielką liczbą na pudełku. 200K tokenów. Brzmi imponująco. W praktyce to sufit, a nie gwarancja.

Oto rzeczywiste obliczenia:

200K całkowitego contextu
Minus około 65K na narzędzia MCP załadowane przy starcie (~33%)
Minus około 10K na pliki instrukcji, takie jak AGENTS.md albo copilot-instructions.md

To zostawia Ci około 125K, zanim napiszesz choć jedno słowo. I jest jeszcze gorzej — LLM-y nie degradują się łagodnie, gdy context się zapełnia. Uderzają w ścianę przy około 60% pojemności. Model zaczyna gubić rzeczy wspomniane 30 tur wcześniej, zaprzecza wcześniejszym odpowiedziom i halucynuje nazwy plików, które 10 minut wcześniej z pełnym przekonaniem podał. Branża nazywa to problemem “lost in the middle”.

Efektywny limit: 45K tokenów zanim jakość zacznie spadać. To może oznaczać 20-30 aktywnych tur rozmowy, zanim agent zacznie dryfować. Dlatego trafiasz na /compact co 45 minut — nie dlatego, że zużyłeś 200K tokenów, ale dlatego, że model już przy 120K zaczyna się psuć.

Podatek kompaktacji

Każdy /compact zabiera Ci stan przepływu. Jesteś głęboko w sesji debugowania. Wspólny context budował się przez 30 minut. Agent zna strukturę plików, nieudany test i hipotezę. Potem pojawia się ostrzeżenie.

Zignoruj je → agent stopniowo głupieje i zaczyna halucynować stary stan
Uruchom /compact → agent dostaje dwuzdaniowe streszczenie 30-minutowego dochodzenia

W obu przypadkach przegrywasz. W obu przypadkach opowiadasz swój projekt tak, jakbyś był nowym pracownikiem pierwszego dnia.

Najgorsze? Pamięć już istnieje. Copilot CLI zapisuje każdą sesję do lokalnej bazy SQLite w ~/.copilot/session-store.db — każdy dotknięty plik, każdą turę, każdy checkpoint. Wszystko leży na dysku. Agent po prostu nie potrafi tego odczytać.

auto-memory: warstwa recall, nie system pamięci

To jest główna idea stojąca za auto-memory: nie buduj nowego systemu pamięci — zbuduj warstwę zapytań tylko do odczytu na tym, co już istnieje.

pip install auto-memory

Około 1,900 linii Pythona. Zero zależności. Instaluje się w 30 sekund.

Zamiast zalewać context wynikami grep, dajesz agentowi chirurgiczny dostęp do tego, co naprawdę ma znaczenie:

Operacja	Tokeny	Co dostajesz
`grep -r "auth" src/`	~5,000–10,000	500 wyników, z których większość jest nieistotna
`find . -name "*.py"`	~2,000	Wszystkie pliki Pythona, bez kontekstu
Ponowna orientacja agenta	~2,000	Ty tłumaczysz to, co on już powinien wiedzieć
`auto-memory files --json --limit 10`	~50	10 plików, nad którymi pracowałeś wczoraj

To poprawa 200x. Agent omija wykopaliska archeologiczne i od razu trafia do tego, co ważne.

Rekomendowany przepływ: gdy zbliżasz się do użycia 50-70% contextu, uruchom /clear, a potem wpisz: “przejrzyj ostatnie sesje, w których omawialiśmy temat X”. Zamiast spalać 12K tokenów na ślepe wyszukiwanie, auto-memory wyciąga odpowiedni context w 50.

Dlaczego to ma znaczenie dla programistów .NET

Jeśli używasz GitHub Copilot CLI do pracy z .NET — scaffoldowanie usług, debugowanie zapytań EF Core, iterowanie nad komponentami Blazor — problem context rot uderza równie mocno. Złożone rozwiązania z wieloma projektami, współdzielonymi bibliotekami i głębokimi łańcuchami wywołań to dokładnie ten rodzaj codebase’u, w którym agent najszybciej gubi wątek.

Instrukcja instalacji pokazuje, jak skierować na to Copilot CLI. To jednorazowa konfiguracja.

Szczerze? Odzyskanie 68 minut dziennie to nie jest drobny tweak jakości życia. To prawie 6 godzin tygodniowo.

Podsumowanie

Context rot to realne ograniczenie architektoniczne, a nie bug, który po prostu zostanie załatany. auto-memory omija je, dając agentowi tani i precyzyjny mechanizm recall zamiast kosztownego i hałaśliwego ponownego eksplorowania. Jeśli prowadzisz poważny development wspierany przez AI z GitHub Copilot CLI, ta 30-sekundowa instalacja jest tego warta.

Sprawdź: auto-memory na GitHubie. Oryginalny wpis Desi Villanuevy: I Wasted 68 Minutes a Day Re-Explaining My Code.