Azure | The .NET Blog

El Azure MCP Server Ara és un .mcpb — Instal·la'l sense Cap Runtime

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í.

Saps el que era molest de configurar servidors MCP? Necessitaves un runtime. Node.js per a la versió npm, Python per a pip/uvx, .NET SDK per a la variant dotnet.

L’Azure MCP Server acaba de canviar això. Ara està disponible com a .mcpb — un MCP Bundle — i la configuració és arrossegar i deixar anar.

Què és un MCP Bundle?

Pensa-hi com una extensió de VS Code (.vsix) o una extensió de navegador (.crx), però per a servidors MCP. Un fitxer .mcpb és un arxiu ZIP autònom que inclou el binari del servidor i totes les seves dependències.

Com instal·lar-lo

1. Descarrega el bundle per a la teva plataforma

Ves a la pàgina de GitHub Releases i descarrega el fitxer .mcpb per al teu OS i arquitectura.

2. Instal·la a Claude Desktop

La manera més fàcil: arrossega i deixa anar el fitxer .mcpb a la finestra de Claude Desktop mentre estàs a la pàgina de configuració d’Extensions. Revisa els detalls del servidor, fes clic a Instal·la i confirma.

3. Autentifica’t a Azure

az login

Per a començar

Descarrega: GitHub Releases
Repositori: aka.ms/azmcp

Consulta el post complet per a més detalls.

GPT-5.5 Ja És Aquí a Azure Foundry — El que els Desenvolupadors .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í.

Microsoft acaba d’anunciar que GPT-5.5 ja és disponible a Microsoft Foundry. Si has estat construint agents a Azure, aquesta és l’actualització que esperaves.

La progressió de GPT-5

GPT-5: va unificar raonament i velocitat en un sol sistema
GPT-5.4: raonament multi-pas més robust, capacitats agèntiques per a empreses
GPT-5.5: raonament de llarg context més profund, execució agèntica més fiable, millor eficiència de tokens

Què ha canviat realment

Millor codificació agèntica: GPT-5.5 manté el context a través de grans bases de codi, diagnostica fallades arquitectòniques i anticipa requisits de proves.

Eficiència de tokens: Sortides de major qualitat amb menys tokens i menys reintents. Menys cost i latència en producció.

Anàlisi de llarg context: Gestiona documents extensos i historials multi-sessió sense perdre el fil.

Preus

Model	Entrada ($/M tokens)	Entrada en memòria cau	Sortida ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

Foundry Agent Service

Defineix agents en YAML o connecta’ls amb Microsoft Agent Framework, GitHub Copilot SDK, LangGraph o l’SDK d’OpenAI Agents — i executa’ls com a agents allotjats aïllats amb sistema de fitxers persistent, identitat de Microsoft Entra i preus d’escala a zero.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Ets un assistent útil.", name: "ElMeuAgent");

Consulta l’anunci complet.

Foundry Toolboxes: Un únic endpoint per a totes les eines dels teus agents

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

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

Hi ha un problema que sembla avorrit fins que el pateixes de primera mà: la teva organització està construint múltiples agents d’IA, cadascun necessita eines, i cada equip les connecta des de zero. La mateixa integració de cerca web, la mateixa config d’Azure AI Search, la mateixa connexió al servidor MCP de GitHub — però en un altre repositori, per un altre equip, amb altres credencials i sense cap governança compartida.

Microsoft Foundry acaba de llançar Toolboxes en preview pública, i és una resposta directa a aquest problema.

Què és un Toolbox?

Un Toolbox és un bundle d’eines amb nom, reutilitzable, que defineixes una vegada a Foundry i exposes a través d’un únic endpoint compatible amb MCP. Qualsevol runtime d’agent que parli MCP pot consumir-lo — no estàs bloquejat a Foundry Agents.

La proposta és simple: build once, consume anywhere. Defineix les eines, configura l’autenticació de forma centralitzada, publica l’endpoint. Cada agent que necessiti les eines es connecta a l’endpoint i les obté totes.

Els quatre pilars (dos disponibles avui)

Pilar	Estat	Què fa
Discover	Pròximament	Troba eines aprovades sense buscar manualment
Build	Disponible avui	Agrupa eines en un bundle reutilitzable
Consume	Disponible avui	Un únic endpoint MCP exposa totes les eines
Govern	Pròximament	Auth centralitzada + observabilitat en totes les crides

Exemple pràctic

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Cerca documentació i respon a issues de GitHub.",
 tools=[
 {"type": "web_search", "description": "Cerca documentació pública"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Un cop publicat, Foundry et dona un endpoint unificat. Un punt de connexió, totes les eines.

No estàs bloquejat a Foundry Agents

Els Toolboxes es creen i gestionen a Foundry, però la superfície de consum és el protocol MCP obert. Pots usar-los des d’agents personalitzats amb Microsoft Agent Framework o LangGraph, GitHub Copilot i qualsevol runtime que parli MCP.

Per què importa ara

L’onada multi-agent està arribant a producció. Cada nou agent és una nova superfície per a configuració duplicada, credencials desfasades i comportament inconsistent. La base de Build + Consume és suficient per començar a centralitzar. Quan arribi el pilar Govern, tindràs una capa d’eines observable i controlada centralment per a tota la teva flota d’agents.

Conclusió

Això és aviat — preview pública, SDK Python primer. Però el model és sòlid i el disseny natiu MCP significa que funciona amb les eines que ja estàs construint. Fes una ullada a l’anunci oficial per començar.

azd + GitHub Copilot: Configuració de projecte amb IA i resolució intel·ligent d'errors

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Aquest article ha estat traduït automàticament. Per veure la versió original en anglès, fes clic aquí.

Coneixes aquell moment en què vols desplegar una aplicació existent a Azure i et quedes mirant un azure.yaml en blanc, intentant recordar si la teva API Express hauria d’usar Container Apps o App Service? Aquell moment acaba de ser molt més curt.

L’Azure Developer CLI (azd) ara s’integra amb GitHub Copilot de dues maneres concretes: scaffolding assistit per IA durant azd init, i resolució intel·ligent d’errors quan els desplegaments fallen. Les dues funcions es queden completament al terminal — exactament on vull que siguin.

Configuració amb Copilot durant azd init

Quan executes azd init, ara apareix l’opció “Set up with GitHub Copilot (Preview)”. Selecciona-la i Copilot analitza el teu codebase per generar l’azure.yaml, les plantilles d’infraestructura i els mòduls Bicep — basant-se en el teu codi real.

azd init
# Selecciona: "Set up with GitHub Copilot (Preview)"

Requisits:

azd 1.23.11 o superior — comprova amb azd version o actualitza amb azd update
Una subscripció activa de GitHub Copilot (Individual, Business o Enterprise)
GitHub CLI (gh) — azd demanarà login si cal

El que trobo genuïnament útil és que funciona en els dos sentits. Construint des de zero? Copilot t’ajuda a configurar els serveis Azure correctes des del principi. Tens una app existent que vols desplegar? Apunta Copilot cap a ella i genera la configuració sense haver de reestructurar res.

El que fa realment

Imagina que tens una API Express en Node.js amb dependència de PostgreSQL. En lloc de decidir manualment entre Container Apps i App Service, i després escriure Bicep des de zero, Copilot detecta el teu stack i genera:

Un azure.yaml amb els ajustaments correctes de language, host i build
Un mòdul Bicep per a Azure Container Apps
Un mòdul Bicep per a Azure Database for PostgreSQL

I fa comprovacions prèvies abans de tocar res — verifica que el teu directori git estigui net, demana consentiment per a les eines del servidor MCP. Res no passa sense que sàpigues exactament què canviarà.

Resolució d’errors amb Copilot

Els errors de desplegament són inevitables. Paràmetres que falten, problemes de permisos, disponibilitat de SKUs — i el missatge d’error rarament et diu l’única cosa que realment necessites saber: com solucionar-ho.

Sense Copilot, el cicle és: copiar l’error → buscar als docs → llegir tres respostes irrellevants de Stack Overflow → executar alguns comandos az CLI → tornar-ho a intentar i rezar. Amb Copilot integrat a azd, aquest cicle s’esfondra. Quan qualsevol comandament azd falla, ofereix immediatament quatre opcions:

Explain — descripció en llenguatge natural del que ha anat malament
Guidance — instruccions pas a pas per solucionar-ho
Diagnose and Guide — anàlisi completa + Copilot aplica la solució (amb la teva aprovació) + reintent opcional
Skip — gestionar-ho tu mateix

El punt clau: Copilot ja té context sobre el teu projecte, el comandament que ha fallat i la sortida de l’error. Les seves suggerències són específiques per a la teva situació.

Configurar un comportament predeterminat

Si sempre tries la mateixa opció, salta el prompt interactiu:

azd config set copilot.errorHandling.category troubleshoot

Valors: explain, guidance, troubleshoot, fix, skip. També pots habilitar auto-fix i reintent:

azd config set copilot.errorHandling.fix allow

Torna al mode interactiu en qualsevol moment:

azd config unset copilot.errorHandling.category

Conclusió

Executa azd update per obtenir la versió més recent i usa azd init en el teu proper projecte. És exactament el tipus d’integració de Copilot que aporta valor real.

Llegeix l’anunci original aquí.

Els vostres experiments d'IA a Azure estan cremant diners: aquí teniu com solucionar-ho

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

Si esteu creant aplicacions amb intel·ligència artificial a Azure en aquest moment, probablement heu notat alguna cosa: la vostra factura al núvol sembla diferent del que abans. No només més alt, sinó més estrany. Espinós. Difícil de predir.

Microsoft acaba de publicar un article fantàstic sobre principis d’optimització de costos del núvol que encara importen, i sincerament, el moment no podria ser millor. Perquè les càrregues de treball d’IA han canviat el joc pel que fa als costos.

Per què les càrregues de treball d’IA són diferents

Aquí està la cosa. Les càrregues de treball.NET tradicionals són relativament previsibles. Coneixeu el vostre nivell de servei d’aplicacions, coneixeu les vostres DTU SQL, podeu estimar la despesa mensual amb força precisió. Càrregues de treball d’IA? No tant.

Esteu provant diversos models per veure quin s’adapta. Esteu creant una infraestructura recolzada per la GPU per ajustar-la. Esteu fent trucades a l’API a Azure OpenAI, on el consum de testimoni varia enormement depenent de la durada del missatge i del comportament de l’usuari. Cada experiment costa diners reals i podeu executar-ne desenes abans d’aconseguir l’enfocament correcte.

Aquesta impredictibilitat és el que fa que l’optimització de costos sigui crítica, no com una idea posterior, sinó des del primer dia.

Gestió vs. optimització: coneixeu la diferència

Una distinció de l’article que crec que els desenvolupadors passen per alt: hi ha una diferència entre gestió de costos i optimització de costos.

La gestió és el seguiment i la presentació d’informes. Configureu pressupostos a Azure Cost Management, rebeu alertes i veureu taulers de control. Això són apostes de taula.

L’optimització és on realment es prenen decisions. Realment necessiteu aquest nivell S3 o S1 gestionaria la vostra càrrega? Aquesta instància informàtica sempre activa està inactiva els caps de setmana? Podríeu utilitzar instàncies puntuals per als vostres treballs de formació?

Com a desenvolupadors de.NET, tendim a centrar-nos en el codi i deixar les decisions sobre la infraestructura a “l’equip d’operacions”. Però si esteu implementant a Azure, aquestes decisions també són les vostres.

El que realment funciona

A partir de l’article i de la meva pròpia experiència, aquí teniu el que mou l’agulla:

Coneix el que gastes i on. Etiqueta els teus recursos. De debò. Si no sabeu quin projecte o experiment s’està consumint el vostre pressupost, no podeu optimitzar res. Azure Cost Management amb l’etiquetatge adequat és el vostre millor amic.

Configureu baranes abans d’experimentar. Utilitzeu la política d’Azure per restringir les SKU cares en entorns de desenvolupament/prova. Establiu límits de despesa als vostres desplegaments d’Azure OpenAI. No espereu fins que arribi la factura per adonar-vos que algú va deixar un clúster de GPU en funcionament durant el cap de setmana.

Mida correctament contínuament. Aquesta màquina virtual que vau triar durant la creació de prototips? Probablement és incorrecte per a la producció. Azure Advisor us ofereix recomanacions; mireu-les. Revisió mensual, no anual.

Penseu en el cicle de vida. Els recursos per a desenvolupadors haurien de baixar. Els entorns de prova no cal que funcionin les 24 hores del dia. Utilitzeu polítiques d’apagada automàtica. Específicament, per a les càrregues de treball d’IA, tingueu en compte les opcions sense servidor on pagueu per execució en lloc de mantenir el càlcul calent.

Mesura el valor, no només el cost. Aquest és fàcil d’oblidar. Un model que costa més però que ofereix resultats significativament millors podria ser la trucada adequada. L’objectiu no és gastar el mínim, sinó gastar intel·ligentment.

El menjar per emportar

L’optimització de costos del núvol no és una neteja puntual. És un hàbit. I amb les càrregues de treball d’IA que fan que la despesa sigui menys predictible que mai, construir aquest hàbit aviat us estalvia de sorpreses doloroses més tard.

Si sou un desenvolupador de.NET que es basa en Azure, comenceu a tractar la vostra factura al núvol com si tracteu el codi: reviseu-lo regularment, refactoritzeu-lo quan estigui desordenat i mai no ho feu sense entendre el que us costarà.

L'RFT de Foundry s'ha tornat més barat i intel·ligent: això és el que ha canviat

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

Si esteu creant aplicacions.NET que es basen en models afinats, val la pena prestar atenció a les actualitzacions de Foundry d’aquest mes. L’afinació del reforç acaba de ser més accessible i molt més barata.

Els detalls complets es troben a l’anunci oficial, però aquí teniu el desglossament pràctic.

Formació global per a o4-mini

o4-mini és el model de referència per a càrregues de treball pesades i de raonament. La gran notícia: ara podeu llançar treballs d’ajustament de més de 13 regions Azure amb taxes d’entrenament per testimoni més baixes en comparació amb la formació estàndard. Mateixa infraestructura, mateixa qualitat, abast més ampli.

Si el vostre equip està repartit per geografies, això és important. Ja no estàs fixat a un grapat de regions per entrenar.

Aquí teniu la crida a l’API REST per iniciar una feina de formació global:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Aquesta bandera trainingType: globalstandard és la diferència clau.

Nou model de classificadors: família GPT-4.1

Els qualificadors defineixen el senyal de recompensa amb el qual optimitza el vostre model. Fins ara, els qualificadors basats en models es limitaven a un conjunt més petit de models. Ara teniu tres opcions noves: GPT-4.1, GPT-4.1-mini i GPT-4.1-nano.

Quan hauríeu d’aconseguir els qualificadors model en lloc dels deterministes? Quan la sortida de la vostra tasca és oberta, quan necessiteu una puntuació de crèdit parcial en diverses dimensions o quan esteu creant fluxos de treball agents on la correcció de la trucada d’eines depèn del context semàntic.

Aquesta és la qüestió: l’estratègia de classificació és pràctica:

GPT-4.1-nano per a les iteracions inicials. Bucles de retroalimentació ràpids i de baix cost.
GPT-4.1-mini un cop la rúbrica de qualificació sigui estable i necessiteu una fidelitat més alta.
GPT-4.1 per a la qualificació de la producció o rúbriques complexes on cada decisió de puntuació compta.

Fins i tot podeu barrejar tipus de classificador en un sol treball RFT. Utilitzeu string-match per a la dimensió “resposta correcta” i un model de qualificació per avaluar la qualitat del raonament. Aquesta flexibilitat és sincerament el que fa que sigui útil per a càrregues de treball reals.

El format de dades de RFT es troba

Això fa ensorrar la gent. El format de dades RFT és diferent de SFT. L’últim missatge de cada fila ha de ser una funció d’usuari o de desenvolupador, no d’assistent. La resposta esperada va en una clau de nivell superior com reference_answer que el qualificador fa referència directament.

Si heu estat fent un ajustament supervisat i voleu canviar a RFT, heu de reestructurar les vostres dades d’entrenament. No us salteu aquest pas o els vostres treballs fallaran en silenci.

Per què això és important per als desenvolupadors de.NET

Si truqueu a models ajustats des de les vostres aplicacions.NET mitjançant l’SDK d’Azure OpenAI, una formació més barata significa que podeu repetir de manera més agressiva. Les opcions de classificació del model us permeten ajustar amb precisió les tasques matisades, no només escenaris de concordança exacta. I la guia de bones pràctiques a GitHub us estalviarà temps real de depuració.

Comença petit. De deu a cent mostres. Avaluador simple. Valida el bucle. Després escala.

Les eines MCP d'Azure s'incorporen ara a Visual Studio 2022: no es requereix cap extensió

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

Si heu estat utilitzant les eines de l’Azure MCP a Visual Studio mitjançant l’extensió separada, ja coneixeu l’exercici: instal·leu el VSIX, reinicieu, espereu que no es trenqui, gestioneu els desajustos de versions. Aquesta fricció ha desaparegut.

Yun Jung Choi va anunciar que les eines d’Azure MCP ara s’envien directament com a part de la càrrega de treball de desenvolupament d’Azure a Visual Studio 2022. Sense extensió. No VSIX. No reinicia el ball.

Què significa realment això

A partir de la versió 17.14.30 de Visual Studio 2022, l’Azure MCP Server s’inclou amb la càrrega de treball de desenvolupament d’Azure. Si ja teniu aquesta càrrega de treball instal·lada, només cal que l’activeu a GitHub Copilot Chat i ja heu acabat.

Més de 230 eines en 45 serveis Azure, accessibles directament des de la finestra de xat. Enumereu els vostres comptes d’emmagatzematge, implementeu una aplicació ASP.NET Core, diagnostiqueu problemes del servei d’aplicacions, consulteu Log Analytics, tot sense obrir una pestanya del navegador.

Per què això importa més del que sembla

Això és el que passa amb les eines per a desenvolupadors: cada pas addicional és fricció i la fricció mata l’adopció. Tenir MCP com a extensió independent significava desajustos de versions, errors d’instal·lació i una cosa més a mantenir actualitzada. Incorporar-lo a la càrrega de treball significa:

Camí d’actualització únic mitjançant l’instal·lador de Visual Studio
Sense deriva de versió entre l’extensió i l’IDE
Sempre actual: el servidor MCP s’actualitza amb versions regulars de VS

Per als equips que s’estandarditzen a Azure, això és un gran problema. Instal·leu la càrrega de treball una vegada, activeu les eines i hi són per a cada sessió.

Què pots fer amb ell

Les eines cobreixen tot el cicle de vida del desenvolupament mitjançant Copilot Chat:

Aprendre: pregunteu sobre els serveis d’Azure, les pràctiques recomanades i els patrons d’arquitectura
Disseny i desenvolupament: obteniu recomanacions de servei, configureu el codi de l’aplicació
Desplega: proveïu recursos i implementeu-los directament des de l’IDE
Resolució de problemes: consulteu registres, comproveu l’estat dels recursos, diagnosticeu problemes de producció

Un exemple ràpid: escriviu això a Copilot Chat:

List my storage accounts in my current subscription.

Copilot truca a les eines d’Azure MCP darrere de les escenes, consulta les vostres subscripcions i retorna una llista amb format amb noms, ubicacions i SKU. No cal cap portal.

Com activar-lo

Actualització a Visual Studio 2022 17.14.30 o superior
Assegureu-vos que la càrrega de treball Desenvolupament d’Azure estigui instal·lada
Obriu GitHub Copilot Chat
Feu clic al botó Selecciona eines (la icona de dues claus)
Activa Servidor MCP d’Azure

Això és tot. Es manté activat durant les sessions.

Una advertència

Les eines estan desactivades de manera predeterminada: heu d’activar-les. I les eines específiques de VS 2026 no estan disponibles a VS 2022. La disponibilitat de les eines també depèn dels vostres permisos de subscripció a Azure, igual que el portal.

La imatge més gran

Això forma part d’una tendència clara: MCP s’està convertint en la forma estàndard d’aprofitar les eines de núvol en els IDE de desenvolupadors. Ja hem vist la versión estable d’Azure MCP Server 2.0 i les integracions MCP a VS Code i altres editors. Tenir-lo integrat al sistema de càrrega de treball de Visual Studio és la progressió natural.

Per als desenvolupadors de.NET que vivim a Visual Studio, això elimina un altre motiu per canviar de context al portal Azure. I sincerament, com menys canvis de pestanya, millor.

Aspire 13.2 obté MongoDB EF Core i Azure Data Lake: dues integracions que val la pena provar

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Aspire 13.2 acaba d’aterrar amb dues noves integracions de bases de dades que mereixen la vostra atenció: MongoDB Entity Framework Core i Azure Data Lake Storage. Si heu volgut utilitzar EF Core amb MongoDB en una aplicació Aspire o necessiteu connectar les càrregues de treball del llac de dades amb un descobriment de serveis adequat, aquesta versió ofereix tots dos.

MongoDB compleix EF Core a Aspire

Aquest és el que m’emociona més. Aspire ha donat suport a MongoDB durant un temps, però sempre va ser el controlador en brut: sense EF Core, sense DbContext, sense consultes LINQ als vostres documents. Ara teniu l’experiència completa d’EF Core amb MongoDB, a més de les comprovacions automàtiques de l’estat i el descobriment de serveis d’Aspire.

Configurar-lo és el patró típic d’Aspire. Al vostre AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

A continuació, al vostre projecte de consum, afegiu la integració d’EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

I registre el teu DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

A partir d’aquí, és EF Core estàndard. Defineix les teves entitats, utilitza el teu DbContext com ho faries amb qualsevol altre proveïdor. La integració gestiona l’agrupació de connexions, les traces d’OpenTelemetry i les comprovacions de salut darrere de les escenes.

Per als desenvolupadors de.NET que han estat utilitzant MongoDB amb el controlador en brut i cablejat manualment les cadenes de connexió, aquesta és una bona actualització de qualitat de vida. Obteniu l’abstracció completa d’EF Core sense perdre el descobriment del servei d’Aspire.

Azure Data Lake Storage s’uneix a la festa

La segona gran incorporació és una integració d’Azure Data Lake Storage (ADLS). Si esteu creant canalitzacions de dades, processos ETL o plataformes d’anàlisi, ara podeu connectar els recursos de Data Lake de la mateixa manera que connectaríeu qualsevol altra dependència d’Aspire.

A l’AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

En el projecte de consum:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Sense gestió manual de cadenes de connexió, sense recerca de credencials. Aspire proporciona recursos i els injecta. Per a aquells de nosaltres que creem aplicacions.NET natives del núvol que toquen tant dades operatives com càrregues de treball d’anàlisi, això fa que el llac de dades se senti com un ciutadà de primera classe en el model Aspire.

Les petites solucions que importen

Més enllà de les funcions dels titulars, hi ha algunes millores en la qualitat de vida que cal destacar:

Correcció de cadena de connexió MongoDB: la barra inclinada abans del nom de la base de dades ara es gestiona correctament. Si heu treballat amb això, podeu eliminar aquesta solució
Exporta SQL Server — Aspire.Hosting.SqlServer ara exporta opcions addicionals de configuració del servidor per a un control més detallat
Actualitzacions de l’emulador: l’emulador ServiceBus 2.0.0, l’emulador de configuració d’aplicacions 1.0.2 i l’emulador de vista prèvia de CosmosDB ara inclou una comprovació de la preparació
Azure Managed Redis: ara el valor predeterminat és rediss:// (Redis Secure), de manera que les connexions es xifren de manera immediata

Aquest últim és subtil però important: Redis xifrat per defecte significa una cosa menys per configurar en producció.

Tancant

Aspire 13.2 és una versió incremental, però les integracions MongoDB EF Core i Data Lake omplen buits reals. Si estàveu esperant el suport adequat d’EF Core amb MongoDB a Aspire, o necessiteu que Data Lake sigui una dependència de primera classe, actualitzeu a 13.2 i feu-los una volta. L’ordre aspire add inclou tot el que necessiteu.

Llegiu les notes completes de la versió per obtenir més detalls i consulteu la galeria d’integració per obtenir la llista completa.

azd update: una comanda per controlar tots els vostres gestors de paquets

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Sabeu que el missatge “Hi ha una versió nova d’azd disponible” que apareix cada poques setmanes? El que descarteu perquè no recordeu si vau instal·lar azd mitjançant winget, Homebrew o aquell script curl que vau executar fa sis mesos? Sí, finalment s’ha arreglat.

Microsoft acaba d’enviar azd update: una ordre única que actualitza l’Azure Developer CLI a la darrera versió, independentment de com l’haveu instal·lat originalment. Windows, macOS, Linux, no importa. Una ordre.

Com funciona

azd update

Això és tot. Si voleu un accés anticipat a noves funcions, podeu canviar a la creació diària d’insiders:

azd update --channel daily
azd update --channel stable

L’ordre detecta el vostre mètode d’instal·lació actual i utilitza el mecanisme d’actualització adequat sota el capó. No més “espera, he fet servir winget o choco en aquesta màquina?”

La petita captura

azd update s’envia a partir de la versió 1.23.x. Si teniu una versió anterior, haureu de fer una darrera actualització manual mitjançant el vostre mètode d’instal·lació original. Després d’això, azd update s’encarrega de tot el futur.

Comproveu la vostra versió actual amb azd version. Si necessiteu una instal·lació nova, els documents d’instal·lació us cobreixen.

Per què és important

Aquesta és una petita millora de la qualitat de vida, però per a aquells de nosaltres que utilitzem azd diàriament per desplegar agents d’IA i aplicacions Aspire a Azure, mantenir-se al dia significa menys moments “aquest error ja s’ha solucionat a la darrera versió”. Una cosa menys per pensar.

Llegiu l’anunci complet i la immersió més profunda de Jon Gallant per a més context.

Azure Smart Tier és GA: optimització automàtica de costos d'emmagatzematge de blob sense regles de cicle de vida

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Si alguna vegada heu passat temps ajustant les polítiques de cicle de vida d’Azure Blob Storage i després heu vist com es van trencar quan els patrons d’accés canviaven, aquesta és la vostra. Microsoft acaba d’anunciar la disponibilitat general del nivell intel·ligent per a Azure Blob i Data Lake Storage: una capacitat de nivells totalment gestionada que mou automàticament objectes entre nivells calents, freds i freds en funció de l’ús real.

Què fa realment el nivell intel·ligent

El concepte és senzill: el nivell intel·ligent avalua contínuament el darrer temps d’accés de cada objecte al vostre compte d’emmagatzematge. Les dades a les quals s’accedeix amb freqüència es mantenen en calent, les dades inactives es mouen per refredar-se després de 30 dies i després a fred després de 60 dies més. Quan s’accedeix de nou a les dades, es torna a activar immediatament. El cicle es reinicia.

No hi ha regles de cicle de vida per configurar. No hi ha prediccions de patrons d’accés. Sense sintonització manual.

Durant la previsualització, Microsoft va informar que més del 50% de la capacitat gestionada per nivells intel·ligents es va canviar automàticament a nivells més freds en funció dels patrons d’accés reals. Això suposa una reducció de costos significativa per als comptes d’emmagatzematge grans.

Per què això és important per als desenvolupadors de.NET

Si esteu creant aplicacions que generen registres, telemetria, dades analítiques o qualsevol tipus de fons de dades en creixement, i sincerament, qui no, els costos d’emmagatzematge s’acumulen ràpidament. L’enfocament tradicional era escriure polítiques de gestió del cicle de vida, provar-les i tornar-les a ajustar quan canviaven els patrons d’accés de la vostra aplicació. El nivell intel·ligent elimina tot aquest flux de treball.

Alguns escenaris pràctics on això ajuda:

Telemetria i registres d’aplicacions: calent durant la depuració, rarament s’hi accedeix després d’unes setmanes
Conductes de dades i sortides d’ETL: s’hi accedeix molt durant el processament, després principalment en fred
Contingut generat per l’usuari: les càrregues recents són interessants, el contingut més antic es refreda gradualment
Còpia de seguretat i dades d’arxiu: s’accedeix de tant en tant per complir-ho, principalment inactiu

Configurant-lo

Habilitar el nivell intel·ligent és una configuració única:

Comptes nous: seleccioneu el nivell intel·ligent com a nivell d’accés predeterminat durant la creació del compte d’emmagatzematge (es requereix redundància zonal)
Comptes existents: canvieu el nivell d’accés a blob del nivell predeterminat actual al nivell intel·ligent

Els objectes de menys de 128 KiB es mantenen en calent i no incorren en la taxa de supervisió. Per a la resta, pagueu tarifes estàndard de capacitat calenta/fresca/fred sense càrrecs de transició de nivell, sense despeses d’eliminació anticipada i sense costos de recuperació de dades. Una quota de seguiment mensual per objecte cobreix l’orquestració.

La compensació a conèixer

Les regles de classificació del nivell intel·ligent són estàtiques (30 dies → fred, 90 dies → fred). Si necessiteu llindars personalitzats (per exemple, passar a la refrigeració després de 7 dies per a una càrrega de treball específica), les regles del cicle de vida encara són el camí a seguir. I no barregeu les dues coses: eviteu utilitzar regles de cicle de vida en objectes gestionats per nivell intel·ligent, ja que poden entrar en conflicte.

Tancant

Això no és revolucionari, però soluciona un autèntic mal de cap operatiu. Si gestioneu comptes d’emmagatzematge de blobs en creixement i esteu cansat de mantenir polítiques de cicle de vida, habilita el nivell intel·ligent i deixeu que Azure s’encarregui. Actualment està disponible a gairebé totes les regions de núvol públic de zona.

On hauríeu d'allotjar els vostres agents d'IA a Azure? Una guia pràctica de decisions

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Si esteu creant agents d’IA amb.NET ara mateix, probablement heu notat alguna cosa: hi ha * moltes * maneres d’allotjar-los a Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents, i tots semblen raonables fins que realment n’has de triar un. Microsoft acaba de publicar una guia completa per a l’allotjament d’agents d’Azure AI que ho aclareix, i vull desglossar-ho des d’una perspectiva pràctica del desenvolupador.NET.

Les sis opcions d’un cop d’ull

Així és com resumiria el paisatge:

Opció	El millor per	Tu gestiones
Aplicacions de contenidors	Control total del contenidor sense complexitat K8s	Observabilitat, estat, cicle de vida
AKS	Compliment empresarial, multi-clúster, xarxes personalitzades	Tot (aquest és el punt)
Funcions d’Azure	Tasques d’agent de curta durada i impulsades per esdeveniments	No gaire, veritat sense servidor
Servei d’aplicacions	Agents HTTP simples, trànsit previsible	Desplegament, configuració d’escalat
Agents de Foundry	Agents opcionals de codi a través del portal/SDK	Gairebé res
Agents allotjats de Foundry	Agents de marc personalitzats amb infraestructures gestionades	Només el vostre codi d’agent

Els quatre primers són càlculs de propòsit general: podeu executar-hi agents, però no estaven dissenyats per a això. Els dos últims són nadius dels agents: entenen les converses, les trucades d’eines i els cicles de vida dels agents com a conceptes de primera classe.

Foundry Hosted Agents: el lloc ideal per als desenvolupadors d’agents.NET

Aquí és el que em va cridar l’atenció. Els agents allotjats de Foundry se situen al centre: teniu la flexibilitat d’executar el vostre propi codi (nucli semàntic, marc d’agents, LangGraph, el que sigui), però la plataforma gestiona la infraestructura, l’observabilitat i la gestió de converses.

La peça clau és l’Adaptador d’allotjament: una capa d’abstracció fina que connecta el vostre marc d’agent amb la plataforma Foundry. Per a Microsoft Agent Framework, té aquest aspecte:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Aquesta és tota la vostra història d’allotjament. L’adaptador gestiona la traducció del protocol, la transmissió mitjançant esdeveniments enviats pel servidor, l’historial de converses i el seguiment d’OpenTelemetry, tot automàticament. Sense programari intermedi personalitzat, sense fontaneria manual.

El desplegament és realment senzill

Abans he desplegat agents a Container Apps i funciona, però acabeu escrivint molt codi de cola per a la gestió de l’estat i l’observabilitat. Amb Hosted Agents i azd, el desplegament és:

# Install the AI agent extension
azd ext install azure.ai.agents

# Init from a template
azd ai agent init

# Build, push, deploy — done
azd up

Aquest únic azd up crea el vostre contenidor, l’envia a ACR, subministra el projecte Foundry, desplega els punts finals del model i inicia el vostre agent. Cinc passos es van col·lapsar en una ordre.

Gestió de converses integrada

Aquesta és la peça que estalvia més temps en la producció. En lloc de crear el vostre propi magatzem d’estat de conversa, els agents allotjats ho gestionen de manera nativa:

# Create a persistent conversation
conversation = openai_client.conversations.create()

# First turn
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Second turn — context is preserved
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

No Redis. No hi ha botiga de sessions de Cosmos DB. No hi ha programari intermediari personalitzat per a la serialització de missatges. La plataforma només ho gestiona.

El meu marc de decisió

Després de revisar les sis opcions, aquí teniu el meu model mental ràpid:

Necessites zero infraestructura? → Agents de Foundry (portal/SDK, sense contenidors)
Tens un codi d’agent personalitzat però vols un allotjament gestionat? → Agents allotjats de Foundry
Necessiteu tasques d’agent de curta durada i basades en esdeveniments? → Azure Functions
Necessites el màxim control dels contenidors sense K8? → Aplicacions de contenidors
Necessites un compliment estricte i múltiples clústers? → AKS
Teniu un agent HTTP senzill amb trànsit previsible? → Servei d’aplicacions

Per a la majoria de desenvolupadors de.NET que creen amb Semantic Kernel o Microsoft Agent Framework, Hosted Agents és probablement el punt de partida adequat. Obteniu una escala a zero, OpenTelemetry integrada, gestió de converses i flexibilitat de marc, sense gestionar Kubernetes ni connectar la vostra pròpia pila d’observabilitat.

Tancant

El paisatge d’allotjament d’agents a Azure està madurant ràpidament. Si inicieu un nou projecte d’agent d’IA avui, m’agradaria considerar seriosament els agents allotjats de Foundry abans d’arribar a Container Apps o AKS per costum. La infraestructura gestionada estalvia temps real i el patró de l’adaptador d’allotjament us permet mantenir la vostra elecció de marc.

Consulteu la guia completa de Microsoft i el repositori de mostres de Foundry per obtenir exemples de treball.

Les habilitats d'agent a.NET s'acaben de ser molt flexibles

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Si heu estat creant agents amb Microsoft Agent Framework, coneixeu l’exercici: definiu les habilitats, les connecteu a un proveïdor i deixeu que l’agent esbringui quina invocar. El que és nou és com autors d’aquestes habilitats, i el salt de flexibilitat és important.

L’última actualització introdueix tres patrons de creació personalitzats per a les habilitats d’agent: basat en fitxers, basat en classes i definit en codi en línia. Els tres es connecten a un únic AgentSkillsProviderBuilder, el que significa que podeu barrejar i combinar sense cap lògica d’encaminament ni codi de cola especial. Permeteu-me que us acompanyi a través de cadascuna i quan ho aconseguiu.

Habilitats basades en fitxers: el punt de partida

Les habilitats basades en fitxers són exactament el que sonen: un directori al disc amb un fitxer SKILL.md, scripts opcionals i documents de referència. Penseu en això com la manera més senzilla de donar noves capacitats al vostre agent:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

El frontmatter SKILL.md declara el nom i la descripció de l’habilitat, i la secció d’instruccions indica a l’agent com utilitzar els scripts i les referències:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

A continuació, connecteu-lo amb SubprocessScriptRunner.RunAsync per a l’execució de l’script:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

L’agent descobreix l’habilitat automàticament i invoca l’script de subministrament quan necessita comprovar l’estat del compte. Net i senzill.

Habilitats basades en classe: enviament mitjançant NuGet

Aquí és on es posa interessant per als equips. Les habilitats basades en classe es deriven de AgentClassSkill<T> i utilitzen atributs com [AgentSkillResource] i [AgentSkillScript] perquè el marc ho descobreixi tot mitjançant la reflexió:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

La bellesa aquí és que un equip pot empaquetar-ho com a paquet NuGet. L’afegiu al vostre projecte, el deixeu anar al constructor i funciona juntament amb les vostres habilitats basades en fitxers amb una coordinació zero:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Les dues habilitats es mostren a l’indicador del sistema de l’agent. L’agent decideix quin utilitzar en funció de la conversa, no cal cap codi d’encaminament.

Habilitats en línia: el pont ràpid

Coneixeu aquell moment en què un altre equip està construint exactament l’habilitat que necessiteu, però no s’enviarà per a un sprint? AgentInlineSkill és el teu pont:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Afegiu-lo al constructor igual que els altres:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Quan finalment s’envia el paquet NuGet, canvieu l’habilitat en línia per la basada en classe. L’agent no sap la diferència.

Però les habilitats en línia no són només per als ponts. També són l’opció correcta quan necessiteu generar habilitats de manera dinàmica en temps d’execució (penseu en una habilitat per unitat de negoci carregada des de la configuració) o quan un script s’ha de tancar a l’estat local que no pertany a un contenidor DI.

Aprovació de l’script: human-in-the-loop

Per als desenvolupadors de.NET que creem agents de producció, aquesta és la part que realment desbloqueja les converses de desplegament. Alguns scripts tenen conseqüències reals: inscriure algú als beneficis, consultar la producció infra. Gireu UseScriptApproval i l’agent s’aturarà abans d’executar qualsevol script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Quan l’agent vol executar un script, torna una sol·licitud d’aprovació. La vostra aplicació recull la decisió (aprovar o rebutjar) i l’agent continua en conseqüència. En entorns regulats, aquesta és la diferència entre “podem desplegar això” i “legal diu que no”.

Per què és important aquesta combinació

El poder real no és cap patró d’autor, sinó la composició. Pots:

Comença petit amb una habilitat basada en fitxers, itera les instruccions i envia’l sense escriure C#
Envia habilitats reutilitzables com a paquets NuGet que altres equips poden afegir amb una línia
Rebre els buits amb habilitats en línia quan necessiteu alguna cosa ara
Filtreu els directoris d’habilitats compartits amb predicats perquè el vostre agent només carregui el que hauria de fer
Afegiu supervisió humana per als scripts que toquen els sistemes de producció

Tots ells es componen mitjançant AgentSkillsProviderBuilder. Sense encaminament especial, sense lògica condicional, sense comprovacions de tipus d’habilitat.

Tancant

Les habilitats d’agent a.NET ara tenen un model d’autoria realment flexible. Tant si sou un desenvolupador en solitari que dibuixa un prototip amb habilitats basades en fitxers com si un equip empresarial envia capacitats empaquetades mitjançant NuGet, els patrons s’ajusten. I el mecanisme d’aprovació de l’script fa que estigui llest per a la producció per a entorns on necessiteu aquest punt de control humà.

Consulteu l’anunci original per a la guia completa, la documentació d’habilitats de l’agent a Microsoft Learn i les mostres.NET a GitHub per fer-ho pràctica.

L'Azure MCP Server 2.0 s'acaba de caure: l'automatització del núvol agent autoallotjada és aquí

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

Si darrerament heu estat creant alguna cosa amb MCP i Azure, probablement ja sabeu que l’experiència local funciona bé. Connecteu un servidor MCP, deixeu que el vostre agent d’IA parli amb els recursos d’Azure, seguiu endavant. Però, en el moment que necessiteu compartir aquesta configuració amb un equip? Allà va ser on les coses es van complicar.

Ja no. Servidor MCP d’Azure acaba d’aconseguir 2.0 estable, i la funció de titular és exactament el que els equips empresarials han demanat: suport del servidor MCP remot autoallotjat.

Què és Azure MCP Server?

Actualització ràpida. Azure MCP Server implementa l’especificació Model Context Protocol i exposa les capacitats d’Azure com a eines estructurades i detectables que els agents d’IA poden invocar. Penseu en això com un pont estandarditzat entre el vostre agent i Azure: subministrament, desplegament, supervisió, diagnòstic, tot mitjançant una interfície coherent.

Les xifres parlen per si soles: 276 eines MCP en 57 serveis Azure. Això és una cobertura seriosa.

El gran problema: desplegaments remots autoallotjats

Aquí està la cosa. Executar MCP localment a la vostra màquina està bé per a desenvolupament i experiments. Però en un escenari d’equip real, necessiteu:

Accés compartit per a desenvolupadors i sistemes d’agents interns
Configuració centralitzada (context de l’arrendatari, valors predeterminats de subscripció, telemetria)
Xarxa empresarial i límits polítics
Integració en pipelines CI/CD

Azure MCP Server 2.0 aborda tot això. Podeu implementar-lo com a servei intern gestionat de manera centralitzada amb transport basat en HTTP, autenticació adequada i govern coherent.

Per a l’autenticació, obteniu dues opcions sòlides:

Identitat gestionada: quan s’executa al costat de Microsoft Foundry
Flux en nom de (OBO): delegació d’OpenID Connect que crida a les API d’Azure mitjançant el context de l’usuari iniciat

Aquest flux OBO és especialment interessant per als desenvolupadors de.NET. Vol dir que els vostres fluxos de treball d’agent poden funcionar amb els permisos reals de l’usuari, no amb un compte de servei amb privilegis excessius. Principi del mínim privilegi, integrat.

Enduriment de la seguretat

Això no és només una versió de funcions, també és una de seguretat. La versió 2.0 afegeix:

Validació de punt final més forta
Proteccions contra patrons d’injecció en eines orientades a la consulta
Controls d’aïllament més estrictes per a entorns de desenvolupament

Si voleu exposar MCP com a servei compartit, aquestes garanties són importants. Molts.

On el pots utilitzar?

La història de la compatibilitat del client és àmplia. Azure MCP Server 2.0 funciona amb:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agents CLI: GitHub Copilot CLI, Claude Code
Autònom: servidor local per a configuracions senzilles
Control remot autoallotjat: la nova estrella de la 2.0

A més, hi ha suport sobirà al núvol per al govern d’Azure dels Estats Units i Azure operat per 21Vianet, que és fonamental per als desplegaments regulats.

Per què això és important per als desenvolupadors de.NET

Si esteu creant aplicacions agents amb.NET, ja sigui el nucli semàntic, el Microsoft Agent Framework o la vostra pròpia orquestració, Azure MCP Server 2.0 us ofereix una manera preparada per a la producció de permetre que els vostres agents interactuïn amb la infraestructura Azure. No hi ha embolcalls REST personalitzats. No hi ha patrons d’integració específics del servei. Només MCP.

Combinat amb l’API fluida per a aplicacions MCP que va caure fa uns dies, l’ecosistema.NET MCP està madurant ràpidament.

Primers passos

Tria el teu camí:

GitHub Repo — codi font, documents, tot
Imatge Docker — desplegament en contenidors
Extensió de codi VS — Integració IDE
Guia d’allotjament personal: la funció insígnia 2.0

Tancant

Azure MCP Server 2.0 és exactament el tipus d’actualització d’infraestructura que no sembla cridaner en una demostració, però que ho canvia tot a la pràctica. MCP remot autoallotjat amb autenticació adequada, reforç de la seguretat i suport sobirà del núvol significa que MCP està preparat per a equips reals que creen fluxos de treball reals a l’Azure. Si heu estat esperant el senyal “preparat per a l’empresa”, això és tot.

Connecteu els vostres servidors MCP a les funcions d'Azure amb els agents de Foundry: aquí teniu com

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Aquí hi ha una cosa que m’encanta de l’ecosistema MCP: creeu el vostre servidor una vegada i funciona a tot arreu. VS Code, Visual Studio, Cursor, ChatGPT: cada client MCP pot descobrir i utilitzar les vostres eines. Ara, Microsoft afegeix un altre consumidor a aquesta llista: agents de Foundry.

Lily Ma de l’equip d’Azure SDK va publicar una guia pràctica sobre la connexió de servidors MCP desplegats a Azure Functions amb agents de Microsoft Foundry. Si ja teniu un servidor MCP, això és pur valor afegit, no cal reconstruir-lo.

Per què aquesta combinació té sentit

Azure Functions us ofereix una infraestructura escalable, una autenticació integrada i una facturació sense servidor per allotjar servidors MCP. Microsoft Foundry us ofereix agents d’IA que poden raonar, planificar i prendre accions. Connectar les dues significa que les vostres eines personalitzades (consultar una base de dades, trucar a una API empresarial, executar una lògica de validació) esdevenen capacitats que els agents d’IA empresarials poden descobrir i utilitzar de manera autònoma.

El punt clau: el vostre servidor MCP es manté igual. Només esteu afegint Foundry com un altre consumidor. Les mateixes eines que funcionen a la configuració de VS Code ara alimenten un agent d’IA amb el qual interactuen el vostre equip o clients.

Opcions d’autenticació

Aquí és on la publicació realment afegeix valor. Quatre mètodes d’autenticació segons el vostre escenari:

Mètode	Cas d’ús
Basat en clau (per defecte)	Desenvolupament o servidors sense autenticació Entra
Entrada de Microsoft	Producció amb identitats gestionades
Transmissió d’identitat OAuth	Producció on cada usuari s’autentica individualment
No autenticat	Desenvolupament/proves o dades públiques només

Per a la producció, el camí recomanat és Microsoft Entra amb la identitat de l’agent. El pas d’identitat d’OAuth és per quan el context de l’usuari importa: l’agent demana als usuaris que iniciïn sessió i cada sol·licitud porta el testimoni propi de l’usuari.

Configurant-lo

El flux d’alt nivell:

Implementeu el vostre servidor MCP a Azure Functions: mostres disponibles per a .NET, Python, TypeScript i Java
Activa l’autenticació MCP integrada a l’aplicació de funcions
Obteniu l’URL del vostre punt final — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Afegiu el servidor MCP com a eina a Foundry: aneu al vostre agent al portal, afegiu una eina MCP nova, proporcioneu el punt final i les credencials.

A continuació, proveu-ho al parc infantil de l’Agent Builder enviant un missatge que activaria una de les vostres eines.

La meva opinió

La història de la composició aquí s’està fent molt forta. Creeu el vostre servidor MCP una vegada a.NET (o Python, TypeScript, Java), implementeu-lo a Azure Functions i tots els clients compatibles amb MCP el podran utilitzar: eines de codificació, aplicacions de xat i ara agents d’IA empresarials. Aquest és un patró “Escriu una vegada, utilitza a tot arreu” que realment funciona.

Per als desenvolupadors de.NET específicament, l’extensió MCP d’Azure Functions ho fa senzill. Definiu les vostres eines com a Azure Functions, les implementeu i disposeu d’un servidor MCP de nivell de producció amb tota la seguretat i escala que ofereix Azure Functions.

Tancant

Si teniu eines MCP que s’executen a Azure Functions, connectar-les als agents de Foundry és una victòria ràpida: les vostres eines personalitzades es converteixen en capacitats d’IA empresarial amb una autenticació adequada i sense canvis de codi al propi servidor.

Llegiu la guia completa per obtenir instruccions pas a pas sobre cada mètode d’autenticació i consulteu la documentació detallada per a les configuracions de producció.

Creació d'interfícies d'usuari multiagent en temps real que no semblin com una caixa negra

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Això és el que passa amb els sistemes multiagent: tenen un aspecte increïble a les demostracions. Tres agents que passen treballant, resolent problemes, prenent decisions. Aleshores intentes posar-ho davant dels usuaris reals i… silenci. Un indicador de gir. No hi ha idea de quin agent està fent què o per què el sistema està en pausa. Això no és un producte, és un problema de confiança.

L’equip de Microsoft Agent Framework acaba de publicar una revisió fantàstica sobre la combinació de fluxos de treball MAF amb AG-UI, un protocol obert per a esdeveniments d’execució d’agents de transmissió a una interfície sobre esdeveniments enviats pel servidor. I sincerament? Aquest és el tipus de pont que hem trobat a faltar.

Per què això és important per als desenvolupadors de.NET

Si esteu creant aplicacions basades en intel·ligència artificial, probablement heu tocat aquest mur. La vostra orquestració de fons funciona molt bé: els agents s’entreguen, les eines es disparen i es prenen decisions. Però la interfície no té ni idea del que passa darrere de les escenes. AG-UI ho soluciona mitjançant la definició d’un protocol estàndard per als esdeveniments de l’agent de transmissió (penseu a RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) directament a la vostra capa d’IU a través de SSE.

La demostració que van crear és un flux de treball d’atenció al client amb tres agents: un agent de triatge que encamina les sol·licituds, un agent de reemborsament que gestiona els diners i un agent de comandes que gestiona les substitucions. Cada agent té les seves pròpies eines i la topologia de traspàs es defineix explícitament: no hi ha vibracions de “esbrinar-ho a partir del missatge”.

La topologia de traspàs és la veritable estrella

El que em va cridar l’atenció és com HandoffBuilder us permet declarar un gràfic d’encaminament dirigit entre agents:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Cada add_handoff crea una vora dirigida amb una descripció en llenguatge natural. El marc genera eines de transferència per a cada agent basant-se en aquesta topologia. Per tant, les decisions d’encaminament es basen en la vostra estructura d’orquestració, no només en el que el LLM vulgui fer. Això és un gran negoci per a la fiabilitat de la producció.

Human-in-the-loop que realment funciona

La demostració mostra dos patrons d’interrupció que necessita qualsevol aplicació d’agent del món real:

L’aprovació de l’eina s’interromp: quan un agent truca a una eina marcada amb approval_mode="always_require", el flux de treball s’atura i emet un esdeveniment. La interfície representa un modal d’aprovació amb el nom de l’eina i els arguments. No hi ha bucles de reintent de gravació de testimonis, només un flux net de pausa, aprovació i reinici.

La sol·licitud d’informació s’interromp: quan un agent necessita més context de l’usuari (com ara un identificador de comanda), s’atura i pregunta. La interfície mostra la pregunta, l’usuari respon i l’execució es reprèn exactament des d’on es va aturar.

Tots dos patrons es transmeten com a esdeveniments AG-UI estàndard, de manera que la vostra interfície no necessita lògica personalitzada per agent; només representa qualsevol esdeveniment que passi a través de la connexió SSE.

El cablejat és sorprenentment senzill

La integració entre MAF i AG-UI és una única trucada de funció:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

El workflow_factory crea un flux de treball nou per fil, de manera que cada conversa té un estat aïllat. El punt final gestiona tota la fontaneria SSE automàticament. Si ja esteu utilitzant FastAPI (o podeu afegir-lo com a capa lleugera), això és gairebé zero fricció.

La meva opinió

Per als desenvolupadors de.NET, la pregunta immediata és: “Puc fer això en C#?” L’Agent Framework està disponible tant per a.NET com per a Python, i el protocol AG-UI és independent de l’idioma (només és SSE). Així, mentre que aquesta demostració específica utilitza Python i FastAPI, el patró es tradueix directament. Podeu connectar una API mínima ASP.NET Core amb punts finals SSE seguint el mateix esquema d’esdeveniments AG-UI.

El més important és que les interfícies d’usuari multiagent s’estan convertint en una preocupació de primera classe, no en una idea posterior. Si esteu creant qualsevol cosa on els agents interactuen amb humans (atenció al client, fluxos de treball d’aprovació, processament de documents), aquesta combinació d’orquestració MAF i transparència AG-UI és el patró a seguir.

Tancant

AG-UI + Microsoft Agent Framework us ofereix el millor dels dos mons: una robusta orquestració multiagent al backend i visibilitat en temps real al frontend. No més interaccions d’agent de caixa negra.

Fes una ullada a la revisió completa i al repositori del protocol AG-UI per aprofundir.

L'avaluació de la modernització de GitHub Copilot és la millor eina de migració que encara no feu servir

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Migrar una aplicació.NET Framework heretada a.NET moderna és una d’aquestes tasques que tothom sap que hauria de fer, però ningú vol començar. Mai és només “canviar el marc objectiu”. Són les API que van desaparèixer, paquets que ja no existeixen, models d’allotjament que funcionen d’una manera completament diferent i un milió de petites decisions sobre què contener, què reescriure i què deixar en pau.

Jeffrey Fritz acaba de publicar una immersió profunda en l’avaluació de la modernització de GitHub Copilot, i sincerament? Aquesta és la millor eina de migració que he vist per a.NET. No a causa de la generació de codi, això és ara l’aposta de la taula. Pel document d’avaluació que elabora.

No és només un motor de suggeriments de codi

L’extensió VS Code segueix un model Avaluar → Planificar → Executar. La fase d’avaluació analitza tota la vostra base de codi i produeix un document estructurat que ho recull tot: què cal canviar, quins recursos d’Azure proveir, quin model de desplegament utilitzar. Tot el que hi ha a baix (infraestructura com a codi, contenidors, manifestos de desplegament) depèn del que troba l’avaluació.

L’avaluació s’emmagatzema a .github/modernize/assessment/ del vostre projecte. Cada execució produeix un informe independent, de manera que creeu un historial i podeu fer un seguiment de com evoluciona la vostra postura de migració a mesura que solucioneu els problemes.

Dues maneres de començar

Avaluació recomanada: el camí ràpid. Trieu entre dominis seleccionats (actualització de Java/.NET, preparació al núvol, seguretat) i obteniu resultats significatius sense tocar la configuració. Ideal per a una primera mirada a on es troba la teva aplicació.

Avaluació personalitzada: el camí objectiu. Configureu exactament què voleu analitzar: càlcul objectiu (App Service, AKS, Container Apps), sistema operatiu objectiu, anàlisi de contenidors. Trieu diversos objectius d’Azure per comparar els enfocaments de migració de manera conjunta.

Aquesta visió de comparació és realment útil. Una aplicació amb 3 problemes obligatoris per a App Service pot tenir 7 per a AKS. Veure tots dos ajuda a impulsar la decisió d’allotjament abans de comprometre’s amb una ruta de migració.

El desglossament del problema és accionable

Cada problema ve amb un nivell de criticitat:

Obligatori: s’ha de solucionar o la migració falla
Potencial: pot afectar la migració, necessita el judici humà
Opcional: millores recomanades, no bloquejaran la migració

I cada problema enllaça amb fitxers i números de línia afectats, proporciona una descripció detallada del que està malament i per què és important per a la vostra plataforma objectiu, ofereix passos concrets de correcció (no només “arreglar-ho”) i inclou enllaços a documentació oficial.

Podeu lliurar problemes individuals als desenvolupadors i aquests tenen tot el que necessiten per actuar. Aquesta és la diferència entre una eina que us diu “hi ha un problema” i una que us indica com resoldre’l.

Els camins d’actualització coberts

Específicament per a.NET: -.NET Framework →.NET 10

ASP.NET → ASP.NET Core

Cada camí d’actualització té regles de detecció que coneixen quines API s’han eliminat, quins patrons no tenen cap equivalent directe i quins problemes de seguretat necessiten atenció.

Per als equips que gestionen diverses aplicacions, també hi ha una CLI que admet avaluacions per lots multirepositori: cloneu tots els repositoris, avalueu-los tots, obteniu informes per aplicació i una visualització de cartera agregada.

La meva opinió

Si esteu asseguts en aplicacions heretades de.NET Framework (i siguem reals, la majoria dels equips empresarials ho són), aquesta és l’eina per començar. Només el document d’avaluació val la pena el temps: converteix un vague “hauríem de modernitzar” en una llista concreta i prioritzada d’elements de treball amb camins clars.

El flux de treball col·laboratiu també és intel·ligent: exporteu avaluacions, compartiu amb el vostre equip, importeu-les sense tornar-les a executar. Revisions d’arquitectura on els que prenen les decisions no són els que executen les eines? Coberta.

Tancant

L’avaluació de la modernització de GitHub Copilot transforma la migració.NET d’un projecte aterridor i indefinit a un procés estructurat i rastrejable. Comenceu amb una avaluació recomanada per veure on us trobeu i, a continuació, utilitzeu avaluacions personalitzades per comparar els objectius d’Azure i crear el vostre pla de migració.

Llegiu el tutorial complet i agafeu l’extensió del codi VS per provar-ho a la vostra pròpia base de codi.

L'enginyeria de la plataforma agentica s'està tornant real: Git-APE mostra com

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

L’enginyeria de plataformes ha estat un d’aquells termes que sona molt bé a les conferències, però normalment significa “vam construir un portal intern i un embolcall de Terraform”. La veritable promesa: una infraestructura d’autoservei que és realment segura, governada i ràpida, sempre ha estat a pocs passos.

L’equip d’Azure acaba de publicar la Part 2 de la seva sèrie d’enginyeria de plataformes agents, i aquesta tracta sobre la implementació pràctica. L’anomenen Git-APE (sí, l’acrònim és intencionat) i és un projecte de codi obert que utilitza agents GitHub Copilot més servidors Azure MCP per convertir les sol·licituds de llenguatge natural en una infraestructura validada i desplegada.

Què fa realment Git-APE

La idea bàsica: en lloc que els desenvolupadors aprenguin mòduls de Terraform, naveguin per les interfícies d’usuari del portal o presenten entrades a un equip de plataforma, parlen amb un agent Copilot. L’agent interpreta la intenció, genera Infrastructure-as-Code, la valida amb polítiques i desplega, tot dins de VS Code.

Aquí teniu la configuració:

git clone https://github.com/Azure/git-ape
cd git-ape

Obriu l’espai de treball a VS Code i GitHub Copilot descobreix automàticament els fitxers de configuració de l’agent. Interacciones directament amb l’agent:

@git-ape deploy a function app with storage in West Europe

L’agent utilitza Azure MCP Server sota el capó per interactuar amb els serveis d’Azure. La configuració de MCP a la configuració del codi VS permet capacitats específiques:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Per què això és important

Per a aquells que estem construint a Azure, això canvia la conversa sobre l’enginyeria de la plataforma de “com construïm un portal” a “com descriurem les nostres baranes com a API”. Quan la interfície de la vostra plataforma és un agent d’IA, la qualitat de les vostres limitacions i polítiques es converteix en el producte.

El bloc de la Part 1 va exposar la teoria: les API ben descrites, els esquemes de control i les baranes explícites fan que les plataformes estiguin preparades per a agents. La part 2 demostra que funciona enviant eines reals. L’agent no només genera recursos a cegues, sinó que valida les millors pràctiques, respecta les convencions de denominació i aplica les polítiques de la vostra organització.

La neteja és igual de fàcil:

@git-ape destroy my-resource-group

La meva opinió

Seré sincer: aquest tracta més del patró que de l’eina específica. El mateix Git-APE és una arquitectura de demostració/referència. Però la idea subjacent (agents com a interfície de la vostra plataforma, MCP com a protocol, GitHub Copilot com a amfitrió) és cap a on es dirigeix l’experiència dels desenvolupadors empresarials.

Si sou un equip de plataformes que mira com fer que els vostres agents d’eines internes siguin amigables, no hi ha millor punt de partida. I si sou un desenvolupador de.NET i us pregunteu com es connecta això amb el vostre món: els agents Azure MCP Server i GitHub Copilot funcionen amb qualsevol càrrega de treball d’Azure. La vostra API ASP.NET Core, la vostra pila.NET Aspire, els vostres microserveis en contenidors: tot això pot ser l’objectiu d’un flux de desplegament agent.

Tancant

Git-APE és una visió primerenca però concreta de l’enginyeria de plataformes agències a la pràctica. Cloneu el repo, proveu la demostració i comenceu a pensar com haurien de buscar un agent per utilitzar-los de manera segura les API i les polítiques de la vostra plataforma.

Llegiu la publicació completa per a la guia i les demostracions de vídeo.

Microsoft Foundry Març de 2026: GPT-5.4, Agent Service GA i l'SDK Refresh que ho canvia tot

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Les publicacions mensuals “Què hi ha de nou a Microsoft Foundry” solen ser una barreja de millores incrementals i la funció de titular ocasional. La edició de març de 2026? Es tracta bàsicament de totes les funcions dels titulars. El servei d’agent de Foundry passa a GA, el GPT-5.4 s’envia per a la producció, l’SDK obté una versió estable important i Fireworks AI aporta la inferència de model obert a Azure. Permeteu-me desglossar el que importa per als desenvolupadors de.NET.

El servei d’agent de Foundry està llest per a la producció

Aquest és el gran. El temps d’execució de l’agent de nova generació està disponible generalment: construït a partir de l’API OpenAI Responses, compatible amb cables amb els agents OpenAI i obert a models de diversos proveïdors. Si esteu creant amb l’API Responses avui, la migració a Foundry afegeix seguretat empresarial, xarxes privades, Entra RBAC, seguiment complet i avaluació a més de la vostra lògica d’agent existent.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Addicions clau: xarxes privades d’extrem a extrem, expansió d’autenticació MCP (inclòs OAuth passthrough), previsualització de Voice Live per a agents de veu a veu i agents allotjats en 6 regions noves.

GPT-5.4: fiabilitat sobre la intel·ligència bruta

GPT-5.4 no es tracta de ser més intel·ligent. Es tracta de ser més fiable. Raonament més sòlid sobre interaccions llargues, millor adherència a les instruccions, menys errors en el flux de treball mitjà i capacitats integrades d’ús de l’ordinador. Per als agents de producció, aquesta fiabilitat és molt més important que les puntuacions de referència.

Model	Preu (per M fitxes)	Millor per
GPT-5.4 (≤272K)	2,50 $ / 15 $ de sortida	Agents de producció, codificació, fluxos de treball de documents
GPT-5.4 Pro	30 $ / 180 $ de sortida	Anàlisi profunda, raonament científic
GPT-5.4 Mini	Rentable	Classificació, extracció, trucades d’eines lleugeres

El joc intel·ligent és una estratègia d’encaminament: GPT-5.4 Mini gestiona el treball de gran volum i de baixa latència, mentre que GPT-5.4 accepta les sol·licituds de gran raonament.

L’SDK és finalment estable

azure-ai-projects SDK va enviar versions estables a tots els idiomes: Python 2.0.0, JS/TS 2.0.0, Java 2.0.0 i.NET 2.0.0 (1 d’abril). La dependència azure-ai-agents ha desaparegut: tot viu sota AIProjectClient. Instal·leu amb pip install azure-ai-projects i els paquets de paquets openai i azure-identity com a dependències directes.

Per als desenvolupadors de.NET, això significa un únic paquet NuGet per a tota la superfície de Foundry. No més fer malabars amb els SDK d’agents separats.

Fireworks AI porta models oberts a Azure

Potser l’addició més interessant des del punt de vista arquitectònic: Fireworks AI processa més de 13 bilions de fitxes diaris a ~180.000 sol·licituds per segon, ara disponible a través de Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5 i MiniMax M2.5 al llançament.

La història real és porta els teus propis pesos: penja pesos quantificats o ajustats des de qualsevol lloc sense canviar la pila de porcions. Desplegueu mitjançant pagament per testimoni sense servidor o rendiment subministrat.

Altres aspectes destacats

Phi-4 Reasoning Vision 15B: raonament multimodal per a gràfics, diagrames i dissenys de documents
Avaluacions GA: avaluadors predefinits amb un seguiment continu de la producció canalitzat a Azure Monitor
Processament prioritari (visualització prèvia): carril informàtic dedicat per a càrregues de treball sensibles a la latència
Voice Live: temps d’execució de veu a veu que es connecta directament als agents de Foundry
Tracing GA: inspecció de traça d’agents d’extrem a extrem amb classificació i filtre
PromptFlow obsolet: migració a Microsoft Framework Workflows abans de gener de 2027

Tancant

El març de 2026 és un punt d’inflexió per a Foundry. Agent Service GA, SDK estables en tots els idiomes, GPT-5.4 per a agents de producció fiables i inferència de model obert mitjançant Fireworks AI: la plataforma està preparada per a càrregues de treball serioses.

Llegiu el resum complet i creeu el vostre primer agent per començar.

Servidor SQL MCP: la manera correcta de donar accés a la base de dades d'AI Agents

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Siguem sincers: la majoria dels servidors MCP de bases de dades disponibles avui dia són aterridors. Prenen una consulta en llenguatge natural, generen SQL sobre la marxa i l’executen amb les dades de producció. Què podria sortir malament? (Tot. Tot podria sortir malament.)

L’equip d’Azure SQL acaba de introduir SQL MCP Server, i té un enfocament fonamentalment diferent. Creat com a característica del Data API Builder (DAB) 2.0, ofereix als agents d’IA un accés estructurat i determinista a les operacions de la base de dades, sense NL2SQL, sense exposar el vostre esquema i amb RBAC complet a cada pas.

Per què no NL2SQL?

Aquesta és la decisió de disseny més interessant. Els models no són deterministes i les consultes complexes tenen més probabilitats de produir errors subtils. Les consultes exactes que els usuaris esperen que l’IA pugui generar són també les que necessiten més escrutini quan es produeixen de manera no determinista.

En lloc d’això, SQL MCP Server utilitza un enfocament NL2DAB. L’agent treballa amb la capa d’abstracció d’entitats del creador de l’API de dades i el creador de consultes integrat per produir un T-SQL precís i ben format de manera determinista. Mateix resultat per a l’usuari, però sense risc de JOIN al·lucinats o exposició accidental de dades.

Set eines, no set-centes

SQL MCP Server exposa exactament set eines DML, independentment de la mida de la base de dades:

describe_entities — descobreix entitats i operacions disponibles
create_record — inserir files
read_records — consulteu taules i vistes
update_record — modifica les files
delete_record — elimina les files
execute_entity — executa procediments emmagatzemats
aggregate_records — consultes d’agregació

Això és intel·ligent perquè les finestres de context són l’espai de pensament de l’agent. Inundar-los amb centenars de definicions d’eines deixa menys espai per al raonament. Set eines fixes mantenen l’agent centrat a pensar en lloc de navegar.

Cada eina es pot activar o desactivar individualment:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Com començar en tres ordres

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Això és un servidor SQL MCP en execució que exposa la vostra taula de clients. La capa d’abstracció d’entitats significa que podeu aliar noms i columnes, limitar camps per rol i controlar exactament el que veuen els agents, sense exposar els detalls de l’esquema intern.

La història de seguretat és sòlida

Aquí és on la maduresa del creador de l’API de dades té els seus fruits:

RBAC a cada capa: cada entitat defineix quins rols poden llegir, crear, actualitzar o suprimir i quins camps són visibles
Integració d’Azure Key Vault: cadenes de connexió i secrets gestionats de manera segura
Microsoft Entra + OAuth personalitzat: autenticació de grau de producció
Política de seguretat de contingut: els agents interactuen mitjançant un contracte controlat, no SQL brut

L’abstracció de l’esquema és especialment important. Els noms de les vostres taules i columnes internes mai s’exposen a l’agent. Definiu entitats, àlies i descripcions que tinguin sentit per a la interacció de l’IA, no la vostra base de dades ERD.

Multibase de dades i multiprotocol

SQL MCP Server és compatible amb Microsoft SQL, PostgreSQL, Azure Cosmos DB i MySQL. I com que és una funció DAB, obteniu punts finals REST, GraphQL i MCP simultàniament des de la mateixa configuració. Les mateixes definicions d’entitat, les mateixes regles RBAC, la mateixa seguretat, als tres protocols.

La configuració automàtica a DAB 2.0 pot fins i tot inspeccionar la vostra base de dades i crear la configuració de manera dinàmica, si us sentiu còmode amb menys abstracció per a la creació de prototips ràpids.

La meva opinió

Així és com hauria de funcionar l’accés a la base de dades empresarial per als agents d’IA. No “hey LLM, escriu-me una mica d’SQL i YOLO contra la producció”. En lloc d’això: una capa d’entitat ben definida, generació de consultes deterministes, RBAC a cada pas, memòria cau, monitorització i telemetria. És avorrit de la millor manera possible.

Per als desenvolupadors de.NET, la història d’integració és neta: DAB és una eina.NET, el servidor MCP s’executa com a contenidor i funciona amb Azure SQL, que la majoria de nosaltres ja estem utilitzant. Si esteu creant agents d’IA que necessiten accés a dades, comenceu aquí.

Tancant

SQL MCP Server és gratuït, de codi obert i s’executa a qualsevol lloc. És l’enfocament prescriptiu de Microsoft per oferir als agents d’IA un accés segur a la base de dades. Consulteu la publicació completa i la documentació per començar.

azd ara us permet executar i depurar agents d'IA localment: aquí teniu el que va canviar el març de 2026

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

Set llançaments en un mes. Això és el que va impulsar l’equip de l’Azure Developer CLI (azd) el març de 2026, i la funció de titular és la que estava esperant: un bucle local d’execució i depuració per als agents d’IA.

PC Chan va publicar el resum complet i, tot i que hi ha moltes coses, permeteu-me filtrar-ho fins al que realment importa per als desenvolupadors de.NET que creen aplicacions basades en IA.

Executeu i depureu agents d’IA sense desplegar-los

Aquest és el gran. La nova extensió azure.ai.agents afegeix un conjunt d’ordres que us ofereixen una experiència de bucle interior adequada per als agents d’IA:

azd ai agent run: inicia el vostre agent localment
azd ai agent invoke: li envia missatges (locals o desplegats)
azd ai agent show: mostra l’estat i la salut del contenidor
azd ai agent monitor: transmet els registres dels contenidors en temps real

Abans d’això, provar un agent d’IA significava desplegar-lo a Microsoft Foundry cada vegada que feies un canvi. Ara podeu iterar localment, provar el comportament del vostre agent i només implementar-lo quan estigueu preparat. Si heu estat creant agents amb Microsoft Agent Framework o Semantic Kernel, això canvia el vostre flux de treball diari.

L’ordre d’invocació funciona amb agents locals i desplegats, la qual cosa significa que podeu utilitzar el mateix flux de treball de prova independentment d’on s’executi l’agent. Aquest és el tipus de detall que us estalvia mantenir dos conjunts de scripts de prova.

GitHub Copilot arma el vostre projecte azd

azd init ara ofereix una opció “Configura amb GitHub Copilot (vista prèvia)”. En lloc de respondre manualment les sol·licituds sobre l’estructura del vostre projecte, un agent de Copilot us encarrega la configuració. Comprova si hi ha un directori de treball brut abans de modificar res i demana el consentiment de l’eina del servidor MCP per endavant.

Quan una ordre falla, azd ara ofereix una resolució de problemes assistida per IA: trieu una categoria (explica, orienta, soluciona problemes o salta), deixeu que l’agent suggereixi una solució i torneu-ho a provar, tot sense sortir del terminal. Per a configuracions d’infraestructures complexes, això suposa un estalvi de temps real.

Feines de l’aplicació de contenidors i millores en el desplegament

Algunes funcions de desplegament que cal destacar:

Fines d’aplicacions de contenidors: azd ara desplega Microsoft.App/jobs mitjançant la configuració existent host: containerapp. La vostra plantilla de bíceps determina si l’objectiu és una aplicació de contenidor o una feina, sense cap configuració addicional.
Temps d’espera de desplegament configurables: nova marca --timeout a azd deploy i un camp deployTimeout a azure.yaml. Ja no cal endevinar el límit predeterminat de 1200 segons.
Recurs de compilació remota: quan la compilació remota d’ACR falla, azd torna automàticament a la compilació local de Docker/Podman.
Validació local de preflight: els paràmetres de bíceps es validen localment abans de desplegar-se, capturant els paràmetres que falten sense un viatge d’anada i tornada a Azure.

Polit de l’experiència del desenvolupador

Algunes millores més petites que sumen:

Detecció automàtica de pnpm/fils per a projectes JS/TS
Compatibilitat amb pyproject.toml per a l’embalatge de Python
Directoris de plantilles locals — azd init --template ara accepta camins del sistema de fitxers per a la iteració fora de línia
Millors missatges d’error en mode --no-prompt: tots els valors que falten es reporten alhora amb ordres de resolució
Variables d’entorn de compilació injectades a tots els subprocessos de creació de marcs (.NET, Node.js, Java, Python)

Aquesta última és subtil però important: la vostra compilació.NET ara té accés a les variables d’entorn azd, la qual cosa significa que podeu fer una injecció de configuració en temps de compilació sense scripts addicionals.

Tancant

El bucle de depuració de l’agent d’IA local és l’estrella d’aquesta versió, però l’acumulació de millores en el desplegament i la poliment DX fa que azd se senti més madur que mai. Si esteu desplegant aplicacions.NET a Azure, especialment agents d’IA, aquesta actualització val la pena instal·lar-la.

Comproveu les notes completes de la versió per a cada detall o comenceu amb instal·lació d’azd.

KubeCon Europe 2026: què haurien de preocupar-se realment als desenvolupadors.NET

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Coneixes aquesta sensació quan cau una publicació d’anunci massiva i t’estàs desplaçant per ella pensant “genial, però què canvia això realment per a mi”? Soc jo cada temporada de la KubeCon.

Microsoft acaba de publicar el seu resum complet de KubeCon Europe 2026, escrit pel mateix Brendan Burns, i sincerament? Aquí hi ha substància real. No només inclouen les caselles de selecció, sinó també el tipus de millores operatives que canvien la manera d’executar les coses en producció.

Permeteu-me desglossar el que realment importa per als desenvolupadors de.NET.

mTLS sense l’impost de malla de servei

Això és el que passa amb les malles de servei: tothom vol les garanties de seguretat, ningú vol la sobrecàrrega operativa. AKS finalment està tancant aquesta bretxa.

Azure Kubernetes Application Network us ofereix TLS mutu, autorització conscient de l’aplicació i telemetria de trànsit, sense desplegar una malla plena de sidecars. Combinat amb Cilium mTLS a Advanced Container Networking Services, obteniu una comunicació xifrada de pod a pod mitjançant certificats X.509 i SPIRE per a la gestió d’identitats.

Què significa això a la pràctica: les vostres API ASP.NET Core parlen amb treballadors en segon pla, els vostres serveis gRPC es trucen entre ells, tot xifrat i verificat per la identitat a nivell de xarxa, sense canvis en el codi de l’aplicació. Això és enorme.

Per als equips que migren des de ingress-nginx, també hi ha Application Routing with Meshless Istio amb suport complet de l’API de Kubernetes Gateway. Sense sidecars. Basat en estàndards. I van enviar eines ingress2gateway per a la migració incremental.

Observabilitat de la GPU que no és una idea posterior

Si utilitzeu una inferència d’IA juntament amb els vostres serveis.NET (i siguem sincers, qui no comença a fer-ho?), probablement heu arribat al punt cec de supervisió de la GPU. Obtindreu grans taulers de CPU/memòria i després… res per a les GPU sense una fontaneria d’exportació manual.

AKS ara mostra les mètriques de la GPU de manera nativa a Prometheus i Grafana gestionats. Mateixa pila, mateixos taulers de comandament, mateix canal d’alertes. Sense exportadors personalitzats, ni agents de tercers.

Al costat de la xarxa, van afegir visibilitat per flux per al trànsit HTTP, gRPC i Kafka amb una experiència d’Azure Monitor amb un sol clic. IP, ports, càrregues de treball, direcció del flux, decisions polítiques, tot en taulers integrats.

I aquesta és la que m’ha fet fer una doble presa: xarxa de contenidors agent afegeix una interfície d’usuari web on podeu fer preguntes en llenguatge natural sobre l’estat de la xarxa del vostre clúster. “Per què el pod X no arriba al servei Y?” → diagnòstics de només lectura de la telemetria en directe. Això és realment útil a les 2 del matí.

Xarxes entre clústers que no requereixen un doctorat

Històricament, Kubernetes multiclúster ha estat una experiència de “porta la teva pròpia cola de xarxa”. Azure Kubernetes Fleet Manager ara s’envia xarxes entre clústers mitjançant la malla de clúster de Cilium gestionada:

Connectivitat unificada entre clústers AKS
Registre global de serveis per a la descoberta entre clústers
Configuració gestionada de manera centralitzada, no repetida per clúster

Si utilitzeu microserveis.NET en diferents regions per a la seva resiliència o compliment, això substitueix una gran quantitat de fontaneria personalitzada fràgil. El servei A a l’oest d’Europa pot descobrir i trucar al servei B a l’est dels EUA a través de la malla, amb polítiques d’encaminament i seguretat coherents.

Actualitzacions que no requereixen valentia

Siguem sincers: les actualitzacions de Kubernetes en producció són estressants. “Actualitzar i esperar” ha estat l’estratègia de facto per a massa equips, i és el principal motiu pel qual els clústers es queden endarrerits en les versions.

Dues noves capacitats canvien això:

Les actualitzacions del grup d’agents blau-verd creen un grup de nodes paral·lels amb la nova configuració. Valideu el comportament, canvieu el trànsit gradualment i manteniu un camí de retrocés net. No més mutacions in situ als nodes de producció.

La recuperació de l’agrupació d’agents us permet revertir una agrupació de nodes a la seva versió anterior de Kubernetes i a la imatge de node després d’una actualització de costat, sense haver de reconstruir el clúster.

En conjunt, finalment donen als operadors un control real sobre el cicle de vida de l’actualització. Per als equips.NET, això és important perquè la velocitat de la plataforma controla directament la rapidesa amb què podeu adoptar nous temps d’execució, pedaços de seguretat i capacitats de xarxa.

Les càrregues de treball d’IA s’estan convertint en ciutadans de primer nivell de Kubernetes

El treball de codi obert amunt és igual d’important. L’assignació dinàmica de recursos (DRA) acaba de passar a GA a Kubernetes 1.36, fent que la programació de la GPU sigui una funció adequada de primera classe en lloc d’una solució alternativa.

Alguns projectes que val la pena veure:

Projecte	Què fa
AI Runway	API comuna de Kubernetes per a la inferència: implementeu models sense conèixer els K8, amb el descobriment d’HuggingFace i les estimacions de costos
HolmesGPT	Resolució de problemes d’agent per als nadius del núvol: ara un projecte Sandbox CNCF
Dalec	La imatge de contenidor declarativa es construeix amb la generació SBOM: menys CVE en l’etapa de creació

La direcció és clara: la vostra API.NET, la vostra capa d’orquestració del nucli semàntic i les vostres càrregues de treball d’inferència s’han d’executar en un model de plataforma coherent. Hi arribem.

Per on començaria aquesta setmana

Si esteu avaluant aquests canvis per al vostre equip, aquí teniu la meva llista de prioritats honesta:

Observabilitat primer: activeu les mètriques de la GPU i els registres de flux de xarxa en un clúster que no sigui de producte. Mira què t’has perdut.
Proveu les actualitzacions blau-verd: proveu el flux de treball de retrocés abans de la propera actualització del clúster de producció. Generar confiança en el procés.
Pilota de xarxes conscients de la identitat: trieu una ruta de servei interna i activeu mTLS amb Cilium. Mesureu la sobrecàrrega (spoiler: és mínim).
Avalueu el gestor de flotes: si executeu més de dos clústers, la xarxa entre clústers es compensa amb una cola personalitzada reduïda.

Petits experiments, feedback ràpid. Aquest és sempre el moviment.

Tancant

Els anuncis de KubeCon poden ser aclaparadors, però aquest lot realment mou l’agulla dels equips.NET a AKS. Millor seguretat de xarxes sense sobrecàrrega de malla, observabilitat real de la GPU, actualitzacions més segures i bases d’infraestructura d’IA més sòlides.

Si ja esteu a AKS, aquest és un bon moment per endurir la vostra línia de base operativa. I si teniu previst traslladar les càrregues de treball.NET a Kubernetes, la plataforma s’acaba de preparar molt més per a la producció.

Servidor SQL MCP, Copilot a SSMS i un concentrador de bases de dades amb agents d'IA: el que realment importa de SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft acaba de començar SQLCon 2026 juntament amb FabCon a Atlanta, i hi ha molt per desempaquetar. L’anunci original cobreix des de plans d’estalvi fins a funcions de compliment empresarial. Vaig a ometre les diapositives de preus empresarials i em centraré en les peces que importen si sou un desenvolupador que construeix coses amb Azure SQL i AI.

El servidor SQL MCP està en previsualització pública

Aquest és el titular per a mi. L’Azure SQL Database Hyperscale ara té un SQL MCP Server en previsualització pública que us permet connectar de manera segura les vostres dades SQL a agents d’IA i Copilots mitjançant el Model Context Protocol.

Si heu estat seguint l’onada MCP, i sincerament, és difícil perdre’s ara mateix, això és un gran problema. En lloc de crear canalitzacions de dades personalitzades per alimentar el context dels vostres agents d’IA des de la vostra base de dades, obteniu un protocol estandarditzat per exposar les dades SQL directament. Els vostres agents poden consultar, raonar i actuar sobre la informació de la base de dades en directe.

Per a aquells de nosaltres que creem agents d’IA amb Semantic Kernel o Microsoft Agent Framework, això obre un camí d’integració net. El vostre agent necessita comprovar l’inventari? Busqueu un registre de client? Validar una comanda? MCP li ofereix una manera estructurada de fer-ho sense que escriviu codi d’obtenció de dades a mida per a cada escenari.

GitHub Copilot a SSMS 22 ara és GA

Si passeu algun temps a SQL Server Management Studio (i siguem sincers, la majoria de nosaltres encara ho fem), GitHub Copilot ara està disponible generalment a SSMS 22. La mateixa experiència Copilot que ja feu servir a VS Code i Visual Studio, però per a T-SQL.

El valor pràctic aquí és senzill: assistència basada en xat per escriure consultes, refactoritzar procediments emmagatzemats, resoldre problemes de rendiment i gestionar tasques d’administració. No hi ha res revolucionari en concepte, però tenir-lo allà mateix a SSMS significa que no cal que canvieu de context a un altre editor només per obtenir ajuda d’IA amb el treball de la vostra base de dades.

Els índexs vectorials han rebut una actualització seriosa

L’Azure SQL Database ara té índexs vectorials més ràpids i capaços amb suport complet per a la inserció, l’actualització i la supressió. Això vol dir que les vostres dades vectorials es mantenen actuals en temps real, sense necessitat de reindexació per lots.

Aquí teniu les novetats:

Quantització per a mides d’índex més petites sense perdre massa precisió
Filtratge iteratiu per obtenir resultats més precisos
Integració més estreta de l’optimitzador de consultes per a un rendiment previsible

Si esteu fent la generació augmentada per la recuperació (RAG) amb Azure SQL com a magatzem de vectors, aquestes millores són directament útils. Podeu mantenir els vostres vectors al costat de les vostres dades relacionals a la mateixa base de dades, cosa que simplifica significativament la vostra arquitectura en comparació amb l’execució d’una base de dades vectorial separada.

Les mateixes millores vectorials també estan disponibles a la base de dades SQL a Fabric, ja que totes dues s’executen amb el mateix motor SQL a sota.

Database Hub in Fabric: gestió agentica

Aquest és més avançat, però és interessant. Microsoft va anunciar el Database Hub a Microsoft Fabric (accés anticipat), que us ofereix un únic panell de vidre a Azure SQL, Cosmos DB, PostgreSQL, MySQL i SQL Server mitjançant Arc.

L’angle interessant no és només la visió unificada, sinó l’enfocament agent de la gestió. Els agents d’IA controlen contínuament el patrimoni de la vostra base de dades, evidencien què ha canviat, expliquen per què és important i suggereixen què fer a continuació. És un model human-in-the-loop on l’agent fa el treball i tu fas les trucades.

Per als equips que gestionen més d’un grapat de bases de dades, això podria reduir realment el soroll operatiu. En lloc de saltar entre portals i comprovar manualment les mètriques, l’agent us porta el senyal.

Què significa això per als desenvolupadors de.NET

El fil que connecta tots aquests anuncis és clar: Microsoft està incorporant agents d’IA a cada capa de la pila de bases de dades. No com un truc, sinó com una capa d’eines pràctica.

Si esteu creant aplicacions.NET amb el suport d’Azure SQL, això és el que faria realment:

Proveu el servidor SQL MCP si esteu creant agents d’IA. És la manera més neta de donar accés a la base de dades dels vostres agents sense fontaneria personalitzada.
Activa Copilot a SSMS si encara no ho has fet: guanys de productivitat gratuïts per al treball SQL diari.
Mira els índexs vectorials si estàs fent RAG i actualment tens una botiga de vectors independent. La consolidació a Azure SQL significa un servei menys per gestionar.

Tancant

L’anunci complet té més: plans d’estalvi, assistents de migració, funcions de compliment, però la història del desenvolupador es troba al servidor MCP, les millores vectorials i la capa de gestió agent. Aquestes són les peces que canvien la manera de construir, no només el pressupost.

Fes una ullada a l’anunci complet de Shireesh Thota per obtenir la imatge completa i inscriu-te a l’accés anticipat al centre de bases de dades si vols provar la nova experiència de gestió.

De l'ordinador portàtil a la producció: desplegament d'agents d'IA a Microsoft Foundry amb dues ordres

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Coneixeu aquesta bretxa entre “funciona a la meva màquina” i “està desplegat i atén el trànsit”? Per als agents d’IA, aquesta bretxa ha estat dolorosament àmplia. Heu de subministrar recursos, desplegar models, connectar la identitat, configurar la supervisió, i això és abans que ningú pugui trucar al vostre agent.

L’Azure Developer CLI acaba de convertir-ho en un assumpte de dos comandaments.

El nou flux de treball `azd ai agent`

Permeteu-me explicar com és realment això. Teniu un projecte d’agent d’IA, diguem-ne un agent de consergeria d’hotel. Funciona localment. Voleu que funcioni a Microsoft Foundry.

azd ai agent init
azd up

Això és tot. Dues ordres. azd ai agent init arma la infraestructura com a codi al vostre dipòsit i azd up proveeix tot a Azure i publica el vostre agent. Obteniu un enllaç directe al vostre agent al portal de Foundry.

Què passa sota el capó

L’ordre init genera plantilles de bíceps reals i inspeccionables al vostre repositori:

Un Recurs de Foundry (contenidor de primer nivell)
Un Projecte de Foundry (on viu el vostre agent)
Configuració del model de desplegament (GPT-4o, etc.)
Identitat gestionada amb assignacions de rol RBAC adequades
azure.yaml per al mapa de serveis
agent.yaml amb metadades de l’agent i variables d’entorn

Aquí teniu la part clau: sou el propietari de tot això. Està versionat Bicep al teu repositori. Podeu inspeccionar-lo, personalitzar-lo i confirmar-lo juntament amb el vostre codi d’agent. Sense capses negres màgiques.

El bucle intern del desenvolupament

El que m’agrada molt és la història del desenvolupament local. Quan esteu iterant la lògica de l’agent, no voleu tornar a desplegar cada vegada que canvieu una sol·licitud:

azd ai agent run

Això inicia el vostre agent localment. Vinculeu-lo amb azd ai agent invoke per enviar sol·licituds de prova i teniu un bucle de comentaris ajustat. Edita el codi, reinicia, invoca, repeteix.

L’ordre invoke també és intel·ligent pel que fa a l’encaminament: quan s’executa un agent local, l’orienta automàticament. Quan no ho és, arriba al punt final remot.

Monitorització en temps real

Aquesta és la característica que em va vendre. Un cop desplegat el vostre agent:

azd ai agent monitor --follow

Cada sol·licitud i resposta que flueix pel vostre agent es transmet al vostre terminal en temps real. Per depurar problemes de producció, això és inestimable. Sense investigar l’analítica de registres, sense esperar que les mètriques s’agreguin; veuràs què està passant ara mateix.

El conjunt d’ordres complet

Aquí teniu la referència ràpida:

Comandament	Què fa
`azd ai agent init`	Armar un projecte d’agent de Foundry amb IaC
`azd up`	Proveïu els recursos d’Azure i implementeu l’agent
`azd ai agent invoke`	Envieu sol·licituds a l’agent local o remot
`azd ai agent run`	Executeu l’agent localment per al desenvolupament
`azd ai agent monitor`	Transmet els registres en temps real de l’agent publicat
`azd ai agent show`	Comproveu l’estat i l’estat de l’agent
`azd down`	Netegeu tots els recursos d’Azure

Per què això és important per als desenvolupadors de.NET

Tot i que la mostra de l’anunci està basada en Python, la història de la infraestructura és independent del llenguatge. El vostre agent.NET obté la mateixa bastida Bíceps, la mateixa configuració d’identitat gestionada, la mateixa canalització de monitorització. I si ja esteu utilitzant azd per a les vostres aplicacions.NET Aspire o implementacions d’Azure, això s’adapta perfectament al vostre flux de treball existent.

La bretxa de desplegament dels agents d’IA ha estat un dels punts de fricció més grans de l’ecosistema. Passar d’un prototip de treball a un punt final de producció amb una identitat, una xarxa i un seguiment adequats no hauria de requerir una setmana de treball DevOps. Ara requereix dues ordres i uns minuts.

Tancant

azd ai agent ja està disponible. Si heu postergat la implementació dels vostres agents d’IA perquè la configuració de la infraestructura us semblava massa feina, proveu-ho. Fes una ullada a la tutorial completa per veure el pas a pas complet, inclosa la integració de l’aplicació de xat frontal.

El servei d'agents de Foundry és GA: el que realment importa per als constructors d'agents.NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Siguem sincers: construir un prototip d’agent d’IA és la part fàcil. La part difícil és que tot sigui després: posar-lo en producció amb un aïllament adequat de la xarxa, fer avaluacions que realment signifiquen alguna cosa, gestionar els requisits de compliment i no trencar les coses a les 2 del matí.

El Foundry Agent Service acaba de passar a GA, i aquest llançament està centrat en aquest buit de “tot després”.

Creat a partir de l’API Responses

Aquí teniu el titular: el servei d’agent de Foundry de nova generació es basa en l’API de respostes d’OpenAI. Si ja esteu creant amb aquest protocol de cable, migrar a Foundry és un canvi de codi mínim. Què obteniu: seguretat empresarial, xarxes privades, Entra RBAC, seguiment complet i avaluació, a més de la vostra lògica d’agent existent.

L’arquitectura és oberta intencionadament. No esteu bloquejat a un proveïdor de models ni a un marc d’orquestració. Utilitzeu DeepSeek per a la planificació, OpenAI per a la generació, LangGraph per a l’orquestració: el temps d’execució gestiona la capa de coherència.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Si veniu del paquet azure-ai-agents, ara els agents són operacions de primera classe a AIProjectClient a azure-ai-projects. Deixeu anar el pin autònom i utilitzeu get_openai_client() per generar respostes.

Xarxes privades: s’ha eliminat el bloquejador empresarial

Aquesta és la característica que desbloqueja l’adopció empresarial. Foundry ara admet xarxes privades d’extrem a extrem amb BYO VNet:

Sense sortida pública: el trànsit d’agents no toca mai l’Internet pública
Injecció de contenidor/subxarxa a la vostra xarxa per a la comunicació local
Connectivitat d’eines inclosa: els servidors MCP, Azure AI Search i els agents de dades de Fabric operen per camins privats

Aquest darrer punt és crític. No només les trucades d’inferència es mantenen privades: totes les trucades d’invocació i recuperació d’eines també es mantenen dins dels límits de la vostra xarxa. Per als equips que operen sota polítiques de classificació de dades que prohibeixen l’encaminament extern, això és el que faltava.

Autenticació MCP feta correctament

Les connexions del servidor MCP ara admeten l’espectre complet de patrons d’autenticació:

Mètode d’autenticació	Quan s’ha d’utilitzar
Basat en claus	Accés compartit senzill per a eines internes de tota l’organització
Entra la identitat de l’agent	servei a servei; l’agent s’autentica com ell mateix
Entra a la identitat gestionada	Aïllament per projecte; cap gestió de credencials
Passthrough d’identitat OAuth	Accés delegat per l’usuari; agent actua en nom dels usuaris

OAuth Identity Passthrough és l’interessant. Quan els usuaris han de concedir a un agent accés a les seves dades personals (el seu OneDrive, la seva organització de Salesforce, una API de SaaS definida per l’usuari), l’agent actua en nom seu amb els fluxos d’OAuth estàndard. No hi ha cap identitat de sistema compartida que pretengui ser tothom.

Voice Live: veu a veu sense la fontaneria

Afegir veu a un agent solia significar unir STT, LLM i TTS: tres serveis, tres salts de latència, tres superfícies de facturació, tot sincronitzat a mà. Voice Live ho col·lapsa en una única API gestionada amb:

Activitat de veu semàntica i detecció de final de torn (comprèn el significat, no només el silenci)
Supressió de soroll del costat del servidor i cancel·lació d’eco
Suport d’intrusió (els usuaris poden interrompre la resposta mitjana)

Les interaccions de veu passen pel mateix temps d’execució de l’agent que el text. Els mateixos avaluadors, els mateixos rastres, la mateixa visibilitat de costos. Per a escenaris d’assistència al client, servei de camp o accessibilitat, això substitueix el que abans requeria una canalització d’àudio personalitzada.

Avaluacions: des de la casella de selecció fins al seguiment continu

Aquí és on Foundry es pren seriosament sobre la qualitat de la producció. El sistema d’avaluació té ara tres capes:

Avaluadors fora de la caixa: coherència, rellevància, fonamentació, qualitat de recuperació, seguretat. Connecta’t a un conjunt de dades o trànsit en directe i recupera les puntuacions.
Avaluadors personalitzats: codifiqueu la vostra pròpia lògica empresarial, estàndards de to i regles de compliment específiques del domini.
Avaluació contínua: Foundry mostra el trànsit de producció en directe, executa la vostra suite d’avaluadors i mostra els resultats mitjançant taulers de control. Establiu alertes d’Azure Monitor per quan cau la connexió a terra o incompliment dels llindars de seguretat.

Tot es publica a Azure Monitor Application Insights. Qualitat de l’agent, salut de la infraestructura, cost i telemetria d’aplicacions, tot en un sol lloc.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Sis noves regions per als agents allotjats

Els agents allotjats ara estan disponibles a l’est dels EUA, al nord del centre dels EUA, a Suècia al centre, al sud-est asiàtic, al Japó oriental i més. Això és important per als requisits de residència de les dades i per comprimir la latència quan el vostre agent s’executa a prop de les seves fonts de dades.

Per què això és important per als desenvolupadors de.NET

Tot i que les mostres de codi de l’anunci de GA són Python primer, la infraestructura subjacent és independent del llenguatge, i l’SDK.NET per a azure-ai-projects segueix els mateixos patrons. L’API Responses, el marc d’avaluació, la xarxa privada, l’autenticació MCP, tot això està disponible a.NET.

Si heu estat esperant que els agents d’IA passin de “demo fantàstica” a “Puc enviar-ho a la feina”, aquest llançament de GA és el senyal. Les xarxes privades, l’autenticació adequada, l’avaluació contínua i el seguiment de la producció són les peces que faltaven.

Tancant

El servei d’agent de Foundry ja està disponible. Instal·leu l’SDK, obriu el portal i comenceu a crear. La guia d’inici ràpid us porta de zero a un agent en execució en qüestió de minuts.

Per obtenir la informació tècnica completa amb totes les mostres de codi, consulteu l’anunci de GA.

El servidor Azure DevOps MCP arriba a Microsoft Foundry: què significa això per als vostres agents d'IA

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) ha tingut un moment. Si heu estat seguint l’ecosistema d’agents d’IA, probablement heu notat que els servidors MCP apareixen a tot arreu, donant als agents la possibilitat d’interaccionar amb eines i serveis externs mitjançant un protocol estandarditzat.

Ara el Servidor MCP d’Azure DevOps està disponible a Microsoft Foundry, i aquesta és una d’aquestes integracions que et fa pensar en les possibilitats pràctiques.

Què està passant realment aquí

Microsoft ja va llançar l’Azure DevOps MCP Server com a vista prèvia pública, això és el propi servidor MCP. La novetat és la integració de Foundry. Ara podeu afegir l’Azure DevOps MCP Server als vostres agents de Foundry directament des del catàleg d’eines.

Per a aquells que encara no estiguin familiaritzats amb Foundry: és la plataforma unificada de Microsoft per crear i gestionar aplicacions i agents basats en IA a escala. Accés al model, orquestració, avaluació, desplegament, tot en un sol lloc.

Configurant-lo

La configuració és sorprenentment senzilla:

Al vostre agent de Foundry, aneu a Afegeix eines > Catàleg
Cerqueu “Azure DevOps”
Seleccioneu el servidor Azure DevOps MCP (visualització prèvia) i feu clic a Crea
Introduïu el nom de la vostra organització i connecteu-vos

Això és tot. El vostre agent ara té accés a les eines d’Azure DevOps.

Controlar a què pot accedir el vostre agent

Aquesta és la part que agraeixo: no us enganxeu amb un enfocament de tot o res. Podeu especificar quines eines estan disponibles per al vostre agent. Per tant, si només voleu que llegeixi elements de treball però no toqui les canalitzacions, podeu configurar-ho. Principi de privilegis mínims, aplicat als vostres agents d’IA.

Això és important per als escenaris empresarials en què no voleu que un agent activi accidentalment una canalització de desplegament perquè algú li va demanar que “ajudés amb el llançament”.

Per què això és interessant per als equips.NET

Penseu en què permet això a la pràctica:

Ajudants de planificació de sprint: agents que poden extreure elements de treball, analitzar dades de velocitat i suggerir capacitat de sprint
Bots de revisió de codi: agents que entenen el vostre context de relacions públiques perquè poden llegir els vostres repositoris i els elements de treball enllaçats.
Resposta a incidents: agents que poden crear elements de treball, consultar implementacions recents i correlacionar errors amb canvis recents
Incorporació de desenvolupadors — “En què he de treballar?” obté una resposta real recolzada per dades reals del projecte

Per als equips.NET que ja utilitzen Azure DevOps per als seus pipelines CI/CD i la gestió de projectes, tenir un agent d’IA que pugui interactuar directament amb aquests sistemes és un pas important cap a una automatització útil (no només chatbot com a servei).

La imatge MCP més gran

Això forma part d’una tendència més àmplia: els servidors MCP s’estan convertint en la manera estàndard en què els agents d’IA interactuen amb el món exterior. Els veiem per a GitHub, Azure DevOps, bases de dades, API SaaS, i Foundry s’està convertint en el centre on s’uneixen totes aquestes connexions.

Si esteu creant agents a l’ecosistema.NET, val la pena prestar atenció a MCP. El protocol està estandarditzat, les eines estan madurant i la integració de Foundry el fa accessible sense haver de connectar manualment les connexions del servidor.

Tancant

El servidor Azure DevOps MCP a Foundry està en vista prèvia, així que espereu que evolucioni. Però el flux de treball bàsic és sòlid: connecteu-vos, configureu l’accés a les eines i deixeu que els vostres agents treballin amb les vostres dades de DevOps. Si ja sou a l’ecosistema de Foundry, això és a uns quants clics. Prova-ho i mira quins fluxos de treball pots crear.

Consulteu l’anunci complet per a la configuració pas a pas i més detalls.

Respostes de fons a Microsoft Agent Framework: no hi ha més ansietat de temps d'espera

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Si heu creat alguna cosa amb models de raonament com l’o3 o el GPT-5.2, coneixeu el dolor. El vostre agent comença a pensar en una tasca complexa, el client s’asseu allà esperant i en algun lloc entre “això està bé” i “s’ha estavellat?” la vostra connexió s’esgota. Tota aquesta feina? Desaparegut.

Microsoft Agent Framework acaba d’enviar respostes de fons i, sincerament, aquesta és una d’aquestes característiques que haurien d’haver existit des del primer dia.

El problema amb el bloqueig de trucades

En un patró de sol·licitud-resposta tradicional, el vostre client es bloqueja fins que l’agent acabi. Això funciona bé per a tasques ràpides. Però quan demaneu a un model de raonament que faci una investigació profunda, una anàlisi en diversos passos o que generi un informe de 20 pàgines? Esteu mirant els minuts del rellotge de paret. Durant aquesta finestra:

Les connexions HTTP es poden esgotar
Els blips de xarxa maten tota l’operació
El vostre usuari mira un spinner preguntant-se si està passant alguna cosa

Les respostes de fons donen la volta a això.

Com funcionen les fitxes de continuació

En lloc de bloquejar, inicieu la tasca de l’agent i recupereu un token de continuació. Penseu-ho com un bitllet de reclamació en un taller de reparacions: no us quedeu al taulell esperant, torneu quan estigui llest.

El flux és senzill:

Envieu la vostra sol·licitud amb AllowBackgroundResponses = true
Si l’agent admet el processament en segon pla, obtindreu un testimoni de continuació
Enquesta sobre el teu horari fins que el testimoni torni null; això vol dir que el resultat està preparat

Aquí teniu la versió de.NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Poll until complete
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Si l’agent completa immediatament (tasques senzilles, models que no necessiten processament en segon pla), no es retorna cap testimoni de continuació. El vostre codi només funciona, no cal cap manipulació especial.

Transmissió amb currículum: la veritable màgia

Les enquestes estan bé per als escenaris de foc i oblit, però què passa quan voleu progrés en temps real? Les respostes en segon pla també admeten la transmissió amb la represa integrada.

Cada actualització en streaming porta el seu propi testimoni de continuació. Si la vostra connexió cau a la meitat del flux, repreneu exactament on ho vau deixar:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulate a network interruption
}

// Resume from exactly where we left off
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

L’agent continua processant el costat del servidor independentment del que passi amb el vostre client. Això és una tolerància a fallades integrada sense que escriviu la lògica de reintent o els interruptors.

Quan s’ha d’utilitzar realment

No totes les trucades d’agent necessiten respostes en segon pla. Per completar-les ràpidament, esteu afegint complexitat sense cap motiu. Però aquí és on brillen:

Tasques de raonament complexes: anàlisi en diversos passos, investigació profunda, qualsevol cosa que faci pensar realment a un model de raonament
Generació llarga de contingut: informes detallats, documents de diverses parts, anàlisis exhaustives
Xarxes poc fiables: clients mòbils, desplegaments perifèrics, VPN corporatives descabellades
Patrons UX asíncrons: envieu una tasca, aneu a fer una altra cosa, torneu per obtenir resultats

Per als desenvolupadors de.NET que creem aplicacions empresarials, aquesta última és especialment interessant. Penseu en una aplicació Blazor en què un usuari sol·licita un informe complex: desactiveu la tasca de l’agent, els mostreu un indicador de progrés i deixeu que continuï treballant. Sense gimnàstica WebSocket, sense infraestructura de cua personalitzada, només un testimoni i un bucle d’enquesta.

Tancant

Les respostes de fons estan disponibles ara tant a.NET com a Python mitjançant Microsoft Agent Framework. Si esteu creant agents que fan alguna cosa més complexa que les simples preguntes i respostes, val la pena afegir-ho al vostre conjunt d’eines. El patró de testimoni de continuació manté les coses senzilles alhora que resol un problema de producció molt real.

Consulteu la documentació completa per obtenir la referència completa de l’API i més exemples.