«А ваш ИИ-агент это умеет?» — вопрос, из-за которого мы разложили агента на скиллы

Позвонил директор по развитию из компании, с которой мы работали уже полгода. Голос напряжённый: «Слушай, а ваш ИИ-агент умеет ещё вот это? Нам срочно надо». Мы честно ответили: «Сейчас нет, но за пару недель добавим». Клиент вздохнул. Через день он позвонил снова — с ещё одной задачей. И ещё. К концу недели у нас в списке было девять «умений», которые агент должен освоить, и очень нервный тимлид, который не понимал, куда всё это встраивать в текущий код.

Именно тогда мы поняли: пора хоронить монолитного агента и делить его на скиллы. А заодно перестать отвечать «за две недели» на каждый второй запрос.

Как выглядел агент до того, как мы всё сломали

Изначально это был один большой сервис на FastAPI, за ним GigaChat Pro, вокруг — набор функций-инструментов и один общий системный промпт на четыре тысячи токенов. Работало. Но каждое новое «а вы можете ещё…» превращалось в правку промпта, дописывание функции, тестирование всего сразу и надежду, что не сломается старое поведение.

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

Почему это была не ошибка кода, а ошибка архитектуры

Тут стоит остановиться и разобрать вещь, которую часто путают даже опытные IT-руководители. Отличие ИИ от агента ИИ — это не про мощность модели. Языковая модель сама по себе умеет одно: получать текст и возвращать текст. Она не звонит в 1С, не пишет в базу, не ждёт ответа от почтового сервера. ИИ-агент — это обвязка вокруг модели, которая даёт ей руки: инструменты, доступ к данным, память, циклы принятия решений, право самой решить, какой шаг сделать следующим.

И вот эти «руки» и есть скиллы ИИ-агента. Каждый скилл — это законченное умение: «оформить счёт», «найти клиента в CRM», «сравнить два договора», «поднять статус заявки». За скиллом стоит промпт-инструкция, набор функций-инструментов и правила, когда его вообще уместно применять.

Пока мы держали всё это в одной куче, у клиента и у нас было разное представление о том, что агент умеет. Клиент видел общее «он же ИИ, он всё может». Мы видели ворох условий в промпте.

Инфоповод, который дожал решение

В середине августа Confluent выпустили Agent Skills в open source — это пакет умений для кодовых ИИ-агентов, где каждый скилл про свою узкую задачу: миграция, работа с Kafka, UDF для Flink, ограничители. И это ровно та же логика, к которой пришли мы: не пихать всё в один большой промпт, а собрать библиотеку модулей, каждый из которых знает про одну область.

Идея не новая — Anthropic давно продвигают формат skills для кодовых ассистентов, — но именно широкий релиз в продакшене от вендора показал: индустрия сходится на этой модели. Значит, мы не изобретаем велосипед, а делаем то, что уже становится стандартом.

Что мы поменяли в архитектуре

Разложили агента на три слоя.

Первый слой — маршрутизатор. Маленькая быстрая модель, которая читает входящий запрос и решает, какой скилл (или связка скиллов) сейчас нужен. Не пытается ничего исполнить сама. Только смотрит: «это про счета — включай скилл "финансы"; это про поиск в CRM — включай "клиенты"». Если запрос составной, поднимает несколько.

Второй слой — сами скиллы. Каждый лежит в отдельной папке. Внутри — файл с инструкцией на естественном языке (что этот скилл умеет, чего не умеет, какие есть ограничения), набор функций-инструментов, тесты и метаданные. Скилл — самодостаточная единица: его можно включить, выключить, обновить отдельно от остальных.

Третий слой — исполнитель. Он берёт активные скиллы, склеивает их инструкции в контекст и передаёт большой модели. Дальше начинается обычный цикл ИИ-агента: модель решает, что делать, дёргает функции, читает ответы, идёт дальше.

Что дал этот пересбор

Первое и главное — у нас появился внятный ответ на «а ваш агент это умеет?». Теперь у клиента есть каталог скиллов. Открыл — увидел, что доступно, что в разработке, что мы принципиально не делаем. Аналог меню в кафе, а не гадания «принесут ли мне борщ, если попросить».

Второе — новые умения перестали ломать старые. Скилл живёт в своей папке, у него свои тесты. Добавили — прогнали регресс только по своей зоне, а не по всему агенту. Раньше на такое добавление уходил рабочий день, теперь спокойно укладываемся до обеда.

Третье — стало проще делегировать. Раньше добавить умение мог только человек, который держит в голове всю систему промптов. Сейчас это может сделать любой инженер, который прочитал инструкцию по скиллам. Мы перестали быть узким горлышком.

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

Про курсы и обучение — короткое отступление

Клиенты часто спрашивают: «А есть курсы по созданию ИИ-агентов, чтобы наш IT-отдел сам всё сделал?» Курсы есть, и хорошие — от Anthropic, DeepLearning.AI, российских школ. Мы даже сами делаем короткие обучающие интенсивы для команд заказчиков после запуска. Но проблема не в том, что нельзя научиться. Проблема в том, что курс даёт синтаксис и первые примеры, а не архитектурное мышление. Понять, что монолит — это тупик, и разложить агента на скиллы, — это уже опыт, а не лекция.

Поэтому наш совет тем, кто собирается разрабатывать ИИ-агентов внутри своей компании: не начинайте с одного большого промпта. Даже если задача одна. Заложите структуру скиллов сразу — потом переделывать больнее, чем построить с нуля.

Что осталось за кадром

Не всё гладко. Маршрутизатор иногда ошибается — поднимает не тот скилл или пропускает нужный. Это лечится, но требует своей телеметрии и разбора инцидентов. Есть скиллы, которые слишком часто зависят друг от друга — их пришлось объединять обратно, потому что искусственное разделение делало только хуже. И есть вопрос версионирования: клиент привык, что скилл ведёт себя определённым образом, а мы его обновили — надо явно управлять совместимостью.

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

А как у вас — держите умения агента в одном промпте или уже разложили? И что стало последней каплей?

Похожие статьи

• Закон об ИИ вступил в силу — заказчик переписал ТЗ на середине проекта: как мы пересобрали создание ИИ-агента и почти ничего не потеряли
• Кто такой этот ИИ-агент в вашей системе: почему создание ИИ-агента для бизнеса начинается с бейджа, а не с промпта
• ИИ-агент, который сначала думает, а потом делает: Plan-and-Execute на разборе тендерной документации
• Сколько стоит ИИ-агент: почему честный ответ начинается с проектирования, а не с прайса