这是那种特定语言焦点比其架构启示更窄的文章之一。
是的，文章是关于 Agent Skills for Python。
但更有趣的点在于组合。
通过一个提供者模型混合使用基于文件、基于类和内联式技能的能力，正是那种让框架感觉可扩展而非花哨的东西。
重要的转变不是文件式 vs 类式 vs 内联式
很容易把文章读成一个功能矩阵：
- 基于文件的 skills
- 基于类的 skills
- 内联 skills
这很有用，但它不是主要的架构观点。
主要的观点是，框架正在让从多个来源组合能力变得更容易，而不必每次都重写提供者的实现方式。
当技能从小型演示迁移到真正的团队环境时，这才是关键。
我会关注的那句话
源文章说，来自本地仓库的技能、来自内部索引的打包技能，以及"你十分钟前写的快速内联桥接，都接入同一个提供者。"
这句话才是真正的干货。
因为可维护性就在这里体现。
如果团队可以混合使用：
- 打包技能
- 临时桥接
- 本地仓库技能
- 未来的替代品
而无需每次重写智能体管道，那么技能系统就有机会在真正的组织中规模化。
为什么即使你更关注 .NET 这也重要
尽管这篇文章是针对 Python 的，我仍然认为这个模式值得关注，即使你主要工作在 .NET 生态中。
为什么？因为底层的疑问超越了语言选择：
技能如何在团队间演进而不变成一团乱麻？
答案很少是简单地"增加更多技能类型"。
答案几乎总是关于组合模型是否足够强大，能让这些技能类型干净地共存。
这就是我认为这篇文章做对的地方。
我的看法
即使你更关注 .NET 这边，这仍然是一个值得关注的模式，因为组合性决定了技能在跨团队传播时是否还能保持可维护性。
而一旦团队开始在仓库和内部生态中打包、共享和交换技能，这种组合性就比任何单一写作风格的语法重要得多。
原文：Agent Skills for Python: File, Code, and Class – Composed in One Provider
