TL;DR
Обвязка агента (harness) — это программа вокруг модели. Она решает, что модель видит, какие инструменты ей доступны, как повторять неудачные шаги и когда остановиться. Примеры: Codex CLI, OpenCode, Pi CLI, DeepAgents. Авторы прогнали одни и те же модели в четырёх обвязках на одних и тех же задачах. Они считали две вещи отдельно: решена ли задача и завершился ли прогон чисто (агент остановился сам и сдал результат в читаемом виде).
Главная находка: рейтинг «какая модель лучше» и «какая обвязка лучше» не переносится с одной пары на другую. Одна и та же модель в одной обвязке решает задачу, а в другой почти ничего не делает. Например, Kimi на задачах с долгим контекстом показывает то 8%, то 54% в среднем — только от смены обвязки. А лидер у одной модели оказывается аутсайдером у другой. Причина в том, что у обвязки есть «цена входа»: формат наблюдений, способ вызова инструментов, правила повторов. Одной модели это удобно, другой — нет.
Ещё два вывода. Во-первых, чистое завершение ≠ решённая задача: прогон может закончиться аккуратно и ничего не решить, а может «упасть» и всё равно получить частичный балл. Во-вторых, больше токенов ≠ лучше результат. Мало токенов часто значит, что агент остановился слишком рано. Много — что он долбился в одну и ту же ошибку.
Схема метода
Это не техника промптинга, а схема оценки. Её можно повторить в малом масштабе.
ШАГ 1: Фиксируем набор одинаковых задач → одни и те же для всех пар
ШАГ 2: Берём несколько моделей × несколько обвязок → таблица «модель × обвязка»
ШАГ 3: Каждую пару гоняем несколько раз (в статье — 4) → усредняем
ШАГ 4: Для каждого прогона отдельно отмечаем:
(а) решена ли задача (балл)
(б) завершился ли прогон чисто и сдал результат (да/нет)
ШАГ 5: Считаем «пригодность пары» → результат пары / лучший результат этой модели среди обвязок
ШАГ 6: Смотрим расход токенов рядом с результатом → ищем «много сожгли — мало получили»
Каждый шаг — отдельный запуск. Всё считается снаружи, одним промптом это не сделать.
Пример применения
Метод ценен там, где вы выбираете, чем запускать агента на своих задачах. Решить такой выбор одним промптом нельзя, но вот как сделать проверку на практике.
Задача: Студия в Новосибирске делает интеграции для интернет-магазинов: выгрузки на Ozon и Wildberries, правки в 1С-обменах. Тимлид хочет посадить агента на мелкие баги из бэклога. Для экономии он берёт недорогую открытую модель (например, Qwen). Вопрос: в какой обвязке её запускать? Бенчмарки показывают лидера, но на их задачах, а не на задачах студии.
Промпт (для ревью журнала прогонов — отдаёте LLM лог каждого запуска):
Ты проверяешь журнал одного прогона кодового агента. Задача была: {описание_задачи}.
Критерий решения: {критерий — например, "тест test_export_wb.py проходит"}.
Ответь строго по пунктам и ничего не смешивай:
1. ЗАВЕРШЕНИЕ. Агент остановился сам и выдал итоговый результат (патч/коммит/отчёт)?
Варианты: чистое / упал или завис / остановился, но результата нет.
Приведи цитату из лога, подтверждающую вывод.
2. РЕШЕНИЕ. Выполнен ли критерий решения?
Варианты: да / частично / нет. Приведи доказательство из лога.
3. РАСХОД. Были ли повторы одного и того же неудачного действия?
Сколько раз и какого именно.
4. РАННИЙ СТОП. Остановился ли агент до того, как задача была решена,
без попытки проверить результат?
5. Итог одной строкой: [чистое/нет] + [решено/нет] + [повторы: да/нет].
Журнал прогона:
{журнал}
Результат: Для каждого прогона вы получаете короткую карточку из пяти пунктов с цитатами из лога. Набираете 8–10 своих задач, гоняете каждую 2–3 раза в двух-трёх обвязках и складываете карточки в таблицу. Видно, какая пара чаще всего завершается чисто и решает задачу. Видно, где агент «сгорел» на повторах, а где остановился слишком рано. Победителя в чужом рейтинге искать не нужно: вы смотрите на свою пару и свои задачи.
Почему это работает
Слабость. Один итоговый балл смешивает три разных вещи: умеет ли модель решать, удобно ли ей работать в этой обвязке и не помогла ли обвязка задаче заранее встроенным сценарием. Агент мог решить задачу и не сдать результат, и тогда балл ноль. Или мог упасть и всё равно получить частичный кредит. По одному числу причину не определить.
Сильная сторона. Если менять один компонент за раз (модель при фиксированной обвязке, обвязку при фиксированной модели) и мерить два измерения отдельно, причина видна. Данные показывают, где лидерство меняет знак. Например, Kimi в Codex CLI слабее среднего на SWE-bench, но выше среднего на LOCA-Bench.
Как это даёт рычаги вам: - Число повторов (в статье 4) → для своей проверки хватит 2–3: меньше расход, шум чуть больше. - Набор задач → берите свои реальные, а не абстрактные. Именно на них зависит «пригодность пары». - Отдельный пункт про токены → если пара сожгла вдвое больше и не решила больше, считайте её нерабочей, а не «стараться надо больше». - Два измерения вместо одного → если чистых завершений мало, чините сначала остановку и сдачу результата, а уже потом качество решения.
Шаблон промпта
В статье готовых промптов нет — это работа об оценке, а не о промптинге. Выше — мой шаблон для ревью журнала, сделанный по логике статьи (два измерения отдельно + расход). Универсальная версия:
Ты проверяешь журнал одного прогона агента.
Задача: {задача}
Критерий решения: {критерий}
Оцени отдельно и не смешивай:
1. ЗАВЕРШЕНИЕ: чистое / упал или завис / остановился без результата. Цитата из лога.
2. РЕШЕНИЕ: да / частично / нет. Доказательство из лога.
3. ПОВТОРЫ: сколько раз агент повторял одно и то же неудачное действие.
4. РАННИЙ СТОП: остановился ли до решения без проверки результата.
5. Итог: [чистое/нет] + [решено/нет] + [повторы: да/нет]
Журнал: {журнал}
Подставляйте: {задача} — формулировка, которую получил агент; {критерий} — что считается успехом (тест, файл, цифра); {журнал} — текст лога прогона.
Ограничения
⚠️ Рейтинги не переносятся: лидер на этой панели (OpenCode) стабилен только для выбранных моделей и бенчмарков. Авторы прямо пишут: предпочтения конкретных моделей и промежуточные места зависят от набора. Не берите «лучшая обвязка» как готовый ответ.
⚠️ Нужен запуск самому: вывод применяется не промптом, а проверкой пары на ваших задачах. Это требует нескольких прогонов в разных обвязках и времени на разбор логов.
⚠️ Модели в статье — открытые и не из топа: Qwen, Kimi, MiniMax, DeepSeek. Для закрытых флагманов (Claude, GPT) картина может быть спокойнее: у них обвязка и модель обычно настроены друг под друга.
⚠️ Нет рецепта «как чинить»: статья диагностирует расхождения, но не проверяет конкретные правки обвязки. Что менять в инструкциях агента, она не говорит.
⚠️ Только кодовые и сервисные агентные задачи: творческие и аналитические сценарии не проверялись.
Как исследовали
Идея была простой: скрестить модели и обвязки, как в таблице умножения. Взяли четыре обвязки (DeepAgents, OpenCode, Pi CLI, Codex CLI) и четыре открытые модели. Прогнали шесть бенчмарков: правка кода (SWE-bench), терминал (Terminal-Bench 2), сервисные API (VitaBench), длинный контекст (LOCA-Bench), многодневные рабочие сценарии (ClawMark) и выбор навыков (AgentSkillOS). Для сводных цифр взяли общую панель из трёх моделей и четырёх обвязок: 72 конфигурации, 35 472 запуска, всего разобрали 52 168 траекторий. Каждую задачу гоняли по 4 раза. Разрешения, бюджеты и условия остановки уравняли. Собственные промпты и циклы каждой обвязки оставили как есть — сравнивали целые системы.
Чтобы развести «не решил» и «не сдал», ввели долю чистых завершений и пригодность пары — результат пары делится на лучший результат этой модели среди обвязок. Неопределённость оценивали бутстрепом (2000 перевыборок задач).
Что получилось. Рейтинг переворачивается: на SWE-bench DeepSeek обгоняет MiniMax в Codex CLI, а в OpenCode лидирует MiniMax. Разброс кратный: у Kimi в ClawMark OpenCode даёт около 82 балла, Pi CLI и Codex — около 12. У MiniMax в LOCA-Bench Codex даёт 93, Pi CLI — 21. Есть стабильные модели: DeepSeek сдаёт прогоны чисто в 91–94% случаев в любой обвязке, хотя результат всё равно зависит от обвязки. Токены не равны качеству: самая «лёгкая» обвязка меняется от пары к паре, а низкий расход иногда означает ранний стоп.
Удивило то, что отклонения пары от среднего меняют знак между бенчмарками и в итоговой цифре гасят друг друга. Для практики отсюда следует, что одного общего балла мало: смотрите профиль по своим типам задач.
Адаптации и экстраполяции
Это мои идеи, в статье их нет.
🔧 Техника: добавить в инструкцию агента правила остановки и сдачи → меньше «тихих» провалов.
Статья называет четыре слабых места использования обвязки: сборка действия, использование обратной связи, восстановление после ошибки и остановка. Их можно закрыть текстом в файле инструкций (CLAUDE.md, AGENTS.md):
Перед тем как остановиться:
1. Запусти проверку результата (тест, сборка, сверка с критерием).
2. Если проверка не пройдена — не останавливайся, назови причину и попробуй другой подход.
3. Если одно и то же действие провалилось 2 раза подряд — смени подход, не повторяй.
4. В конце выдай отчёт: что сделано, что проверено, что не получилось.
Работает ли это на вашей паре, надо проверить тем же ревью журналов.
Ресурсы
- Работа: When Agents Fail: Model or Harness—Who's to Blame?
- Авторы: Shao Zhang, Hangfan Zhang, Yuanyuan Shi, Hao Li, Min-Le Su, Kangcong Li, Jingping Wang, Chunjiang Mu, Chen Zhang, Yang Chen, Bo Zhang, Shuyue Hu — Shanghai Artificial Intelligence Laboratory.
- Бенчмарки: SWE-bench, Terminal-Bench 2, VitaBench, LOCA-Bench, ClawMark, AgentSkillOS.
- Обвязки: DeepAgents (LangChain), OpenCode, Pi CLI, Codex CLI (OpenAI).