C’est l’un de ces billets où le focus linguistique spécifique est plus étroit que la leçon architecturale.
Oui, l’article parle des Agent Skills pour Python.
Mais le point le plus intéressant concerne la composition.
La capacité de mélanger des skills basées fichier, classe et inline via un seul modèle de fournisseur est exactement le genre de chose qui donne à un framework l’impression d’être évolutif plutôt que mignon.
Le changement important n’est pas fichier vs classe vs inline
Il est facile de lire l’article comme une matrice de fonctionnalités :
- skills basées fichier
- skills basées classe
- skills inline
C’est utile, mais ce n’est pas le point architectural principal.
Le point principal est que le framework facilite la composition de capacités à partir de plusieurs sources sans réécrire l’histoire du fournisseur à chaque fois.
C’est la partie qui compte quand les skills passent d’une petite démo à un vrai environnement d’équipe.
La phrase sur laquelle je me concentrerais
L’article source dit qu’une skill provenant d’un dépôt local, une skill packagée d’un index interne, et « un pont inline rapide que vous avez écrit il y a dix minutes se branchent tous sur le même fournisseur ».
Cette phrase fait le vrai travail.
Parce que c’est là que la maintenabilité commence à se manifester.
Si les équipes peuvent mélanger :
- des skills packagées
- des ponts temporaires
- des skills de dépôt local
- de futurs remplacements
sans réécrire la plomberie de l’agent à chaque fois, alors le système de skills a une chance de passer à l’échelle dans de vraies organisations.
Pourquoi cela compte même si vous êtes plus orienté .NET
Même si ce billet est spécifique à Python, je pense encore que ce modèle mérite d’être suivi même si vous vivez surtout en .NET.
Pourquoi ? Parce que la question sous-jacente est plus grande que le choix du langage :
comment les skills évoluent-elles entre équipes sans devenir un bazar ?
La réponse n’est presque jamais simplement « plus de types de skills ».
C’est presque toujours une question de savoir si le modèle de composition est assez solide pour permettre à ces types de skills de coexister proprement.
C’est ce que je pense que cet article réussit bien.
Mon avis
Même si vous êtes plus concentré sur le côté .NET, c’est encore un modèle utile à surveiller parce que la composabilité est l’un des facteurs qui décident si les skills restent maintenables à mesure qu’elles se répandent entre équipes.
Et dès que les équipes commencent à packager, partager et échanger des skills entre dépôts et écosystèmes internes, cette composabilité devient bien plus importante que la syntaxe d’un style d’écriture unique.
Original post: Agent Skills for Python: File, Code, and Class – Composed in One Provider
