ИИ-агент, который работает сам на ноутбуке: как мы выбирали open-source модель после августовских релизов

Директор по продажам среднего производственного холдинга описал задачу одной фразой: «Хочу, чтобы ноутбук что-то делал, пока я на совещании». Не чат-бот, который ждёт вопроса. Не окошко, куда надо приходить и что-то печатать. Помощник, который сам разбирает утреннюю почту, готовит справку по встречам, поднимает нужные документы к переговорам — и молча кладёт результат в отдельную папку. Тихо, в фоне, без облака.

Мы взялись разработать ИИ-агента под этот сценарий и довольно быстро упёрлись в скучный вопрос: на какой модели он будет жить. В августе 2026-го ответ на этот вопрос сильно поменялся, и рассказ, собственно, про это.

Что такое ИИ-агент простыми словами, если он работает в фоне

Обычно, когда объясняют, что такое ИИ-агент простыми словами, показывают чат: пользователь спрашивает, модель отвечает, модель вызывает функции, модель отдаёт результат. Всё крутится вокруг диалога.

Always-on агент устроен наоборот. Пользователь его не запускает. Триггером становится событие: пришло письмо, обновилась карточка в CRM, наступил час до встречи, добавился файл в папку. Агент просыпается сам, смотрит контекст, решает, что делать, дёргает нужные инструменты через MCP, кладёт результат — и снова засыпает. Иногда пишет короткое уведомление, иногда молчит.

Ключевая разница — не в промпте, а в режиме жизни. Такой ИИ-агент должен работать самостоятельно недели напролёт, не съедая всю оперативку, не грея процессор до звона вентилятора и не отправляя данные наружу. Именно из-за последнего пункта заказчик и позвал нас: у него на ноутбуке — переписка по крупным сделкам, и облако он не рассматривает в принципе.

Первый подход: облако, счёт и тихое разочарование

По привычке мы начали с прототипа на облачной модели среднего класса — просто чтобы показать сам сценарий. Работало красиво: агент разбирал письма, тегировал, писал сводки к встречам. Демка зашла.

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

И главное — данные. Заказчик хотел, чтобы переписка вообще не покидала машину. С облачной моделью это можно вырулить только через жёсткое маскирование, а любое маскирование бьёт по качеству разбора именно в тех местах, где нужны цифры и имена. Не наш случай.

Мы вернулись к идее локальной модели. И тут оказалось, что за последние две недели картина сильно изменилась.

Август подкинул неожиданно много доступных ИИ-агентов

В первой половине августа вышли сразу три релиза, которые ровно про наш сценарий — «агент, живущий на одном consumer-GPU».

Qwen3.8-27B от Alibaba, 27,8 миллиарда параметров, dense-архитектура, лицензия Apache 2.0. Заявлены сильные результаты на agent-бенчмарках, включая Terminal-Bench. Запускается на топовой пользовательской видеокарте без плясок с квантованием на грани.

Muse Glimmer 30B от Meta, open-weights, тоже Apache 2.0, мультимодальная, 128K контекста. В релизе прямо написано «local agent that runs all the time» — это буквально описание нашей задачи.

Nemotron 3.5 Lightning от NVIDIA, 30B в MoE-конфигурации, из которых активны около трёх миллиардов. Обещает кратно более быструю работу на агентных сценариях и рассчитана на low-latency always-on агентов на ноутбучном GPU.

Плюс фоном — свежий DeepSeek V4-Pro и Gemini 3.7 Flash, но это уже облачная история, для нашего кейса — мимо. И, конечно, российские варианты для тех задач, где важен 152-ФЗ, — но здесь заказчик хотел именно локальный запуск без каких-либо API.

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

Как мы гоняли модели через один MCP-стенд

Чтобы сравнение было честным, мы собрали единый стенд. Один и тот же набор MCP-серверов: почта, календарь, файловое хранилище, CRM через переходник, внутренняя вики. Один и тот же промпт-каркас с описанием ролей и инструментов. Один и тот же набор из полутора сотен реальных событий, обезличенных из архивов заказчика: письма, встречи, апдейты сделок.

Дальше — три прогона, три модели, метрики руками:

• корректно ли агент выбрал нужный MCP-инструмент;
• сколько шагов ушло на задачу;
• как часто он уходил в бесполезный цикл;
• сколько оперативки съедал в устоявшемся режиме;
• как менялась температура ноутбука через час непрерывной работы;
• насколько внятно писал сводку по-русски.

Последний пункт оказался важнее, чем мы думали. Английский все три модели знают отлично. С русским деловым — по-разному. Одна из них упорно называла контрагентов «уважаемый Партнёр» с большой буквы, вторая почему-то переходила на украинизмы в датах.

Что победило и почему — и где обломались

Не буду делать вид, что нашли идеал. Идеала нет.

Qwen3.8-27B выиграл по качеству разбора и работе с инструментами. Ошибок в выборе MCP-функции — заметно меньше, чем у соседей. Русский — уверенный, деловой, без странностей. Но она заметно тяжелее в памяти и на длинных сессиях начинает подъедать ресурсы. Ноутбук держит, но параллельно рендерить видео в Premiere уже не получится.

Muse Glimmer 30B проиграл в чистом языковом разборе, зато вытащил себя мультимодальностью. Он единственный из тройки внятно смотрел на скриншоты и PDF-страницы без OCR-костыля. Для сценария «пришёл акт в pdf — посмотри, всё ли на месте» — очень удобно.

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

В итоге мы посадили Qwen3.8-27B как основной «мозг» агента, а Nemotron оставили как быстрый маршрутизатор: сначала он смотрит событие и решает, стоит ли вообще будить тяжёлую модель. Это классическая двухуровневая схема, но именно в always-on режиме она даёт самый заметный выигрыш — большая часть событий отсекается на быстром слое и вообще не доходит до большой модели.

Muse Glimmer держим в резерве под конкретные сценарии со сканами.

Что мы поняли про агента, который работает самостоятельно

Пара выводов, которые пригодятся, если вы тоже думаете разработать ИИ-агента для фонового режима, а не для чат-окошка.

Первое — оптимизировать надо не среднее время ответа, а поведение на длинной дистанции. Модель, которая шустрая первые полчаса, но через сутки съедает половину оперативки, никому не нужна. Метрики измеряйте после суток непрерывной работы, а не после десяти минут.

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

Третье — MCP как стандарт наконец-то экономит нам недели. Мы подключили один и тот же набор серверов ко всем трём моделям без единой строчки под конкретный движок. Ещё год назад это был бы месяц работы, сейчас — пара часов.

И последнее. Когда клиент говорит «пусть ноутбук что-то делает, пока я на совещании», за этой фразой стоит не одна большая модель, а маленькая продуманная архитектура. Раньше на подбор компонентов такой архитектуры уходили недели переговоров с провайдерами API. Теперь — вечер на стенде и три прогона на реальных событиях.

Как вы думаете, какие ещё сценарии в вашем бизнесе просятся в always-on режим — и что мешает их туда переселить?

Похожие статьи

• Кто такой этот ИИ-агент в вашей системе: почему создание ИИ-агента для бизнеса начинается с бейджа, а не с промпта
• ИИ-агент, который сначала думает, а потом делает: Plan-and-Execute на разборе тендерной документации
• Сколько стоит ИИ-агент: почему честный ответ начинается с проектирования, а не с прайса
• «А ваш ИИ-агент это умеет?» — вопрос, из-за которого мы разложили агента на скиллы