Skill нужен для дисциплины порядка, а не для энциклопедии
14 августа 2026 на arXiv вышла работа Demystifying Agent Skills: Why They Work—Until They Don’t (Princeton, UC San Diego и соавторы). Сегодня снова резко выросла волна разборов. По 8 135 запускам агентов и разбору 240 траекторий главный вывод: 65,7% пользы Skill — от стабилизации порядка действий, а прямое добавление знаний объясняет только 4,5% улучшений. Параллельно растёт риск масштаба: точность фактического выбора Skill падает с ~29,6% при наборе из 5 до ~3,3% при 100.
Коротко
- Что обсуждают: исследование Demystifying Agent Skills — препринт от 14 августа 2026; сегодня снова усилилась волна разборов (сама работа не «новость последних суток», новая именно дискуссия).
- Кому полезно: тем, кто проектирует библиотеки Skills для Claude, Cursor и маркетинговых агентов; владельцам каталогов «у нас N Skills».
- Главное ограничение: цифры получены на terminal/tool-use бенчмарках и ограниченном наборе agent–model пар; авторы сами ограничивают обобщение на все типы агентных задач.
- Главное последствие: Skill стоит проектировать как методику работы, а не как свалку знаний; метрика каталога — качество маршрутизации, а не количество карточек.
Что изменилось
Авторы (Princeton, UC San Diego и соавторы) ставят вопрос не «улучшают ли Skills успех в среднем», а когда они помогают, почему работают и где ломаются.
Методика (по тексту препринта):
- Нормализовали 8 135 записей запусков из контролируемых экспериментов.
- Вручную / открытое кодирование разобрали 240 траекторий, оставили 238 валидных уникальных меток.
- Свели наблюдения в таксономию из трёх верхних категорий и двенадцати режимов использования Skill.
- Сравнивали представление одного и того же опыта как память рабочего процесса и как дистиллированный `SKILL.md`.
Самый неожиданный механизмный результат:
- 65,7% случаев пользы Skill приходится на процедурное якорение: Skill стабилизирует порядок действий — что проверить раньше, что сравнить потом, какую ошибку исключить, когда остановиться.
- Прямое добавление знаний объясняет только 4,5% улучшений.
Отдельно — узел маршрутизации. В экспериментах с пулом кандидатов точность фактического использования «правильного» Skill падала примерно с 29,6% при пуле из 5 Skills до 3,3% при пуле из 100. Авторы отдельно отмечают: точный выбор эталонного Skill не всегда обязателен для успеха задачи, но маршрутизация всё равно становится узким местом при росте библиотеки.
Сравнение представлений: Skill улучшает результат относительно памяти рабочего процесса примерно на 6,06 процентных пункта в matched-сравнениях (с доверительным интервалом bootstrap у авторов).
Почему это важно
Слабая архитектура знакома многим командам:
``` SKILL.md = всё, что мы знаем + сегментация + JTBD + клиенты + рынок + продукт ```
Более сильная:
``` ЗНАНИЯ НАВЫК факты какие шаги выполнить данные что проверить продукт какие ошибки исключить рынок какие доказательства нужны когда остановиться как выглядит хороший результат ```
Skill отвечает на вопрос «как правильно выполнить работу». Слой знаний отвечает на вопрос «что мы знаем». Смешение двух слоёв в одном файле даёт иллюзию «мощного навыка» и одновременно ломает переиспользование.
Второй рыночный сигнал ещё жёстче. Хвастовство «у нас 300 Skills» может быть антипреимуществом, если агент не умеет надёжно выбрать нужный.
Что это означает для бизнеса
| Подход | Что получаете | Типичный риск |
|---|---|---|
| Энциклопедия в `SKILL.md` | Много контекста в одном месте | Шум, слабая дисциплина шагов, раздувание файла |
| Skill как методика | Стабильный порядок проверок и стоп-критерии | Нужна отдельная база знаний и дисциплина версий |
| Плоский каталог из 100+ Skills | «Богатство» на слайде | Падение точности выбора нужного Skill |
| Двухэтапная маршрутизация | Задача → домен → Skill | Нужен маршрутизатор и оценка маршрутизации |
Для маркетинговых команд это значит: не раздувать один Skill «сегментация + JTBD + рынок + продукт», а разделять знания и процедуру. И не растить каталог без теста выбора.
Что протестировать
- Задача: проверить, помогает ли текущий Skill дисциплиной шагов или только «фактами».
- Сценарий: взять 10 реальных запросов команды; для каждого заранее зафиксировать «какой Skill должен быть выбран».
- Данные и инструменты: ваш каталог Skills + лог фактического выбора агента.
- Что сравнить: успех задачи при выбранном Skill vs попадание в «правильный» Skill; отдельно — качество при пуле 10 vs 50+.
- Метрики: precision фактического выбора; доля задач, где помог порядок шагов, а не новая фактология.
Практический тест, который я бы держала отдельно:
``` Оценка маршрутизации Skills 100 реальных запросов ↓ какой Skill должен выбрать агент? ↓ какой выбрал? ↓ почему? ```
Прогонять при каждом существенном расширении каталога.
Что это значит для ваших данных
Если вы собираете маркетинговую систему Skills (стратегия, перформанс, SEO/GEO, CRM, контент, аналитика), логичнее не отдавать агенту плоский список из сотен карточек, а ввести маршрутизатор по доменам:
``` ЗАДАЧА ↓ ДОМЕН (5–10 Skills) ↓ конкретный НАВЫК ```
вместо
``` ЗАДАЧА ↓ искать среди всего каталога ```
Для команд, которые держат Skills рядом с коннекторами и живыми данными бизнеса, этот вывод особенно практичен: сначала дисциплина процедуры и маршрутизация, потом объём библиотеки. Иначе рост каталога увеличивает шум выбора быстрее, чем качество работы.
Главный вывод
Новость суток здесь не в дате препринта, а в смене мышления: Skill — прежде всего методика работы, а не энциклопедия. Следующая важная метрика каталога — не «сколько Skills существует», а с какой вероятностью агент выбирает нужный Skill для реальной задачи. Пока этой метрики нет, масштабирование библиотеки легко превращается в антипреимущество.
Источники
- Demystifying Agent Skills: Why They Work—Until They Don’t — arXiv (Princeton / UC San Diego et al.), 2026-08-14
- AI agent skills study (overview) — Neura Market, 2026-08-23
Читайте также
Cainex: исправляйте принцип Skill, а не пример
Cainex в гайде Anthropic 20 августа: не костыль под кейс, а правка принципа Skill. Эталонный набор, регрессии, версии. Для маркетинговых навыков.
Anthropic: аналитика Skills и экономика агентных процессов
Anthropic измеряет Skills: стоимость запуска, действия коннекторов, MCP-записи и «насколько агентна работа». Какие метрики взять в MCP Panel и почему не делать главным KPI «сэкономленные часы».
Anthropic: Skills API в общей доступности
19 августа: Skills API и Files API в общей доступности, доменные ограничения веб-поиска, память в собственной среде и просмотр сессий со стоимостью. Жизненный цикл агента в промышленной эксплуатации.
Anthropic: Skills как корпоративная библиотека через Plugins
Anthropic 14 августа: централизованные Skills на Team и Enterprise. Один ZIP для всей организации или Plugin на группу — маркетинг, продажи, аналитика. Chat и Cowork из одного каталога.