Router skills: обязательный паттерн когда библиотека навыков агента перерастает 50 штук
Когда у агента накапливается 50+ навыков, точность выбора правильного инструмента падает. Router skills — промежуточный слой маршрутизации, который решает эту проблему на архитектурном уровне.
Проблема, которую замечаешь не сразу
У каждого, кто строит агентов, есть момент эйфории: ты подключаешь скилл за скиллом, агент умнеет на глазах. Поиск по базе, генерация кода, работа с файлами, API-вызовы, аналитика — всё работает. На 10-15 навыках.
Потом библиотека дорастает до 30. Потом до 50. И в какой-то момент замечаешь: агент начинает путать инструменты. Вместо поиска по документации вызывает генерацию кода. Вместо API-запроса лезет в файловую систему. Не потому что сломался — потому что утонул в выборе.
Это не баг конкретного фреймворка. Это архитектурное ограничение: LLM получает список из 50+ описаний инструментов, каждое по 100-200 токенов, и должна за один inference-шаг выбрать правильный. Контекстное окно забито метаданными инструментов, а не задачей пользователя.
Почему LLM плохо выбирает среди 50 инструментов
Корень проблемы — в механизме function calling. Когда модель получает запрос вместе со списком доступных функций, она оценивает семантическую близость описания каждой функции к запросу. При 5-10 инструментах пересечения минимальны: «поиск по базе» и «генерация кода» — очевидно разные вещи.
При 50+ инструментах неизбежно появляются семантические пересечения. «Поиск по документации» vs «поиск по базе знаний» vs «RAG-запрос» vs «извлечение информации из файлов» — для модели эти описания различаются слабо. Добавьте сюда то, что описания пишут разные люди в разное время, и получите зону неопределённости, в которой модель гадает.
По данным Arize AI, точность выбора инструмента начинает деградировать при ~20 инструментах и значимо падает при 50+. При этом каждая ошибка маршрутизации не просто даёт неправильный ответ — она запускает цепочку: неверный инструмент → неверный промежуточный результат → неверный финальный ответ. В мультиагентных системах ошибка compound-ится через несколько шагов.
Что такое router skill
Router skill — это промежуточный навык, единственная задача которого — принять запрос и направить его к правильному навыку из библиотеки. Он не выполняет работу сам. Он классифицирует и маршрутизирует.
Архитектурно: Запрос пользователя → [Router Skill] (анализирует intent, выбирает категорию) → [Целевой навык] (выполняет задачу) → Результат.
Вместо того чтобы модель выбирала из 50 инструментов напрямую, router сначала определяет категорию задачи (поиск, генерация, анализ, администрирование), а затем передаёт запрос в нужную подгруппу, где инструментов уже 5-10.
Три основных подхода к реализации:
1. LLM-based routing. Отдельный LLM-вызов с промптом: «Вот категории навыков, вот запрос, выбери категорию». Самый гибкий вариант, но добавляет latency одного inference-шага. По данным Patronus AI, это сейчас стандарт в продакшн-системах.
2. Intent-based routing. Классификатор (может быть небольшая модель или embedding-based система) определяет intent запроса и маршрутизирует по таблице intent→навык. Быстрее LLM-routing, но менее гибок при нестандартных запросах.
3. Иерархический routing. Навыки группируются в дерево: верхний уровень выбирает домен (код, данные, коммуникации), средний — поддомен, нижний — конкретный инструмент. Масштабируется лучше всего, но сложнее в поддержке.
Практическая реализация
Допустим, у агента 60 навыков. Группируем их в 6 доменов: Поиск и извлечение (12 навыков), Генерация контента (10), Анализ данных (8), Файловые операции (9), API и интеграции (11), Администрирование (10).
Router получает описания шести доменов вместо шестидесяти навыков. Выбрать из шести — задача тривиальная для любой модели. После выбора домена, внутри него уже 8-12 навыков — тоже приемлемо.
Ключевые моменты реализации:
Описания доменов должны быть взаимоисключающими. Если «поиск по документации» может попасть и в «Поиск», и в «Файловые операции» — router будет ошибаться ровно так же, как модель без router-а. Тратьте время на чёткие границы между доменами.
Fallback обязателен. Если router не уверен в выборе (confidence ниже порога), запрос должен идти на ручную обработку или на второй проход с уточнением. Лучше спросить пользователя, чем выбрать не тот домен.
Логирование решений router-а — must have. Без него невозможно отладить ошибки: вы не поймёте, router ошибся или навык внутри домена. Трассировка маршрута запроса (query → router decision → skill execution → result) — базовая гигиена для агентных систем.
Когда router не нужен
Router добавляет сложность. Если у агента 15 навыков и они семантически различны — router будет overhead без пользы. Порог, при котором router становится необходимым, зависит от качества описаний навыков и степени их пересечения.
Эмпирическое правило: если при добавлении нового навыка существующие начинают выбираться реже или ошибочно — пора думать о router-е. Обычно это происходит в районе 20-30 навыков для плохо структурированных библиотек и 40-60 для хорошо описанных.
Ещё один сигнал: если вы тратите больше времени на переписывание описаний существующих навыков (чтобы они «не конфликтовали» с новыми), чем на создание новых — это костыль, который router заменяет на архитектурное решение.
Паттерн, а не фича
Router skill — это не фича конкретного фреймворка. Это архитектурный паттерн, применимый к любой агентной системе: LangChain, CrewAI, AutoGen, самописные решения. В LangGraph маршрутизация реализуется через conditional edges. В OpenAI Swarm — через handoff-функции. В более простых системах — через отдельный LLM-вызов перед основным.
Суть одна: не заставляйте одну модель выбирать из неограниченного списка. Разделяйте и властвуйте.
Агентные библиотеки навыков будут только расти. Модели станут умнее, но количество инструментов растёт быстрее. Router skill — это способ масштабировать библиотеку навыков без деградации качества выбора. И чем раньше вы заложите его в архитектуру, тем меньше будет боли при росте.