https://thedotnetblog.com/pt/tags/composition/Articles, tutorials and insights from the .NET community.Hugopt@thedotnetblog (The .NET Blog)@thedotnetblogTue, 09 Jun 2026 00:00:00 +0000https://thedotnetblog.com/pt/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/Tue, 09 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/pt/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/O post recente sobre Agent Skills para Python é nominalmente sobre skills de arquivo, classe e inline, mas a ideia mais importante é a composabilidade entre fontes sem reescrever o modelo de provider.<p>Este é um daqueles posts em que o foco específico de linguagem é mais estreito do que a lição arquitetural.</p> <p>Sim, o artigo é sobre <strong>Agent Skills para Python</strong>.</p> <p>Mas o ponto mais interessante é sobre <strong>composição</strong>.</p> <p>A capacidade de misturar skills baseadas em arquivo, em classe e inline através de um único modelo de provider é exatamente o tipo de coisa que faz um framework parecer escalável em vez de apenas simpático.</p> <h2 id="a-mudança-importante-não-é-arquivo-vs-classe-vs-inline">A mudança importante não é arquivo vs. classe vs. inline</h2> <p>É fácil ler o artigo como uma matriz de recursos:</p> <ul> <li>skills baseadas em arquivo</li> <li>skills baseadas em classe</li> <li>skills inline</li> </ul> <p>Isso é útil, mas não é o ponto arquitetural principal.</p> <p>O ponto principal é que o framework está tornando mais fácil <strong>compor capacidades de múltiplas fontes sem reescrever a história do provider toda vez</strong>.</p> <p>Essa é a parte que importa quando as skills saem de uma pequena demo e vão para um ambiente real de equipe.</p> <h2 id="a-frase-em-que-eu-focaria">A frase em que eu focaria</h2> <p>O artigo original diz que uma skill de um repositório local, uma skill empacotada de um índice interno, e &ldquo;<strong>uma ponte inline rápida que você escreveu dez minutos atrás se conectam todas ao mesmo provider</strong>&rdquo;.</p> <p>Essa frase é quem faz o trabalho de verdade.</p> <p>Porque é aí que a manutenibilidade começa a aparecer.</p> <p>Se as equipes conseguem misturar:</p> <ul> <li>skills empacotadas</li> <li>pontes temporárias</li> <li>skills de repositório local</li> <li>substituições futuras</li> </ul> <p>sem reescrever a &ldquo;encanação&rdquo; do agente toda vez, então o sistema de skills tem chance de escalar em organizações reais.</p> <h2 id="por-que-isso-importa-mesmo-se-você-é-mais-focado-em-net">Por que isso importa mesmo se você é mais focado em .NET</h2> <p>Mesmo que este post seja específico de Python, ainda acho que o padrão vale a pena acompanhar se você vive principalmente no .NET.</p> <p>Por quê? Porque a pergunta subjacente é maior do que a escolha de linguagem:</p> <p><strong>como as skills evoluem entre equipes sem virar uma bagunça?</strong></p> <p>A resposta raramente é apenas &ldquo;mais tipos de skill&rdquo;.</p> <p>Quase sempre é sobre se o modelo de composição é forte o suficiente para permitir que esses tipos de skill coexistam de forma limpa.</p> <p>É isso que acho que este artigo acerta.</p> <h2 id="minha-opinião">Minha opinião</h2> <p>Mesmo que você seja mais focado no lado .NET, este ainda é um padrão útil para observar, porque a composabilidade é uma das coisas que decide se as skills permanecem sustentáveis à medida que se espalham entre equipes.</p> <p>E assim que as equipes começarem a empacotar, compartilhar e trocar skills entre repositórios e ecossistemas internos, essa composabilidade se torna muito mais importante do que a sintaxe de qualquer estilo único de autoria.</p> <p>Post original: <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>