AI Apps | The .NET Blog

SQL Server 2025 com a base de dades preparada per a agents: seguretat, còpies de seguretat i MCP en un sol motor

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

Aquest post ha estat traduït automàticament. Per a la versió original, fes clic aquí.

He seguit la sèrie Polyglot Tax d’Aditya Badramraju amb molt d’interès. Les parts 1-3 van construir un cas convincent per a SQL Server 2025 com una base de dades realment multimodel — JSON, grafs, vectors i dades relacionals en un sol motor amb un planificador de consultes unificat. La part 4 tanca la sèrie amb les parts que realment determinen si confiaries en aquesta arquitectura en producció.

Spoiler: la història de producció és sòlida.

Un Sol Model de Seguretat per a Tots els Models de Dades

Això és el que passa amb els stacks poliglotes: quan un auditor pregunta “demostra que el Tenant A no pot veure les dades del Tenant B”, has de respondre aquesta pregunta per a cada base de dades de manera independent. Cinc bases de dades, cinc models de seguretat, cinc proves.

Amb SQL Server 2025, defineixes una sola política de Row-Level Security i cobreix tots els models de dades:

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);

A partir d’aquí, qualsevol consulta — joins relacionals, consultes de camins JSON, travessies de graf, cerques de similitud vectorial — es filtra automàticament per tenant. El motor injecta el predicat a la planificació abans que cap dada surti de l’emmagatzematge. El teu codi no necessita WHERE TenantID = @id per tot arreu. Proves la política una sola vegada.

Les capes es combinen encara més: Dynamic Data Masking per a les columnes que no haurien de mostrar els valors complets a certs rols, Always Encrypted per al xifrat de punta a punta (fins i tot els DBAs no el poden llegir), i els stored procedures com a frontera de permisos perquè els agents només cridin allò que has exposat explícitament.

Aquesta és la part de l’arquitectura que realment importa en un SaaS amb requisits de compliment. Una política, una prova.

Còpia de Seguretat Unificada = Recuperació Atòmica

Una instrucció, tots els models de dades, un punt en el temps coherent:

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';

En un stack poliglota, la recuperació point-in-time a través de cinc bases de dades significa coordinar cinc operacions de restauració i esperar que els timestamps encaixin dins d’un o dos segons. Per a dades financeres, aquesta inconsistència de dos segons és inacceptable. Amb una sola base de dades, un sol registre de transaccions i una sola restauració — la recuperació és atòmica per definició.

Taules Ledger per a Rastreig d’Auditoria a Prova de Manipulacions

Per a sectors regulats, necessites més que “tenim logs”. Necessites prova criptogràfica que aquells logs no han estat modificats:

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);

Cada insert, update i delete queda hashat criptogràficament dins d’una estructura tipus blockchain. Pots demostrar a un auditor — matemàticament — que una fila no ha estat manipulada des que es va escriure. En un stack poliglota, aquesta capacitat no existeix de manera uniforme a totes les teves bases de dades.

Integració MCP: Agents Sense Middleware Fet a Mà

Això és cap on anava la sèrie: SQL Server 2025 dona suport directe al SQL MCP Server, cosa que significa que els teus agents poden cridar la base de dades mitjançant tool calls en llenguatge natural sense que hagis d’escriure middleware per a cada operació.

Combina això amb els stored procedures com a frontera de permisos i amb Row-Level Security aplicada al motor, i tens un model on:

L’agent crida una eina, per exemple “obté el context del client per al compte 12345”
MCP ho tradueix al stored procedure que has definit
El motor SQL aplica l’aïllament de tenant i l’emmascarament de columnes automàticament
L’agent rep exactament les dades que té permís de veure

No hi ha capa de middleware. No hi ha risc d’injecció de consultes ad hoc. El motor gestiona l’autorització, no l’agent.

Per Què Això Importa Als Desenvolupadors .NET

Si estàs construint serveis .NET amb SQL Server com a magatzem principal, el missatge d’aquesta sèrie és: no necessites afegir Redis per a la caché, ni una base de dades de graf per a les relacions, ni un magatzem vectorial per a les embeddings. SQL Server 2025 s’encarrega de tot això — amb una coherència operativa millor que un stack poliglota i una seguretat unificada que realment es pot auditar.

La integració MCP significa que els teus agents de Semantic Kernel o els fluxos de Microsoft Agent Framework poden interactuar amb la capa de dades a través del mateix SQL MCP Server, amb les mateixes garanties de seguretat que imposaries a les consultes humanes.

Tancant

La sèrie Polyglot Tax val la pena llegir-la de cap a cap. Les parts 1-3 demostren la història del planificador de consultes. La part 4 demostra la història de producció. Per als desenvolupadors .NET que construeixen aplicacions agent-first o AI-augmented sobre Azure SQL, aquesta arquitectura mereix una consideració seriosa.

Publicació original d’Aditya Badramraju: The Polyglot Tax – Part 4.

68 Minuts al Dia Reexplicant Codi a Copilot? Hi Ha una Solució

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

Aquesta publicació ha estat traduïda automàticament. Per a la versió original, fes clic aquí.

Saps aquell moment en què la teva sessió de Copilot arriba a /compact i l’agent oblida completament què estaves fent? Passes els cinc minuts següents reexplicant l’estructura de carpetes, el test que falla i les tres aproximacions que ja has provat. I després torna a passar. I una altra vegada.

Desi Villanueva ho va mesurar: 68 minuts al dia — només en reorientació. No escrivint codi. No revisant PRs. Només posant la IA al corrent del que ja sabia.

Resulta que hi ha una raó concreta per això, i una solució concreta.

La mentida de la finestra de context

El teu agent ve amb un número gran a la capsa. 200K tokens. Sona massiu. A la pràctica és un sostre, no una garantia.

Aquí tens la matemàtica real:

200K de context total
Menys uns 65K per a eines MCP carregades a l’arrencada (~33%)
Menys uns 10K per a fitxers d’instruccions com AGENTS.md o copilot-instructions.md

Això et deixa aproximadament 125K abans d’escriure ni una paraula. I encara va a pitjor — els LLM no es degraden amb gràcia a mesura que el context s’omple. Xoquen amb una paret al voltant del 60% de la capacitat. El model comença a perdre coses esmentades fa 30 torns, contradiu respostes anteriors, i al·lucina noms de fitxer que havia dit amb total confiança fa 10 minuts. La indústria anomena això el problema de “lost in the middle”.

Límit efectiu: 45K tokens abans que la qualitat es degradi. Això són potser 20-30 torns de conversa activa abans que l’agent comenci a desviar-se. Per això estàs fent /compact cada 45 minuts — no perquè hagis omplert 200K tokens, sinó perquè el model ja està prou degradat a 120K.

L’impost de la compactació

Cada /compact et fa perdre l’estat de flux. Estàs immers en una sessió de depuració. El context compartit s’ha anat construint durant 30 minuts. L’agent coneix l’estructura de fitxers, el test que falla i la hipòtesi. Llavors arriba l’avís.

Ignora’l → l’agent es torna progressivament més tonto i comença a al·lucinar l’estat antic
Executa /compact → l’agent obté un resum de dos paràgrafs d’una investigació de 30 minuts

En qualsevol dels dos casos perds. En qualsevol dels dos casos estàs narrant el teu propi projecte com si fos un nou empleat el primer dia.

La part cruel? La memòria ja existeix. Copilot CLI escriu cada sessió a una base de dades SQLite local a ~/.copilot/session-store.db — cada fitxer tocat, cada torn, cada punt de control. Tot és al disc. L’agent simplement no ho pot llegir.

auto-memory: una capa de recuperació, no un sistema de memòria

Aquesta és la idea clau darrere de auto-memory: no construeixis un sistema de memòria nou — construeix una capa de consulta només lectura sobre la que ja existeix.

pip install auto-memory

Unes 1.900 línies de Python. Zero dependències. S’instal·la en 30 segons.

En lloc d’inundar el context amb resultats de grep, li dones a l’agent accés quirúrgic al que realment importa:

Operació	Tokens	Què obtens
`grep -r "auth" src/`	~5,000–10,000	500 resultats, la majoria irrellevants
`find . -name "*.py"`	~2,000	Tots els fitxers Python, sense context
Reorientació de l’agent	~2,000	Tu explicant allò que ja hauria de saber
`auto-memory files --json --limit 10`	~50	Els 10 fitxers en què vas treballar ahir

Això és una millora de 200x. L’agent s’estalvia l’excavació arqueològica i va directament al que importa.

El flux recomanat: quan t’acostis al 50-70% d’ús del context, executa /clear i després demana: “revisa les últimes sessions que vam parlar del tema X”. En lloc de cremar 12K tokens en cerques a cegues, auto-memory extreu el context rellevant en 50.

Per què això importa als desenvolupadors .NET

Si fas servir GitHub Copilot CLI per a feina de .NET — scaffolding de serveis, depuració de consultes EF Core, iteració sobre components Blazor — el problema del context rot et pega igual de fort. Les solucions complexes amb múltiples projectes, biblioteques compartides i cadenes de crida profundes són exactament el tipus de codebase en què l’agent perd el fil més ràpid.

La guia d’instal·lació explica com apuntar-hi Copilot CLI. És una configuració d’una sola vegada.

Sincerament? Recuperar 68 minuts al dia no és un petit ajust de qualitat de vida. Això és gairebé 6 hores a la setmana.

Resumint

El context rot és una restricció arquitectònica real, no un bug que es corregirà. auto-memory la rodeja donant al teu agent un mecanisme de recuperació barat i precís en lloc d’una reexploració costosa i sorollosa. Si fas desenvolupament seriós assistit per IA amb GitHub Copilot CLI, val la pena la instal·lació de 30 segons.

Fes-hi un cop d’ull: auto-memory a GitHub. Post original de Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.