Слишком много инструментов ломает ИИ-агента: как чинят tool overload

Разработчики, которые собирают агентов поверх LLM, столкнулись с закономерностью: чем больше инструментов подключено к модели, тем чаще она выбирает не тот, придумывает несуществующий или зацикливается. Проблема получила рабочее название tool overload — перегрузка инструментами. Об этом всё чаще пишут в блогах Anthropic и OpenAI, а разработчики протокола Model Context Protocol (MCP) прямо предупреждают: подключать к одному агенту сотню функций одновременно — плохая идея.

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

Почему это происходит

Инструмент¹ в контексте LLM-агента — это внешняя функция, которую модель может вызвать: запрос к API, поиск в базе, отправка письма. Модель не выполняет её сама, а генерирует структурированный вызов, который исполняет ваш код. Список доступных инструментов и их описания подаются модели в каждом запросе как часть контекста.

Отсюда три источника проблем.

• Расход контекстного окна. Описания инструментов² занимают токены, которые не остаются на историю диалога и данные задачи. Пятьдесят подробных схем легко съедают десятки тысяч токенов ещё до того, как пользователь задал вопрос.
• Семантическое смешение. Функции с похожими названиями и назначением модель путает. get_user, fetch_user, load_profile — для человека это разные вещи по контексту, для модели — три близких кандидата.
• Рост числа шагов. Чем больше вариантов, тем чаще агент делает лишние вызовы, проверяет не то и увеличивает и задержку, и стоимость запроса.

Инструмент, который вы подключили «на всякий случай», не бесплатен: он стоит токенов в каждом запросе и повышает шанс, что агент выберет именно его вместо нужного.

Как с этим борются

Отбор инструментов под задачу

Вместо того чтобы отдавать модели весь арсенал, инструменты выбирают динамически. Перед вызовом LLM отдельный шаг — часто через векторный поиск или RAG³ по описаниям — отбирает 5–10 функций, релевантных текущему запросу, и только их кладёт в контекст. Пользователь спросил про заказы — модель видит инструменты для заказов, а не для аналитики склада.

Группировка и иерархия

Второй подход — не плоский список, а дерево. Агент сначала выбирает категорию (заказы, оплата, доставка), а потом внутри неё — конкретный инструмент. Это уменьшает число вариантов на каждом шаге выбора, хотя добавляет один лишний вызов.

Мультиагентная архитектура

Крупные системы разбивают на специализированных агентов, у каждого — свой узкий набор инструментов. Координирующий агент маршрутизирует задачу к нужному специалисту. Anthropic описывала такой подход в материалах о построении агентных систем: узкая специализация повышает надёжность ценой усложнения оркестрации.

Сравнение подходов

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

Роль MCP

Model Context Protocol, открытый стандарт от Anthropic для подключения инструментов и данных к моделям, сделал проблему заметнее: подключить чужой MCP-сервер стало легко, и агенты начали обрастать десятками функций от разных серверов. Документация MCP и обсуждения в сообществе прямо рекомендуют не грузить в один контекст всё подряд, а фильтровать доступные инструменты на стороне клиента. Сам протокол механизм фильтрации не навязывает — это ответственность разработчика агента.

Кому это пригодится и кому нет

Пригодится, если вы:

• строите агента с доступом к нескольким API сразу — CRM, платежи, почта, календарь — и замечаете, что он путает вызовы;
• подключаете несколько MCP-серверов и суммарно набирается больше 15–20 функций;
• видите рост стоимости запросов из-за раздувшегося промпта с описаниями;
• получаете жалобы, что агент делает лишние шаги или зацикливается.

Скорее не нужно, если вы:

• делаете узкого бота на 3–5 функций — здесь плоский список работает лучше любой надстройки;
• на этапе прототипа и оптимизировать выбор инструментов рано;
• используете единственный инструмент вроде веб-поиска — усложнять нечего.

Практический ориентир: пока функций мало и агент не ошибается — не усложняйте. Как только начинаются промахи в выборе или растёт цена запроса, первым делом попробуйте динамический отбор: он даёт лучший результат при умеренной сложности.

¹ Инструмент (tool, function calling) — внешняя функция, вызов которой модель формирует в структурированном виде; исполняет её ваш код, а не сама модель.

² Контекстное окно — максимальный объём текста в токенах, который модель обрабатывает за один запрос; в него входят и системный промпт, и описания инструментов, и история диалога.

³ RAG (retrieval-augmented generation) — подход, при котором перед генерацией система ищет релевантные фрагменты (здесь — описания инструментов) и подставляет только их.