Comments 11
Пока нет строгих контрактов, тестирования и воспроизводимости, Skill остается скорее хорошо оформленным промптом, а не полноценным алгоритмом. Сравнение с кодом выглядит преждевременным.
Получается, что с развитием AI нам снова приходится возвращаться к базовым принципам разработки, разделять ответственность, правильно строить процессы и думать об архитектуре. Похоже, что за AI-агентами будущее, и важно уже сейчас учиться с ними работать
Паттерны разумные, но у меня от статьи остался вопрос крупнее самих паттернов.
Мы по инерции считаем агентное программирование очередным подъёмом уровня абстракции: был ассемблер, стал C, стали фреймворки, теперь markdown — и к нему, как ко всему предыдущему, положено прилагаться методологии, стилю и своду правил. Кажется, это не тот случай. Подъём абстракции — это когда человек продолжает писать, только короче. А здесь меняется не длина, здесь меняется тот, кто пишет.
Отсюда прямой вопрос автору: вы эти скиллы пишете руками? В статье 27 тысяч знаков о том, как их правильно структурировать, и ни слова о том, что структурировать их может сам агент. Если руками — то почему именно руками? Если нет — то это и есть самая интересная часть текста, и её в тексте нет.
У нас в конторе скиллы заказываются примерно так: «Я устал вспоминать, почему вчера, работая в десяти параллельных сессиях Клода, принял то или иное решение. Клод, напиши скилл, чтобы хуком на коммит и на выход сессия сохранялась в каталог под гитигнором, и чтобы ты потом мог туда слазить и напомнить». Ни одного из трёх паттернов я при этом в голове не держал. Через 20 минут у меня был работающий скилл, сегодня им пользуются ещё три человека в конторе (да, я в курилке похвастался, но не форсил). Оговорюсь сразу: проверить его было тривиально — сессия либо сохранилась, либо нет, критерий бинарный и виден в первый же день.
А вот проверяется это дёшево далеко не всегда. Возьмите текст этой самой статьи, отдайте агенту и попросите скилл по производству скиллов. Первый черновик выйдет минут за десять — три паттерна изложены достаточно формально, чтобы модель их разложила. Беда в том, что черновик этот ничего не стоит: у него нет бинарного критерия. Пока он не прогнан на полусотне реальных задач, неизвестно, меняет ли он выход агента вообще хоть как-нибудь. И вот эта проверка — уже недели, и её не делегируешь ни агенту, ни статье.
Получается, узкое место не в том, как писать скиллы. Оно в том, как понять, что написанный работает. Вот про это я бы почитал.
Кто будет писать — не важно, важен принцип. Мы пишем комбинировано, что-то агент (и это большинство), что-то руками, иногда попросить агент дольше и дороже, чем написать руками пару строк в Markdown. Но тут вопрос не в этом, вопрос в том, что если агент напишет за вас Skill насколько вы будете понимать, как он работает и что там вообще написано? Это может показаться неважным если у вас десяток Skills и небольшой проект, но если у вас 100+ Skills, а если 1000+, то уже нужно уметь управлять тем, что они делают, а для этого процесс требует систематизации. Я нашел для себя такой способ и решил поделиться им сейчас потому, что он уже успешно работает и хорошо себя зарекомендовал у нас в команде, вы можете найти свой и поделиться им, мне было бы очень интересно посмотреть на другие решения. Мы все сейчас находимся немного "в творческом поиске" и я не исключаю, что возможно найдется решение лучше.
Про масштаб принимаю, довод честный. На десятке скиллов всё держится в голове, на тысяче не держится.
Смущает меня другое место в вашей формулировке. «Насколько вы будете понимать, как он работает» — при тысяче скиллов вы не понимаете их глазами в любом случае, кто бы их ни писал. Тысячу, написанную руками, вы точно так же не удержите. Систематизация решает навигацию: где лежит, за что отвечает, кто с кем связан. А вот вопрос «делает ли оно то, что я думаю» она не закрывает, и чем больше скиллов, тем сильнее эти две задачи расходятся.
Раз позвали поделиться — вот наш способ, он глупый и рабочий. Все скиллы, которыми бойцы в конторе решили поделиться, лежат во внутренней репе, в папочках. Есть скрипт, который перед пушем переделывает оглавление и проставляет ключевики (через запрос к LLM), результат выкладывается в TOC.md. Поэтому я могу спросить агента: «а есть у нас скиллы, чтобы CODEOWNERS заполнить?» — и он найдёт.
Но это ровно навигация и ничего сверх неё. Что скилл после правки стал делать не то, наш TOC не поймает, и мы пока ничем не ловим.
Отсюда встречный вопрос, и он мне правда интересен: а у вас есть регресс на сами скиллы? Когда правите один из тысячи, чем вы ловите, что поведение агента поехало? Вот эту часть я бы прочитал отдельной статьей!
а у вас есть регресс на сами скиллы?
На Skills нет, на рабочий процесс которые эти Skills обслуживают — да. Я оставил ссылку на нашу платформу, в ней есть такое понятие как pipelines, они представляют из себя способ декларировать конвейер который агенты должны исполнить и это не просто Skills, это может быть несколько Skills workflow запущенные параллельно или последовательно в разных агентных сессиях, у этого piplelines есть UI интерфейс через который можно регрессировать процесс хоть UI тестами, он так же умеет писать свое состояние и runtime log на файловую систему, что позволяет написать функциональные тесты. Агент может немного по разному задавать вопросы и писать вывод, но якоря и стадии не меняются если Skills - это алгоритм, а не 1000 строк требований и ограничений, половину из которых агент никогда не исполнит. Артефакты между стадиями шаблонезированы и могут быть верифицированы. Да и в целом это конечный автомат который полностью детерменирован. Можно пойти дальше и обрастить процессы метриками, обновлять Skills и смотреть где-нибудь в Grafana, как изменяются метрики процессов и результатов которые мы ожидаем. Поэтому я не вижу смысла в принципе регрессировать сами скиллы, когда можно регрессировать и мониторить процессы которые эти скилы обслуживают.
На мой взгляд, тут гораздо более интересный вопрос в том, что делать если регрессия показала деградацию =) Но это тема отдельной статьи =)
Десятилетиями мы учили разработчиков, что Markdown - это документация.
Мадрид бодрит, прямо таки захотелось к вам записаться на ближайшее десятилетие...
Сколько бессмысленного текста ради рекламы своего канала. Жуть
Помоему польза есть. Хотя бы напомнили, про фокус и контекст, и как с ними лучше обходиться, если делать качественный скилл/процесс.
Возможно агенты сами будут именно так делать свои скилы / процессы потом. Но пока не делают, если не попросить, поэтому статья даёт некое преимущество читателю.
Ну а рекламой, кто уж тут не грешит 🙂
Интересное наблюдение - если "три паттерна" написать слитно, как "трипаттерна", то это прозвучит, как название какого-то заболевания
Для меня это звучит как вид какой-то рептилии, червячка или бактерии)
А текст для ИИ мне напоминает документацию, которую до ИИ мы писать разучились. А когда-то до эпохи извращенного понимания Agile-ов и Scrum-ов, мы доки писали по таким же принципам как и софт, продумывая наперед, соблюдая структурирование и делая рефакторинг, просто их клиентом был человек. А теперь промпты - это наш вербальный фронтенд для LLMок, такая же по сути дока как и обычное правильное ТЗ из индустриальной эпохи. Может, ИИ даже возродит Waterfall, кто знает..
Три паттерна написания Agent Skills