ИИ-агент, который исправляет баг, но через раз не запускает тесты, — не помощник разработчика, а источник новой очереди на ревью. На митапе «Русское техно 2» команда MWS показала, почему харнесс для ИИ-агентов становится важнее выбора самой модели: именно он задаёт инструменты, контекст, проверки и правила завершения задачи. Для российских команд это практичный разговор о том, как масштабировать агентные сценарии дальше личного локального окружения.
Участники встречи обсуждали внедрение агентов в крупных организациях: от задержки первого ответа почти в 40 секунд до оценки бизнес-эффекта. Как сообщает Habr / Карьера, MWS разворачивает агентную инфраструктуру в Kubernetes и поддерживает OpenClaw и Hermes. Задача уже не сводится к тому, чтобы дать сотруднику чат с LLM: компании пытаются встроить исполнителей-агентов в трекеры, процессы разработки и человеческое ревью.
Product Owner MWS Даниил Малышев объяснил термин на примере проверки кода. По его словам, при одной и той же задаче модель Opus дала три небольших замечания, а DeepSeek Harness нашёл около 50 проблем; 25 из них требовали внимания разработчика. Смысл кейса не в том, что одна модель магически стала сильнее другой. «Голая» LLM получает текст и продолжает текст, а результат определяет окружающая её среда: системные правила, подключённые данные, память, доступные действия, цикл проверки и ограничения безопасности.
Не промпт, а рабочая среда
В MWS описывают этот переход как движение от промпт-инжиниринга к контекст-инжинирингу, а затем к инженерии харнесса. В 2022 году ChatGPT сделал массовым сам формат диалога с моделью. Затем в агентных системах появились внешние инструменты, поиск по корпоративным данным, файловые хранилища, терминал и тесты. Теперь разработчику мало написать хороший запрос: надо решить, какие сведения попадут в контекст, кто и когда вызовет инструмент, что нельзя делать агенту и по каким критериям он вправе сообщить о завершении работы.
Управление контекстом здесь выглядит самым приземлённым, но самым дорогим элементом. История диалога разрастается, а модель начинает хуже держать ранние детали задачи. Один из вариантов — сжимать прошлые сообщения; другой — не тащить в беседу всё подряд, а запрашивать нужные данные через субагентов или хранить рабочие сведения в файлах. Это знакомая проблема для тех, кто уже пробовал «вайбкодинг»: после длинной серии правок ассистент может уверенно следовать инструкции, которую сам же неверно пересказал несколько сообщений назад.
Второй слой — точные инструменты. Модель не умеет самостоятельно выполнить программу, получить сведения из системы или проверить расчёт: она лишь формирует запрос на действие. Харнесс должен проверить права, вызвать разрешённый сервис или среду исполнения и вернуть результат в контекст. Такой механизм превращает LLM из собеседника в участника процесса, но одновременно повышает цену ошибки в настройке доступа. Особенно в корпоративных системах, где у агента потенциально есть путь к коду, документам и данным клиентов.
Меньше инструментов, больше проверок
На митапе отдельно разобрали цикл работы агента: он планирует действие, выполняет его, читает результат и корректирует следующий шаг. Качество этого цикла важнее количества подключённых возможностей. В качестве примера приводились эксперименты Vercel: агент с 17 инструментами ошибался примерно в одной задаче из пяти, а после сокращения набора до четырёх необходимых инструментов справлялся со всеми задачами в тестовом сценарии. Лишние опции не только расширяют функциональность, но и раздувают контекст, оставляя модели больше способов выбрать не тот путь.
Ошибка усиливается по мере длины цепочки. Если каждый отдельный шаг верен с вероятностью 99%, то в последовательности из десяти действий вероятность пройти без промаха падает примерно до 90%, а в цепочке из 50 — до 60%. Поэтому агенту нужны не общие призывы «будь внимателен», а спецификация: цель, критерии приёмки, список разрешённых источников, формат результата, запреты и обязательная самопроверка. Для разработки это означает возврат к дисциплине, от которой многие команды пытались уйти: хорошо описанная задача и автотесты становятся интерфейсом не только между людьми, но и между человеком с агентом.
В MWS показали и схему самоулучшения такой среды. Агент исправляет баги в корзине, получает правила из AGENTS.md, навыки для починки и доступ к файлам с терминалом. За день он завершил шесть сессий, но в трёх не запустил тесты. Логи поступают в базу знаний, а отдельный настройщик раз в сутки ищет повторяющиеся сбои. В этом случае он добавил правило: не сдавать работу без тестов; на следующий день тесты прошли во всех шести сессиях. В ряде сценариев решение об обновлении харнесса оставляют человеку, чтобы автоматизация не начала сама переписывать правила по случайному паттерну.
Практический вывод для бизнеса довольно жёсткий: измерять нужно не число выданных агенту задач и не впечатляющие демо, а долю принятых результатов, время до первого полезного ответа, количество итераций ревью и стоимость исправления ошибок. В MWS Track исполнителем задачи можно назначить как человека, так и агента, а итог всё равно проверяет сотрудник. Следующий вопрос для отрасли — кто станет владельцем харнесса для ИИ-агентов: отдельная платформенная команда, руководители функций или сами продуктовые команды. От этого выбора зависит, останутся ли виртуальные сотрудники эффектной надстройкой над чатами или получат место в обычном производственном контуре.