https://thedotnetblog.com/it/tags/composition/Articles, tutorials and insights from the .NET community.Hugoit@thedotnetblog (The .NET Blog)@thedotnetblogTue, 09 Jun 2026 00:00:00 +0000https://thedotnetblog.com/it/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/Tue, 09 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/it/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/L'ultimo post su Agent Skills per Python parla nominalmente di skill file, class e inline, ma l'idea più importante è la componibilità tra fonti diverse senza riscrivere il modello provider.<p>Questo è uno di quei post in cui il focus linguistico specifico è più ristretto della lezione architetturale.</p> <p>Sì, l&rsquo;articolo parla di <strong>Agent Skills per Python</strong>.</p> <p>Ma il punto più interessante riguarda la <strong>composizione</strong>.</p> <p>La capacità di mescolare skill basate su file, su classi e inline attraverso un unico modello provider è esattamente il tipo di cosa che fa sembrare un framework scalabile invece che carino.</p> <h2 id="il-cambiamento-importante-non-è-file-vs-classe-vs-inline">Il cambiamento importante non è file vs classe vs inline</h2> <p>È facile leggere l&rsquo;articolo come una matrice di funzionalità:</p> <ul> <li>skill basate su file</li> <li>skill basate su classi</li> <li>skill inline</li> </ul> <p>Questo è utile, ma non è il punto architetturale principale.</p> <p>Il punto principale è che il framework sta rendendo più facile <strong>comporre capacità da fonti multiple senza riscrivere la storia del provider ogni volta</strong>.</p> <p>Questa è la parte che conta quando le skill passano da una piccola demo a un ambiente di team reale.</p> <h2 id="la-riga-su-cui-mi-concentrerei">La riga su cui mi concentrerei</h2> <p>L&rsquo;articolo sorgente dice che una skill da un repository locale, una skill pacchettizzata da un indice interno e &ldquo;<strong>un rapido bridge inline che hai scritto dieci minuti fa si inseriscono tutti nello stesso provider</strong>.&rdquo;</p> <p>Quella frase sta facendo il lavoro vero.</p> <p>Perché è lì che inizia a manifestarsi la manutenibilità.</p> <p>Se i team possono mescolare:</p> <ul> <li>skill pacchettizzate</li> <li>bridge temporanei</li> <li>skill da repository locali</li> <li>sostituzioni future</li> </ul> <p>senza riscrivere l&rsquo;impianto degli agenti ogni volta, allora il sistema di skill ha la possibilità di scalare in organizzazioni reali.</p> <h2 id="perché-questo-è-importante-anche-se-sei-più-focalizzato-su-net">Perché questo è importante anche se sei più focalizzato su .NET</h2> <p>Anche se questo post è specifico per Python, penso comunque che il pattern meriti attenzione se vivi principalmente in .NET.</p> <p>Perché? Perché la domanda sottostante è più grande della scelta del linguaggio:</p> <p><strong>come evolvono le skill tra team diversi senza diventare un pasticcio?</strong></p> <p>La risposta raramente è solo &ldquo;più tipi di skill.&rdquo;</p> <p>È quasi sempre sulla forza del modello di composizione: se è abbastanza solido da far coesistere quei tipi di skill in modo pulito.</p> <p>Questo è ciò che secondo me questo articolo fa bene.</p> <h2 id="il-mio-parere">Il mio parere</h2> <p>Anche se sei più concentrato sul lato .NET, questo è comunque un pattern utile da osservare perché la componibilità è una delle cose che decide se le skill rimangono manutenibili mentre si diffondono tra i team.</p> <p>E quando i team inizieranno a impacchettare, condividere e scambiare skill tra repository ed ecosistemi interni, quella componibilità diventerà molto più importante della sintassi di un singolo stile di authoring.</p> <p>Post originale: <a href="https://devblogs.microsoft.com/agent-framework/agent-skills-for-python-file-code-and-class-composed-in-one-provider/">Agent Skills for Python: File, Code, and Class – Composed in One Provider</a></p>