<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Composition | The .NET Blog</title><link>https://thedotnetblog.com/zh/tags/composition/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>zh</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Tue, 09 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/zh/tags/composition/index.xml" rel="self" type="application/rss+xml"/><item><title>Agent Skills for Python 表明组合比写作风格更重要</title><link>https://thedotnetblog.com/zh/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/</link><pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/zh/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/</guid><description>最新的 Agent Skills for Python 文章名义上是在讲文件式、类式和内联式技能，但更重要的思想是不重写提供者模型即可跨源组合的能力。</description><content:encoded>&lt;p&gt;这是那种特定语言焦点比其架构启示更窄的文章之一。&lt;/p&gt;
&lt;p&gt;是的，文章是关于 &lt;strong&gt;Agent Skills for Python&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;但更有趣的点在于&lt;strong&gt;组合&lt;/strong&gt;。&lt;/p&gt;
&lt;p&gt;通过一个提供者模型混合使用基于文件、基于类和内联式技能的能力，正是那种让框架感觉可扩展而非花哨的东西。&lt;/p&gt;
&lt;h2 id="重要的转变不是文件式-vs-类式-vs-内联式"&gt;重要的转变不是文件式 vs 类式 vs 内联式&lt;/h2&gt;
&lt;p&gt;很容易把文章读成一个功能矩阵：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;基于文件的 skills&lt;/li&gt;
&lt;li&gt;基于类的 skills&lt;/li&gt;
&lt;li&gt;内联 skills&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;这很有用，但它不是主要的架构观点。&lt;/p&gt;
&lt;p&gt;主要的观点是，框架正在让&lt;strong&gt;从多个来源组合能力&lt;/strong&gt;变得更容易，而不必每次都重写提供者的实现方式。&lt;/p&gt;
&lt;p&gt;当技能从小型演示迁移到真正的团队环境时，这才是关键。&lt;/p&gt;
&lt;h2 id="我会关注的那句话"&gt;我会关注的那句话&lt;/h2&gt;
&lt;p&gt;源文章说，来自本地仓库的技能、来自内部索引的打包技能，以及&amp;quot;&lt;strong&gt;你十分钟前写的快速内联桥接，都接入同一个提供者&lt;/strong&gt;。&amp;quot;&lt;/p&gt;
&lt;p&gt;这句话才是真正的干货。&lt;/p&gt;
&lt;p&gt;因为可维护性就在这里体现。&lt;/p&gt;
&lt;p&gt;如果团队可以混合使用：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;打包技能&lt;/li&gt;
&lt;li&gt;临时桥接&lt;/li&gt;
&lt;li&gt;本地仓库技能&lt;/li&gt;
&lt;li&gt;未来的替代品&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;而无需每次重写智能体管道，那么技能系统就有机会在真正的组织中规模化。&lt;/p&gt;
&lt;h2 id="为什么即使你更关注-net-这也重要"&gt;为什么即使你更关注 .NET 这也重要&lt;/h2&gt;
&lt;p&gt;尽管这篇文章是针对 Python 的，我仍然认为这个模式值得关注，即使你主要工作在 .NET 生态中。&lt;/p&gt;
&lt;p&gt;为什么？因为底层的疑问超越了语言选择：&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;技能如何在团队间演进而不变成一团乱麻？&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;答案很少是简单地&amp;quot;增加更多技能类型&amp;quot;。&lt;/p&gt;
&lt;p&gt;答案几乎总是关于组合模型是否足够强大，能让这些技能类型干净地共存。&lt;/p&gt;
&lt;p&gt;这就是我认为这篇文章做对的地方。&lt;/p&gt;
&lt;h2 id="我的看法"&gt;我的看法&lt;/h2&gt;
&lt;p&gt;即使你更关注 .NET 这边，这仍然是一个值得关注的模式，因为组合性决定了技能在跨团队传播时是否还能保持可维护性。&lt;/p&gt;
&lt;p&gt;而一旦团队开始在仓库和内部生态中打包、共享和交换技能，这种组合性就比任何单一写作风格的语法重要得多。&lt;/p&gt;
&lt;p&gt;原文：&lt;a href="https://devblogs.microsoft.com/agent-framework/agent-skills-for-python-file-code-and-class-composed-in-one-provider/"&gt;Agent Skills for Python: File, Code, and Class – Composed in One Provider&lt;/a&gt;&lt;/p&gt;</content:encoded></item></channel></rss>