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

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

Поэтому выбор модели постепенно перестаёт быть настройкой в интерфейсе. Он становится частью политики выполнения агента.

Что произошло

Workweave Router — открытый проект, который предлагает поставить перед агентной системой отдельный слой маршрутизации. Клиент обращается не напрямую к Anthropic, OpenAI или Gemini, а к роутеру. Роутер уже решает, какую модель выбрать для конкретного запроса.

Идея не новая в целом: маршрутизация между моделями обсуждается давно. Но здесь важен практический контекст. Проект явно нацелен на агентные инструменты: Claude Code, Codex, opencode, Cursor и собственные приложения. То есть речь не про абстрактный чат, а про рабочую среду, где модель уже пишет код, вызывает инструменты и участвует в длинном процессе.

Авторы заявляют, что роутер выбирает модель менее чем за 50 мс и может снизить затраты на 40–70% простой заменой адреса API. Эти цифры стоит читать аккуратно: это заявление проекта, а не мой замер и не универсальный результат. Для своей системы их нужно проверять на собственных задачах.

Но сам сигнал важнее цифр.

Почему «одна модель на всё» начинает ломаться

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

В агентной системе это уже не работает так чисто. Один пользовательский запрос разворачивается в цепочку действий. Агент может прочитать файлы, построить план, вызвать поиск, изменить код, запустить проверку, объяснить результат и спросить подтверждение. Снаружи это один сценарий. Внутри — несколько разных классов задач.

Если отправлять всё в самую сильную модель, растёт цена. Если всё в дешёвую — падает качество там, где ошибка дорогая. Если всё держать локально — можно потерять качество на сложном рассуждении. Если всё отправлять наружу — появляются вопросы по данным, логам и контролю.

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

Что такое политика выполнения

Политика выполнения — это не список любимых моделей. Это набор решений до запуска агента.

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

Для специалиста это вопрос качества работы. Для компании — вопрос архитектуры, безопасности и ответственности.

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

Роутер в такой схеме — не «кнопка сэкономить». Это компонент, который должен жить внутри более широкой политики.

Что с этим делать компании

Первый шаг — не ставить роутер. Первый шаг — описать свои классы задач.

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

После этого можно задавать практические вопросы.

Какие задачи можно отдавать более дешёвой модели без заметной потери качества? Где экономия недопустима? Где нужен локальный запуск? Где можно использовать облачную модель, потому что данные не чувствительные? Какие решения должны подтверждаться человеком? Что считается ошибкой маршрутизации?

Без этих вопросов роутер может создать ложное ощущение контроля. Система начнёт выбирать модели автоматически, но никто не сможет объяснить, почему конкретный шаг ушёл именно туда и как это повлияло на результат.

На что смотреть перед внедрением

У таких инструментов есть несколько проверок, которые важнее красивых процентов экономии.

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

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

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

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

Почему это важно шире Workweave

Workweave Router может оказаться удачным инструментом, а может остаться одним из многих экспериментов. Для этого материала это не главный вопрос.

Главный вопрос в другом: агентная инфраструктура взрослеет. Сначала мы выбирали модель. Потом — инструмент вокруг модели. Теперь появляется слой, который управляет тем, какая модель выполняет какой шаг.

Это похоже на сдвиг от «купить AI-доступ» к «спроектировать AI-контур». В таком контуре есть провайдеры, локальные модели, внешние инструменты, память, правила доступа, журналирование, подтверждение человеком и маршрутизация запросов. Каждый элемент влияет на стоимость, качество и риск.

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

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

Граница вывода

Я не утверждаю, что Workweave Router даст 40–70% экономии в любой системе. Это заявление авторов проекта. Я не утверждаю, что такой роутер нужно включать в рабочий контур без проверки.

Но я считаю сам тип инструмента важным сигналом. Когда AI-агент становится частью работы, выбор модели перестаёт быть личной настройкой разработчика. Он становится правилом выполнения процесса.

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

Источник: workweave/router.