MWS сократила старт ИИ-агента с 37,6 до 16,8 секунды: разбор харнесса

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

Харнесс — это почти всё, кроме модели

Голая LLM — черный ящик: получает текст, выдает текст. Памяти, точного счета и самопроверки у неё нет. Агент, по определению докладчиков, равен модели плюс харнесс. Харнесс — это промпт, контекст и память, инструменты, цикл действий, проверки, ограничения и оркестрация.

Как эту разницу видно на практике? Архитектор в MWS поручил проверку чужого кода Opus и получил три мелких замечания. Та же задача на DeepSeek с обвязкой дала около 50 замечаний, из них 25 требовали внимания. То есть «средняя» модель в хорошей обвязке обошла сильную в обычной.

Несколько уроков из доклада:

• Контекст — главное. Модель перечитывает весь разговор заново, и чем он длиннее, тем хуже ответы. Выход: сжимать историю, подгружать нужное через субагентов или выносить данные в файлы.
• Больше инструментов — не лучше. У Vercel агент с 17 инструментами ошибался в одной задаче из пяти. После сокращения до четырех нужных задачи проходили на 100%.
• Ошибки копятся. При точности шага 99% цепочка из 10 шагов проходит чисто в 90% случаев, из 50 шагов — только в 60%. Поэтому нужны тесты после каждой правки и спецификация под задачу, например в OpenSpec.

Тренд 2026 года — харнесс, который правит сам себя. Настройщик читает логи сессий, находит повторяющиеся сбои и дописывает правила. В примере MWS агент в трех сессиях из шести сдавал работу без тестов. Настройщик добавил хук «без тестов не сдавать», и на следующий день все шесть сессий прошли с тестами.

Куда уходят 37,6 секунды

Проект «Цифровой сотрудник» — это персональный агент-консьерж в Telegram и Max с 30+ навыками. Под капотом у каждого пользователя свой под в Kubernetes с OpenClaw или Hermes. Первый ответ приходилось ждать в среднем 37,6 секунды, хотя сам ответ модели занимал 2,3–4,5 секунды.

Время уходило на инфраструктуру:

• 4 с — оператор раскладывает манифест агента в Kubernetes;
• 10 с — подключение диска к ноде;
• 5 с — монтирование диска в под;
• 5 с — инициализация контейнеров;
• 9,5 с — загрузка Gateway агента;
• 3,1 с — проверка готовности;
• 1 с — доставка файлов.

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

Цепочка оптимизаций получилась такой:

1. Вынесли подъем пода и доставку ключей в слоты: минус 4 с, остается 33,6.
2. Перешли с блочных дисков на общее хранилище CephFS: минус 15 с, остается 18,6.
3. Прогрели контейнеры и модули агента: выигрыш всего 1,8 с, потому что добавились закрепление слота и пробуждение агента.

Итог: 16,8 секунды. Цель — 6–8, но для неё придется лезть в код агента и, возможно, форкать его.

Цена скорости

Каждый шаг усложнял систему. Нужен реестр слотов на PostgreSQL, события из Kafka и гарантия, что слот ушедшего пользователя A не достанется B. Главная проблема — общий диск: в текущем варианте слоты видят общий корень, и из-за прав пользователь теоретически может увидеть соседей. Решение — монтировать subvolume по ключу, но это потребует отдельного сервиса.

Файлы в workspace агента разделили на пять областей: managed (по реестру), protected (профили, не трогать), runtime, user-owned и seed (доставляются один раз). Правило простое: обновлять и удалять можно только своё.

Еще одна боль — когда усыплять агента. Сейчас по времени: через 30–35 минут после последней активности пользователя или через 5 минут, если слот поднял Cron. Отличить «ушел» от «думает над ответом» без доступа к runtime нельзя. Команда проверяет гипотезу с быстрой моделью, которая решает за 0,5 секунды.

Что из этого взять

Если вы строите агентов для многих пользователей, измеряйте время до первого ответа отдельно от времени работы модели. Скорее всего, ваша проблема в инфраструктуре, а не в LLM. Не раздувайте набор инструментов и ставьте проверки внутри цикла. Заранее продумайте изоляцию данных: общее хранилище ускоряет старт, но превращает права доступа в главный риск.

Ограничение материала: текст обрывается на докладе о внедрении ИИ в организациях и оценке бизнес-эффекта, так что об измерении окупаемости здесь сказать нечего. Часть тезисов (например, про Google Research Harness 2) дана без источников, их стоит воспринимать как заявления спикеров.