Стек агентов раскалывается надвое

Самая дорогая ошибка в проектировании агентов сегодня — использовать одну и ту же модель для всего. Вы берете frontier-модель, чтобы решить, вызывать ли API, а затем ту же самую модель, чтобы сформировать JSON-пейлоад. Для одной из этих задач нужен физик, для другой — грамотный клерк. Платить по ставке физика за канцелярскую работу не просто расточительно — это плохая инженерия. Это связывает интеллект агента с его операционными расходами так, что ухудшает и то, и другое.

Релиз Meta Muse Ember делает этот раскол осязаемым. Это небольшая модель, созданная специально для того, на что агенты фактически тратят большую часть своих циклов: вызовы инструментов, маршрутизация и извлечение данных [1]. При цене 10 центов за миллион входных токенов она значительно обходит Claude Haiku 5.5 и GPT-6 Luna [3]. Meta заявляет, что модель выдает больше интеллекта на доллар на этих повторяющихся задачах, при этом открыто признавая, что она не дотягивает до уровня реального программирования [1]. Именно это признание и есть самое интересное. Они продают не модель, которая умеет всё; они продают модель, которая делает скучную часть работы агентов чрезвычайно дешево.

Слой исполнения становится товаром

Последние два года стандартная архитектура агентов была монолитной. Одна модель — обычно frontier — занимается планированием, рассуждением, выбором инструментов и механической работой по структурированию вывода. Это имело смысл, когда маленькие модели не могли надежно генерировать валидные вызовы функций или следовать инструкциям маршрутизации. Но этот порог надежности был преодолен. Muse Ember — не первая небольшая модель, компетентно работающая с инструментами, но ее цена и явное позиционирование Meta как движка исполнения для агентов сигнализируют о том, что этот слой теперь стал товарным рынком.

Следствие для разработчиков: в архитектуре вашего агента теперь есть очевидный шов. Слой рассуждения — где вам нужен реальный интеллект для декомпозиции задач, обработки неоднозначности или написания кода — остается за frontier-моделью. Слой исполнения — где вам нужен быстрый, надежный, структурированный вывод по известным паттернам — переезжает на что-то вроде Ember. Эти два слоя могут быть разными моделями, от разных провайдеров, оптимизированными под разные задачи.

Что это значит для оценки качества

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

Это также меняет подход к fallback-стратегии. Если ваша модель исполнения достаточно дешева, вы можете позволить себе запустить ее несколько раз с разными промптами и проголосовать за результат — паттерн, который непомерно дорог с frontier-моделями. Надежность через избыточность становится легитимной стратегией, когда избыточные вызовы стоят доли цента.

Урок Instagram

Есть еще один сигнал, достойный внимания, хотя он исходит с другой стороны. Effect Builder в Instagram теперь генерирует AR-фильтры из AI-промптов [2]. Это не инфраструктура для агентов — это пользовательская фича. Но она иллюстрирует тот же паттерн с обратной стороны: ИИ переходит в роли исполнения, где результатом является структурированный артефакт, а не диалог. Промпт создает фильтр, а не сообщение в чате. Модель выполняет работу с инструментами, просто обернутую в дружественный интерфейс.

Для разработчиков агентов это напоминание о том, что структурированный вывод становится ожиданием по умолчанию, а не специализированной возможностью. Когда пользовательские приложения воспринимают «промпт в артефакт» как рядовую функцию, способность вашего агента выдавать валидный JSON с первой попытки перестает впечатлять и становится базовым требованием. Дифференциация смещается выше по потоку — к рассуждению, которое решает, какой JSON создавать и почему.

Практический вывод прост. Посмотрите на потребление токенов вашим агентом и разделите его на работу по рассуждению и работу по исполнению. Если более половины ваших расходов приходится на генерацию структурированного вывода, решения по маршрутизации или соблюдение схемы, у вас есть шов, куда просится модель вроде Muse Ember. Разница в стоимости не маржинальна — это порядок величины — а инженерная выгода от отделения интеллекта от исполнения будет нарастать по мере того, как оба слоя эволюционируют с разной скоростью.