Вот сижу, разбираюсь с этим апдейтом Skills, что-то тестирую.
И бац, мысля в голову прилетела.
Ведь всё, что ново-модно сейчас обсуждать с агентами в разработке
Декомпозиция. Специализация. Оркестрация. КонтрактыВсё это используем уже десятилетия в микросервисах.
Фундаментально решить пытаемся одну и ту же задачу:
Как управлять сложностью через декомпозицию?
Микросервисы разбивают монолитное приложение на независимые сервисы.
А skills разбивают сложную задачу на специализированные "навыки", которыми владеет агент.
| Микросервисы | Skills |
|----------------------------------|---------------------------------|
| Независимые deployment units | Независимые SKILL.md файлы |
| API контракты (OpenAPI) | Контракты на естественном языке |
| Service discovery | LLM-роутинг по описаниям |
| Оркестрация (K8s) | Оркестрация через LLM |
Обе архитектуры обещают: модульность, переиспользование, независимую эволюцию компонентов, возможность комбинировать базовые блоки в сложные системы.
Но как справедливо отмечает Guille Ojeda в своём анализе:
Они обе делят сложность на управляемые части, но делают это по разным причинам и делят разную сложность.
Фундаментальное различие: зачем мы декомпозируемМикросервисы: структура приложения
Микросервисы появились как ответ на боли монолита: медленные релизы, неэффективное масштабирование, технологический lock-in, каскадные отказы. Это паттерн софтверной архитектуры, направленный на улучшение жизненного цикла разработки.
Декомпозиция в микросервисах привязана к бизнес-доменам — стабильным концепциям предметной области. Сервис CatalogService управляет каталогом товаров. PaymentService — платежами. Границы сервисов отражают границы бизнеса, что обеспечивает долгосрочную поддерживаемость.
Skills: структура задачи
Skills появились как ответ на ограничения LLM: сложные задачи требуют многошаговых процессов, доступа к внешним инструментам, сохранения контекста. Это паттерн AI-системного дизайна, направленный на достижение автономного, целеориентированного поведения.
Декомпозиция в Skills привязана к логике выполнения задачи — функциональным шагам, ролям, рабочим процессам. Skill pdf знает, как извлекать текст из PDF. Skill code-review знает, как проводить ревью кода. Границы Skills отражают границы экспертизы, а не бизнес-домены.
Ключевой инсайт:
Микросервисы декомпозируют структуру приложения. Skills декомпозируют процесс решения задачи.
Ради этой таблички пишу постВ AI-native разработке формируется своя иерархия:
| Уровень | Традиционный | AI-Native |
|------------|----------------------------|-----------------------------------|
| Атомарный | Функция | Tool (Read, Write, Bash) |
| Экспертиза | Модуль | Skill (домен + workflow) |
| Автономный | Сервис | Agent (reasoning + tools) |
| Система | Приложение | Agentic Workflow |
И почему же
не получается полностью перенести весь "опыт" разработки на агентские рельсы?
Мысль то моя не нова и есть десятки репозиториев со сложными сценариями на десятки агентов, со сложными сценариями, которые "копируют" процесс разработки и автоматизируют его.
НО дальше концепта и звезд на GitHub не идет?
___
Bounded Contexts из Domain-Driven Design отлично работают для микросервисов, но плохо подходят для Skills. Skill декомпозируется по функциональным шагам, а не по доменным границам.
Попытка создать "UserProfileSkill" по аналогии с "UserProfileService" приведёт к размытым границам и неэффективному использованию.
Заключение
Skills — это не "микросервисы для AI". Это новый архитектурный паттерн, который заимствует идеи декомпозиции из микросервисного мира, но применяет их к принципиально другой проблеме: оркестрации интеллектуального поведения.
