Posts | The .NET Blog

.NET 10 Inclòs amb Ubuntu 26.04 LTS — Les Novetats

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

És el dia d’Ubuntu LTS. Ubuntu 26.04 (Resolute Raccoon) ha arribat avui amb .NET 10.

Instal·la .NET 10 en dos comandes

sudo apt update
sudo apt install dotnet-sdk-10.0

Contenidors: actualitza `-noble` a `-resolute`

sed -i "s/noble/resolute/g" Dockerfile

Native AOT: arrencada en 3ms, binari de 1.4MB

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# binari natiu de 1.4MB, arrencada en 3ms

Necessites .NET 8 o 9?

add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

Consulta el post complet per a més detalls.

CodeAct al Agent Framework: Com Reduir la Latència del teu Agent a la Meitat

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

Hi ha un moment en tot projecte d’agents en què mires el trace i penses: “per què tarda tant això?” El model està bé. Les eines funcionen. Però hi ha set round trips per obtenir un resultat que es podria calcular d’una sola vegada.

Exactament aquest és el problema que resol CodeAct — i l’equip d’Agent Framework acaba de publicar suport alpha a través del nou paquet agent-framework-hyperlight.

Què és CodeAct?

El patró CodeAct és elegantment simple: en lloc de donar al model una llista d’eines i deixar-lo cridar-les una per una, li dones una única eina execute_code i li permets expressar el pla complet com un programa Python curt. L’agent escriu el codi una vegada, el sandbox l’executa, i tornes a rebre un únic resultat consolidat.

Un pla de cinc passos que abans requeria cinc torns del model ara es converteix en un torn execute_code que conté un script Python que crida les teves eines via call_tool(...).

El benchmark del repositori ho fa concret. Vuit usuaris, dotzenes de comandes, cinc eines. Mateix model, mateixes eines, mateix prompt — només cablejat diferent:

Cablejat	Temps	Tokens
Tradicional	27.81s	6.890
CodeAct	13.23s	2.489
Millora	52,4%	63,9%

La peça de seguretat: micro-VMs de Hyperlight

El paquet agent-framework-hyperlight utilitza micro-VMs de Hyperlight. Cada crida execute_code obté la seva pròpia micro-VM recentment creada — amb la seva pròpia memòria, sense accés al sistema de fitxers del host més enllà del que muntes explícitament. L’arrencada es mesura en mil·lisegons.

Les teves eines segueixen executant-se al host. El codi de pegament generat pel model s’executa en el sandbox. Aquesta és la divisió correcta.

Com connectar-ho

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quan fer servir CodeAct (i quan no)

Fes servir CodeAct quan:

La tasca encadena moltes crides petites a eines (consultes, joins, càlculs, formatació)
Et preocupa la latència i el cost de tokens
Vols aïllament fort per crida en codi generat pel model

Queda’t amb el tool-calling tradicional quan:

L’agent només fa una o dues crides a eines per torn
Cada crida té efectes secundaris que vols aprovar individualment
Les descripcions d’eines són escasses o ambigües

Prova-ho ara

pip install agent-framework-hyperlight --pre

Consulta el post complet al blog d’Agent Framework per a cobertura més profunda.

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.

On Recorda les Coses el teu Agent? Guia Pràctica sobre l'Emmagatzematge de l'Historial de Xat

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

Quan construeixes un agent IA, dediques la major part de la teva energia al model, les eines i els prompts. La pregunta de on viu l’historial de conversa sembla un detall d’implementació — però és una de les decisions arquitectòniques més importants que prendràs.

Determina si els usuaris poden bifurcar converses, desfer respostes, reprendre sessions després d’un reinici, i si les teves dades surten mai de la teva infraestructura. L’equip d’Agent Framework ha publicat una anàlisi en profunditat.

Dos patrons fonamentals

Gestionat pel servei: el servei d’IA emmagatzema l’estat de la conversa. La teva app manté una referència i el servei inclou automàticament l’historial rellevant en cada sol·licitud.

Gestionat pel client: la teva app manté l’historial complet i envia missatges rellevants amb cada sol·licitud. El servei no té estat. Controles tot.

Com Agent Framework abstreu això

// C# — funciona igual independentment del proveïdor
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Em dic Alice.", session);
var second = await agent.RunAsync("Quin és el meu nom?", session);

# Python
session = agent.create_session()
first = await agent.run("Em dic Alice.", session=session)
second = await agent.run("Quin és el meu nom?", session=session)

Referència ràpida de proveïdors

Proveïdor	Emmagatzematge	Model	Compactació
OpenAI/Azure Chat Completions	Client	N/A	Tu
Foundry Agent Service	Servei	Lineal	Servei
Responses API (per defecte)	Servei	Bifurcació	Servei
Anthropic Claude, Ollama	Client	N/A	Tu

Llegeix el post complet per a l’arbre de decisions complet.

VS Code 1.118: Copilot CLI Obté Noms de Sessió, Insígnies de Model i TypeScript 7.0 Nightly

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

Visual Studio Code 1.118 és un llançament petit i enfocat — principalment millores de Copilot CLI.

Copilot CLI: les sessions ara tenen noms reals

Les APIs de títol de sessió del SDK de Copilot CLI s’utilitzen ara com a font de veritat. Les sessions mostren el nom real del SDK en lloc d’etiquetes auto-generades.

Canvia de sessió amb dreceres de teclat

L’app d’Agents ara té Ctrl+1, Ctrl+2, etc. per canviar ràpidament entre sessions.

Insígnies de model al xat

Les respostes de Copilot CLI al panell de xat ara mostren una insígnia de model per veure quin model ha gestionat cada sol·licitud.

Selecció automàtica de model a Copilot CLI

La selecció automàtica de model — anteriorment disponible en altres parts de Copilot — ara funciona també a l’agent Copilot CLI.

Opt-in a TypeScript 7.0 nightly

Ara pots optar per provar els nightly de TypeScript 7.0 directament des de la configuració de VS Code.

Consulta les notes de versió completes.

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.

Hooks d'azd en Python, TypeScript i .NET: adéu als scripts de shell

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

Si alguna vegada has tingut un projecte completament en .NET i tot i així has hagut d’escriure scripts Bash per als hooks d’azd, coneixes bé aquell dolor. Per què canviar a sintaxi de shell en un pas de pre-provisioning quan tota la resta del projecte és C#?

Aquesta frustració té ara solució oficial. L’Azure Developer CLI acaba de llançar suport multi-llenguatge per a hooks, i és exactament tan bo com sona.

Hooks, breument

Els hooks són scripts que s’executen en punts clau del cicle de vida d’azd — abans del provisioning, després del desplegament, i més. Es defineixen a azure.yaml i permeten injectar lògica personalitzada sense modificar la CLI.

Abans només s’admetien Bash i PowerShell. Ara pots usar Python, JavaScript, TypeScript o .NET — i azd s’encarrega de la resta automàticament.

Com funciona la detecció

Simplement apuntes el hook a un fitxer i azd infereix el llenguatge per l’extensió:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Sense configuració addicional. Si l’extensió és ambigua, pots afegir kind: python (o el que correspongui) per especificar-ho explícitament.

Detalls importants per llenguatge

Python

Col·loca un requirements.txt o pyproject.toml al costat del script (o en qualsevol directori pare) i azd crea un entorn virtual, instal·la dependències i executa l’script.

JavaScript i TypeScript

El mateix patró — posa un package.json a prop del script i azd executarà npm install primer. Per a TypeScript, usa npx tsx sense pas de compilació ni tsconfig.json.

.NET

Dos modes disponibles:

Mode projecte: Si hi ha un .csproj al costat del script, azd executa dotnet restore i dotnet build automàticament.
Mode single-file: En .NET 10+, pots posar un fitxer .cs independent i s’executa directament amb dotnet run script.cs. Sense fitxer de projecte.

Configuració per executor

Cada llenguatge admet un bloc config opcional:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Per què importa per a desenvolupadors .NET

Els hooks eren l’últim lloc d’un projecte basat en azd que t’obligava a usar un altre llenguatge. Ara tot el pipeline de desplegament pot viure en un sol llenguatge. Pots reutilitzar les teves utilitats .NET existents als hooks, referenciar llibreries compartides i evitar el manteniment de scripts de shell.

Conclusió

És un d’aquells canvis que semblen petits però que eliminen molta fricció del dia a dia amb azd. El suport multi-llenguatge per a hooks ja està disponible — consulta el post oficial per a la documentació completa.

Windows App Dev CLI v0.3: F5 des del terminal i automatització de UI per a 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í.

L’experiència F5 de Visual Studio és fantàstica. Però haver d’obrir VS només per llançar i depurar una app Windows empaquetada és excessiu quan estàs en un pipeline de CI, executant un workflow automatitzat, o quan un agent d’IA fa les proves.

Windows App Development CLI v0.3 acaba de sortir i ho aborda directament amb dues funcions destacades: winapp run i winapp ui.

winapp run: F5 des de qualsevol lloc

winapp run pren una carpeta d’app sense empaquetar i un manifest, i fa tot el que VS fa en un debug launch: registra un paquet loose, llança l’app i preserva el LocalState entre re-deploys.

winapp run ./bin/Debug

Funciona per a WinUI, WPF, WinForms, Console, Avalonia i més. Els modes estan pensats per a developers i workflows automatitzats:

--detach: Llança i retorna el control al terminal immediatament.
--unregister-on-exit: Neteja el paquet registrat en tancar l’app.
--debug-output: Captura missatges OutputDebugString i excepcions en temps real.

Nou paquet NuGet: dotnet run per a apps empaquetades

Per a developers .NET hi ha un nou paquet NuGet: Microsoft.Windows.SDK.BuildTools.WinApp. Afegeix-lo al projecte i dotnet run gestiona tot l’inner loop: build, preparar un paquet loose-layout, registrar a Windows i llançar — tot en un pas.

winapp init
# o
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: UI Automation des de la línia de comandes

winapp ui et dóna accés complet d’UI Automation a qualsevol app Windows en execució — WPF, WinForms, Win32, Electron, WinUI3. Pots llistar finestres, navegar l’arbre de UI Automation, trobar elements, fer clics, prendre captures de pantalla i esperar l’aparició d’elements.

Combina winapp ui amb winapp run i tens un workflow complet build → llançar → verificar des del terminal. Un agent pot executar la teva app, inspeccionar l’estat de la UI i validar el resultat.

Altres novetats

winapp unregister: Elimina un paquet sideloaded quan acabes.
winapp manifest add-alias: Afegeix un àlies per llançar l’app per nom des del terminal.
Tab completion: Configura completat amb una sola comanda per a PowerShell.

Com obtenir-ho

winget install Microsoft.WinAppCli
# o
npm install -g @microsoft/winappcli

Consulta el repositori a GitHub per a documentació completa i l’anunci original per a tots els detalls.

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

Escrivint complements natius de Node.js en C# amb .NET Native AOT

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

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

Aquí teniu un escenari que m’encanta: un equip que treballa en eines .NET tenia complements natius de Node.js escrits en C++ i compilats amb node-gyp. Funcionava. Però requeria que Python estigués instal·lat a la màquina de cada desenvolupador — una versió antiga de Python, per cert — només per compilar un paquet que ningú de l’equip tocaria mai directament.

Llavors es van fer una pregunta molt raonable: ja tenim el .NET SDK instal·lat, per què estem escrivint C++ en absolut?

La resposta va ser Native AOT, i el resultat és genuïnament elegant. Drew Noakes de l’equip de C# Dev Kit va descriure com ho van fer, i crec que val la pena entendre-ho fins i tot si no esteu creant extensions de VS Code.

La idea bàsica

Un complement natiu de Node.js és una biblioteca compartida (.dll a Windows, .so a Linux, .dylib a macOS) que Node.js pot carregar en temps d’execució. La interfície s’anomena N-API — una API C estable i compatible amb ABI. N-API no li importa quin idioma ha produït la biblioteca, només que exporti els símbols correctes.

.NET Native AOT pot produir exactament això. Compila el vostre codi C# per endavant en una biblioteca compartida nativa amb punts d’entrada arbitraris. Aquest és tot el truc.

La configuració del projecte

El fitxer de projecte és mínim:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot és el que indica al SDK que produeixi una biblioteca compartida en dotnet publish. AllowUnsafeBlocks és necessari per a l’interoperabilitat N-API amb punters de funcions i buffers fixes.

Exportant el punt d’entrada

Node.js espera que la vostra biblioteca exporti napi_register_module_v1. En C#, [UnmanagedCallersOnly] fa exactament això:

[UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
public static nint Init(nint env, nint exports)
{
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
}

nint és un enter de mida nativa. El sufix u8 produeix un ReadOnlySpan<byte> amb un literal de cadena UTF-8, passat directament a N-API sense cap assignació d’encoding.

Resolent N-API contra el procés amfitrió

Les funcions N-API les exporta node.exe en si, no una biblioteca separada. Per tant, en lloc d’enllaçar contra alguna cosa, les resoleu contra el procés en execució a l’inici:

NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
}

Amb això, les vostres declaracions P/Invoke funcionen neta:

[LibraryImport("node", EntryPoint = "napi_create_string_utf8")]
internal static partial Status CreateStringUtf8(
 nint env, ReadOnlySpan<byte> str, nuint length, out nint result);

Cridant-lo des de TypeScript

dotnet publish produeix la vostra biblioteca nativa específica de la plataforma. La canvieu de nom a .node i l’useu amb un require() estàndard:

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk',
 'InstallLocation'
);

Això és tot. TypeScript cap a C#, sense Python, sense C++.

Conclusions

L’equip de C# Dev Kit va substituir la sobrecàrrega de Python/C++ amb codi C# net que tothom a l’equip ja sap com escriure i depurar. El patró no és complicat un cop el veieu, i és un gran exemple de Native AOT resolent un problema real del qual no es parla prou.

Llegiu la publicació original al blog de .NET.

VS Code 1.117: Els agents s'estan guanyant les seves pròpies branques Git i això m'encanta

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

La línia entre “assistència IA” i “company de feina IA” cada cop és més fina. VS Code 1.117 acaba d’arribar i les notes completes de la versió venen carregades, però el missatge és clar: els agents s’estan convertint en ciutadans de primera classe del teu flux de treball de desenvolupament.

Això és el que realment importa.

El mode Autopilot finalment recorda la teva preferència

Abans, havies de reactivar Autopilot cada vegada que començaves una sessió nova. Molest. Ara el teu mode de permisos es manté entre sessions i pots configurar el valor per defecte.

L’Agent Host admet tres configuracions de sessió:

Per defecte — les eines demanen confirmació abans d’executar-se
Bypass — aprova automàticament tot
Autopilot — totalment autònom, respon les seves pròpies preguntes i continua fins que la tasca s’acaba

Si estàs preparant un projecte .NET nou amb migracions, Docker i CI, configura-ho una vegada en mode Autopilot i oblida-t’en. Aquesta preferència es manté.

Aïllament de worktree i Git per a sessions d’agents

Aquesta és la gran novetat. Les sessions d’agents ara admeten un aïllament complet de worktree i Git. Això vol dir que, quan un agent treballa en una tasca, obté la seva pròpia branca i el seu propi directori de treball. La teva branca principal queda intacta.

I encara millor: Copilot CLI genera noms de branca significatius per a aquestes sessions de worktree. Res de agent-session-abc123. Obtens alguna cosa que realment descriu el que l’agent està fent.

Per als desenvolupadors .NET que treballen amb diverses branques de funcionalitat o arreglen errors mentre corre una tasca llarga d’esqueletatge de projecte, això canvia les regles del joc. Pots tenir un agent construint els controladors de l’API en un worktree mentre tu depures un problema a la capa de serveis en un altre. Sense conflictes. Sense stash. Sense embolics.

Subagents i equips d’agents

El protocol Agent Host ara admet subagents. Un agent pot engegar altres agents per encarregar-los parts d’una tasca. Pensa-ho com delegar: el teu agent principal coordina i els agents especialitzats fan les peces concretes.

Això encara és una funcionalitat inicial, però el potencial per als fluxos de treball .NET és evident. Imagina un agent gestionant les teves migracions d’EF Core mentre un altre prepara els tests d’integració. Encara no hi som del tot, però el suport al protocol que arriba ara farà que les eines segueixin ràpidament.

La sortida del terminal s’inclou automàticament quan els agents envien entrada

Petita, però important. Quan un agent envia entrada al terminal, la sortida del terminal s’inclou automàticament al context. Abans, l’agent havia de fer un torn extra només per llegir què havia passat.

Si mai has vist un agent executar dotnet build, fallar i després fer una altra ronda només per llegir l’error, aquesta fricció desapareix. Ho veu de seguida i reacciona.

L’app d’Agents s’actualitza sola a macOS

L’aplicació d’Agents independent per a macOS ara s’actualitza sola. Ja no cal descarregar noves versions manualment. Simplement es manté al dia.

El que val la pena saber de la resta

Els hovers de package.json ara mostren tant la versió instal·lada com la més recent. Útil si gestiones eines npm al costat dels teus projectes .NET.
Les imatges als comentaris JSDoc es renderitzen correctament als hovers i a les completes.
Les sessions de Copilot CLI ara indiquen si s’han creat des de VS Code o externament, cosa útil quan saltes entre terminals.
Copilot CLI, Claude Code i Gemini CLI es reconeixen com a tipus de shell. L’editor sap què estàs executant.

La conclusió

VS Code 1.117 no és un llançament ple de funcions espectaculars. És infraestructura. L’aïllament de worktrees, els permisos persistents i els protocols de subagents són els blocs de construcció d’un flux de treball on els agents gestionen tasques reals en paral·lel sense trepitjar-se el codi.

Si estàs construint amb .NET i encara no t’has llançat al flux de treball agentic, sincerament, ara és el moment de començar.

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.

Deixeu de fer de cangur al vostre terminal: el mode desconnectat d'Aspire canvia el flux de treball

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

Cada vegada que executeu un Aspire AppHost, el vostre terminal desapareixerà. Tancat. Ocupat fins que en feu Ctrl+C. Necessites executar una comanda ràpida? Obre una altra pestanya. Voleu comprovar els registres? Una altra pestanya. És una petita fricció que s’acumula ràpidament.

Aspire 13.2 soluciona això. James Newton-King va escriure tots els detalls, i sincerament, aquesta és una d’aquestes característiques que canvia immediatament la manera de treballar.

Mode desconnectat: una comanda, terminal enrere

aspire start

Aquesta és l’abreviatura de aspire run --detach. El vostre AppHost s’inicia en segon pla i recupereu el terminal immediatament. Sense pestanyes addicionals. Sense multiplexor de terminals. Només la teva indicació, llest per començar.

Gestionant el que s’està executant

Aquesta és la qüestió: executar-se en segon pla només és útil si realment podeu gestionar el que hi ha. Aspire 13.2 ofereix un conjunt complet d’ordres CLI per exactament això:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Això converteix l’Aspire CLI en un gestor de processos adequat. Podeu iniciar diversos AppHosts, comprovar el seu estat, seguir els seus registres i tancar-los, tot des d’una única sessió de terminal.

Combina-ho amb el mode aïllat

El mode separat es combina de manera natural amb el mode aïllat. Voleu executar dues instàncies del mateix projecte en segon pla sense conflictes de ports?

aspire start --isolated
aspire start --isolated

Cadascun obté ports aleatoris, secrets separats i el seu propi cicle de vida. Utilitzeu aspire ps per veure tots dos, aspire stop per matar el que hàgiu acabat.

Per què això és enorme per als agents de codificació

Aquí és on es posa realment interessant. Un agent de codificació que treballa al vostre terminal ara pot:

Inicieu l’aplicació amb aspire start
Consulta el seu estat amb aspire describe
Comproveu els registres amb aspire logs per diagnosticar problemes
Atureu-ho amb aspire stop quan estigui acabat

Tot sense perdre la sessió del terminal. Abans del mode desconnectat, un agent que executava el vostre AppHost es bloquejaria fora del seu propi terminal. Ara pot començar, observar, iterar i netejar, exactament com voldríeu que funcionés un agent autònom.

L’equip d’Aspire es va inclinar en això. L’execució de aspire agent init configura un fitxer d’habilitats d’Aspire que ensenya als agents aquestes ordres. Així, eines com l’agent de codificació de Copilot poden gestionar les vostres càrregues de treball d’Aspire des de la caixa.

Tancant

El mode desconnectat és una actualització del flux de treball disfressada com una simple bandera. Atureu el canvi de context entre terminals, els agents deixen de bloquejar-se i les noves ordres CLI us ofereixen una visibilitat real del que s’està executant. És pràctic, és net i fa que el cicle de desenvolupament diari sigui notablement més suau.

Llegiu la publicació completa per obtenir tots els detalls i agafeu Aspire 13.2 amb aspire update --self.

Docker Sandbox permet als agents Copilot refactoritzar el vostre codi sense posar en risc la vostra màquina

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

Si heu utilitzat el mode d’agent de Copilot per a qualsevol cosa més enllà de petites edicions, coneixeu el dolor. Cada escriptura de fitxers, cada ordre del terminal: un altre indicador de permís. Ara imagineu-ho fent servir 50 projectes. No és divertit.

L’equip d’Azure acaba de publicar una publicació sobre Docker Sandbox for GitHub Copilot agents, i sincerament, aquesta és una de les millores d’eines d’agents més pràctiques que he vist. Utilitza microVMs per oferir a Copilot un entorn totalment aïllat on es pot desenredar: instal·lar paquets, executar compilacions, executar proves, sense tocar el vostre sistema amfitrió.

Què us ofereix realment Docker Sandbox

La idea bàsica és senzilla: engegueu una microVM lleugera amb un entorn Linux complet, sincronitzeu-hi el vostre espai de treball i deixeu que l’agent Copilot operi lliurement a l’interior. Quan s’hagi acabat, torna a canviar la sincronització.

Això és el que fa que sigui més que “executar coses en un contenidor”:

Sincronització bidireccional de l’espai de treball que conserva camins absoluts. L’estructura del vostre projecte sembla idèntica dins del sandbox. No hi ha errors de compilació relacionats amb el camí.
Dimoni Docker privat que s’executa dins de la microVM. L’agent pot construir i executar contenidors sense muntar mai el sòcol Docker del vostre host. Això és un gran problema per a la seguretat.
Proxis de filtratge HTTP/HTTPS que controlen a què pot arribar l’agent a la xarxa. Tu decideixes quins registres i punts finals es permeten. Atacs a la cadena de subministrament d’un canalla npm install dins del sandbox? Bloquejat.
Mode YOLO — sí, així l’anomenen. L’agent s’executa sense sol·licituds de permís perquè literalment no pot danyar el vostre amfitrió. Tota acció destructiva està continguda.

Per què els desenvolupadors.NET haurien de preocupar-se

Penseu en el treball de modernització que tants equips s’enfronten ara mateix. Teniu una solució.NET Framework amb 30 projectes i l’heu de traslladar a.NET 9. Això són centenars de canvis de fitxers: fitxers de projecte, actualitzacions d’espais de noms, substitucions d’API, migracions NuGet.

Amb Docker Sandbox, podeu apuntar un agent Copilot a un projecte, deixar-lo refactoritzar lliurement dins de la microVM, executar dotnet build i dotnet test per validar i acceptar només els canvis que funcionen realment. No hi ha cap risc que accidentalment destrueixi el vostre entorn de desenvolupament local mentre experimenteu.

La publicació també descriu l’execució d’una flota d’agents paral·lels, cadascun en el seu propi sandbox, abordant diferents projectes simultàniament. Per a grans solucions.NET o arquitectures de microserveis, això suposa un estalvi de temps enorme. Un agent per servei, tots en funcionament aïllat, tots validats de manera independent.

L’angle de seguretat és important

Això és el que la majoria de la gent passa per alt: quan deixeu que un agent d’IA executi ordres arbitràries, hi confieu amb tota la vostra màquina. Docker Sandbox canvia aquest model. L’agent obté total autonomia dins d’un entorn d’ús. El servidor intermediari de xarxa garanteix que només es pot extreure de fonts aprovades. El vostre sistema de fitxers amfitrió, el dimoni Docker i les credencials no es toquen.

Per als equips amb requisits de compliment, i això és la majoria de les botigues.NET empresarials, aquesta és la diferència entre “no podem utilitzar IA agència” i “podem adoptar-la de manera segura”.

Per emportar

Docker Sandbox resol la tensió fonamental de la codificació agentica: els agents necessiten llibertat per ser útils, però la llibertat a la vostra màquina amfitriona és perillosa. Les microVM us ofereixen tots dos. Si esteu planejant qualsevol refactorització o modernització de.NET a gran escala, val la pena configurar-la ara. La combinació de la intel·ligència de codi de Copilot amb un entorn d’execució segur és exactament el que els equips de producció estaven esperant.

El clúster de pins finalment arriba als mapes.NET MAUI: una propietat, zero dolor

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

Coneixes aquell moment en què carregues un mapa amb cent agulles i tot es converteix en una taca il·legible? Sí, aquesta ha estat l’experiència de.NET MAUI Maps fins ara. No més.

David Ortinau acaba d’anunciar que.NET MAUI 11 Preview 3 inclou pins agrupats fora de la caixa a Android i iOS/Mac Catalyst. I la millor part: activar-lo és ridículament senzill.

Una propietat per governar-les totes

<maps:Map IsClusteringEnabled="True" />

Això és tot. Els pins propers s’agrupen en grups amb una insígnia de recompte. Apropa i s’amplien. Allunya el zoom i es col·lapsen. El tipus de comportament que els usuaris esperen de qualsevol mapa modern, i ara ho obteniu amb una única propietat.

Grups de agrupació independents

Aquí és on es posa interessant. No tots els pins s’han d’agrupar. Les cafeteries i els parcs són coses diferents, i el vostre mapa ho hauria de saber.

La propietat ClusteringIdentifier us permet separar els pins en grups independents:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Pins amb el mateix grup d’identificadors junts. Els diferents identificadors formen clústers independents fins i tot quan estan geogràficament propers. Sense identificador? Grup per defecte. Net i previsible.

Gestió de les aixetes de clúster

Quan un usuari toca un clúster, obteniu un esdeveniment ClusterClicked amb tot el que necessiteu:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Els arguments de l’esdeveniment us proporcionen Pins (els pins del clúster), Location (el centre geogràfic) i Handled (establert a true si voleu anul·lar el zoom predeterminat). Senzill, pràctic, exactament el que esperaries.

Val la pena conèixer els detalls de la plataforma

A Android, la agrupació en clúster utilitza un algorisme personalitzat basat en quadrícula que recalcula els canvis de zoom, sense dependències externes. A iOS i Mac Catalyst, aprofita el suport natiu MKClusterAnnotation de MapKit, que significa animacions fluides i natives de la plataforma.

Aquest és un d’aquests casos en què l’equip de MAUI va fer la trucada correcta: recolzeu-vos a la plataforma on tingui sentit.

Per què això és important

La agrupació de pins ha estat una de les funcions més sol·licitades a.NET MAUI (issue #11811), i per una bona raó. Tota aplicació que mostra ubicacions en un mapa (seguiment de lliurament, localitzadors de botigues, béns immobles) ho necessita. Anteriorment, havíeu de crear-lo vosaltres mateixos o treure una biblioteca de tercers. Ara està incorporat.

Per als desenvolupadors de.NET que creem aplicacions mòbils multiplataforma, aquest és el tipus de millora de la qualitat de vida que fa que MAUI sigui una opció realment pràctica per a escenaris amb mapes pesats.

Comença

Instal·leu .NET 11 Preview 3 i actualitzeu la càrrega de treball.NET MAUI. La mostra de mapes inclou una nova pàgina de clúster amb la qual podeu jugar immediatament.

Aneu a construir alguna cosa amb ell i deixeu que els vostres mapes finalment respiren.

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.

Manteniment de.NET d'abril de 2026: pegats de seguretat que hauríeu d'aplicar avui

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

Les actualitzacions de servei d’abril de 2026 per a.NET i.NET Framework ja estan fora, i aquesta inclou solucions de seguretat que voldreu aplicar aviat. Sis CVE pegats, incloses dues vulnerabilitats d’execució de codi remota (RCE).

Què està pegat

Aquí teniu el resum ràpid:

CVE	Tipus	Afecta
CVE-2026-26171	Bypass de les funcions de seguretat	.NET 10, 9, 8 +.NET Framework
CVE-2026-32178	Execució de codi remota	.NET 10, 9, 8 +.NET Framework
CVE-2026-33116	Execució de codi remota	.NET 10, 9 i 8
CVE-2026-32203	Denegació de servei	.NET 10, 9, 8 +.NET Framework
CVE-2026-23666	Denegació de servei	.NET Framework 3.0–4.8.1
CVE-2026-32226	Denegació de servei	.NET Framework 2.0–4.8.1

Els dos CVE RCE (CVE-2026-32178 i CVE-2026-33116) afecten la gamma més àmplia de versions.NET i haurien de ser la prioritat.

Versions actualitzades

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Tots estan disponibles a través dels canals habituals: dotnet.microsoft.com, imatges de contenidors a MCR i gestors de paquets de Linux.

Què fer

Actualitzeu els vostres projectes i pipelines CI/CD a les últimes versions de pedaços. Si utilitzeu contenidors, traieu les imatges més recents. Si esteu a.NET Framework, consulteu les Notes de la versió de.NET Framework per trobar els pedaços corresponents.

Per a aquells que executen.NET 10 en producció (és la versió actual), 10.0.6 és una actualització obligatòria. El mateix per a.NET 9.0.15 i.NET 8.0.26 si esteu en aquestes pistes LTS. Dues vulnerabilitats RCE no són una cosa que posposeu.

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.

Servidor Azure DevOps d'abril de 2026: correcció de finalització de relacions públiques i actualitzacions de seguretat

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

Informació ràpida per als equips que executen Azure DevOps Server: Microsoft va llançar el pegat 3 per a l’abril de 2026 amb tres solucions específiques.

Què s’ha solucionat

Errores de finalització de la sol·licitud d’extracció: una excepció de referència nul·la durant la compleció automàtica d’elements de treball podria provocar que les combinacions de PR fallin. Si heu trobat errors de finalització de PR aleatòries, és probable que aquesta sigui la causa
Validació de la redirecció de tancament de la sessió: validació millorada durant la tancament de la sessió per evitar possibles redireccions malicioses. Aquesta és una solució de seguretat que val la pena aplicar ràpidament
Connexions PAT del servidor GitHub Enterprise: la creació de connexions de testimoni d’accés personal al servidor GitHub Enterprise es va trencar, ara s’ha restaurat

Com actualitzar

Baixeu Pedaç 3 i executeu l’instal·lador. Per verificar que s’ha aplicat el pegat:

<patch-installer>.exe CheckInstall

Si esteu executant Azure DevOps Server localment, Microsoft us recomana fermament mantenir-vos en l’últim pedaç tant per seguretat com per fiabilitat. Consulteu les notes de la versió per a tots els detalls.

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.

.NET Aspire 13.2 vol ser el millor amic del vostre agent d'IA

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

Coneixeu aquell moment en què el vostre agent de codificació d’IA escriu un codi sòlid, us emocioneu i després es desfà completament intentant executar la cosa? Conflictes de ports, processos fantasma, variables d’entorn incorrectes: de sobte, el vostre agent està cremant fitxes per resoldre problemes d’inici en lloc de crear funcions.

L’equip d’Aspire acaba de publicar una publicació molt atenta sobre exactament aquest problema, i la seva resposta és convincent: Aspire 13.2 està dissenyat no només per a humans, sinó per a agents d’IA.

El problema és real

Els agents d’IA són increïbles per escriure codi. Però enviar una aplicació de pila completa que funcioni implica molt més que generar fitxers. Heu d’iniciar els serveis en l’ordre correcte, gestionar ports, establir variables d’entorn, connectar bases de dades i obtenir comentaris quan les coses es trenquin. Ara mateix, la majoria d’agents gestionen tot això mitjançant prova i error: executant ordres, llegint la sortida d’error, tornant-ho a provar.

Superposem instruccions de Markdown, habilitats personalitzades i indicacions per intentar guiar-les, però són imprevisibles, no es poden compilar i costen fitxes només per analitzar-les. L’equip d’Aspire va clavar la visió bàsica: els agents necessiten compiladors i API estructurades, no més Markdown.

Aspira com a infraestructura d’agents

Això és el que aporta Aspire 13.2 a la taula de desenvolupament agent:

La vostra pila sencera en codi escrit. L’AppHost defineix la vostra topologia completa: API, frontend, base de dades, memòria cau, en TypeScript o C# compilable:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agent pot llegir-ho per entendre la topologia de l’aplicació, afegir recursos, connectar connexions i crear per verificar. El compilador li indica immediatament si alguna cosa no funciona. Sense endevinar, sense prova i error amb fitxers de configuració.

Una comanda per governar-los tots. En lloc d’agents que fan malabars amb docker compose up, npm run dev i scripts d’inici de bases de dades, tot és només aspire start. Tots els recursos s’inicien en l’ordre correcte, als ports adequats, amb la configuració correcta. Els processos de llarga durada tampoc pengen l’agent: Aspire els gestiona.

Mode aïllat per a agents paral·lels. Amb --isolated, cada execució d’Aspire té els seus propis ports aleatoris i secrets d’usuari separats. Hi ha diversos agents treballant en els arbres de treball de git? No xocaran. Això és enorme per a eines com els agents de fons de VS Code que fan girar entorns paral·lels.

Ulls d’agent a través de la telemetria. Aquí és on es fa realment potent. L’Aspire CLI exposa dades completes d’OpenTelemetry durant el desenvolupament: traces, mètriques, registres estructurats. El vostre agent no només llegeix la sortida de la consola i espera el millor. Pot rastrejar una sol·licitud fallida entre serveis, perfilar punts finals lents i identificar exactament on es trenquen les coses. Això és observabilitat de grau de producció en el bucle de desenvolupament.

L’analogia del para-xocs de bitlles

L’equip d’Aspire utilitza una gran analogia: penseu en Aspire com a para-xocs de la pista de bitlles per als agents d’IA. Si l’agent no és perfecte (i no ho serà), els para-xocs eviten que llanci boles de canaló. La definició de pila evita la configuració incorrecta, el compilador detecta errors, la CLI gestiona la gestió del procés i la telemetria proporciona el bucle de retroalimentació.

Combineu-ho amb alguna cosa com Playwright CLI i el vostre agent pot utilitzar la vostra aplicació: fent clic a través dels fluxos, comprovant el DOM, veient coses trencades a la telemetria, arreglant el codi, reiniciant i provant de nou. Construir, executar, observar, arreglar. Aquest és el bucle de desenvolupament autònom que hem estat perseguint.

Primers passos

Nou a Aspire? Instal·leu la CLI des de get.aspire.dev i seguiu la guia d’inici.

Ja fas servir Aspire? Executeu aspire update --self per obtenir 13.2 i, a continuació, indiqueu el vostre agent de codificació preferit al vostre repositori. Potser us sorprendrà quant s’avança amb les baranes d’Aspire al seu lloc.

Tancant

Aspire 13.2 ja no és només un marc d’aplicacions distribuïdes, sinó que s’està convertint en una infraestructura d’agent essencial. Les definicions de pila estructurades, l’inici d’un sol comandament, les execucions paral·leles aïllades i la telemetria en temps real ofereixen als agents d’IA exactament el que necessiten per passar d’escriure codi a enviar aplicacions.

Llegiu la publicació completa de l’equip d’Aspire per veure tots els detalls i vídeos de demostració.

Aquella configuració de Windows flotant de Visual Studio que no sabíeu (però hauríeu)

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

Si utilitzeu diversos monitors amb Visual Studio (i sincerament, qui no ho fa en aquests dies), probablement heu experimentat la molèstia: les finestres d’eines flotants desapareixen quan minimitzeu l’IDE principal, sempre es mantenen al capdavant de tota la resta i no apareixen com a botons separats de la barra de tasques. Funciona per a alguns fluxos de treball, però per a configuracions de diversos monitors és frustrant.

Mads Kristensen de l’equip de Visual Studio ha compartit una configuració poc coneguda que canvia completament el comportament de les finestres flotants. Un desplegable. Això és tot.

La configuració

Eines > Opcions > Entorn > Windows > Finestres flotants

El menú desplegable “Aquestes finestres flotants són propietat de la finestra principal” té tres opcions:

Cap — total independència. Cada finestra flotant té la seva pròpia entrada a la barra de tasques i es comporta com una finestra normal de Windows.
Tool Windows (per defecte): els documents floten lliurement, les finestres d’eines es mantenen lligades a l’IDE.
Finestres de documents i eines: comportament clàssic de Visual Studio, tot lligat a la finestra principal.

Per què “Cap” és el moviment per a les configuracions de diversos monitors

Estableix-lo a Cap i, de sobte, totes les teves finestres i documents d’eines flotants es comporten com aplicacions de Windows reals. Apareixen a la barra de tasques, es mantenen visibles quan minimitzeu la finestra principal de Visual Studio i deixen de forçar-se al davant de tot.

Combineu-ho amb PowerToys FancyZones i és un canvi de joc. Creeu dissenys personalitzats als vostres monitors, col·loqueu el vostre Explorador de solucions a una zona, depureu a una altra i codifiqueu fitxers allà on vulgueu. Tot es manté, tot és accessible de manera independent i el vostre espai de treball se sent organitzat en lloc de caòtic.

Recomanacions ràpides

Usuaris avançats amb monitors múltiples: s’estableix en Cap, s’acobla amb FancyZones
Flotants ocasionals: Tool Windows (per defecte) és un sòlid terme mitjà
Flux de treball tradicional: Documents i Windows Tool manté tot el clàssic

Consell professional: Ctrl + feu doble clic a la barra de títol de qualsevol finestra d’eina per flotar o acoblar-la a l’instant. No cal reiniciar després de canviar la configuració.

Tancant

És una d’aquestes configuracions “No em puc creure que no sabia sobre això”. Si alguna vegada les finestres flotants a Visual Studio us han molestat, aneu a canviar-ho ara mateix.

Llegiu la publicació completa per obtenir els detalls i les captures de pantalla.

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.

El mode aïllat d'Aspire soluciona el malson del conflicte del port per al desenvolupament paral·lel

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

Si alguna vegada has provat d’executar dues instàncies del mateix projecte al mateix temps, saps el dolor. El port 8080 ja està en ús. S’ha pres el port 17370. Matar alguna cosa, reiniciar, fer malabars amb les variables d’entorn: és un assassí de la productivitat.

Aquest problema empitjora, no millora. Els agents d’IA creen arbres de treball git per treballar de manera independent. Els agents de fons generen entorns separats. Els desenvolupadors comproven el mateix repositori dues vegades per a les branques de funcions. Cadascun d’aquests escenaris toca el mateix mur: dues instàncies de la mateixa aplicació lluitant pels mateixos ports.

Aspire 13.2 soluciona això amb una sola bandera. James Newton-King de l’equip d’Aspire va escriure tots els detalls, i és una d’aquestes característiques de “per què no vam tenir això abans”.

La correcció: `--isolated`

aspire run --isolated

Això és tot. Cada cursa obté:

Ports aleatoris: no hi ha més col·lisions entre instàncies
Secrets d’usuari aïllats: les cadenes de connexió i les claus API es mantenen separades per instància

No hi ha reasignació manual del port. Sense malabars amb variables d’entorn. Cada cursa obté un entorn fresc i lliure de col·lisions automàticament.

Escenaris reals on això brilla

Múltiples pagaments. Tens una branca de funcions en un directori i una correcció d’errors en un altre:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Tots dos funcionen sense conflictes. El tauler mostra què s’està executant i on.

Agents de fons a VS Code. Quan l’agent de fons de Copilot Chat crea un arbre de treball git per treballar amb el vostre codi de manera independent, pot ser que hagi d’executar l’Aspire AppHost. Sense --isolated, això és una col·lisió de port amb el vostre arbre de treball principal. Amb ell, ambdues instàncies només funcionen.

L’habilitat d’Aspire que s’envia amb aspire agent init indica automàticament als agents que utilitzin --isolated quan treballen en arbres de treball. Per tant, l’agent de fons de Copilot hauria de gestionar-ho des de la caixa.

Proves d’integració juntament amb el desenvolupament. Necessites fer proves amb un AppHost en directe mentre continues creant funcions? El mode aïllat dóna a cada context els seus propis ports i configuració.

Com funciona sota el capó

Quan passeu --isolated, la CLI genera un ID d’instància únic per a l’execució. Això provoca dos comportaments:

Aleatoria de ports: en lloc d’unir-se a ports previsibles definits a la configuració de l’AppHost, el mode aïllat tria els ports disponibles aleatòriament per a tot: el tauler de control, els punts finals del servei, tot això. El descobriment de serveis s’ajusta automàticament, de manera que els serveis es troben entre ells independentment dels ports on aterren.
Aïllament secret: cada execució aïllada obté el seu propi magatzem de secrets d’usuari, clau per l’ID de la instància. Les cadenes de connexió i les claus API d’una execució no es filtren a una altra.

El vostre codi no necessita cap canvi. El descobriment de serveis d’Aspire resol els punts finals en temps d’execució, de manera que tot es connecta correctament independentment de l’assignació del port.

Quan utilitzar-lo

Utilitzeu --isolated quan executeu diverses instàncies del mateix AppHost simultàniament, tant si es tracta de desenvolupament paral·lel, proves automatitzades, agents d’IA o arbres de treball de git. Per al desenvolupament d’una sola instància on preferiu ports previsibles, aspire run normal encara funciona bé.

Tancant

El mode aïllat és una petita característica que resol un problema real i cada cop més comú. A mesura que el desenvolupament assistit per IA ens empeny cap a fluxos de treball més paral·lels (múltiples agents, múltiples arbres de treball, múltiples contextos), la capacitat de fer girar una altra instància sense lluitar pels ports és essencial.

Llegiu la publicació completa per obtenir tots els detalls tècnics i proveu-ho amb aspire update --self per obtenir 13.2.

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.

Les aplicacions MCP obtenen una API fluida: creeu interfícies d'usuari d'eines d'IA rica a.NET amb tres passos

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

Les eines MCP són excel·lents per oferir capacitats als agents d’IA. Però, què passa si la vostra eina ha de mostrar alguna cosa a l’usuari: un tauler, un formulari, una visualització interactiva? Aquí és on entren les aplicacions MCP i són molt més fàcils de crear.

Lilian Kasem de l’equip de l’SDK d’Azure va presentar la nova API de configuració fluida per a les aplicacions MCP a.NET Azure Functions, i és el tipus de millora de l’experiència dels desenvolupadors que us fa preguntar-vos per què no sempre va ser tan senzill.

Què són les aplicacions MCP?

Les aplicacions MCP amplien el protocol de context del model deixant que les eines portin les seves pròpies vistes d’interfície d’usuari, actius estàtics i controls de seguretat. En lloc de només retornar text, la vostra eina MCP pot representar experiències HTML completes (taulers interactius, visualitzacions de dades, formularis de configuració), tot això invocable pels agents d’IA i presentat als usuaris pels clients MCP.

El problema va ser que el cablejat de tot això manualment requeria conèixer íntimament les especificacions MCP: ui:// URI, tipus de mime especials, coordinació de metadades entre eines i recursos. No és difícil, però complicat.

L’API fluida en tres passos

Pas 1: defineix la teva funció. Només una eina MCP estàndard d’Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Pas 2: promocioneu-lo a una aplicació MCP. A l’inici del vostre programa:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Pas 3: afegiu la vostra vista HTML. Creeu assets/hello-app.html amb la interfície d’usuari que necessiteu.

Això és tot. L’API fluida gestiona tota la fontaneria d’especificacions MCP: genera la funció de recursos sintètics, estableix el tipus de mime correcte, injecta les metadades que connecten l’eina a la seva vista.

La superfície de l’API està ben dissenyada

Algunes coses que m’agraden molt:

Les fonts de visualització són flexibles. Podeu publicar HTML des de fitxers al disc o inserir recursos directament al vostre conjunt per a desplegaments autònoms:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP es pot redactar. Llista de permisos explícita que els orígens de la teva aplicació necessita, seguint els principis de privilegis mínims. Truqueu a WithCsp diverses vegades i els orígens s’acumulen:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Control de visibilitat. Podeu fer que una eina només sigui visible per al LLM, només per a la interfície d’usuari de l’amfitrió o ambdues. Voleu una eina que només representi la interfície d’usuari i que el model no l’hagi de cridar? Fàcil:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Primers passos

Afegeix el paquet de previsualització:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Si ja esteu creant eines MCP amb Azure Functions, això és només una actualització del paquet. El inici ràpid de les aplicacions MCP és el millor lloc per començar si sou nou al concepte.

Tancant

Les aplicacions MCP són un dels desenvolupaments més interessants de l’espai d’eines d’IA: eines que no només * fan coses * sinó que poden * mostrar coses * als usuaris. L’API fluida elimina la complexitat del protocol i us permet centrar-vos en allò que importa: la lògica de l’eina i la seva interfície d’usuari.

Llegiu la publicació completa per obtenir la referència completa de l’API i els exemples.

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.

VS Code 1.116: l'aplicació d'agents obté la navegació per teclat i la finalització del context dels fitxers

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

VS Code 1.116 és la versió d’abril de 2026 i, tot i que és més lleuger que algunes actualitzacions recents, els canvis són enfocats i significatius, sobretot si feu servir l’aplicació Agents diàriament.

Aquí teniu el que va arribar, basat en les notes oficials de la versió.

Millores de l’aplicació d’agents

L’aplicació Agents continua madurant amb un poliment d’usabilitat que marca una diferència real en els fluxos de treball diaris:

Combinacions de tecles dedicades: ara podeu centrar la vista Canvis, l’arbre de fitxers dins de Canvis i la vista Personalitzacions de xat amb ordres dedicades i dreceres de teclat. Si heu fet clic per l’aplicació Agents per navegar, això ofereix fluxos de treball complets basats en el teclat.

Diàleg d’ajuda d’accessibilitat: prement Alt+F1 al quadre d’entrada del xat ara s’obre un diàleg d’ajuda d’accessibilitat que mostra les ordres i les combinacions de tecles disponibles. Els usuaris de lectors de pantalla també poden controlar la verbositat dels anuncis. Una bona accessibilitat beneficia a tothom.

Completacions de context de fitxer: escriviu # al xat de l’aplicació Agents per activar les finalitzacions de context de fitxer a l’abast del vostre espai de treball actual. Aquesta és una d’aquelles petites millores de qualitat de vida que acceleren cada interacció; ja no cal escriure els camins complets dels fitxers quan es fa referència al codi.

CSS `@import` resolució d’enllaç

Una bona per als desenvolupadors d’interfície: ara VS Code resol les referències CSS @import que utilitzen camins node_modules. Podeu Ctrl+click mitjançant importacions com @import "some-module/style.css" quan utilitzeu agrupadors. Petit però elimina un punt de fricció en els fluxos de treball CSS.

Tancant

VS Code 1.116 tracta de perfeccionament, fent que l’aplicació Agents sigui més navegable, més accessible i més amigable amb el teclat. Si passeu molt de temps a l’aplicació Agents (i sospito que molts de nosaltres ho estem), aquests canvis s’acumulen.

Consulteu les notes completes de la versió per obtenir la llista completa.

VS Code 1.115: notificacions de terminal en segon pla, mode d'agent SSH i més

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 acaba de sortir i, tot i que és una versió més lleugera pel que fa a les funcions de titular, les millores relacionades amb l’agent són realment útils si treballeu amb assistents de codificació d’IA diàriament.

Permeteu-me destacar el que realment val la pena saber.

Els terminals de fons parlen amb els agents

Aquesta és la característica destacada. Els terminals de fons ara notifiquen automàticament als agents quan es completen les ordres, inclòs el codi de sortida i la sortida del terminal. Les sol·licituds d’entrada als terminals de fons també es detecten i s’envien a l’usuari.

Per què importa això? Si heu utilitzat el mode d’agent de Copilot per executar ordres de compilació o suites de proves en segon pla, coneixeu el dolor de “Ja s’ha acabat?” — Els terminals de fons eren essencialment de foc i oblidar. Ara l’agent rep una notificació quan el vostre dotnet build o dotnet test s’acabi, veu la sortida i pot reaccionar en conseqüència. És un petit canvi que fa que els fluxos de treball impulsats per agents siguin significativament més fiables.

També hi ha una nova eina send_to_terminal que permet als agents enviar ordres a terminals en segon pla amb la confirmació de l’usuari, solucionant el problema en què run_in_terminal amb un temps d’espera traslladaria els terminals a segon pla i els faria només de lectura.

Allotjament d’agent remot SSH

VS Code ara admet la connexió a màquines remotes mitjançant SSH, instal·lant automàticament la CLI i iniciant-la en mode d’amfitrió de l’agent. Això significa que les vostres sessions d’agent d’IA poden orientar-se directament a entorns remots, cosa que és útil per als desenvolupadors de.NET que creen i proveu en servidors Linux o màquines virtuals en núvol.

Edita el seguiment a les sessions d’agent

Les edicions de fitxers fetes durant les sessions de l’agent ara es fan un seguiment i es restauren, amb diferències, desfer/refer i restauració de l’estat. Si un agent fa canvis al vostre codi i alguna cosa va malament, podeu veure exactament què ha canviat i revertir-lo. Tranquil·litat per deixar que els agents modifiquin la vostra base de codi.

Coneixement de la pestanya del navegador i altres millores

Algunes addicions més de qualitat de vida:

Seguiment de pestanyes del navegador: ara el xat pot fer un seguiment i enllaçar amb les pestanyes del navegador obertes durant una sessió, de manera que els agents poden fer referència a les pàgines web que esteu mirant
Fitxer enganxat al terminal: enganxeu fitxers (incloses les imatges) al terminal amb Ctrl+V, arrossegueu i deixeu anar o feu clic amb el botó dret.
Cobertura de prova al minimapa: ara els indicadors de cobertura de prova es mostren al minimapa per obtenir una visió visual ràpida
Pinch-to-zoom a Mac: el navegador integrat admet gestos de pessigar-to-zoom
Drets de Copilot a Sessions: la barra d’estat mostra la informació d’ús a la vista Sessions
Favicon a Anar al fitxer: les pàgines web obertes mostren favicons a la llista de selecció ràpida

Tancant

VS Code 1.115 és una versió incremental, però les millores de l’agent (notificacions de terminal en segon pla, allotjament d’agents SSH i seguiment d’edició) afegeixen una experiència notablement més fluida per al desenvolupament assistit per IA. Si utilitzeu el mode d’agent de Copilot per a projectes.NET, aquests són els tipus de correccions de qualitat de vida que redueixen la fricció diàriament.

Consulteu les notes completes de la versió per a cada detall.

C# 15 obté tipus d'unió, i són exactament el que hem estat demanant

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

Aquest és el que estava esperant. C# 15 introdueix la paraula clau union: unions discriminades adequades amb una concordança exhaustiva de patrons forçada pel compilador. Si alguna vegada has envejat els sindicats discriminats de F# o les enumeracions de Rust, saps exactament per què això importa.

Bill Wagner va publicar la immersió profunda al bloc.NET, i sincerament? El disseny és net, pràctic i molt C#. Permeteu-me explicar-vos què hi ha realment aquí i per què és una cosa més gran del que pot semblar a primera vista.

El problema que resolen els sindicats

Abans de C# 15, retornar “un dels diversos tipus possibles” d’un mètode sempre era un compromís:

object — sense restriccions, sense ajuda del compilador, llançament defensiu a tot arreu
Interfícies de marcador: millor, però qualsevol pot implementar-les. El compilador mai pot considerar el conjunt complet
Classes base abstractes: el mateix problema, a més els tipus necessiten un avantpassat comú

Cap d’aquests us ofereix el que realment voleu: un conjunt tancat de tipus on el compilador garanteix que heu gestionat tots els casos. Això és el que fan els sindicats.

La sintaxi és molt senzilla

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Una línia. Pet pot contenir un Cat, un Dog o un Bird. Les conversions implícites es generen automàticament:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

I aquí està la màgia: el compilador imposa una concordança exhaustiva:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

No cal descartar _. El compilador sap que aquest commutador cobreix tots els casos possibles. Si més tard afegiu un quart tipus a la unió, cada expressió de commutació que no la gestioni produeix un avís. Casos que falten capturats en temps de compilació, no en temps d’execució.

On això es fa pràctic

L’exemple Pet és bonic, però aquí és on els sindicats realment brillen en codi real.

Respostes de l’API que retornen diferents formes

public union ApiResult<T>(T, ApiError, ValidationFailure);

Ara tots els consumidors es veuen obligats a gestionar l’èxit, l’error i el fracàs de validació. No hi ha més errors “m’he oblidat de comprovar el cas d’error”.

Valor únic o col·lecció

El patró OneOrMore<T> mostra com els sindicats poden tenir un cos amb mètodes auxiliars:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Les persones que trucen passen el formulari que sigui convenient:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Composició de tipus no relacionats

Aquesta és la característica assassina de les jerarquies tradicionals. Podeu unir tipus que no tenen res en comú: string i Exception, int i IEnumerable<T>. No es necessita cap avantpassat comú.

Unions personalitzades per a biblioteques existents

Aquí teniu una opció de disseny intel·ligent: qualsevol classe o estructura amb un atribut [Union] es reconeix com a tipus d’unió, sempre que segueixi el patró bàsic (constructors públics per a tipus de casos i una propietat Value). Les biblioteques com OneOf que ja proporcionen tipus d’unió poden optar al suport del compilador sense reescriure els seus elements interns.

Per a escenaris sensibles al rendiment amb tipus de valors, les biblioteques poden implementar un patró d’accés que no sigui boxing amb mètodes HasValue i TryGetValue.

La imatge més gran

Els tipus d’unió formen part d’una història d’exhaustivitat més àmplia que arriba a C#:

Tipus d’unió: concordança exhaustiva sobre un conjunt tancat de tipus (disponible ara a la vista prèvia)
Jerarquies tancades — El modificador closed impedeix classes derivades fora del conjunt definidor (proposat)
Enumeracions tancades: impedeix la creació de valors diferents dels membres declarats (proposat)

En conjunt, aquestes tres funcions donaran a C# un dels sistemes de concordança de patrons segurs de tipus més complets en qualsevol llenguatge convencional.

Prova-ho avui

Els tipus d’unió estan disponibles a.NET 11 Preview 2:

Instal·leu .NET 11 Preview SDK
Orienta net11.0 al teu projecte
Establiu <LangVersion>preview</LangVersion>

Una advertència: a la vista prèvia 2, haureu de declarar UnionAttribute i IUnion al vostre projecte, ja que encara no estan en temps d’execució. Agafeu RuntimePolyfill.cs del dipòsit de documents o afegiu això:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Tancant

Els tipus d’unió són una d’aquestes característiques que us fan preguntar-vos com ens ho hem passat sense ells. Coincidència exhaustiva forçada pel compilador, sintaxi neta, suport genèric i integració amb la concordança de patrons existents: és tot el que hem estat demanant, fet de la manera C#.

Proveu-los a.NET 11 Preview 2, trenca coses i compartiu els vostres comentaris a GitHub. Aquesta és una vista prèvia i l’equip de C# escolta activament. Els vostres casos de punta i els vostres comentaris sobre el disseny donaran forma a la versió final.

Per obtenir la referència completa de l’idioma, consulteu els documents de tipus unió i l’especificació de la funció.

Aspire 13.2 envia una CLI de Docs, i el vostre agent d'IA també la pot utilitzar

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

Coneixeu aquell moment en què esteu endinsat en un Aspire AppHost, connectant integracions i heu de comprovar exactament quins paràmetres espera la integració de Redis? Feu una pestanya alternativa al vostre navegador, busqueu aspire.dev, mireu els documents de l’API i torneu al vostre editor. Context perdut. Flux trencat.

Aspire 13.2 només ha enviat una solució per això. La CLI aspire docs us permet cercar, navegar i llegir la documentació oficial d’Aspire directament des del vostre terminal. I com que està recolzat per serveis reutilitzables, els agents i les habilitats d’IA poden utilitzar les mateixes ordres per buscar documents en lloc d’al·lucinar API que no existeixen.

El problema que això resol realment

David Pine ho clava a la publicació original: els agents d’IA van ser terribles per ajudar els desenvolupadors a crear aplicacions Aspire. Recomanarien dotnet run en lloc de aspire run, fer referència a learn.microsoft.com per als documents que viuen a aspire.dev, suggerir paquets NuGet obsolets i, el meu favorit personal, al·lucinar API que no existeixen.

Per què? Com que Aspire era específic de.NET molt més temps del que ha estat políglot, i els LLM treballen amb dades de formació anteriors a les últimes funcions. Quan doneu a un agent d’IA la possibilitat de buscar realment els documents actuals, deixa d’endevinar i comença a ser útil.

Tres ordres, zero pestanyes del navegador

La CLI és molt senzilla:

Llista tots els documents

aspire docs list

Retorna totes les pàgines de documentació disponibles a aspire.dev. Necessites una sortida llegible per màquina? Afegeix --format Json.

Cerca un tema

aspire docs search "redis"

Cerca tant títols com contingut amb una puntuació de rellevància ponderada. El mateix motor de cerca que impulsa l’eina de documentació internament. Obteniu resultats classificats amb títols, slugs i puntuacions de rellevància.

Llegeix una pàgina sencera (o només una secció)

aspire docs get redis-integration

Transmet la pàgina completa com a reducció al terminal. Necessites només una secció?

aspire docs get redis-integration --section "Add Redis resource"

Precisió quirúrgica. Sense desplaçament per 500 línies. Només la part que necessiteu.

L’angle de l’agent d’IA

Aquí és on és interessant per als desenvolupadors que construïm amb eines d’IA. Les mateixes ordres aspire docs funcionen com a eines per als agents d’IA, mitjançant habilitats, servidors MCP o embolcalls CLI senzills.

En comptes que el vostre assistent d’IA creï les API d’Aspire basades en dades d’entrenament obsoletes, pot trucar a aspire docs search "postgres", trobar els documents oficials d’integració, llegir la pàgina adequada i oferir-vos l’enfocament documentat. Documentació actual en temps real, no la que el model va memoritzar fa sis mesos.

L’arquitectura darrere d’això és intencionada. L’equip d’Aspire va crear serveis reutilitzables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) en lloc d’una integració única. Això vol dir que el mateix motor de cerca funciona per a humans al terminal, agents d’IA al vostre editor i automatització al vostre pipeline CI.

Escenaris del món real

Cerques ràpides del terminal: Teniu tres fitxers de profunditat i necessiteu paràmetres de configuració de Redis. Dues ordres, noranta segons, tornen a treballar:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Desenvolupament assistit per IA: la vostra habilitat VS Code inclou les ordres CLI. Demaneu “Afegeix una base de dades PostgreSQL al meu AppHost” i l’agent cerca els documents reals abans de respondre. Sense al·lucinacions.

Validació CI/CD: el vostre pipeline valida les configuracions d’AppHost amb la documentació oficial mitjançant programació. --format Json emet les canonades netament a jq i altres eines.

Bases de coneixement personalitzades: crear la teva pròpia eina d’IA? Introduïu la sortida JSON estructurada directament a la vostra base de coneixement:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Sense raspat web. No hi ha claus API. Les mateixes dades estructurades que les eines de documents utilitza internament.

La documentació sempre està en directe

Aquesta és la part que més agraeixo. La CLI no baixa cap instantània: consulta aspire.dev amb la memòria cau basada en ETag. En el moment en què s’actualitzen els documents, la vostra CLI i qualsevol habilitat incorporada al damunt ho reflecteixen. No hi ha còpies obsoletes, no “però el wiki va dir…” moments.

Tancant

aspire docs és una d’aquestes petites característiques que resol un problema real de manera neta. Els humans tenen accés a la documentació nativa del terminal. Els agents d’IA tenen una manera de deixar d’endevinar i començar a fer referència a documents reals. I tot està recolzat per la mateixa font de veritat.

Si esteu creant amb.NET Aspire i encara no heu provat la CLI, executeu aspire docs search "your-topic-here" i mireu com us sembla. A continuació, considereu incloure aquestes ordres en qualsevol habilitat d’IA o configuració d’automatització que feu servir; els vostres agents us ho agrairan.

Fes una ullada a La immersió profunda de David Pine sobre com es van reunir les eines de documents i la referència oficial de la CLI per a tots els detalls.

Microsoft Agent Framework Hits 1.0: això és el que realment importa per als desenvolupadors de.NET

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

Si heu estat seguint el viatge de l’Agent Framework des dels primers dies del nucli semàntic i de l’AutoGen, aquest és significatiu. Microsoft Agent Framework només accedir a la versió 1.0: API estables, preparades per a la producció, compromís de suport a llarg termini. Està disponible tant per a.NET com per a Python, i està realment preparat per a càrregues de treball reals.

Permeteu-me reduir el soroll de l’anunci i centrar-me en allò que importa si esteu creant aplicacions basades en IA amb.NET.

La versió curta

Agent Framework 1.0 unifica el que abans era Semantic Kernel i AutoGen en un únic SDK de codi obert. Abstracció d’un agent. Un motor d’orquestració. Diversos proveïdors d’IA. Si heu estat rebotant entre el nucli semàntic per a patrons empresarials i AutoGen per a fluxos de treball multiagent de grau de recerca, podeu aturar-vos. Aquest és l’SDK ara.

Començar és gairebé injustament senzill

Aquí hi ha un agent que treballa a.NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Això és tot. Un grapat de línies i teniu un agent d’IA que s’executa contra Azure Foundry. L’equivalent de Python és igualment concís. Afegiu eines de funció, converses de diversos torns i transmissió a mesura que avanceu: la superfície de l’API augmenta sense ser estrany.

Orquestració multiagent: aquest és el veritable negoci

Els agents únics estan bé per a les demostracions, però els escenaris de producció solen necessitar coordinació. Agent Framework 1.0 s’envia amb patrons d’orquestració provats en batalla directament de Microsoft Research i AutoGen:

Seqüencial: els agents processen per ordre (escriptor → revisor → editor)
Simultània: es distribueix a diversos agents en paral·lel, convergeix els resultats
Handoff: un agent delega a un altre segons la intenció
Xat de grup: diversos agents discuteixen i convergeixen en una solució
Magentic-One: el patró multiagent de grau de recerca de MSR

Tots admeten la transmissió en temps real, els punts de control, les aprovacions humanes en el bucle i la pausa/reprèn. La part del punt de control és crucial: els fluxos de treball de llarga durada sobreviuen als reinicis del procés. Per als desenvolupadors de.NET que hem creat fluxos de treball duradors amb Azure Functions, això ens sembla familiar.

Les característiques que més importen

Aquí teniu la meva llista del que val la pena saber:

Enganxs de middleware. Saps com ASP.NET Core té canalitzacions de middleware? Mateix concepte, però per a l’execució de l’agent. Intercepteu totes les etapes (afegiu seguretat de contingut, registre, polítiques de compliment) sense tocar les indicacions de l’agent. Així és com podeu preparar els agents per a l’empresa.

Memòria connectable. Historial de conversa, estat clau-valor persistent, recuperació basada en vectors. Trieu el vostre backend: Foundry Agent Service, Mem0, Redis, Neo4j o enrotlleu el vostre. La memòria és el que converteix una trucada LLM sense estat en un agent que realment recorda el context.

Agents YAML declaratius. Definiu les instruccions, les eines, la memòria i la topologia d’orquestració del vostre agent en fitxers YAML controlats per versions. Carregueu i executeu amb una única trucada a l’API. Això és un canvi de joc per als equips que volen repetir el comportament de l’agent sense tornar a desplegar el codi.

Compatibilitat amb A2A i MCP. MCP (Model Context Protocol) permet als agents descobrir i invocar eines externes de manera dinàmica. A2A (protocol d’agent a agent) permet la col·laboració entre temps d’execució: els vostres agents.NET poden coordinar-se amb els agents que s’executen en altres marcs. El suport A2A 1.0 arribarà aviat.

Les funcions de previsualització val la pena veure-les

Algunes funcions s’envien com a previsualització a la versió 1.0: funcionals, però les API poden evolucionar:

DevUI: un depurador local basat en navegador per visualitzar l’execució de l’agent, els fluxos de missatges i les trucades d’eines en temps real. Penseu en Application Insights, però per al raonament dels agents.
GitHub Copilot SDK i Claude Code SDK: utilitzeu Copilot o Claude com a arnès d’agent directament des del vostre codi d’orquestració. Escriu un agent capaç de codificar juntament amb els altres agents en el mateix flux de treball.
Agent Harness: un temps d’execució local personalitzable que ofereix als agents accés a l’intèrpret d’ordres, al sistema de fitxers i als bucles de missatgeria. Penseu en agents de codificació i patrons d’automatització.
Habilitats: paquets de capacitats de domini reutilitzables que ofereixen als agents capacitats estructurades de manera immediata.

Migració des del nucli semàntic o AutoGen

Si teniu codi Semàntic Kernel o AutoGen, hi ha assistents de migració dedicats que analitzen el vostre codi i generen plans de migració pas a pas. La guia de migració del nucli semàntic i la guia de migració d’AutoGen us acompanyen tot.

Si heu estat als paquets RC, l’actualització a la 1.0 és només un augment de la versió.

Tancant

Agent Framework 1.0 és la fita de producció que els equips empresarials estaven esperant. API estables, suport per a diversos proveïdors, patrons d’orquestració que funcionen realment a escala i rutes de migració tant del nucli semàntic com d’AutoGen.

El marc és totalment de codi obert a GitHub, i podeu començar avui mateix amb dotnet add package Microsoft.Agents.AI. Consulteu la guia d’inici ràpid i les mostres per embrutar-vos les mans.

Si heu estat esperant el senyal “Segur per utilitzar en producció”, això és tot.

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.

Azure DevOps finalment soluciona l'UX de l'editor de Markdown de què es va queixar tothom

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

Si utilitzeu Azure Boards, probablement haureu experimentat això: esteu llegint la descripció d’un element de treball, potser revisant els criteris d’acceptació i accidentalment feu doble clic. Boom: esteu en mode d’edició. No volies editar res. Només estaves llegint.

Dan Hellem va anunciar la correcció, i és un d’aquests canvis que sona minúscul però que en realitat elimina la fricció real del vostre flux de treball diari.

Què va canviar

L’editor Markdown per als camps de text d’elements de treball ara s’obre en mode de vista prèvia de manera predeterminada. Podeu llegir i interactuar amb el contingut (seguir enllaços, revisar el format) sense preocupar-vos d’entrar accidentalment al mode d’edició.

Quan realment voleu editar, feu clic a la icona d’edició a la part superior del camp. Quan hàgiu acabat, torneu al mode de previsualització explícitament. Simple, intencionat, previsible.

Això és tot. Aquest és el canvi.

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

El fil de comentaris de la comunitat sobre això era llarg. El comportament de fer doble clic per editar es va introduir amb l’editor Markdown el juliol de 2025 i les queixes van començar gairebé immediatament. El problema no eren només les edicions accidentals, sinó que tota la interacció semblava impredictible. Mai no sabíeu si fer clic es llegiria o editaria.

Per als equips que fan planificació d’esprints, preparació de backlog o revisió de codi amb Azure Boards, aquest tipus de compostos de microfricció. Cada entrada accidental del mode d’edició és un canvi de context. Cada “espera, he canviat alguna cosa?” moment és una atenció perduda.

El nou valor predeterminat respecta el patró d’interacció més comú: llegiu els elements de treball amb molta més freqüència que no els editeu.

Estat de llançament

Això ja s’està implementant a un subconjunt de clients i s’ampliarà a tothom durant les properes dues o tres setmanes. Si encara no ho veus, aviat ho faràs.

Tancant

No totes les millores han de ser una característica de titular. De vegades, la millor actualització és simplement eliminar alguna cosa molesta. Aquest és un d’ells: una petita correcció d’UX que fa que Azure Boards se senti menys hostil a les persones que només volen llegir els seus elements de treball amb tranquil·litat.

Bookmark Studio aporta la navegació i l'ús compartit basats en ranures als marcadors de Visual Studio

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

Els marcadors a Visual Studio sempre han estat… bé. En establiu un, navegueu al següent, oblideu quin marcador és quin. Funcionen, però mai han estat el tipus de funció que podríeu dir poderosa.

Mads Kristensen acaba de publicar Bookmark Studio, una extensió experimental que omple exactament els buits que probablement us heu trobat si feu servir els marcadors amb regularitat.

Navegació basada en ranures

L’addició bàsica: ara les adreces d’interès es poden assignar a les ranures 1–9 i passar directament a Alt+Shift+1 a Alt+Shift+9. Les adreces d’interès noves obtenen automàticament la següent ranura disponible, de manera que, en la majoria dels casos, la navegació ràpida funciona sense cap configuració.

Sembla senzill, però canvia les adreces d’interès de “Tinc algunes adreces d’interès en algun lloc” a “L’espai 3 és el meu controlador de l’API, l’espai 5 és la capa de servei, l’espai 7 és la prova”. Aquest tipus de memòria espacial fa que la navegació sigui gairebé instantània durant les sessions de treball concentrades.

El gestor d’adreces d’interès

Una nova finestra d’eines mostra totes les vostres adreces d’interès en un sol lloc amb un filtratge per nom, fitxer, ubicació, color o ranura. Fes doble clic o navega amb el teclat per saltar a qualsevol marcador.

Si alguna vegada heu tingut més de cinc o sis adreces d’interès i heu perdut la pista de quins, només val la pena instal·lar l’extensió.

Organització amb etiquetes, colors i carpetes

Opcionalment, les adreces d’interès poden tenir etiquetes, colors i agrupar-se en carpetes. Res d’això és necessari: el vostre flux de treball de marcador actual continua funcionant. Però quan esteu depurant un problema complex o explorant una base de codi desconeguda, poder codificar amb colors i etiquetar les vostres adreces d’interès afegeix un context útil.

Totes les metadades s’emmagatzemen per solució, de manera que la vostra organització d’adreces d’interès persisteix entre les sessions.

Exporta i comparteix

Aquesta és la funció que no sabia que volia. Bookmark Studio us permet exportar les adreces d’interès com a text sense format, Markdown o CSV. Això vol dir que pots:

Incloeu camins d’adreces d’interès a les descripcions de la sol·licitud d’extracció
Compartiu la investigació amb els companys d’equip
Mou els conjunts d’adreces d’interès entre repositoris o branques

Els marcadors deixen de ser una eina de navegació en solitari i comencen a ser una manera de comunicar-se “aquí teniu el camí a través d’aquest codi”.

Adreces d’interès que fan un seguiment del moviment del codi

Bookmark Studio fa un seguiment de les adreces d’interès en relació al text al qual estan ancorats, de manera que no es desviïn cap a línies incorrectes mentre editeu. Si alguna vegada heu establert adreces d’interès durant una sessió de depuració i heu fet que tots apunten a les línies equivocades després d’un refactor, això ho soluciona.

Tancant

Bookmark Studio no reinventa res. Es necessita una funció que ha estat “prou bona” durant anys i la fa realment útil per al desenvolupament centrat. La navegació per ranures, el Gestor d’adreces d’interès i les capacitats d’exportació són els més destacats.

Agafeu-lo del Visual Studio Marketplace i proveu-ho.

El tauler de control de l'Aspire 13.2 acaba de tenir una API de telemetria i ho canvia tot

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

Si heu estat creant aplicacions distribuïdes amb.NET Aspire, ja sabeu que el tauler és el millor de tota l’experiència. Tots els vostres rastres, registres i mètriques en un sol lloc: sense Jaeger extern, sense configuració de Seq, sense moments “deixa’m comprovar l’altre terminal”.

Aspire 13.2 l’acaba de millorar significativament. James Newton-King va anunciar l’actualització, i sincerament? Només l’exportació de telemetria i les funcions de l’API mereixen l’actualització.

Exporta la telemetria com una persona sensata

Aquest és l’escenari que tots hem viscut: esteu depurant un problema distribuït, finalment el reproduïu després de vint minuts de configuració i ara heu de compartir el que va passar amb el vostre equip. Abans? Captures de pantalla. Copia i enganxa ID de traça. L’embolic habitual.

Aspire 13.2 afegeix un diàleg adequat Gestiona els registres i la telemetria on podeu:

Esborra tota la telemetria (útil abans d’un intent de reproducció)
Exporteu la telemetria seleccionada a un fitxer ZIP en format estàndard OTLP/JSON
Torneu a importar aquest ZIP a qualsevol tauler de control d’Aspire més tard

Aquesta última part és la característica assassina. Reproduïu un error, exporteu la telemetria, l’adjunteu al vostre element de treball i el vostre company d’equip pot importar-lo al seu propi tauler per veure exactament el que heu vist. No més “pots reproduir-lo a la teva màquina?”

Les traces, els intervals i els registres individuals també reben una opció “Exporta JSON” als seus menús contextuals. Necessites compartir un rastre específic? Feu clic amb el botó dret, copieu JSON i enganxeu-lo a la vostra descripció de PR. Fet.

L’API de telemetria és el veritable canvi de joc

Això és el que m’emociona més. El tauler ara exposa una API HTTP a /api/telemetry per consultar dades de telemetria amb programació. Punts finals disponibles:

GET /api/telemetry/resources: llista els recursos amb telemetria
GET /api/telemetry/spans: la consulta s’estén amb filtres
GET /api/telemetry/logs: registres de consultes amb filtres
GET /api/telemetry/traces — llista traces
GET /api/telemetry/traces/{traceId}: obteniu tots els intervals d’un rastre específic

Tot torna en format OTLP JSON. Això impulsa les noves ordres CLI aspire agent mcp i aspire otel, però la implicació real és més gran: ara podeu crear eines, scripts i integracions d’agents d’IA que consulten directament la telemetria de la vostra aplicació.

Imagineu un agent de codificació d’IA que pugui mirar les vostres traces distribuïdes reals mentre es depura. Això ja no és hipotètic: això és el que permet aquesta API.

La telemetria GenAI es fa pràctica

Si esteu creant aplicacions basades en IA amb Semantic Kernel o Microsoft.Extensions.AI, apreciareu el visualitzador de telemetria GenAI millorat. Aspire 13.2 afegeix:

Descripcions d’eines d’IA representades com a Markdown
Un botó dedicat GenAI a la pàgina de traces per accedir ràpidament a traces d’IA
Millor gestió d’errors per a JSON GenAI truncat o no estàndard
Navegació fent clic per ressaltar entre definicions d’eines

La publicació del bloc esmenta que el xat de VS Code Copilot, la CLI de Copilot i l’OpenCode admeten la configuració d’un OTEL_EXPORTER_OTLP_ENDPOINT. Apunteu-los al tauler de control d’Aspire i podreu veure literalment els vostres agents d’IA pensar en temps real mitjançant la telemetria. Aquesta és una experiència de depuració que no trobareu enlloc més.

Tancant

Aspire 13.2 fa que el tauler de control sigui “una bona interfície d’usuari de depuració” a una “plataforma d’observabilitat programable”. Només el flux de treball d’exportació/importació estalvia temps real en la depuració distribuïda i l’API de telemetria obre la porta als diagnòstics assistits per IA.

Si ja esteu a Aspire, actualitzeu-lo. Si no ho feu, aquesta és una bona raó per consultar aspire.dev i veure de què es tracta.

L'actualització de març de Visual Studio us permet crear agents de pilot personalitzats, i l'eina find_symbol és una gran cosa

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

Visual Studio acaba de rebre la seva actualització Copilot més important fins ara. Mark Downie va anunciar el llançament de març, i el títol és agents personalitzats, però sincerament, l’eina find_symbol soterrada més avall podria ser la característica que canviï més el vostre flux de treball.

Permeteu-me desglossar el que hi ha realment aquí.

Agents de Copilot personalitzats al vostre dipòsit

Voleu que Copilot segueixi els estàndards de codificació del vostre equip, executi el vostre pipeline de compilació o consulti els vostres documents interns? Ara pots construir exactament això.

Els agents personalitzats es defineixen com a fitxers .agent.md que deixeu anar a .github/agents/ al vostre repositori. Cada agent té accés complet a la consciència de l’espai de treball, la comprensió del codi, les eines, el model preferit i les connexions MCP a serveis externs. Apareixen al selector d’agents al costat dels agents integrats.

Aquest és el mateix patró que VS Code ha donat suport, i és fantàstic veure que Visual Studio es posa al dia. Per als equips que ja han creat agents per a VS Code, els vostres fitxers .agent.md haurien de funcionar en ambdós IDE (tot i que els noms d’eines poden variar, així que proveu-los).

El repositori awesome-copilot té configuracions d’agents contribuïts per la comunitat que podeu utilitzar com a punts de partida.

Habilitats d’agent: paquets d’instruccions reutilitzables

Les habilitats es recullen automàticament de .github/skills/ al vostre repositori o ~/.copilot/skills/ al vostre perfil. Cada habilitat és un fitxer SKILL.md seguint l’especificació d’habilitats de l’agent.

Penseu en les habilitats com a experiència modular que podeu combinar i combinar. És possible que tingueu una habilitat per a les convencions de l’API, una altra per als vostres patrons de prova i una altra per al vostre flux de treball de desplegament. Quan s’activa una habilitat, apareix al xat perquè sàpigues que s’està aplicant.

Si heu estat utilitzant habilitats a VS Code, ara funcionen de la mateixa manera a Visual Studio.

find_symbol: navegació conscient de l’idioma per als agents

Aquí és on les coses es posen realment interessants. La nova eina find_symbol ofereix al mode d’agent de Copilot una navegació real de símbols basada en el servei d’idiomes. En lloc de cercar el vostre codi com a text, l’agent pot:

Trobeu totes les referències a un símbol al vostre projecte
Informació de tipus d’accés, declaracions i metadades d’abast
Navegueu pels llocs de trucades amb coneixement complet de l’idioma

Què significa això a la pràctica: quan demaneu a Copilot que refactori un mètode o actualitzeu una signatura de paràmetres en llocs de trucada, realment pot veure l’estructura del vostre codi. No més situacions “l’agent va canviar el mètode però va perdre tres llocs de trucades”.

Els llenguatges admesos inclouen C#, C++, Razor, TypeScript i qualsevol cosa amb una extensió LSP compatible. Per als desenvolupadors de.NET, aquesta és una millora massiva: les bases de codi C# amb jerarquies i interfícies de tipus profundes es beneficien enormement de la navegació conscient dels símbols.

Proves de perfil amb Copilot

Ara hi ha una ordre Perfil amb Copilot al menú contextual de l’Explorador de proves. Seleccioneu una prova, feu clic al perfil i l’agent de perfils l’executa automàticament i analitza el rendiment, combinant l’ús de la CPU i les dades d’instrumentació per oferir informació útil.

No més configurar manualment sessions de perfilador, executar la prova, exportar resultats i intentar llegir un gràfic de flama. L’agent fa l’anàlisi i us diu què és lent i per què. Actualment només.NET, cosa que té sentit donada la profunda integració de diagnòstic.NET de Visual Studio.

Consells de rendiment durant la depuració en directe

L’optimització del rendiment ara es produeix mentre depureu, no després. A mesura que passeu pel codi, Visual Studio mostra el temps d’execució i els senyals de rendiment en línia. Veus una línia lenta? Feu clic al Consell de rendiment i demaneu a Copilot suggeriments d’optimització allà mateix.

L’agent de perfils captura automàticament les dades del temps d’execució (temps transcorregut, ús de la CPU, comportament de la memòria) i Copilot les utilitza per identificar els punts calents. Això manté el treball de rendiment com a part del vostre flux de depuració en lloc d’una tasca separada que continueu posposant.

Corregiu les vulnerabilitats de NuGet des de l’Explorador de solucions

Quan es detecta una vulnerabilitat en un paquet NuGet, ara veuràs una notificació amb un enllaç Corregir amb GitHub Copilot directament a l’Explorador de solucions. Feu clic i Copilot analitza la vulnerabilitat, recomana les actualitzacions de paquets adequades i les implementa.

Per als equips que lluiten per mantenir les dependències actualitzades (que és bàsicament per a tothom), això elimina la fricció de “Sé que hi ha una vulnerabilitat, però esbrinar la ruta d’actualització correcta és un projecte en si mateix”.

Tancant

Els agents personalitzats i les habilitats són el titular, però find_symbol és l’èxit dormint: canvia fonamentalment la precisió que pot ser Copilot quan es refactoritza el codi.NET. Combinada amb la integració de perfils en directe i les correccions de vulnerabilitats, aquesta actualització fa que les funcions d’IA de Visual Studio se sentin realment pràctiques en lloc de preparar-se per a la demostració.

Baixeu Visual Studio 2026 Insiders per provar-ho tot.

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.

VS Code 1.112: Què haurien de preocupar-se realment als desenvolupadors de.NET

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

VS Code 1.112 acaba d’aterrar, i sincerament? Aquest és diferent si passeu els vostres dies a la terra.NET. Hi ha moltes coses a les notes oficials de la versió, però permeteu-me que us estalviï una mica de desplaçament i que em concentri en allò que realment ens importa.

Copilot CLI acaba de ser molt més útil

El gran tema d’aquest llançament és autonomia de l’agent, donant més espai a Copilot per fer les seves coses sense que facis de cangur a cada pas.

Direcció i cua de missatges

Coneixes aquell moment en què Copilot CLI està a mig camí d’una tasca i t’adones que t’has oblidat d’esmentar alguna cosa? Abans, calia esperar. Ara només podeu enviar missatges mentre una sol·licitud encara s’està executant, ja sigui per dirigir la resposta actual o posar en cua les instruccions de seguiment.

Això és enorme per a aquelles tasques més llargues de bastida dotnet en què esteu veient Copilot configura un projecte i penseu “oh, espera, també necessito MassTransit”.

Nivells de permís

Aquest és el que m’emociona més. Les sessions de Copilot CLI ara admeten tres nivells de permís:

Permisos predeterminats: el flux habitual on les eines demanen confirmació abans d’executar-se
Evita les aprovacions: s’aprova tot automàticament i torna a provar els errors
Pilot automàtic: és totalment autònom: aprova les eines, respon a les seves pròpies preguntes i continua fins que es fa la tasca

Si esteu fent alguna cosa com la bastida d’una nova API ASP.NET Core amb Entity Framework, migracions i una configuració de Docker, el mode Autopilot significa que descriu el que voleu i aneu a prendre un cafè. Ho descobrirà.

Podeu habilitar el pilot automàtic amb la configuració chat.autopilot.enabled.

Previsualitza els canvis abans de la delegació

Quan delegueu una tasca a Copilot CLI, es crea un arbre de treball. Abans, si teníeu canvis no compromesos, havíeu de comprovar el control de fonts per veure què es veuria afectat. Ara, la vista de xat mostra els canvis pendents abans de decidir si els voleu copiar, moure o ignorar-los.

Poca cosa, però us salva d’aquell “espera, què he posat en escena?” moment.

Depura les aplicacions web sense sortir de VS Code

El navegador integrat ara admet depuració completa. Podeu establir punts d’interrupció, passar pel codi i inspeccionar variables, tot dins de VS Code. No més canviar a Edge DevTools.

Hi ha un nou tipus de depuració editor-browser i si ja teniu configuracions de llançament de msedge o chrome, la migració és tan senzilla com canviar el camp type al vostre launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Per als desenvolupadors de Blazor, això és un canvi de joc. Ja esteu executant dotnet watch al terminal; ara la vostra depuració també es manté a la mateixa finestra.

El navegador també va obtenir nivells de zoom independents (finalment), menús contextuals adequats del clic dret i el zoom es recorda per lloc web.

Sandboxing del servidor MCP

Aquest és més important del que podríeu pensar. Si utilitzeu servidors MCP (potser n’heu configurat un de personalitzat per als vostres recursos d’Azure o consultes de base de dades), s’han executat amb els mateixos permisos que el vostre procés de VS Code. Això significa un accés complet al vostre sistema de fitxers, xarxa, tot.

Ara els podeu sorrar. Al teu mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quan un servidor amb caixa de sorra necessita accés a alguna cosa que no té, VS Code us demana que atorgueu permís. Molt millor que l’enfocament “Espero que ningú faci res estrany”.

Nota: Sandboxing està disponible per ara a macOS i Linux. Arriba el suport de Windows, però escenaris remots com WSL funcionen.

Descobriment de personalitzacions de Monorepo

Si esteu treballant en un monorepo (i siguem sincers, moltes solucions empresarials.NET acaben com una), això resol un veritable problema.

Anteriorment, si obríeu una subcarpeta del vostre repositori, VS Code no trobaria les vostres habilitats copilot-instructions.md, AGENTS.md o personalitzades a l’arrel del dipòsit. Ara, amb la configuració chat.useCustomizationsInParentRepositories, puja a l’arrel .git i ho descobreix tot.

Això significa que el vostre equip pot compartir instruccions de l’agent, fitxers de sol·licitud i eines personalitzades en tots els projectes en un monorepo sense que tothom hagi d’obrir la carpeta arrel.

/resolució de problemes per a la depuració de l’agent

Alguna vegada has configurat instruccions o habilitats personalitzades i t’has preguntat per què no les recullen? La nova habilitat /troubleshoot llegeix els registres de depuració de l’agent i us diu què va passar: quines eines s’han utilitzat o s’han omès, per què les instruccions no s’han carregat i què està causant respostes lentes.

Activa-ho amb:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

A continuació, només cal escriure /troubleshoot why is my custom skill not loading? al xat.

També podeu exportar i importar aquests registres de depuració ara, la qual cosa és ideal per compartir amb el vostre equip quan alguna cosa no funciona com s’esperava.

Compatibilitat amb imatges i fitxers binaris

Els agents ara poden llegir fitxers d’imatge del disc i fitxers binaris de manera nativa. Els fitxers binaris es presenten en format hexdump i les sortides d’imatge (com les captures de pantalla del navegador integrat) es mostren en una vista de carrusel.

Per als desenvolupadors de.NET, penseu: enganxeu una captura de pantalla d’un error de la interfície d’usuari al xat i feu que l’agent entengui què passa, o feu que analitzi la sortida d’una representació de component Blazor.

Referències de símbols automàtiques

Petita millora de la qualitat de vida: quan copieu un nom de símbol (una classe, un mètode, etc.) i l’enganxeu al xat, ara VS Code el converteix automàticament en una referència #sym:Name. Això proporciona a l’agent un context complet sobre aquest símbol sense que hàgiu d’afegir-lo manualment.

Si voleu text sense format, feu servir Ctrl+Shift+V.

Els connectors ara es poden activar/desactivar

Abans, desactivar un servidor o connector MCP significava desinstal·lar-lo. Ara podeu activar-los i desactivar-los, tant a nivell global com per espai de treball. Feu clic amb el botó dret a la vista Extensions o a la vista Personalitzacions i ja heu acabat.

Els connectors de npm i pypi també es poden actualitzar automàticament ara, tot i que primer demanaran l’aprovació, ja que les actualitzacions signifiquen executar codi nou a la vostra màquina.

Tancant

VS Code 1.112 està clarament empenyent l’experiència de l’agent: més autonomia, millor depuració, seguretat més estricta. Per als desenvolupadors de.NET, la depuració integrada del navegador i les millores de Copilot CLI són les característiques més destacades.

Si encara no heu provat d’executar una sessió CLI Copilot completa en mode Autopilot per a un projecte.NET, aquesta versió és un bon moment per començar. Només recordeu establir els vostres permisos i deixar-ho cuinar.

Descarregueu VS Code 1.112 o actualitzeu-ho des de VS Code mitjançant Ajuda > Comproveu actualitzacions.

Posts | The .NET Blog

.NET 10 Inclòs amb Ubuntu 26.04 LTS — Les Novetats

Instal·la .NET 10 en dos comandes

Contenidors: actualitza -noble a -resolute

Native AOT: arrencada en 3ms, binari de 1.4MB

Necessites .NET 8 o 9?

CodeAct al Agent Framework: Com Reduir la Latència del teu Agent a la Meitat

Què és CodeAct?

La peça de seguretat: micro-VMs de Hyperlight

Com connectar-ho

Quan fer servir CodeAct (i quan no)

Prova-ho ara

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

Què és un MCP Bundle?

Com instal·lar-lo

Per a començar

GPT-5.5 Ja És Aquí a Azure Foundry — El que els Desenvolupadors .NET Han de Saber

La progressió de GPT-5

Què ha canviat realment

Preus

Foundry Agent Service

On Recorda les Coses el teu Agent? Guia Pràctica sobre l'Emmagatzematge de l'Historial de Xat

Dos patrons fonamentals

Com Agent Framework abstreu això

Referència ràpida de proveïdors

VS Code 1.118: Copilot CLI Obté Noms de Sessió, Insígnies de Model i TypeScript 7.0 Nightly

Copilot CLI: les sessions ara tenen noms reals

Canvia de sessió amb dreceres de teclat

Insígnies de model al xat

Selecció automàtica de model a Copilot CLI

Opt-in a TypeScript 7.0 nightly

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

Què és un Toolbox?

Els quatre pilars (dos disponibles avui)

Exemple pràctic

No estàs bloquejat a Foundry Agents

Per què importa ara

Conclusió

Hooks d'azd en Python, TypeScript i .NET: adéu als scripts de shell

Hooks, breument

Com funciona la detecció

Detalls importants per llenguatge

Python

JavaScript i TypeScript

.NET

Configuració per executor

Per què importa per a desenvolupadors .NET

Conclusió

Windows App Dev CLI v0.3: F5 des del terminal i automatització de UI per a agents

winapp run: F5 des de qualsevol lloc

Nou paquet NuGet: dotnet run per a apps empaquetades

winapp ui: UI Automation des de la línia de comandes

Altres novetats

Com obtenir-ho

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

Configuració amb Copilot durant azd init

El que fa realment

Resolució d’errors amb Copilot

Configurar un comportament predeterminat

Conclusió

Escrivint complements natius de Node.js en C# amb .NET Native AOT

La idea bàsica

La configuració del projecte

Exportant el punt d’entrada

Resolent N-API contra el procés amfitrió

Cridant-lo des de TypeScript

Conclusions

VS Code 1.117: Els agents s'estan guanyant les seves pròpies branques Git i això m'encanta

El mode Autopilot finalment recorda la teva preferència

Aïllament de worktree i Git per a sessions d’agents

Subagents i equips d’agents

La sortida del terminal s’inclou automàticament quan els agents envien entrada

L’app d’Agents s’actualitza sola a macOS

El que val la pena saber de la resta

La conclusió

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

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

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

El que realment funciona

El menjar per emportar

Contenidors: actualitza `-noble` a `-resolute`