Strands Agents 1 октября 2026 года выпустили Strands Decider 2B — маленькую открытую модель для решений внутри AI-агентов. Это не чат-модель и не очередной универсальный помощник. Её задача уже: быстро выбрать вариант из заранее заданного набора, оценить уверенность и помочь коду решить, что делать дальше.
Релиз важен из-за общей смены акцента. После TypeSafe Jev вокруг System One models началась отдельная гонка: часть задач в агентных системах не требует длинного ответа, рассуждения на несколько экранов или красивого текста. Иногда нужно просто понять, можно ли вызывать инструмент, в какую очередь отправить заявку, какой маршрут выбрать или достаточно ли уверенности, чтобы не будить большую модель. Strands Decider 2B как раз про этот слой.
Что именно выпустили
Strands Decider 2B — модель примерно на 2 миллиарда параметров, которую можно запускать локально на обычном CPU или GPU. Команда Strands описывает её как small decision model: она принимает состояние, вопрос и набор вариантов, а возвращает выбранный ответ и оценки по вариантам.
Код опубликован на GitHub, веса выложены на Hugging Face, вместе с обучающими данными и скриптами. Это принципиальная часть новости: релиз можно не только потрогать через готовый CLI, но и разбирать, дообучать, менять архитектуру и проверять на своих сценариях.
Официальный пример установки начинается с пакета strands-decider. После этого модель можно спросить через CLI: дать ей текст состояния и варианты вроде «billing», «sales», «retail», а на выходе получить выбранный вариант с confidence и распределением вероятностей. Для разработчика это выглядит ближе к умному классификатору, чем к LLM-чату.
Внутри это не обычная генеративная модель с просьбой вернуть JSON. Strands взяли Qwen3.5-2B как предобученный torso, убрали language model head и заменили его pointer head, который оценивает предложенные ответы. Дополнительно используется rank-16 LoRA-адаптер. То есть модель не пытается продолжать текст: её выход изначально устроен вокруг выбора из ограниченного набора.
Чем decision model отличается от LLM
Обычная LLM хороша, когда нужно объяснить, написать, переписать, сгенерировать код, разобрать длинный контекст или пройти цепочку рассуждений. Но в продуктовой автоматизации часто нужен не текст, а решение: да или нет, один вариант из списка, оценка по шкале, вероятность риска.
Сегодня такие задачи часто решают через промпт к большой модели: «верни JSON строго по схеме». Потом вокруг этого вырастают валидаторы, retry, запасные промпты и обработка случаев, когда модель добавила лишний текст или решила объяснить ответ. Это рабочий путь, но он дорогой и хрупкий, если вызов лежит в горячем backend-потоке.
Decision model делает другой компромисс. Она теряет универсальность и не умеет писать свободный ответ, зато лучше подходит для узкого решения. Варианты заранее заданы, ответ ограничен, вероятность становится частью интерфейса. Для кода это удобнее: результат можно сразу использовать в маршрутизации, guardrail, выборе инструмента или пороговой логике.
У этого подхода есть и очевидная граница. Strands прямо пишет, что такая модель хуже подходит для сложных задач, где нужно рассуждать, писать код, суммаризировать документы или вести диалог. Это не замена GPT, Claude или Gemini. Скорее это маленькая быстрая деталь рядом с ними.
Где это полезно в агентных системах
Самый понятный сценарий — проверка tool calls. Агент собирается вызвать инструмент, но в разговоре не хватает данных. Например, пользователь спросил «какая погода», не указав город, а агент уже хочет дернуть weather API с выдуманным аргументом. Strands показывает пример, где Decider читает диалог и предложенный вызов инструмента, а затем отвечает на два вопроса: основаны ли аргументы на словах пользователя и не рано ли вызывать инструмент.
Дальше обычный Python-код принимает решение: пропустить вызов, запретить, отправить на подтверждение или вернуть агенту управление с подсказкой. Важно, что такой слой можно поставить перед инструментом, не вызывая ещё одну большую LLM на каждый чих. Если решение занимает десятки или сотни миллисекунд, его уже можно рассматривать как постоянную часть контура агента.
Второй сценарий — model routing. Перед дорогой reasoning-моделью можно быстро определить, насколько задача сложная, есть ли риск, нужен ли поиск, какой инструмент подходит и стоит ли переводить запрос человеку. На одном запросе экономия незаметна, но на большом потоке она влияет и на цену, и на задержку.
Третий сценарий — классификация политик и guardrails. Например, можно оценивать, разрешено ли действие по внутренним правилам, какой уровень подтверждения нужен, похож ли запрос на опасный, хватает ли данных для автоматического ответа. Это не отменяет обычных security-проверок, но добавляет дешёвый вероятностный фильтр там, где раньше приходилось выбирать между «звать большую модель» и «писать грубые if-else».
Четвёртый сценарий — память и контекстное управление. Агент может решать, что сохранить в память, какой фрагмент контекста поднять, какую ветку workflow активировать, когда сжать историю и когда лучше переспросить. В таких местах генерация текста часто лишняя: нужен компактный сигнал, который потом обработает код.
Скорость и качество по заявлению Strands
Strands заявляет, что Decider 2B может отвечать за десятки миллисекунд на содержательных вопросах, а на локальной Nvidia RTX 3090 медианная задержка в их замерах около 115 мс. Для небольших задач на M3 MacBook указана медиана около 153 мс. Время растёт примерно линейно с размером задачи.
По качеству команда смотрела на accuracy и calibration на публичной части JevBench. В официальном посте говорится, что strands-decider-2b конкурентен с другими моделями этого класса: третье место среди 33 моделей в 2B-классе и первое место среди 30 моделей, если исключить модели чуть больше 2B. Здесь важно не превращать это в абсолютный рейтинг: это замер на конкретном benchmark, а не гарантия для любого домена.
Калибровка особенно интересна. Если модель не только выбирает вариант, но и честно показывает неопределённость, разработчик может строить нормальную пороговую логику. Например: выше 0,9 — действуем автоматически, от 0,6 до 0,9 — просим большую модель перепроверить, ниже 0,6 — отдаём человеку или задаём уточняющий вопрос.
Но такую схему нельзя копировать слепо. На своём домене пороги нужно измерять. Если в поддержке клиентов одна ошибка стоит дорого, модель должна проходить eval на исторических кейсах. Если задача вспомогательная, порог можно сделать мягче. Смысл Decider не в том, чтобы верить каждой вероятности, а в том, чтобы наконец иметь вероятность как нормальный инженерный сигнал.
Почему это продолжает историю Jev
За две недели до этого TypeSafe AI выпустила Jev и назвала его System One model. Идея похожая: не писать свободный текст, а быстро принимать типизированные решения. Strands прямо связывает свой релиз с этим классом моделей и говорит, что вокруг него сейчас появляется много экспериментов.
Разница в открытости. Jev доступен как продукт TypeSafe, а Strands Decider 2B опубликован как open source с весами и обучающими материалами. Это делает релиз особенно полезным для разработчиков, которые хотят не только использовать API, но и понять, как устроен слой решений.
Появляется любопытная архитектурная развилка. Большие модели остаются мозгом для сложных задач, генерации и рассуждения. Маленькие decision models становятся быстрыми рефлексами: дешёвый выбор, классификация, проверка, маршрутизация, confidence. В живом продукте эти слои не конкурируют, а складываются в одну систему.
Что стоит проверить перед внедрением
Первое — класс задачи. Если вы просите модель написать ответ клиенту, собрать отчёт или объяснить решение, Decider не подходит. Если вы просите выбрать из вариантов или оценить риск, уже интересно.
Второе — качество данных. Decision model хорошо выглядит там, где варианты и правила можно описать заранее. Чем расплывчатее вопрос и чем больше скрытого контекста, тем выше шанс, что маленькая модель будет уверенно ошибаться.
Третье — собственный eval. Нужно взять реальные кейсы, разметить правильные решения, прогнать Decider и посмотреть не только среднюю точность, но и ошибки на границах. Отдельно стоит проверить calibration: совпадает ли заявленная уверенность с реальной вероятностью правильного ответа.
Четвёртое — безопасность локального запуска. Модель можно поднять рядом с приложением, но любой локальный HTTP-сервис, demo-сервер или экспериментальный endpoint надо закрывать так же внимательно, как остальные внутренние инструменты. Open source не отменяет эксплуатационную дисциплину.
Что это меняет для разработчиков
Главная польза релиза не в том, что теперь появилась ещё одна маленькая модель. Польза в новом шаблоне проектирования AI-систем. Вместо одного огромного промпта можно разложить workflow на разные типы решений: где-то нужна reasoning-модель, где-то обычная LLM, где-то эмбеддинги, где-то строгий код, а где-то маленькая decision model.
Это похоже на нормальную backend-архитектуру. Не каждый запрос должен идти в самую дорогую и универсальную часть системы. Некоторые решения можно вынести в быстрый специализированный слой, измерить его качество и использовать как фильтр, роутер или предохранитель.
Для агентных продуктов это особенно важно. Чем больше у агента инструментов и прав, тем больше промежуточных решений он принимает: можно ли вызывать tool, хватает ли аргументов, не выдумал ли он параметр, какой маршрут выбрать, нужно ли подтверждение. Если каждое такое решение отдавать большой LLM, система становится медленной и дорогой. Если всё зашить в правила, она становится хрупкой. Decision model занимает промежуточное место.
Strands Decider 2B не делает агентов безопасными автоматически. Но он даёт разработчикам новый кирпич: быстрый, локальный, открытый и проверяемый слой решений. Для рынка AI-инструментов это хороший знак. Мы постепенно выходим из режима «одна большая модель отвечает за всё» и возвращаемся к инженерной композиции, где у каждого компонента есть своя работа.
Как попробовать
Начать можно с репозитория strands-decider и пакета strands-decider. Самый простой эксперимент — взять один существующий LLM-классификатор или ручное правило, описать состояние, варианты ответа и собрать мини-eval на реальных примерах.
Хороший первый сценарий — не критичная маршрутизация: распределение тикетов, выбор команды поддержки, определение необходимости уточняющего вопроса, проверка аргументов tool call. Там быстро становится видно, где модель полезна, а где ей не хватает контекста.
Если результат выглядит сильным, следующий шаг — пороги уверенности и fallback. Например, Decider решает только очевидные случаи, а пограничные отправляет большой модели или человеку. Такой режим честнее, чем сразу давать маленькой модели право принимать все решения подряд.
Источник
Официальный анонс Strands Agents: Introducing Strands Decider 2B: a small, open source, decision model.
Дополнительная проверка релиза: TechCrunch о Strands Decider 2B.