Обвязка агента (harness): почти не влияет на долю решённых задач, но решает, сколько вы заплатите

Это находка, а не техника. Вот схема честного сравнения двух конфигураций агента, которую авторы использовали:

ШАГ 1: Зафиксировать модель, версию обвязки, лимит шагов, набор задач
ШАГ 2: Прогнать каждую конфигурацию минимум 2 раза → измерить разброс «сам с собой»
ШАГ 3: Сравнить конфигурации на тех же задачах → разница в решённых задачах
ШАГ 4: Если разница ≤ разброса между повторами → это шум, не эффект
ШАГ 5: Отдельно посчитать токены и деньги по единому прайсу → именно здесь реальная разница
ШАГ 6: Для каждой проваленной задачи записать, чем закончился запуск
        (сам остановился / лимит вывода / переполнение контекста / лимит шагов)

Задача: Вы ведёте разработку интернет-магазина на Claude Code. Счёт за API растёт. В CLAUDE.md за полгода накопилось 6000 токенов правил, и ещё подключено восемь MCP-серверов. Вы хотите понять, что из этого окупается, а что просто едет с каждым шагом агента и стоит денег.

Промпт:

Ты — аудитор инструкций для кодового агента. Ниже мой CLAUDE.md и список подключённых инструментов.

Контекст: всё, что лежит в системной инструкции и описаниях инструментов, отправляется модели заново на КАЖДОМ шаге работы агента. Если агент делает 100 шагов, каждая лишняя тысяча токенов превращается в сто тысяч. Задача аудита — найти, что можно убрать без потери качества, и что нельзя.

Сделай по шагам:
1. Оцени вес каждого раздела CLAUDE.md в токенах (грубо) и построй таблицу «раздел — вес — нужен ли на каждом шаге».
2. Раздели правила на три группы:
   (а) нужны всегда (стиль кода, запреты, команды запуска тестов);
   (б) нужны только в особых задачах (миграции, деплой, работа с платёжкой) — предложи вынести в отдельные файлы, которые агент читает по запросу;
   (в) дубли, устаревшее, общие слова вроде «пиши качественный код» — предложи удалить.
3. Для списка инструментов: какие из них агент реально вызывал бы в типичной задаче, а какие просто занимают место в описании.
4. Предложи урезанную версию CLAUDE.md и список из 3 проверочных задач, на которых я сравню старую и новую версии. Для каждой задачи — по 2 прогона на версию, чтобы увидеть разброс.
5. Отдельно напомни, что именно мне записывать в каждом прогоне: прошла ли задача, число шагов, число токенов, чем закончился запуск.

Не придумывай цифры. Если не хватает данных — задай вопрос.

CLAUDE.md:
{вставить}

Подключённые инструменты и MCP-серверы:
{список}

Результат: Модель выдаст таблицу с весом разделов, разбивку правил на «всегда / по случаю / удалить» и черновик сокращённой версии. Дальше пойдёт план мини-эксперимента: три задачи, по два прогона на версию, что записывать. Главное — вы получите список кандидатов на удаление и план проверки, а не готовый вердикт. Проверка остаётся за вами.

Слабость: по одному запуску агента трудно судить о качестве. Агент недетерминирован: задача, которую он решил сегодня, завтра может не решиться, и наоборот. Поэтому «поменяли промпт — стало лучше на 3 пункта» легко принять за результат, хотя это жребий. Плюс к тому интуиция обманывает: тяжёлая обвязка с длинными инструкциями выглядит умнее.

Сильная сторона: современные модели уже сами умеют работать с репозиторием. Им хватает одного простого инструмента (командной строки) и короткой инструкции. Длинная преамбула почти не добавляет качества, зато оплачивается на каждом шаге.

Как использовать: смотрите на обвязку как на статью расходов, а не как на источник качества. Рычаги управления: - Размер постоянной части (системный промпт, CLAUDE.md, описания инструментов) → меньше вес, дешевле каждый шаг. - Число шагов → если агент ходит кругами, счёт растёт даже при лёгкой обвязке. У DeepSeek лёгкая обвязка сделала больше шагов и в итоге передала больше токенов. - Повторы запусков → два прогона на конфигурацию, чтобы увидеть шум, прежде чем объявлять победителя. - Причина остановки → фиксируйте, как закончился провал. Если агент оборвался на лимите вывода, это поломка обвязки, а не слабость модели.

Шаблон простой, быстрый старт не нужен. Это промпт-аудит: он находит лишний вес и план проверки.

Ты — аудитор инструкций для кодового агента.

Факт: системная инструкция и описания инструментов отправляются модели заново на каждом шаге. Чем больше шагов, тем дороже каждая лишняя строка.

Проанализируй {файл_инструкций} и список инструментов {инструменты}:
1. Таблица: раздел — вес в токенах — нужен на каждом шаге или только в особых задачах.
2. Три группы: «нужно всегда» / «вынести в отдельный файл по запросу» / «удалить (дубли, общие слова, устаревшее)».
3. Какие инструменты агент вряд ли вызовет в типичной задаче {тип_задач}.
4. Урезанная версия инструкции.
5. План проверки: {число_задач} задач, по {число_прогонов} прогона на версию; в каждом прогоне записывать результат, число шагов, число токенов и причину остановки.

Не придумывай цифры. Если данных мало — спроси.

Что подставлять: {файл_инструкций} — текст вашего CLAUDE.md, AGENTS.md или системного промпта; {инструменты} — список MCP-серверов и команд; {тип_задач} — чем агент чаще всего занят (баги, рефакторинг, тесты); {число_задач} — обычно 3–5; {число_прогонов} — минимум 2.

⚠️ Один бенчмарк: вся работа построена на исправлении багов в Python-репозиториях. Для вёрстки, аналитики, документации или длинных многоступенчатых проектов вывод «обвязка не влияет на качество» никто не проверял.

⚠️ Обвязки менялись целиком: авторы сравнивали готовые продукты, а не отдельные куски. Нельзя сказать, какая именно часть длинной преамбулы лишняя, а какая нужна. Принцип «сокращай» надо проверять на своих задачах.

⚠️ Узкое окно контекста — другой случай: по обзору литературы в статье, управление контекстом (сжатие истории) сильно помогает, когда окно маленькое. Вывод «лёгкая обвязка не хуже» относится к моделям с большим окном.

⚠️ Один запуск на ячейку в большинстве сравнений: повторы были только в части конфигураций. Малые выборки на сложных задачах не различают разницу в десяток пунктов. Малые различия между обвязками авторы увидеть и сами не могли.

⚠️ Деньги посчитаны не для всех: реальную цену в рублях и юанях считали только для двух моделей через API. Для локальных моделей были только токены, для Claude Opus — подписка. Если вы платите подпиской, разница 3× проявится в лимитах, а не в счёте.

⚠️ Причина обрывов неизвестна: авторы не знают, что именно в OpenCode заставляет модель останавливаться раньше. Пересадка подсказки «продолжай» из Claude Code в OpenCode вернула задачи в количестве, неотличимом от нуля.

Идея была простой: перестать верить громким заявлениям вендоров и посмотреть, насколько результат сдвигается при смене обвязки по сравнению с простым перезапуском той же самой обвязки. Взяли три готовые обвязки: Claude Code, mini-SWE-agent и OpenCode. Пять моделей прогнали через все три, а Claude Opus 5 — только через Claude Code, как «потолок». Задачи брали из SWE-bench Verified: 45 самых сложных отдельно, чтобы увидеть, где обвязка должна быть важна, и ещё 447 остальных, чтобы мощности хватало на малые эффекты. Для каждой конфигурации делали повторные прогоны, чтобы измерить «шум». Все запуски шли без интернета: в ранних прогонах с сетью 71% запусков DeepSeek и Qwen просто скачали готовое исправление с GitHub, эти данные выбросили. Стоимость считали по единому прайсу из токенов каждого запуска.

Результат оказался неожиданным. Тяжёлая и лёгкая обвязки на 447 задачах эквивалентны в пределах 5 пунктов. На сложных задачах смена обвязки меняет исход у 13% задач, и перезапуск той же обвязки тоже у 13%. Причём какие именно задачи «выигрывает» обвязка, в следующем прогоне не повторяется. Единственное, что превышает шум, — проигрыш OpenCode (до 9 пунктов), и половина проигрыша сидит в запусках, оборванных лимитом вывода, где обвязка не просит модель продолжить. Деньги же различаются в разы: преамбула в Claude Code 16 тысяч токенов против менее тысячи у mini-SWE-agent, а рост истории за шаг у всех трёх близок. Практический инсайт: цена задаётся на первом вызове и умножается на число шагов. Кэш входных токенов масштабирует счёт, но порядок обвязок по цене не меняет. Ещё одна оценка: при таком шуме 45 задач ловят разрыв в 13 пунктов лишь в половине случаев, а 447 задач — около 5 пунктов. Многие опубликованные «улучшения обвязок» находятся ниже этих порогов.

🔧 Техника: добавить в инструкцию правило про обрыв → страховка от потери задач

Самый чёткий механизм потерь в статье — обрыв ответа на лимите вывода без повторного запроса. В Claude Code повторный запрос есть, и он теряет почти ноль задач. Если ваш агент работает в похожей среде, можно добавить в инструкцию:

Если твой предыдущий ответ оборвался или в рабочей папке нет готового результата,
не завершай работу. Проверь состояние файлов и продолжи с того места,
где остановился. Завершай только когда результат записан на диск и проверен.

Это моя достройка. В статье подобная вставка в OpenCode не дала значимого возврата задач, так что проверяйте на своих сценариях.

Экстраполяция: проверка любых «улучшений промпта» по правилу шума

Принцип статьи работает не только для агентов. Любую новую версию промпта в рабочем процессе можно проверить так:

Я хочу сравнить две версии промпта на своих задачах.
Версия A: {промпт_A}
Версия B: {промпт_B}
Набор тестовых входов: {входы}

Составь план проверки:
1. Сколько раз прогнать каждую версию на каждом входе, чтобы увидеть разброс «A против самой себя».
2. Как записать результаты: пройдено/не пройдено, длина вывода, расход токенов.
3. Правило решения: считаем B лучше только если разница между A и B больше, чем разница между двумя прогонами A.
4. Отдельно сравни стоимость: какая версия дешевле при одинаковом качестве.

• Работа: «What Does a Harness Buy? Tokens, Mostly», Yangze Liu, Zhongyi Han, Shandong University (препринт).
• Обвязки в эксперименте: Claude Code (Anthropic), mini-SWE-agent (Lieret et al.), OpenCode (Anomaly Innovations); запуск через Harbor.
• Бенчмарк: SWE-bench Verified (Jimenez et al.; OpenAI).
• Связанные работы: Vats & Golev (разница по токенам на решённую задачу до 40×), Bjarnason et al. (десять перезапусков одной конфигурации дают разброс 2,2–6,0 пункта), Ben Sghaier et al. (35 релизов одной обвязки без значимого роста качества при почти удвоенных токенах), Fan et al. (компонентный анализ: управление контекстом помогает при тесном окне, а сильным моделям хватает только bash-инструмента).