Бизнес-скиллы для AI-агентов

На дворе 2026 год, почти весь код пишут нейронки, программистам пророчат скорую смерть. Я уже тоже почти не пишу код сам, но это не избавило меня от работы, напротив - если раньше большую часть времени я занимался комфортным для себя делом - писал и рефакторил код, то теперь моя полезная рабочая нагрузка сместилась в область бизнес-аналитики, где для каждой задачи нужно нормально так напрячь мозги.

Вместо написания кода время теперь отнимает ревью. На своих пет-проектах можно обойтись и без ревью - какая разница, как оно там работает, если денег не приносит и пользуешься ты один. Но в случае с коммерческим продуктом, где ты лишь наемный исполнитель, ответственность за написанный код никуда не девается. В случае факапа увольнять будут человека, а не нейронку.

Значит, без ревью не обойтись, но как снизить когнитивную нагрузку? Как избавиться от рутины и действительно перейти от роли няньки для агентов к роли бизнес-аналитика или кого-то вроде?

Ищем корень проблемы

Какой самый очевидный шаг в оптимизации ресурсов на ревью и правки? Делегировать это ревью и правки другому агенту? Нет, это путь в ад, потому что в этом случае ты ничего не контролируешь. Правильный шаг - научить агента писать такой код и принимать такие решения, словно это ты сам.

У каждого взрослого проекта есть свои нюансы, например:

кодовая база неидеальна, есть компромиссы, на которые пришлось пойти
архитектура сильно отличается от примеров, на которых обучались модели
особенности запуска команд, например тестов или сборки
использование кастомных пакетов и либ, о которых нейронка ничего не знает
и т. д.

Этот дифф между базовыми знаниями модели и реальным проектом и порождает впоследствии ту самую рутину: агент запускает не то, пишет классы не туда и делает кривой нейминг. Всё это приходится исправлять либо руками, либо снова составляя список правок.

Эволюция тулинга и инструкций

Напрашивается решение - описать все эти нюансы один раз, чтобы не повторять каждый раз. Для этого сначала использовали системные промпты, всякие там поля персонализации, которые вставляются в каждую сессию, но с развитием harness и коддинг-агентов такие инструкции перекочевали в AGENTS.md.

Файл AGENTS.md стал главной свалкой правил для агентов: туда складывали правила форматирования кода, архитектуры, запуска инструментов и какие-то бизнес-правила. Удобство в том, что файл читается агентом каждый раз при старте сессии и туда как раз можно завернуть все ожидания, чтобы не повторяться каждый раз. Но когда файл разрастается, он начинает занимать все больше контекста, результаты становятся так себе, а стоимость растет.

Скажем, задача модели - всего-то поправить кнопочку, но при этом через AGENTS.md подгружается весь кладезь знаний о проекте на 200к+ токенов. Ничем хорошим это не кончится. Напрашивается решение - разбить знания на маленькие кусочки и подгружать по мере необходимости.

Таким образом, AGENTS.md начал превращаться из свалки всего подряд в короткий индекс. Вся документация и все ожидания лежали где-то отдельно, например в docs/ или даже в .agents/docs/, а сам индекс только указывал на то, какие файлы там есть и в каком случае их нужно прочитать. Уже что-то напоминает? Да, этот паттерн прижился и позже переродился официально в виде стандарта для Skills.

Технические Skills

Skills - это упакованные и разбитые по отдельным частям знания, которые должны быть доступны, но подгружаются только по необходимости.

Обычно скилл выглядит как папка .agents/skills/{skill}/ (для Codex также подходит .codex/skills/{skill}/) с главным Markdown-файлом SKILL.md: в YAML-шапке указываются обязательные параметры name и description, ниже идет тело с инструкциями, а рядом при необходимости лежат папки references/, scripts/ и assets/. Подробную спецификацию можно посмотреть тут.

Например, можно один раз описать агенту, как подключаться к удалённому серверу и запускать там нужный скрипт, а затем попросить его сделать из этого навык. Тогда он упакует последовательность команд, сведения о том, что и где лежит на сервере и как это запускать, в небольшой файл и сохранит его для будущих сессий. В минимальном варианте выглядеть это будет вот так:

---
name: deploy
description: Use when you need to run deployment on the remote server.
---
Connect to the server, pull the latest changes and run the deployment script:
`ssh user@yourhost 'cd /home/user/repo && git pull && ./scripts/deploy.sh'`

Или, скажем, у вас на проекте сложная инфраструктура: всё завёрнуто в Docker, и тесты нужно запускать внутри контейнера. Но без этого знания агент каждый раз будет пытаться использовать локальный интерпретатор для тестов и каждый раз разбираться с этой проблемой. Вместо этого, один раз описав нужные действия агенту и попросив из этого сделать скилл, мы избавляемся от этой рутины в будущем.

Что можно отнести к техническим скиллам? В первую очередь всё, что касается tooling и инфраструктуры: тесты, сборки, запуск линтера и, возможно, работа с дебаггером. Еще супер удобно, когда у агента есть доступ к трекеру ошибок и трекеру задач. В целом, все инструменты, которые нужны тебе, нужны и твоему агенту.

То же касается и всяких тонкостей и нюансов. Например, база данных неприлично огромная, и на ней нельзя просто так делать select * from events, иначе все повиснет - агент должен это знать. И лучшее место для такого знания - скилл по работе с БД: как подключаться, как выполнять запросы, куда делать бэкапы, как импортировать из файла, а также запрещающие правила.

Архитектурные и code-style Skills

Code-style правила частично решаются всякими линтерами, но есть, скажем, пожелания к виду кода, чтобы его легко было ревьюить. Для этого создаётся скилл с описанием предпочтительных конструкций, например:

- use fail-fast principle instead of nested if-else statements:

if ($something) {
    return false;
}

- extract complicated conditions from "if" statements into something human-readable:

$isApplicable = $something && $anotherThing && $yetAnotherThing;

if ($isApplicable) {
    return true;
}

- never use dynamic method calls, e.g. $model->{$method}()

- never use dynamic class names, e.g. $class = "MyClass"; $obj = new $class();

Такой скилл должен служить упрощению кода - чем код проще, тем он легче читается и воспринимается. Ревью должно проходить как чтение лёгкой книжки. Всякие крутые, но неочевидные техники и сложно прогнозируемую магию приносим в жертву простоте и предсказуемости.

А вот архитектурный скилл задает уже более глобальные правила, например:

описание нэймспейсов, доменов, что где лежит
ожидания от того, как разбивать логику: большие сервисы и атомарные экшены
нужно ли поддерживать пустые слои или упрощать при любой возможности

Ок, допустим, мы описали все наши пожелания по генерации кода и таким образом создали что-то вроде джуниор-разработчика, может даже мидла, который может решать базовые задачи и делать мелкие правки. Но как сделать из него сеньора? Такого агента, с которым действительно можно посоветоваться при проектировании фичи. Чего ему не хватает? Ему не хватает знаний о бизнесе.

Зачем коддинг-агенту понимать, как устроен бизнес?

Тут начинается самое интересное, и об этом пока мало кто пишет. Допустим, мы избавились от рутины и переложили на агентов всякую ручную возню и мелкие фиксы. Простые задачи вроде “добавить фильтр в админку” или “поправить колонки в отчёте” можно сразу делегировать агенту.

Но более сложные вещи вроде “добавить в админку раздел для импорта товаров сторонних поставщиков” требуют дополнительных знаний, которые в коде не отражены, например:

кто такие “сторонние поставщики”?
какие правила ценообразования для этих поставщиков?
какие типы файлов для импорта? Какая структура внутри?
какие роли пользователей должны иметь доступ к этому разделу? И т. д.

Разработчик, который уже давно на проекте, понимает задачу с полуслова: он понимает, как происходит работа в офисе, и уже знает ответы на эти вопросы. Но агент про этот бизнес-процесс не знает ничего. И здесь снова начинается рутина, но уже на другом уровне: нужно описать агенту, что именно и в каком виде нужно создать, какой результат должен быть, какие файлы для примеров нужно смотреть и т. д.

В лучшем случае агент может пройтись по файлам, найти релевантные места и попытаться восстановить по туманным и загадочным правилам и условиям представление о том, какие процессы стоят за этим в офисе. Во-первых, это неоптимально: если у агента нет источника истины, он каждый раз будет пытаться восстановить этот смысл снова и снова. Во-вторых, нет гарантий, что в следующий раз он представит себе эти процессы таким же образом. Ну и самое главное - если код является источником истины, значит, нельзя его менять: агент будет стараться сохранить существующую логику в тех случаях, когда новая задача неявно подразумевает, что логику можно упростить или изменить. Появляются всякие ветки логики с “обратной совместимостью” там, где она вовсе не нужна.

Хотелось бы, чтобы у агента было понятное представление о том, как кастомеры используют приложение, как происходит работа офиса с админкой, какие бывают неочевидные сценарии и всё такое. И для этого, конечно, тоже отлично подходят Skills.

Business-Skills и как их проектировать

В случае с техническими скиллами всё просто - мы один раз показываем агенту, какие действия нужно выполнить по шагам и все, скилл готов. Но чтобы завернуть знания о бизнесе в скилл, нужно подумать над структурой, ведь это не последовательность действий, это набор описаний процессов, терминов, особых случаев и сущностей из реального мира. Как к этому подойти?

Обратимся к самому механизму выбора скиллов агентом: агент видит короткое описание в духе “используй этот скилл для Х”. Это описание является своеобразным хуком или триггером для модели, там должны быть ключевые слова, однозначно определяющие границы знания, которое он содержит. Если описание слишком абстрактное или неочевидное, агент проигнорирует скилл как нерелевантный, а если слишком широкое по смыслу, то агент будет подгружать его даже в тех случаях, когда не стоило бы.

Тут мы сталкиваемся с примерно такой же задачей, как и в случае с архитектурой кода: нужно разбить знания на атомарные части с вложенной структурой и понятной точкой входа. Структура будет зависеть от проекта: например, можно разбить знания по фичам, если их немного, а процессы, стоящие за ними, не особо сильно пересекаются. А можно разбить по областям применения, например на админскую и клиентскую стороны - такая разбивка хорошо ложится на екоммерс-приложения, где кастомеры и менеджеры используют разные части продукта.

Ключевое правило - отталкиваемся от реальных процессов:

кастомер выбирает товары и совершает покупку
менеджеры обрабатывают заказ
админ импортирует товары и т. д.

Для типичного екоммерс-приложения можем начать с такой структуры:

./agents/skills/business-catalog/SKILL.md
./agents/skills/business-purchases/SKILL.md
./agents/skills/business-fulfillment/SKILL.md

В business-catalog выносим всё то, что касается поиска и выбора товаров пользователем: как работают фильтры, как ранжируются товары, как отображаются цены, что важного на карточке товара и т. д.

В business-purchases будет храниться всё, что касается процесса покупки: способы оплаты, виды скидочных кодов, как применяются скидки, как работают ваучеры, какие события аналитики должны срабатывать и т. д.

А в business-fulfillment уже упаковываем процессы работы с созданными заказами: статусы заказа и какие процессы стоят за ними, переходы между статусами, какие уведомления должны приходить пользователю, как происходит отмена заказа, возврат и т. д.

Каждый из этих скиллов можно разбить на поддокументы, например в business-fulfillment можно сделать отдельные документы по каждому процессу: отмена заказа, возврат, завершение и т. д.:

./agents/skills/business-fulfillment/references/cancel-order/SKILL.md
./agents/skills/business-fulfillment/references/return-order/SKILL.md
./agents/skills/business-fulfillment/references/complete-order/SKILL.md

Тогда сам файл business-fulfillment/SKILL.md будет содержать ссылки на эти поддокументы:

- Read `./references/cancel-order.md` for cancellation process details
- Read `./references/return-order.md` for return and refund workflows
- Read `./references/complete-order.md` for order completion details

Да, это как раз похоже на то, с чего мы начинали, - разбиение разжиревшего AGENTS.md на мелкие документы. И да, это тоже в определённом смысле теперь работа разработчика или бизнес-аналитика - описывать термины, бизнес-правила, статусы, назначение страниц и кнопок, ожидаемое поведение, назначение особых флагов в моделях и прочее. Не исключаю, что в IT-командах появится отдельная роль, которая будет заниматься только этим.

Best Practices для бизнес-скиллов

У меня есть только капитанские советы в духе “делай хорошо, не делай плохо”. Но область новая, других пока просто нет:

Не усложняй раньше времени. Начни с одного плоского индекса внутри скилла, искусственная группировка на раннем этапе только мешает.
Если контент одного документа занимает больше условных 4к символов, имеет смысл задуматься над разделением на дочерние документы.
Основной принцип разделения: если агент загрузит этот файл целиком, с какой вероятностью ему потребуется вся информация из файла?
Делай перекрёстные ссылки. Удобная структура для агента - это хорошо связный граф. Понятная иерархическая структура важна только для человека, так что сильно заморачиваться над ней не стоит.
Мониторь, какие скиллы и документы агент загружает по ходу работы: чтение нерелевантных документов или пропуск релевантных - это повод поработать с описаниями.

Самые отбитые могут попробовать сделать специальный скилл, чтобы агент сам составлял и разбивал бизнес-скилы. Например, ты просто кидаешь ему текст созвона, а он сам вычленяет бизнес правила и что-то куда-то складывает. Но это уже совсем другой уровень ~~лени~~ мастерства, а вероятность получить помойку на выходе гораздо выше.

Чтобы это не превращалось в помойку, можно подсмотреть идеи из garrytan/gbrain. Например, неплохая идея - хранить неизменные источники из чатов, созвонов, описаний, а на их основе уже синтезировать бизнес-скилы. В этом случае, если модель что-то напридумывала, то можно хотя бы перепроверить это по источникам.

Разработка никуда не делась

Из мясных печатных машин разработчики превратились в кукловодов для агентов. Раньше мы группировали и структурировали код, рефакторили его и проектировали архитектуру, думали, как разные части приложения взаимодействуют и как между ними передаются данные. Теперь об этом думают нейронки, но возникает новая инженерная и довольно сложная задача - спроектировать навыки, настроить инструменты и самих агентов. То есть разработка перешла в другую плоскость, но по сути никуда не делась.

И это интересно. Это новая область для исследований и экспериментов.