TL;DR
Mid-Harness — это прослойка между моделью и обвязкой агента (программой, которая выполняет команды в терминале). Модель на каждом шаге предлагает не одну команду, а несколько (в статье 4–8). Проверяющий (отдельный вызов LLM) выбирает лучшую, и только она уходит на выполнение. Остальные варианты выбрасываются.
Главная находка: выигрыш определяет не число вариантов, а качество проверки. Если проверяет та же слабая модель и смотрит на весь список разом, вариантов можно хоть удвоить, результат почти не растёт. Плохая команда (не тот пакет, не та правка) меняет окружение, и дальше агент идёт по испорченной среде, хотя мог выбрать вариант получше. Если те же варианты оценивает сильная модель, доля решённых задач растёт кратно сильнее. Слабая модель плохо видит, какой из восьми вариантов лучше. С двумя вариантами сразу ей справиться проще.
Суть метода в трёх шагах: сгенерировать N вариантов следующего действия, сравнить их попарно (два кандидата, одна задача, одна история), выбрать победителя по числу побед. Попарное сравнение оказалось лучшим из трёх способов проверки. Но оно самое дорогое по токенам.
Схема метода
ШАГ 1: Генератор по текущей истории → N кандидатов команды (N = 4–8)
ШАГ 2: Проверяющий получает задачу + историю + 2 кандидата
(без рассуждений генератора) → рассуждение + оценки + A / B / TIE
(так перебираются все пары: при N=8 это 28 вызовов)
ШАГ 3: Подсчёт побед с учётом разницы оценок → один победитель
ШАГ 4: Обвязка выполняет победителя, остальные отбрасываются,
история обновляется → снова ШАГ 1
Каждый шаг — отдельный вызов модели. Всё вместе встроено в код вокруг модели, а не в один промпт.
Три способа проверки, которые сравнивали: - Списком — один вызов, проверяющий видит всех кандидатов и выбирает одного. - Поштучно — каждому кандидату своя оценка, берётся максимальная. - Попарно — сравниваются два варианта, победитель считается по числу побед. Лучший результат.
Пример применения
Метод хорошо работает там, где одна неудачная команда необратимо портит окружение: установка пакетов, правки конфигов, миграции. Пример взят оттуда.
Задача: Вы ведёте Telegram-бота на VPS у Timeweb. Агент в терминале чинит упавшую установку зависимостей. Вы хотите, чтобы он не ломал системный Python. Для этого перед запуском команды второй вызов модели сравнивает два предложенных варианта.
Промпт (для проверяющего):
Ты — строгий проверяющий команд терминала. Ты НЕ выполняешь команды.
Ты сравниваешь два варианта следующего действия агента ДО запуска.
Починить запуск Telegram-бота на VPS (Ubuntu 24.04, Python 3.12).
Установка зависимостей падает с ошибкой.
$ pip install -r requirements.txt
error: externally-managed-environment
× This environment is externally managed
sudo pip install --break-system-packages -r requirements.txt
python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
1. Для каждого кандидата опиши, что команда сделает в текущем окружении.
2. Проверь, выполнима ли она (права, пути, зависимости).
3. Проверь, приближает ли она к цели задачи, не создавая новых проблем
для следующих шагов.
4. Поставь каждому кандидату оценку от 1 до 10.
Результат: Модель сначала опишет, что делает каждая команда. Вариант A ломает системные пакеты. Вариант B изолирует установку. Затем выставит две оценки и в конце выдаст вердикт A, B или TIE. Если вариантов больше двух, прогоните все пары. Победитель определяется по числу побед, а не по одной оценке.
Почему это работает
Слабость: модель, которая сама выбирает из длинного списка, плохо отличает полезное действие от вредного. Она должна одновременно оценить все варианты и расставить их по порядку. Поштучные оценки тоже ненадёжны: команды у кандидатов разные по смыслу (диагностика и повтор), и поставить их на одну шкалу трудно.
Сильная сторона: сравнить два варианта проще, чем выбрать из восьми. У проверяющего есть общая точка отсчёта, он смотрит именно на разницу. Кроме того, обычно среди нескольких сэмплов от одной модели уже есть хороший вариант, его только нужно распознать.
Рычаги управления: - Число кандидатов N → меньше N даёт меньше вызовов. Попарные сравнения растут примерно как N²: при N=8 это 28 вызовов, при N=3 всего 3. - Сила проверяющего → самый мощный рычаг. Сильная модель в роли судьи даёт кратно больший выигрыш, чем увеличение N. - Рассуждение в ответе проверяющего → в статье у 9B-модели вариант «только A или B, без объяснений» стал точнее и на пятую часть дешевле. На 4B и 27B стало хуже. Это нужно проверять на своей модели. - Что видит проверяющий → ему не показывают рассуждения генератора, только задачу, историю и команды. Так он не поддаётся на уверенную аргументацию варианта.
Шаблон промпта
Ты — строгий проверяющий действий агента. Ты НЕ выполняешь команды
и не пишешь решение сам. Ты сравниваешь два варианта следующего
действия ДО их выполнения.
{задача}
{история команд и ответов терминала}
{команда A}
{команда B}
1. Опиши, что каждая команда сделает в ТЕКУЩЕМ окружении.
2. Проверь, выполнима ли она (права, пути, установленные программы).
3. Проверь, приближает ли она к цели и не ломает ли среду
для следующих шагов.
4. Поставь каждому кандидату оценку от 1 до 10.
Подставьте:
- {задача} — формулировка цели агента.
- {история} — последние команды и выводы терминала.
- {команда A} и {команда B} — два кандидата.
Чтобы выбрать из нескольких кандидатов, запустите шаблон для каждой пары. Победитель — тот, у кого больше побед. Если побед поровну, смотрите на разницу оценок.
🚀 Быстрый старт — вставь в чат:
Вот шаблон попарной проверки действий агента (Mid-Harness).
Адаптируй под мою задачу: {опиши, что делает агент и в какой среде}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что за среда, какая цель у агента и что уже выполнено. Ещё уточнит, какие действия необратимы. Эти сведения нужны проверяющему, чтобы оценить команду в текущем окружении, а не в вакууме. Паттерн с тегами и пошаговым рассуждением она возьмёт из шаблона.
Ограничения
⚠️ Нужен код: метод встроен в обвязку агента. В готовом Claude Code, Cursor или ChatGPT перехватить вызов модели нельзя. Без своей обёртки это ручной процесс.
⚠️ Слабая проверка не спасает: если вариантов много, а проверяет та же небольшая модель списком, результат почти не растёт. Деньги тратятся впустую.
⚠️ Дорого: попарная проверка на восьми вариантах — это десятки вызовов на каждый шаг. По числу токенов проверяющего она в сотни раз тяжелее проверки списком.
⚠️ Сильная проверка требует сильной модели: главный выигрыш получен с передовой моделью-судьёй. Самопроверка небольшой моделью дала заметно меньше. Обучение проверяющего на ответах сильной модели (дистилляция) дало ещё прирост. Читателю без обучения этот путь недоступен.
⚠️ Трудности остаются: проверяющие чаще всего ошибаются в смысле команды (что она реально сделает) и в выполнимости (сработает ли она в этой среде). В поздних шагах длинных задач согласие с сильным судьёй падает.
⚠️ Малая выборка: основной бенчмарк небольшой, главная модель одна (9B). Дополнительные модели и обвязки в статье упомянуты, но подробности в тексте обрезаны.
Как исследовали
Команда NVIDIA и KAIST взяла маленького терминального агента TMAX-9B и бенчмарк TerminalBench-Lite. Каждая задача запускалась по три раза. Обвязку и генератор не трогали: добавляли только слой «насэмплируй и проверь» между ними.
Сначала проверили, есть ли вообще что выбирать. Для этого поставили в проверяющие передовую модель. Доля решённых задач выросла с 50% до 68% при 8 кандидатах. Значит, среди вариантов слабой модели хорошие уже есть, их просто надо опознавать.
Потом заменили судью на ту же слабую модель. Рост N с 4 до 8 дал едва заметный прирост (около 49% → 51%). Это главная неожиданность: больше кандидатов не помогает, пока проверка слабая. Попарная проверка подняла результат до 54,8%, а обучение на 117 тысячах попарных ответов сильной модели — до 57,1%.
Дальше сравнили стоимость. Попарная проверка при N=8 даёт около 126 тысяч токенов проверяющего на запуск против 0,6 тысячи у проверки списком. Вариант «только A/B без рассуждений» на 9B оказался точнее и дешевле на 21–24%, но на 4B и 27B стал хуже.
Наконец, метод совместили с запуском нескольких полных попыток (Best-of-T) и с повторным запуском на основе разбора прошлого (Sequential Refine). Комбинация с одним раундом повторного запуска обошла Best-of-T при T=7, потратив меньше половины токенов.
Вывод для практики: проверка важнее генерации, а цена проверки растёт быстро.
Адаптации и экстраполяции
Это не проверялось в статье, это переносы принципов на готовые инструменты. Проверяйте на своих задачах.
🔧 Техника: слабый исполнитель → сильный судья. Если в Claude Code или Cursor основной агент работает на быстрой модели, вынесите проверку необратимых действий (миграции, rm, смена конфигов) в отдельный чат с самой сильной моделью. Используйте шаблон выше. Это тот же принцип «судья сильнее генератора», только вручную.
🔧 Техника: меньше кандидатов → дешевле. Просите у агента не 8, а 2–3 варианта и сравнивайте их попарно. Три пары — это три вызова вместо 28.
Экстраполяция: правило в CLAUDE.md / AGENTS.md.
Перед любой необратимой командой (установка пакетов в систему,
миграции БД, удаление файлов, правка конфигов в /etc):
1. Предложи 2–3 варианта команды.
2. Сравни варианты попарно: что каждый сделает в ТЕКУЩЕМ окружении,
выполним ли он, не ломает ли среду для следующих шагов.
3. Выбери победителя и объясни выбор в одной фразе.
4. Только потом выполняй.
Здесь агент сам сочетает генератор и проверяющего в одном контексте. Это слабее варианта с отдельной сильной моделью-судьёй, но ничего не требует писать.
Ресурсы
- Mid-Harness: Scaling Actions Between Model and Harness for Terminal Agents — Minki Kang, Ryo Hachiuma, Shaokun Zhang, Subhashree Radhakrishnan, Yonggan Fu, Jindong Jiang, Mingjie Liu, Ehsan Hosseini-Asl, Yi Dong, Yu-Chiang Frank Wang, Byung-Kwan Lee (NVIDIA, KAIST).
- Страница проекта: byungkwanlee.github.io/MidHarness-page/
- Бенчмарк: TerminalBench-Lite. Генератор: TMAX-9B (на базе Qwen3.5-9B). Обвязка: Vanillux2.
- Связанные методы: Best-of-T (турнир по полным запускам), Sequential Refine, ReAct.
Текст статьи в источнике обрывается в разделе 5.2, поэтому часть выводов (дополнительные модели, бенчмарки, обвязки) здесь не разобрана.