Навыки AI-агента - это наборы инструкций, процедур и правил, которые агент подгружает под конкретную задачу: развернуть сервис, проверить данные, собрать отчёт. Пока навыков два-три, порядок в них держится сам. На десятках навыков плоский список перестаёт работать: агент не понимает, какой навык применить по своей инициативе, какой действует всегда, а какой обязан сработать по событию. Контекст раздувается, предсказуемость падает.
Разработчик под ником u/1ncehost взял решение из карточной игры Magic: The Gathering: в разборе на r/LocalLLaMA он разбил навыки на три категории по образцу типов способностей в MTG - активируемые (activated), статические (static, в его репозитории - passive) и триггерные (triggered).
Тип навыка отвечает на два вопроса: кто запускает действие и как долго оно действует. Активируемый навык агент запускает сам, статический работает постоянно в своей предметной области, триггерный срабатывает автоматически при наступлении заданного события. По словам автора, такое разделение повышает надёжность и снижает избыточность контекста: условия применения закодированы самим типом, а не пересказаны словами в каждом описании.
Что такое навыки AI-агентов и зачем их классифицировать
Навык упаковывает доменное знание или действие в отдельную единицу: текстовые инструкции, скрипты, справочные файлы, которые агент читает перед работой. Практика папок с файлом SKILL.md сделала такие единицы обычными, и центр проблемы сместился с хранения на описание. Держать навыки в одном каталоге мало: агенту нужен признак, по которому он поймёт, когда навык уместен.
Из описания «что делать» не следует «когда делать». Агенту приходится выводить момент применения из текста, а на длинном списке такие выводы съедают контекст и порождают ошибки. Чем больше навыков и политик в проекте, тем острее вопрос их учёта: в материале про governance для агентной разработки разобрано, как навыки, политики и фазы рабочего процесса связывают в управляемую схему вместо набора файлов.
Magic: The Gathering даёт готовый словарь. Текст внизу карты по сути представляет собой отдельный язык кодирования, а его основной блок называется способностью (ability) и обозначает эффект в игре. Способности разделены на типы, которые задают область и время действия эффекта, и автор считает эти типы напрямую переносимыми на навыки. Категории он собирал не с нуля: за два года разработки проектов с агентскими навыками накопились практики, которые он затем централизовал в публичном репозитории, чтобы переиспользовать наработки и стандартизировать свои проекты.
Три категории навыков: активируемые, статические, триггерные
В одном наборе навыков обычно встречаются все три типа. Различаются они инициатором запуска и временем действия, и это различие стоит фиксировать прямо в описании навыка.
| Категория | Кто запускает | Как действует | Пример |
|---|---|---|---|
| Активируемый (activated) | Агент по своему выбору | Набор процедур по шагам, один раз | Сделать резервную копию базы перед миграцией |
| Статический (static, passive) | Не запускается, действует фоном | Правило всё время работы в предметной области | При работе с финансами проверять валюту и часовой пояс |
| Триггерный (triggered) | Событие: действие агента или внешнее | Срабатывает каждый раз при событии | После каждого ответа проверять текст на политику безопасности |
Активируемые навыки: когда агент сам решает
Активируемый навык агент должен выбрать к применению сам, а внутри навык задаёт набор процедур, которые выполняются по порядку один раз. Резервное копирование, миграция схемы, сборка релиза - это процедуры с началом и концом. Агент решает, наступил ли момент, и запускает их.
Это самый привычный тип, и именно поэтому он легко вбирает чужие роли. Процедуру просто перепутать с постоянным правилом, если оба описаны одинаковым текстом без указания на характер действия.
Статические навыки: постоянные правила предметной области
Статический навык, в репозитории автора - passive, задаёт общие правила, которые применяются всё время, пока агент работает в конкретной предметной области. Это не последовательность шагов: момент запуска не нужен, правило действует фоном. «При работе с финансовыми данными всегда проверяй валюту и часовой пояс» - типичный статический навык.
Агент не выбирает такой навык, он попадает в область его действия вместе с задачей. Отсюда практический вывод: статические навыки удобно держать рядом с описанием домена, чтобы они подгружались вместе с ним, а не искались отдельно.
Триггерные навыки: автоматическая реакция на событие
Триггерный навык похож на активируемый, но обязан срабатывать каждый раз, когда происходит заданное событие. Событием может быть что угодно: действие агента или внешнее событие, например течение времени. Проверка ответа на соответствие политике после каждой генерации, сохранение промежуточного состояния по таймауту, отправка уведомления после сборки отчёта - всё это триггеры.
Отличие от активируемого принципиальное: инициатор - не агент, а событие. Агент не может забыть применить триггерный навык, если событие наступило, и не должен решать, уместен ли он в этой ситуации.
Как классификация повышает надёжность и снижает избыточность контекста
Эффект складывается из двух частей. Первая: предварительное понимание. Тип в описании навыка сразу задаёт агенту рамку - запускать самому, соблюдать постоянно или ждать события. Ему не нужно выводить это из текста инструкции на каждом шаге рассуждения.
Вторая: экономия контекста. Когда условия применения закодированы типом, описание навыка сжимается: длинные пояснения «применяй этот навык, если...» заменяет одна категория. Автор пишет, что подход хорошо работает для передачи агенту значительного объёма контекста об области применения навыка при минимальной многословности.
Separating the skill into these categories lets the agent have some preconceived ideas about how the skill should be used, which increases reliability and decreases context redundancy.
Перевод: разделение навыка по этим категориям даёт агенту предварительные представления о том, как его использовать, что повышает надёжность и снижает избыточность контекста. Формулировка принадлежит автору подхода (исходный пост), и это его оценка, а не результат измерений: цифр и метрик он не приводит.
Практические примеры: как это выглядит в проекте
Возьмём абстрактного агента, который готовит отчёты. Один и тот же функционал раскладывается на три типа без потерь:
- Активируемый: «собери месячный отчёт» - процедура из шагов: запросить данные, посчитать метрики, отрендерить документ, сохранить.
- Статический: «всегда используй корпоративный шаблон», «проверяй часовой пояс в датах», «не выгружай персональные данные в отчёт». Эти правила действуют, пока агент работает над отчётами.
- Триггерный: «после сохранения отчёта отправь уведомление ответственному», «если прошло 10 минут без прогресса, сохрани промежуточную версию».
Разделение упрощает отладку и тесты, потому что у каждого типа своя проверка. Активируемые навыки тестируются как сценарии: запустили, прошли шаги, сверили результат. Статические - как инварианты: подсунули данные из области и убедились, что правило не нарушено ни в одном ответе. Триггерные - как события: сымитировали условие и проверили, что реакция наступила ровно один раз.
Событийные проверки - та часть, где чаще всего ломается наивный подход: триггер либо не срабатывает, либо дублируется. Как устроены проверки и evals у зрелых агентных продуктов, разбирается в отдельном материале о том, как Cursor выстраивает доверие к ИИ-агентам через верификацию, skills и строгие CI-проверки.
Пример выше - иллюстрация принципа, а не описание конкретного продукта: состав навыков и формулировки правил в каждом проекте свои.
Что ещё есть в репозитории: самоулучшение, тесты, документация
Классификация - одна из идей, которые автор собрал в публичном репозитории. Кроме неё там описываются:
- система самоулучшения навыков, вдохновлённая hermes;
- организация тестовых процессов;
- стиль и методология документации.
Цель репозитория - переиспользовать наработки и стандартизировать проекты с агентскими навыками, поэтому он интересен не только самой схемой категорий. Ссылку на репозиторий автор приводит в исходном посте на r/LocalLLaMA (обсуждение подхода).
Ограничения и подводные камни подхода
- Опыт личный. Автор обобщает два года собственной разработки, а не результаты формального исследования или независимой проверки. Метрик надёжности и экономии контекста он не приводит, в исходном посте эти эффекты даны как субъективная оценка.
- Терминология расходится. В репозитории статические навыки называются passive, в посте - static. При переносе схемы в чужой проект это стоит проверять, чтобы не спорить о названиях вместо сути.
- Границы триггеров открыты. Событием может быть что угодно, включая течение времени. Два триггера легко накладываются друг на друга или конфликтуют с активируемым навыком, который делает то же самое.
- Не каждый навык попадает в одну категорию. Процедура может содержать правила, которые логичнее вынести в статический навык, а реакция на событие иногда уместнее как явный шаг процедуры.
- Для маленького набора это лишняя работа. Агенту с двумя-тремя навыками три уровня классификации ничего не добавляют к понятности.
Автор описывает подход как идею для обсуждения и приглашает предлагать улучшения, так что воспринимать его как готовый стандарт не стоит. При росте числа ролей и навыков отдельной проблемой становится координация: в материале о масштабировании автономных AI-систем разобрано, во что обходится автономность и какие механизмы контроля удерживают систему управляемой.
Как начать применять подход в своём проекте
- Выпишите все навыки агента в один список, включая те, что живут прямо в системном промпте и потому обычно не считаются навыками.
- Для каждого ответьте на вопрос «кто инициирует»: агент сам, область работы или событие. Ответ задаёт категорию.
- Разнесите правила по трём группам: процедуры - в активируемые, постоянные ограничения и договорённости - в статические, реакции на события - в триггерные.
- Перепишите описания так, чтобы тип считывался с первых строк, и уберите пояснения о моменте применения: за них теперь отвечает категория.
- Прогоните агента на типовых задачах и смотрите на два признака: не запускает ли он активируемый навык без нужды и срабатывают ли триггеры там, где не должны.
- Переклассифицируйте спорные случаи. Навык, который вы дважды перенесли из категории в категорию, скорее всего, стоит разделить на два.
Начать достаточно с одного набора из пяти-десяти навыков: разметьте их, сохраните как шаблон и подключайте к новым проектам. Когда наборов станет много, на первый план выйдет управление ими, а не создание новых: материал про governor shift показывает, как принципы и пороги заменяют разрастающиеся своды правил.
Рабочий критерий простой. Если после разметки агент перестал путать процедуры с постоянными правилами, а описания навыков стали короче без потери смысла, схема прижилась. Если список снова схлопнулся в один текстовый блок без пометок типа, категории не закрепились и разметку стоит перенести в явные метки внутри самих файлов навыков.