Agent Skills per a .NET és Estable, i Això Canvia l'Arquitectura d'Agents Empresarials

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

Agent Skills per a .NET passant a estable és una de les fites més pràctiques en l’ecosistema d’agents actual. Resol un problema central d’escalat: el coneixement de domini no ha de pertànyer a un sol bloc d’instruccions gegant.

Font original: https://devblogs.microsoft.com/agent-framework/agent-skills-for-net-is-now-released/

El disseny és elegant i pragmàtic. Les Skills empaqueten instruccions, recursos i scripts opcionals en unitats reutilitzables que es carreguen sota demanda mitjançant divulgació progressiva. Això manté el context lleuger, redueix la inflor dels prompts i permet la propietat entre equips del coneixement especialitzat.

La meva opinió: aquest és el primer camí creïble cap al manteniment d’agents de grau empresarial en stacks .NET. Sense límits de coneixement modulars, cada actualització de política o playbook es converteix en un exercici fràgil de cirurgia de prompts.

El que més importa no és només la modularitat, sinó la governança. El model d’aprovació integrat per carregar skills, llegir recursos i executar scripts aborda les preocupacions operatives exactes que els equips de seguretat plantegen quan els agents passen de demo a producció. El model extensible d’execució d’scripts també fa explícita la responsabilitat: si voleu execució d’scripts basada en fitxers, vosaltres gestioneu l’sandboxing i la postura d’auditoria.

Patró d’adopció pràctic:

Comença amb skills basades en fitxers per a contingut de polítiques mantingut per equips tècnics mixtos. Utilitza skills basades en classes quan necessitis distribució de paquets via NuGet i controls de cicle de vida d’enginyeria més estrictes. Reserva les skills definides en codi per a muntatge dinàmic en temps d’execució on sigui necessària una composició amb estat.

Afegeix filtratge aviat. No totes les skills haurien de ser visibles per a cada agent o tenant. La visibilitat curada de skills és tant un control de seguretat com un control de rellevància que millora la qualitat de l’encaminament.

A més, registra-ho tot: selecció de skills, lectures de recursos, sol·licituds d’execució d’scripts i aprovacions. Si la vostra revisió d’incidències no pot reconstruir quina skill va influir en una resposta, no teniu observabilitat de producció.

El canvi estratègic més gran és aquest: les skills converteixen el comportament dels agents en una cadena de subministrament componible. Els equips poden versionar, revisar i publicar coneixement de manera similar als components de programari. Això permet una evolució independent sense reentrenar constantment humans per reescriure mega-prompts.

Si esteu construint agents .NET a escala empresarial, retardar aquest patró us costarà car. Acabareu amb una dispersió d’instruccions, aplicació de polítiques inconsistent i un comportament fràgil sota canvi.

Agent Skills no elimina la complexitat, però trasllada la complexitat a components governables. Això és exactament el que hauria de fer l’arquitectura de programari madura. Per a molts equips, aquest llançament és el moment on l’enginyeria d’agents a .NET comença a semblar-se a l’enginyeria de plataforma real.

Agent Skills per a Python Mostren Per Què la Composició Importa Més que l'Estil d'Autorització

Emiliano Montesdeoca — Tue, 09 Jun 2026 00:00:00 +0000

Aquest és un d’aquells articles on l’enfocament específic del llenguatge és més estret que la lliçó arquitectònica.

Sí, l’article tracta sobre Agent Skills per a Python.

Però el punt més interessant és sobre la composició.

La capacitat de barrejar skills basades en fitxers, classes i inline a través d’un sol model de provider és exactament el tipus de cosa que fa que un framework sembli escalable en lloc de simpàtic.

El canvi important no és fitxer vs classe vs inline

És fàcil llegir l’article com una matriu de funcions:

skills basades en fitxers
skills basades en classes
skills inline

Això és útil, però no és el punt arquitectònic principal.

El punt principal és que el framework està facilitant compondre capacitats de múltiples fonts sense reescriure la historia del provider cada vegada.

Aquesta és la part que importa quan les skills passen d’una petita demo a un entorn d’equip real.

La línia en què em centraria

L’article font diu que una skill d’un repositori local, una skill empaquetada d’un índex intern i “un pont inline ràpid que vas escriure fa deu minuts s’endollen tots al mateix provider”.

Aquesta frase fa la feina real.

Perquè aquí és on comença a aparèixer el manteniment.

Si els equips poden barrejar:

skills empaquetades
ponts temporals
skills de repositori local
substitucions futures

sense reescriure la fontaneria de l’agent cada vegada, llavors el sistema de skills té possibilitats d’escalar en organitzacions reals.

Per què això importa encara que estiguis més centrat en .NET

Tot i que aquest article és específic de Python, crec que el patró val la pena seguir-lo fins i tot si vius principalment a .NET.

Per què? Perquè la pregunta subjacent és més gran que l’elecció del llenguatge:

com evolucionen les skills entre equips sense convertir-se en un desastre?

La resposta rarament és “simplement més tipus de skills”.

Gairebé sempre es tracta de si el model de composició és prou sòlid per permetre que aquests tipus de skills convisquin de manera neta.

Això és el que crec que aquest article fa bé.

La meva opinió

Fins i tot si estàs més centrat en la banda de .NET, aquest segueix sent un patró útil de seguir perquè la composabilitat és una de les coses que decideix si les skills es mantenen mantenibles a mesura que s’estenen entre equips.

I un cop els equips comencin a empaquetar, compartir i intercanviar skills entre repositoris i ecosistemes interns, aquesta composabilitat es torna molt més important que la sintaxi de qualsevol estil d’autoria individual.