TL;DR
Исследование Volvo сравнивает два способа собрать агента. Первый: обвязка (harness, то есть код вокруг модели) жёстко прописывает цикл «посмотри → подумай → проверь → сделай». Второй: готовый агент вроде Claude Code или OpenCode, который сам решает, что делать дальше. Его настраивают тремя вещами: файлом инструкций, описаниями инструментов (через MCP, стандарт подключения инструментов к агенту) и субагентами. Модели и инструменты в обоих случаях одинаковые, меняется только обвязка.
Главная находка: на строго пошаговых сценариях готовый агент даёт тот же успех, что самописный, но чаще выдаёт разный результат на повторных прогонах. На открытых задачах («найди отель с такими фильтрами») он выигрывает на 9–28 процентных пунктов. Он не ошибается реже, а лучше исправляет ошибки: после неверного действия доводит задачу до конца в 78–83% случаев против 24–53% у самописного. Самописный агент каждый шаг собирает промпт заново из короткого журнала действий. Поэтому он «не помнит», что нажатие ничего не дало. Готовый агент хранит весь диалог и замечает сбой.
Цена такая: готовый агент тратит в 2,6–10,7 раза больше токенов на задачу. Но экономия на разработке и поддержке перевешивает. По оценке авторов, общие месячные затраты ниже на 3–66%. Работа поддержки смещается с «чинить цикл агента» на «поддерживать инструкции и описания инструментов». Это то, что читатель делает словами.
Схема метода
СЕТАП A (самописный, в проде у Volvo):
Код фиксирует цикл из 4 шагов на КАЖДУЮ итерацию:
1. Наблюдать → скриншот + упрощённая структура экрана (XML)
2. Думать → один вызов модели: чек-лист, "цель достигнута?", следующий инструмент
3. Проверить → существует ли инструмент, верны ли аргументы
4. Действовать → выполнить, записать в журнал
Промпт пересобирается с нуля; из истории — только журнал шагов и последние скриншоты
СЕТАП B (готовый агент: Claude Code / OpenCode):
Один общий цикл, модель сама решает, что делать и когда остановиться
Настройка — только снаружи:
• файл инструкций (одинаковый для всех тестов)
• MCP-сервер с теми же инструментами
• субагенты для подзадач (скролл до пункта, ввод текста, ожидание)
Контекст = весь накопленный диалог (обвязка сжимает его, когда он разрастается)
Всё это работает как настройка агента, отдельных запросов не требуется.
Пример применения
Вывод статьи прямой: если задача открытая и путь к цели не один, дай общему агенту короткую инструкцию с правилом «наблюдай → действуй → проверяй» и не прописывай каждый шаг жёстким циклом. Сильная зона метода — открытые цели. Поэтому берём не «нажми кнопки в таком порядке», а «добейся результата».
Задача: Вы — QA в команде маркетплейса (условно, как Ozon или Wildberries). Нужно регулярно проверять в Android-приложении сценарий: «найти товар, применить промокод, дойти до экрана оплаты, не оплачивая». Интерфейс меняется каждую неделю, и скриптовые тесты постоянно ломаются. Вы подключаете Claude Code к эмулятору через любой MCP-сервер управления Android.
Промпт (файл инструкций CLAUDE.md для агента-тестировщика):
Ты тестируешь Android-приложение маркетплейса на эмуляторе через доступные инструменты.
Правила окружения:
- Работай только на эмуляторе Pixel_7_API_34.
- Все действия выполняй внутри установленного приложения "Маркет", не открывай браузер.
- Платёж не подтверждай: остановись на экране оплаты.
Порядок работы:
1. Перед любым действием посмотри на экран: получи скриншот и структуру элементов.
2. Координаты берёшь из границ элемента в структуре экрана, а не угадываешь.
3. Делай одно действие за раз и после каждого проверяй, что экран изменился так, как ожидалось.
4. Если действие не дало эффекта или дало не тот эффект — признай это и исправь, прежде чем идти дальше.
5. Когда считаешь, что цель достигнута, назови, по какому признаку на экране это видно.
Цель: найти "беспроводные наушники", добавить первый товар с рейтингом от 4.5 в корзину, применить промокод TEST500 и дойти до экрана оплаты.
Результат: Агент будет работать циклами «посмотрел экран → выполнил одно действие → проверил результат». Если нажатие не сработало (например, элемент перекрыт всплывающим окном), он должен заметить это и попробовать другой путь, а не слепо продолжать. В финале придёт заявление о достижении цели с указанием признака на экране. Прогоны могут отличаться маршрутом и числом шагов: готовый агент вариативнее жёсткого цикла.
Почему это работает
Слабость в лоб. Жёсткий цикл с пересборкой промпта на каждом шаге хранит прошлое только в виде сжатого журнала («тапнул кнопку X, успешно»). Если действие формально прошло, но ничего не изменило, в журнале это выглядит как успех. Модель не видит расхождения. Авторы объясняют этим низкое восстановление после ошибок: самописный агент реже возвращается и исправляет неверный шаг.
Сильная сторона модели. Современные модели умеют сами планировать, замечать несоответствие между ожиданием и результатом и корректировать курс, если весь ход работы остаётся перед глазами. Общий агент накапливает вызовы и их результаты в диалоге, поэтому это видит.
Как метод использует это. Решения передаются модели, а код только кормит её инструментами и инструкциями. Каждый инструмент возвращает состояние экрана до и после действия, поэтому проверка встроена в сам вызов. Субагенты забирают на себя многошаговые мелочи (скролл до пункта, ввод текста) и возвращают только итог. Так промежуточные экраны не засоряют основной контекст.
Рычаги управления: - Жёсткость инструкции. Для открытых целей оставляй общий порядок работы. Для строгих сценариев добавь «не отклоняйся от шагов» (см. адаптации). - Правило «одно действие + проверка». Сними его, и агент пойдёт быстрее и дешевле, но чаще будет терять ошибки. - Что возвращает инструмент. Если инструмент отдаёт экран до и после, отдельный вызов «посмотри» не нужен: меньше шагов. - Вынос подзадач. Чем больше рутины в субагентах, тем чище контекст основного агента.
Шаблон промпта
Так выглядит инструкция Setup B из исследования: общие правила окружения плюс общий рабочий порядок. Авторы используют одну и ту же инструкцию для всех тестов.
Ты работаешь как агент для {тип_задачи} в {среда}.
Правила окружения:
- Используй только {устройство_или_система}.
- {ограничение_1: например, работай только в установленном приложении, не в браузере}
- {ограничение_2: что нельзя делать / где остановиться}
Порядок работы:
1. Перед любым действием посмотри на текущее состояние: {что_наблюдать}.
2. Данные для действия бери из {источник_точных_данных}, а не угадывай.
3. Делай одно действие за раз и после каждого проверяй результат.
4. Если результат не тот, что ожидался, разберись и исправь, прежде чем идти дальше.
5. Закончи, когда цель достигнута, и назови признак, по которому это видно.
Цель: {цель}
Что подставлять:
- {тип_задачи} и {среда}: что делает агент и где (тестирование приложения, заполнение форм в CRM и т. п.).
- {что_наблюдать}: что агент видит перед шагом (скриншот, структура страницы, вывод команды).
- {источник_точных_данных}: откуда берутся точные значения (границы элемента, ID, поле API).
- {цель}: желаемый результат. Лучше формулировать как цель, а не как последовательность кликов.
🚀 Быстрый старт: вставь в чат:
Вот шаблон инструкции для агента, который работает в интерфейсе. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, в какой среде работает агент, что он видит перед каждым шагом, какие действия ему запрещены и по какому признаку понять, что цель достигнута. Эти ответы нужны, чтобы правила не остались общими словами и агент мог проверять результат каждого шага.
Ограничения
⚠️ Цена токенов: готовый агент тратит в 2,6–10,7 раза больше токенов на задачу. Экономия получилась только потому, что учитывали стоимость разработки и поддержки. Если разработка уже оплачена или задач очень много, расчёт может поменяться.
⚠️ Нет выигрыша на жёстких сценариях: когда тест расписан по шагам («открой, включи, выключи»), успех у готового агента такой же, как у самописного. Бонус по восстановлению там не работает: ошибка уводит от предписанной процедуры, а исправить её нельзя.
⚠️ Больше разброс: на тех же задачах результат от прогона к прогону меняется чаще. Для регрессионных тестов, где нужна повторяемость, это минус.
⚠️ Меньше контроля: вы не управляете тем, что именно модель получает в контекст. Это решает вендор обвязки. Тестировщики в интервью хотят видеть действия агента и убеждаться, что он следует сценарию, независимо от обвязки.
⚠️ Низкая абсолютная успешность: на самой сложной задаче (бронирование) успех 10–42%, и разница между сетапами статистически не подтвердилась на 16 задачах. Это не «агенты уже всё умеют».
⚠️ Причина — гипотеза: объяснение про накопленный контекст авторы предполагают, но не проверяли отдельным экспериментом. Экономические выкладки привязаны к цифрам трудозатрат конкретной команды.
Как исследовали
Идея простая: изменить только обвязку, а всё остальное оставить одинаковым. Команда взяла боевого тестового агента Volvo для информационно-развлекательных систем автомобиля и вынула из него решение «что делать дальше». Инструменты (скриншот, дамп экрана, тап, свайп и т. д.) оставили теми же и подключили к Claude Code и OpenCode через MCP-сервер. Модели тоже запускали одни и те же: GPT-5.1 (как в проде), GPT-5.4, Claude Sonnet 4.6 и Opus 4.6.
Проверяли на двух наборах. Первый: 66 задач из реальных тест-кейсов Volvo (климат, свет, настройки), записанных по шагам. Второй: 56 открытых задач из датасета AMEX в Google Maps и Booking.com. Каждый прогон повторяли два или три раза, чтобы измерить нестабильность. Прогоны оценивал LLM-судья. Его сверили со вторым судьёй (согласие 93,4%, κ = 0,85) и с ручной разметкой. Ещё провели интервью с десятью людьми: разработчиками, владельцем продукта и тестировщиками.
Неожиданность: на пошаговых тестах никто не выиграл, а на открытых готовый агент выиграл заметно, хотя делал больше ошибочных действий (точность вызовов даже ниже). Выигрыш дало восстановление после ошибок, а не безошибочность. Из интервью вышел ещё один инсайт: собственная обвязка может превратиться в технический долг, даже если сама не ухудшилась, просто потому что экосистема вокруг идёт быстрее.
Адаптации и экстраполяции
🔧 Техника: добавить запрет на «обходные пути» → строгое следование сценарию
Для регрессионных проверок, где важно именно прописанное поведение, добавь в инструкцию:
Следуй сценарию строго по шагам. Если шаг нельзя выполнить как написано,
остановись и опиши, что именно не получилось. Не ищи обходной путь и не меняй порядок.
Основание: на пошаговых тестах восстановление через другой маршрут не помогает, и тестировщики хотят убедиться, что агент идёт по заданному сценарию. Эта фраза — моя адаптация, в статье её нет.
Экстраполяция: вынос длинных подзадач из основного контекста
В исследовании субагенты берут рутину (скролл до пункта, ввод текста, ожидание) и возвращают только итог. В своём файле инструкций можно перенять тот же принцип:
Если подзадача требует нескольких однотипных действий (прокрутить список до нужного пункта,
заполнить длинную форму), делегируй её субагенту с описанием цели на естественном языке.
Из результата тебе нужен только итог: получилось или нет, и что именно сделано.
Это перенос идеи на свои задачи: в статье проверен именно такой вынос в тестовом агенте, а не эта формулировка.
Ресурсы
- Название работы: Build or Adopt? Custom-Built vs. General-Purpose LLM Agent Harnesses for Automotive GUI Testing
- Авторы: Arsham Gholamzadeh Khoee, Ruyu Fu, Jiaqi Wei, Ruikun Deng, Robert Feldt, Dhasarathy Parthasarathy, Yinan Yu
- Организации: Chalmers University of Technology (Гётеборг), Volvo Group
- Упоминаются: Claude Code, OpenCode, Model Context Protocol (MCP), датасет AMEX, библиотека uiautomator2