https://thedotnetblog.com/ru/tags/composition/Articles, tutorials and insights from the .NET community.Hugoru@thedotnetblog (The .NET Blog)@thedotnetblogTue, 09 Jun 2026 00:00:00 +0000https://thedotnetblog.com/ru/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/Tue, 09 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ru/news/emiliano-montesdeoca/agent-skills-python-composition-patterns/Последний пост об Agent Skills для Python формально посвящён файловым, классовым и inline-skills, но более важная идея — композируемость из разных источников без переписывания модели провайдера.<p>Это один из тех постов, где конкретный языковой фокус уже, чем архитектурный урок.</p> <p>Да, статья про <strong>Agent Skills для Python</strong>.</p> <p>Но более интересная мысль — про <strong>композицию</strong>.</p> <p>Возможность смешивать файловые, классовые и inline-skills через единую модель провайдера — это именно то, что заставляет фреймворк ощущаться масштабируемым, а не просто симпатичным.</p> <h2 id="важный-сдвиг--не-файл-против-класса-против-inline">Важный сдвиг — не «файл против класса против inline»</h2> <p>Статью легко прочитать как матрицу возможностей:</p> <ul> <li>skills на основе файлов</li> <li>skills на основе классов</li> <li>inline-skills</li> </ul> <p>Это полезно, но не главная архитектурная мысль.</p> <p>Главная мысль в том, что фреймворк упрощает <strong>композицию возможностей из нескольких источников без переписывания истории провайдера каждый раз</strong>.</p> <p>Именно эта часть имеет значение, когда skills переходят от небольшого демо к реальному командному окружению.</p> <h2 id="строка-на-которой-я-бы-сосредоточился">Строка, на которой я бы сосредоточился</h2> <p>В исходной статье говорится, что skill из локального репозитория, упакованный skill из внутреннего индекса и «<strong>быстрый inline-мост, который вы написали десять минут назад, — всё это подключается к одному и тому же провайдеру</strong>».</p> <p>Именно это предложение выполняет всю реальную работу.</p> <p>Потому что именно здесь начинает проявляться поддерживаемость.</p> <p>Если команды могут смешивать:</p> <ul> <li>упакованные skills</li> <li>временные мосты</li> <li>skills из локального репозитория</li> <li>будущие замены</li> </ul> <p>не переписывая каждый раз внутреннюю «сантехнику» агента, тогда у системы skills есть шанс масштабироваться в реальных организациях.</p> <h2 id="почему-это-важно-даже-если-вы-больше-сфокусированы-на-net">Почему это важно, даже если вы больше сфокусированы на .NET</h2> <p>Даже несмотря на то, что этот пост специфичен для Python, я всё равно считаю этот паттерн достойным внимания, даже если вы в основном живёте в .NET.</p> <p>Почему? Потому что базовый вопрос шире, чем выбор языка:</p> <p><strong>как skills развиваются между командами, не превращаясь в беспорядок?</strong></p> <p>Ответ редко сводится просто к «больше типов skills».</p> <p>Почти всегда дело в том, достаточно ли сильна модель композиции, чтобы эти типы skills могли чисто сосуществовать.</p> <p>Именно это, на мой взгляд, статья делает правильно.</p> <h2 id="моё-мнение">Моё мнение</h2> <p>Даже если вы больше сфокусированы на стороне .NET, это всё равно полезный паттерн, за которым стоит наблюдать, потому что композируемость — это то, что определяет, останутся ли skills поддерживаемыми по мере распространения между командами.</p> <p>И как только команды начинают упаковывать, делиться и обменивать skills между репозиториями и внутренними экосистемами, эта композируемость становится намного важнее синтаксиса любого отдельного стиля написания.</p> <p>Оригинальный пост: <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>