https://thedotnetblog.com/de/tags/composition/Articles, tutorials and insights from the .NET community.Hugode@thedotnetblog (The .NET Blog)@thedotnetblogTue, 09 Jun 2026 00:00:00 +0000https://thedotnetblog.com/de/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/Tue, 09 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/de/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/Der neueste Beitrag zu Agent Skills für Python handelt nominell von Datei-, Klassen- und Inline-Skills, aber die wichtigere Idee ist die Komponierbarkeit über Quellen hinweg ohne Umschreiben des Provider-Modells.<p>Dies ist einer dieser Beiträge, bei denen der sprachspezifische Fokus enger ist als die architektonische Lektion.</p> <p>Ja, der Artikel handelt von <strong>Agent Skills für Python</strong>.</p> <p>Aber der interessantere Punkt ist <strong>Komposition</strong>.</p> <p>Die Fähigkeit, dateibasierte, klassenbasierte und Inline-Skills durch ein einziges Provider-Modell zu mischen, ist genau das, was ein Framework skalierbar statt niedlich wirken lässt.</p> <h2 id="der-wichtige-wandel-ist-nicht-datei-vs-klasse-vs-inline">Der wichtige Wandel ist nicht Datei vs. Klasse vs. Inline</h2> <p>Es ist leicht, den Artikel als Feature-Matrix zu lesen:</p> <ul> <li>dateibasierte Skills</li> <li>klassenbasierte Skills</li> <li>Inline-Skills</li> </ul> <p>Das ist nützlich, aber nicht der architektonische Hauptpunkt.</p> <p>Der Hauptpunkt ist, dass das Framework es einfacher macht, <strong>Fähigkeiten aus mehreren Quellen zu komponieren, ohne die Provider-Geschichte jedes Mal neu zu schreiben</strong>.</p> <p>Das ist der Teil, der zählt, wenn Skills von einer kleinen Demo in eine echte Team-Umgebung übergehen.</p> <h2 id="die-zeile-auf-die-ich-mich-konzentrieren-würde">Die Zeile, auf die ich mich konzentrieren würde</h2> <p>Der Quellartikel sagt, dass ein Skill aus einem lokalen Repository, ein gepackter Skill aus einem internen Index und &ldquo;<strong>eine schnelle Inline-Brücke, die Sie vor zehn Minuten geschrieben haben, alle an denselben Provider anschließen</strong>.&rdquo;</p> <p>Dieser Satz leistet die eigentliche Arbeit.</p> <p>Denn hier zeigt sich Wartbarkeit.</p> <p>Wenn Teams mischen können:</p> <ul> <li>gepackte Skills</li> <li>temporäre Brücken</li> <li>lokale Repository-Skills</li> <li>zukünftige Ersetzungen</li> </ul> <p>ohne jedes Mal die Agent-Installation neu zu schreiben, dann hat das Skill-System eine Chance, in echten Organisationen zu skalieren.</p> <h2 id="warum-das-wichtig-ist-auch-wenn-sie-eher-net-fokussiert-sind">Warum das wichtig ist, auch wenn Sie eher .NET-fokussiert sind</h2> <p>Auch wenn dieser Beitrag Python-spezifisch ist, halte ich das Muster dennoch für beachtenswert, wenn Sie hauptsächlich in .NET leben.</p> <p>Warum? Weil die zugrunde liegende Frage größer ist als die Sprachwahl:</p> <p><strong>wie entwickeln sich Skills über Teams hinweg, ohne ein Chaos zu werden?</strong></p> <p>Die Antwort ist selten nur &ldquo;mehr Skill-Typen&rdquo;.</p> <p>Es geht fast immer darum, ob das Kompositionsmodell stark genug ist, um diese Skill-Typen sauber koexistieren zu lassen.</p> <p>Das ist es, was dieser Artikel meiner Meinung nach richtig macht.</p> <h2 id="meine-meinung">Meine Meinung</h2> <p>Selbst wenn Sie sich mehr auf die .NET-Seite konzentrieren, ist dies dennoch ein nützliches Muster, das man beobachten sollte, denn Komponierbarkeit ist einer der Faktoren, die entscheiden, ob Skills wartbar bleiben, wenn sie sich über Teams ausbreiten.</p> <p>Und sobald Teams anfangen, Skills über Repositories und interne Ökosysteme hinweg zu paketieren, zu teilen und auszutauschen, wird diese Komponierbarkeit viel wichtiger als die Syntax eines einzelnen Authoring-Stils.</p> <p>Originalquelle: <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>