Маршрутизация LLM в AI-агентах: что проверить перед выбором инструментов

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

LLM может участвовать в классификации намерения. Но runtime должен владеть итоговым routing decision: какой домен выбран, какие tools разрешены, когда нужен fallback и что попало в trace. Это особенно важно в production, где агент работает с бизнес-системами, документами, заявками, кодом, доступами или действиями, которые нельзя выполнять случайно.

Отдельный routing layer нужен не каждому прототипу. Если у агента два-три простых инструмента, низкий риск ошибки и оператор всегда рядом, иногда достаточно аккуратного function calling и ручной проверки.

Но слой маршрутизации стоит проектировать заранее, если:

• у агента есть несколько групп инструментов: CRM, база знаний, Jira, Git, документы, платежи, внутренние API;
• часть инструментов похожа по описанию, но ведет к разным последствиям;
• есть действия с правами доступа, approval gates или изменением данных;
• важны стоимость, задержка и размер контекста;
• нужно объяснять, почему агент выбрал один инструмент и отклонил другой;
• после ошибки нужно восстановить цепочку решения, а не читать весь промпт заново.

В таких условиях маршрутизация становится не украшением архитектуры, а частью control-plane AI-агента.

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

Типовые проблемы:

• похожие tools конкурируют между собой;
• в prompt попадает слишком много служебных описаний;
• растет задержка и стоимость вызова;
• модель выбирает технически доступный, но смыслово неверный tool;
• fallback превращается в повторные попытки с тем же шумом;
• ошибку трудно разобрать, потому что решение спрятано внутри генерации.

В production это приводит не только к плохому ответу. Агент может запросить не те данные, открыть не тот контур, создать лишнюю задачу, перепутать действие чтения и изменения или уйти в ненужную цепочку tool calls.

Intent layer — это слой, который определяет намерение запроса и маршрут обработки до того, как агенту будет показан набор инструментов. Он не обязан быть отдельной большой системой, но его результат должен быть структурным.

В этой роли intent layer работает как routing/control-plane: не выполняет действие сам, а принимает проверяемое решение о маршруте, допустимых инструментах, fallback и данных для trace.

Минимальное routing decision должно отвечать на вопросы:

Такой слой не заменяет безопасность, approval и права доступа. Он работает раньше: ограничивает пространство выбора и делает решение проверяемым. Доступы и approval gates остаются отдельными слоями, которые должны подтвердить, можно ли выполнить конкретное действие.

Маршрутизация не обязана быть только LLM-based. На практике устойчивее работает гибридная схема.

Хорошая схема обычно выглядит так: быстрые правила отсекают очевидные случаи, semantic router или classifier выбирает рабочий route, а LLM подключается для неоднозначных запросов или извлечения сущностей. Если confidence низкий, агент не должен угадывать: он задает уточняющий вопрос, передает запрос оператору или выбирает безопасный read-only маршрут.

Routing layer должен возвращать не текстовое объяснение “кажется, это про документы”, а структурный результат. Его потом можно проверить в логах, тестах и разборе инцидента.

Минимальный набор полей:

Trace нужен не ради красивого лога. Он помогает ответить на практические вопросы: почему агент увидел именно эти tools, почему не выбрал соседний namespace, почему ушел в fallback и где порог уверенности оказался слишком низким или слишком высоким.

Перед пилотом AI-агента стоит проверить не только prompt и список tools, но и саму модель маршрутизации.

1. Соберите каталог инструментов. Разделите tools по namespaces: документы, задачи, код, CRM, база знаний, интеграции, администрирование, read-only, write-actions.
2. Опишите рабочие сценарии. Для каждого сценария укажите, какой intent ожидается, какие tools допустимы и какие действия запрещены без approval.
3. Подготовьте набор проверочных запросов. Включите обычные запросы, короткие формулировки, отрицания, неоднозначные вопросы, запросы с пропущенным контекстом и фразы, похожие на соседний route.
4. Задайте thresholds. Решите, при какой уверенности агент действует, когда задает уточняющий вопрос, а когда уходит в ручную проверку.
5. Проверьте wrong-tool scenarios. Отдельно прогоните случаи, где неправильный tool может создать задачу, изменить данные, раскрыть лишний контекст или запустить дорогую цепочку.
6. Сверьте trace. После каждого теста должно быть видно: intent, route, confidence, выбранный namespace, rejected routes и fallback reason.

Если эти проверки не проходят, пилот лучше ограничить read-only сценариями или уменьшить набор tools.

Главная ошибка — считать function calling полноценной архитектурой выбора инструментов. Function calling помогает оформить вызов функции, но не решает весь вопрос маршрутизации: какие tools вообще можно показать модели, когда нужно уточнение, где граница write-action и как потом разобрать выбор.

Другие частые ошибки:

• routing спрятан в одном большом prompt;
• все tools доступны во всех сценариях;
• нет confidence и thresholds;
• fallback означает “попробовать еще раз”, а не безопасный маршрут;
• security, approval и routing смешаны в одну неясную проверку;
• нет набора регрессионных запросов;
• в trace пишется только финальный tool call, но не причина выбора;
• semantic router подключен как модный компонент, но без примеров и критериев качества.

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

После нормальной проработки routing layer у команды должны быть не только prompt и список tools, а несколько рабочих артефактов:

• карта tool namespaces;
• список intent classes;
• правила, какие routes доступны в каких сценариях;
• thresholds для confidence;
• fallback policy;
• набор проверочных запросов;
• trace format;
• список действий, которые требуют approval;
• список сценариев, которые пока остаются read-only.

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

Если агент должен работать в бизнес-процессе, сначала полезно описать сами сценарии: где агент отвечает, где ищет данные, где создает объект и где должен остановиться. Для этого подойдет карта сценариев AI-агента в бизнес-процессе.

Если агент получает доступ к системам, документам или репозиториям, отдельно проверьте approval gates и доступы: routing layer не заменяет права, ограничения и журналирование действий.

Если задача связана с coding agents и доступом к инструментам разработки, рядом стоит читать страницу про MCP-интеграции для coding agents. MCP помогает подключать контекст и инструменты, но не отменяет отдельное решение о маршрутизации.

Если агент должен отвечать по корпоративным документам или базе знаний, routing layer нужно связать с RAG-контуром: где искать сведения, когда обращаться к базе знаний, как отличать поиск от действия и когда возвращать запрос на уточнение.