Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Сильную модель научились не вести весь сценарий агента, а проверять черновик слабой модели перед действиями, которые меняют среду. В нерецензированном препринте, где все числа получили сами авторы, SpecAgent отстал от сильной модели на τ2-Bench не более чем на один процентный пункт. Такая схема позволяет сократить задержку и нагрузку на память, если слабая модель работает заметно быстрее сильной.
Слабая модель читает, сильная проверяет перед записью
Обычный агент вызывает сильную модель на каждом шаге: найти заказ, прочитать карточку клиента, уточнить условие, изменить запись. Даже рутинные запросы требуют последовательной генерации токенов большой моделью, поэтому длинные сценарии дорого обходятся по времени и пропускной способности памяти.
SpecAgent делит действия на обратимые и меняющие состояние. Слабая модель сразу выполняет поиски и чтение данных, получает настоящие результаты инструментов и на их основе продолжает черновик. Первое действие, которое меняет заказ, базу или другой внешний объект, она только предлагает, но не запускает.
В этой точке сильная модель получает историю и весь подготовленный отрезок. Она ищет самый длинный корректный префикс, принимает его и при необходимости исправляет первый ошибочный шаг. Если исправление помещается в вердикт, отдельный запрос к сильной модели не нужен; иначе она делает один корректирующий ход.
Проверка здесь семантическая: действие должно приближать агента к цели, но не обязано совпадать с тем, которое выбрала бы сильная модель. Это существенно для инструментальных сценариев, где один и тот же результат можно получить разным порядком запросов или с разными аргументами.
Сильная модель обрабатывает черновик через предварительное заполнение (prefill): читает много токенов параллельно, а затем генерирует только короткий вердикт. При обычной работе она создавала бы каждый токен каждого шага последовательно и снова обращалась бы к своим весам в памяти.
Экономия возникает в памяти, а не в вычислениях
На τ2-Bench трафик между вычислителями и памятью снизился до 43–57% от режима с одной сильной моделью, а полное время выполнения — до 41–54%. При этом объём вычислений вырос на 30–87% в зависимости от набора задач: сильная модель реже генерирует токены, но заново читает длинный контекст при проверках.
На AutomationBench схема закрыла 44% разрыва по качеству между слабой и сильной моделями, на VitaBench — 75%. Чем чаще проверяющая модель отклоняла черновики и сама выполняла исправления, тем меньше оставалась экономия.
Проверки охватили τ2-Bench, AutomationBench и VitaBench с Qwen3.5-4B в роли слабой модели и Qwen3.5-397B-A17B в роли сильной. SpecAgent сравнивали с самостоятельной работой обеих моделей, AgentCollab и, на τ2-Bench, Speculative Actions. Отдельный эксперимент на MCP-Atlas использовал реальные серверы инструментов и три облачные сильные модели.
Размеры наборов составляли от 50 до 600 заданий. В них были клиентская поддержка, деловые процессы, доставка еды, поиск, базы данных и выполнение кода; качество оценивали по завершённой задаче или итоговому состоянию среды.
Архитектурный план меняется только для сценариев с обратимыми шагами
SpecAgent подходит агентам, которые долго читают данные перед редкими изменениями: ищут заказ, сверяют правила, собирают сведения и только затем обновляют запись или отправляют результат. В такой системе сильную модель можно убрать из основного цикла и вызывать на границе необратимого действия.
Для внедрения придётся явно классифицировать каждый инструмент. Адаптер должен отличать чтение от изменения состояния, задерживать опасный вызов, удалять отклонённый хвост из истории и проверять предложенное исправление. Ошибка в этой классификации опаснее ошибки слабой модели: инструмент может изменить среду до проверки.
Экономия времени также зависит от режима обслуживания. Метод выигрывает, когда последовательная генерация сильной модели упирается в пропускную способность GPU-памяти, а слабая модель быстро готовит черновик. При большой пакетной обработке вычислители загружаются плотнее, и дополнительное чтение контекста может съесть выигрыш.
Для связки локального агента с облачной моделью результат другой. На MCP-Atlas SpecAgent сократил число удалённо сгенерированных токенов и расходы на API, но не ускорил задачи: локальная слабая модель работала примерно столько же, сколько облачная сильная. Поэтому такую архитектуру стоит рассматривать как способ ограничить облачные вызовы, а не как гарантированное сокращение задержки.
Работа даёт готовый принцип проектирования, но не универсальную замену маршрутизации. Если почти каждый шаг меняет состояние, слабая модель редко может продвинуться без проверки. Если же большая часть траектории состоит из чтения, сильная модель действительно может стать рецензентом, а не постоянным автором действий.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
