AI Foundry | The .NET Blog

Azure SDK d'abril de 2026: AI Foundry 2.0 i el que els desenvolupadors de .NET han de saber

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

Les versions mensuals de l’SDK sovint són fàcils d’ignorar. Aquesta en té algunes coses que val la pena tenir en compte — sobretot si estàs construint amb AI Foundry, amb Cosmos DB en Java o si fas aprovisionament d’infraestructura des de codi .NET.

Azure.AI.Projects 2.0.0 — Canvis trencadors que tenen sentit

El paquet NuGet Azure.AI.Projects arriba a la versió estable 2.0.0 amb alguns canvis arquitectònics importants. Si ja estàs fent servir la preview, això és el que ha canviat:

Separació de namespaces: Evaluations s’ha mogut a Azure.AI.Projects.Evaluation, i memory operations a Azure.AI.Projects.Memory. Hauràs d’actualitzar els using.
Tipus reanomenats: Insights → ProjectInsights, Schedules → ProjectSchedules, Evaluators → ProjectEvaluators, Trigger → ScheduleTrigger
Convencions de nomenclatura: les propietats booleanes ara segueixen de manera consistent la convenció Is*

Són el tipus de canvis trencadors que fan mal una vegada i després semblen els correctes per sempre. Si has construït sobre la preview, actualitza les importacions i deixa que el compilador t’assenyali la resta.

La bona notícia: ara és estable. Ja pots confiar de debò en aquesta API.

Cosmos DB Java: correcció de seguretat crítica (RCE)

Això és seriós. La biblioteca Java de Cosmos DB (azure-cosmos) versió 4.79.0 inclou una correcció de seguretat crítica per a una vulnerabilitat d’execució remota de codi (CWE-502).

El problema era la deserialització Java a CosmosClientMetadataCachesSnapshot, AsyncCache i DocumentCollection. La correcció substitueix la deserialització Java per serialització basada en JSON, eliminant tota la classe d’atacs de deserialització.

Si tens algun servei Java que faci servir Azure Cosmos DB, actualitza immediatament a 4.79.0. Això no és opcional.

Noves biblioteques de Provisioning per a .NET

Aquest mes han arribat diverses biblioteques de Provisioning estables a 1.0.0 — són les biblioteques que et permeten definir infraestructura d’Azure en codi C# en lloc de plantilles ARM o Bicep:

N’hi ha diverses més en beta.1, que cobreixen API Management, Batch, Compute, Monitor, MySQL i Security Center. Si fas infraestructura com a codi des de .NET — especialment amb desplegaments Aspire — aquestes biblioteques són el teu punt d’entrada.

Azure AI Agents Java: 2.0.0 GA

La biblioteca Java d’Azure AI Agents també arriba aquest mes a disponibilitat general. Els principals canvis trencadors són:

Diversos tipus enum convertits en classes basades en ExpandableStringEnum (més flexibles per a valors nous)
Les classes de model *Param reanomenades a *Parameter
MCPToolConnectorId → McpToolConnectorId (coherència en la capitalització)
Nou overload de conveniència per a beginUpdateMemories

Tancant

La notícia principal per als desenvolupadors de .NET aquest mes és que Azure.AI.Projects 2.0.0 passa a estable — si construeixes amb AI Foundry, ara és el moment de fixar-te en la versió estable i actualitzar les importacions. Per als equips Java que fan servir Cosmos DB, l’actualització de seguretat és urgent.

Tens les notes de llançament completes a aka.ms/azsdk/releases. Publicació original: Azure SDK Release (April 2026).

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.