Короткий ответ: харнес - это связка, а не одна модель
Харнес для автономного кодинга - это обвязка вокруг LLM, которая ведёт полный цикл: планирует задачи, правит код, запускает сборку и тесты, читает логи и решает, что делать на следующем шаге. Готового рейтинга таких обвязок под прогоны длиной в несколько суток нет. Вопрос, появившийся в ноябре 2026 в сообществе LocalLLaMA, содержит только постановку задачи без ответа и без сравнения инструментов: автор ищет харнес, который выдержит цикл dev/test/update на дни и более.
Длительная автономность держится на пяти вещах: управление контекстом, память между сессиями, оркестрация инструментов через MCP, автоматическая проверка результатов и обработка ошибок. Модель здесь один из элементов, и замена модели не лечит дырявую обвязку. Практика это подтверждает: даже удачный суточный прогон упирается в правила, которые задал человек, и в инфраструктуру вокруг модели, а не в её бенчмарки.
Масштаб задачи из обсуждения задаёт планку. Речь о тестовой игре примерно на 200 страниц кода с подключением Blender MCP, API генерации изображений и MCP для Unity, Godot и Unigine. Автор вопроса оценивает расход в «8-9 знаков токенов» от локальной модели, то есть сотни миллионов или миллиарды токенов. Это порядок величины из обсуждения, а не измеренный результат. Ниже нет выдуманных тестов и рейтингов: разбираем принципы, конкретные приёмы из документации и критерии, по которым собственный стек можно проверить до дорогого запуска.
Почему вопрос «лучший харнес» пока без готового ответа
Рейтинг требует сопоставимых условий: одинаковый проект, одинаковые лимиты, публичные логи расхода токенов и числа успешных проверок. Для многодневных прогонов таких данных в открытом доступе мало. Прогон стоит дорого, длится долго и сильно зависит от кодовой базы: обвязка, которая ровно держит Python-сервис с быстрыми тестами, может развалиться на проекте с Unity, где сборка идёт минутами, а ошибки видны только в редакторе.
Что действительно есть в открытых материалах: отдельные приёмы. Сабагенты с изолированным контекстом и короткой выжимкой на выходе, декларативные Markdown-манифесты конфигурации, белые и чёрные списки инструментов, маршрутизация рутины на дешёвую модель, лимит в 15 000 токенов на описания сабагентов. Плюс пример свободного агента: DeepSeek выложил на GitHub агента для кодинга под лицензией MIT, который проверяет репозиторий каждую минуту. Это ингредиенты, из которых собирается харнес, а не готовое сравнение продуктов.
Из чего состоит автономный цикл dev/test/update
Рабочий цикл выглядит так: планирование задачи, правка кода, сборка и тесты, чтение логов, исправление, коммит и обновление состояния проекта, переход к следующей задаче. Каждый шаг оставляет артефакт: diff, вывод тестов, номер коммита, заметку о решении. Артефакты и есть топливо для следующей итерации.
Автономность ломается в четырёх предсказуемых местах:
- Переполнение контекста. Логи сборки, диффы и вывод тестов забивают окно за десятки шагов, и модель начинает терять исходные требования.
- Потеря состояния между сессиями. После перезапуска или падения процесса агент не помнит, что уже сделано и какие файлы трогать нельзя.
- Неограниченный доступ к инструментам. Агент с правом запускать произвольные команды и писать в любые файлы рано или поздно это сделает.
- Отсутствие автопроверки. Без тестов и сборки в цикле модель чинит одно и ломает другое, а узнаёт об этом только человек через сутки.
Управление контекстом LLM-агента: как не утонуть в логах за несколько суток
Контекст - расходуемый ресурс с жёсткой ценой. За сутки работы агент генерирует тысячи строк вывода: тесты, стектрейсы, диффы, ответы инструментов. Если всё это складывать в одно окно, к концу первого дня модель работает с обрывками и повторяет уже отклонённые решения. Лечится это архитектурой, а не более длинным контекстом.
Сабагенты как способ изолировать контекст
Механика простая: сабагент запускается в изолированном контекстном окне, выполняет поручение и возвращает в основной диалог только короткую выжимку. Длинные логи и промежуточные результаты остаются в его собственном окне и не занимают место в основном разговоре.
Кому отдавать работу: поиск по репозиторию, чтение больших логов и отчётов сборки, сбор статистики, ревью diff. Сабагент-ревьюер, который анализирует изменения и выдаёт замечания с путём к файлу, номером строки и описанием дефекта, а код не правит, экономит контекст и снижает соблазн модели заодно переписать лишнее.
У изоляции есть цена. Поле description каждого зарегистрированного сабагента грузится в контекст основного агента на каждом шаге. Когда суммарный объём описаний превышает 15 000 токенов, Claude Code выводит предупреждение при запуске. Десяток подробно описанных сабагентов съедает бюджет ещё до начала работы. В поставке Claude Code есть встроенные Explore и Plan для быстрых поисковых операций: они по умолчанию стартуют без инструкций CLAUDE.md и без снимка git status, что снижает расход токенов.
Отдельная деталь для автономных прогонов: фоновые сабагенты фильтруются движком автоматически, из них принудительно удаляются интерактивные инструменты AskUserQuestion, EnterPlanMode, ScheduleWakeup и WaitForMcpServers. Сценарий, где фоновый агент в три часа ночи спрашивает разрешение, не сработает. Логика должна быть заложена в конфигурацию заранее.
Память между сессиями и версионирование конфигурации
Конфигурация сабагентов в Claude Code хранится в декларативных Markdown-файлах в репозитории: версионируется через git и применяется на лету, встроенный наблюдатель отслеживает изменения на диске за несколько секунд без перезапуска сессии. Для многодневного прогона это удобно: правила меняются по ходу работы и остаются в истории.
Тот же принцип работает для состояния проекта. Статус, список задач, принятые решения и запреты живут в файлах репозитория, а не в контексте модели. Пример такого подхода - слой состояния проекта с задачами, заметками и runbook'ами, который подключается к разным моделям через MCP. Практический вывод: агент должен уметь восстановить картину мира, прочитав несколько файлов, а не вспоминая диалог.
MCP-оркестрация инструментов: Blender, Unity/Godot/Unigine и генерация изображений
MCP даёт агенту руки: Blender MCP для 3D-ассетов и сцен, MCP для Unity, Godot и Unigine для работы с движком, API генерации изображений для текстур и концептов. Чем больше серверов подключено, тем шире возможности и тем выше риск, что агент тронет не то.
Белые и чёрные списки инструментов на практике
Доступ ограничивают технически. Параметры tools и disallowedTools задают белые и чёрные списки доступных инструментов, и это принципиально надёжнее просьбы в промпте: текстовая инструкция «ничего не меняй в коде» гарантий безопасности не даёт, а исключение Write и Edit из списка технически лишает сабагента возможности модифицировать проект.
Главная ловушка - Bash. Если Write и Edit запрещены, но Bash оставлен, запись файлов всё равно возможна через команды терминала. Для строгого аудита оставляют только Read, Grep, Glob. Для сборки дают Bash с узким набором разрешённых команд. Для правок - Write и Edit без произвольного терминала.
Практичная раскладка ролей для многодневного цикла:
| Роль | Инструменты | Задача | Риск при ошибке настройки |
|---|---|---|---|
| Аудитор | Read, Grep, Glob | Поиск по коду, чтение логов, ревью diff | Минимальный: писать нечем |
| Исполнитель | Read, Write, Edit | Правки в ограниченном наборе директорий | Перепишет лишнее, если не ограничить пути |
| Сборщик | Bash с узким списком команд | Сборка, тесты, запуск линтеров | Высокий: через терминал можно обойти любые запреты |
Blender MCP и MCP движков стоит держать в отдельной роли, у которой нет доступа к ключевым исходникам. Тогда эксперименты с ассетами и сценами не превращаются в переписанный код игры.
Почему несколько MCP-серверов быстро съедают токены
Каждый подключённый сервер добавляет в контекст описания своих инструментов, а каждый вызов возвращает результат: список объектов сцены, ответ API, лог сборки. Всё это служебный текст, который агент оплачивает на каждом шаге. На задаче из обсуждения, где рядом работают Blender, движок и генерация изображений, служебная часть легко превышает полезную.
Отсюда два вывода. Тяжёлые операции с большим выводом стоит выносить в сабагентов с короткой выжимкой на выходе. Рутину вроде сбора статистики, синтаксических проверок и первичного поиска файлов разумно маршрутизировать на более дешёвую модель: в Claude Code для этого предлагают Haiku, поскольку такие задачи не требуют мощности старшей модели. Экономия двойная: дешевле каждый шаг и меньше мусора в основном контексте.
Ограничения локальных LLM в многошаговых циклах: VRAM и пропускная способность
Локальный запуск снимает вопросы приватности и оплаты за токен, но переносит ограничения на железо. Длинный контекст хранится в памяти GPU как KV-кэш: чем больше окно и чем больше одновременных сессий, тем больше VRAM уходит на служебные структуры и тем меньше остаётся под веса модели и под сам инференс.
Публичных замеров, которые связывали бы длину контекста, VRAM и скорость генерации для конкретных моделей в многодневном цикле, в открытых материалах нет. Цифры придётся снимать на своём стеке, а не брать из обещаний. Ориентир для планирования даёт суточный марафон с Qwen 27B на llama.cpp с tensor-split между двумя GPU: там видно, как распределение модели по видеокартам, риск OOM и загрузка сервера влияют на ход работы.
Оценка из исходного обсуждения - сотни миллионов или миллиарды токенов на сборку тестовой игры - при локальном прогоне превращается в часы и сутки машинного времени. Это аргумент за короткие шаги с проверками, а не за один длинный проход по спецификации.
Длинный контекст и память GPU: прямая связь
Каждый лишний килобайт логов в контексте превращается в токены, токены в память под KV-кэш и в время на их обработку. Изоляция контекста через сабагентов экономит и токены, и память GPU: короткое окно основного агента означает меньший KV-кэш и больше запаса под саму модель.
Признак проблемы на практике: генерация замедляется по ходу прогона, приходится резать окно, ответы становятся короче и менее связными. Если это происходит на второй день, дальше будет хуже.
Когда локальная модель проигрывает по пропускной способности
Профиль нагрузки бывает двух видов. Первый: много коротких шагов с проверками, где время уходит на запуск тестов и повторные генерации по несколько тысяч токенов. Второй: редкие длинные генерации на десятки тысяч токенов, где модель пишет крупный модуль. Локальная модель чувствительна ко второму сценарию: длинная генерация упирается в скорость токенов в секунду, и ночь уходит на один файл.
Фоновая активность добавляет нагрузку. Агент, который проверяет репозиторий каждую минуту, как решение DeepSeek, держит постоянный поток небольших запросов. На локальной модели это конкурирует с полезной работой за те же GPU. При планировании стоит заранее решить, что уступает: фоновый опрос или генерация кода.
Как не дать ошибкам накопиться без человека
Главный риск многодневного прогона не в том, что модель не справится, а в том, что она ошибётся незаметно. Неверная структура данных на первом шаге тиражируется в десяти модулях, тесты при этом могут оставаться зелёными, если они написаны под ту же неверную модель. Человек узнаёт об этом на третий день, когда переписывать дороже, чем начинать заново.
Пример внешнего контроля: агент DeepSeek под лицензией MIT проверяет репозиторий каждую минуту. Материалы не содержат результатов его работы без участия человека, так что воспринимать его стоит как пример механики регулярной проверки, а не как доказательство автономности.
Автопроверка и откат: минимальный контур безопасности
- Сборка и тесты после каждого изменения, а не в конце дня.
- Коммит как чекпоинт: рабочее состояние всегда зафиксировано, откат делается одной командой.
- Автоматический откат при провале проверки, без попыток чинить поверх сломанного.
- Лимит попыток на одну ошибку: после N неудач задача уходит в список для человека, а не крутится в цикле.
- Лог решений: что агент менял, зачем и какой результат получил. Без него разбор инцидента через сутки невозможен.
- Стоп-условия по расходу токенов, времени и числу шагов.
Правило, которое стоит зашить в цикл: любое изменение проходит проверку до перехода к следующей задаче. Агент, который накопил пять незакоммиченных правок и три упавших теста, уже не понимает, какая из правок сломала сборку.
Где человек всё равно нужен
Архитектурные решения, приоритеты и финальную приёмку оставляет за собой человек. Модель хорошо держит рутину внутри заданных рамок: написать модуль по спецификации, поправить падающий тест, обновить зависимости. Выбор между двумя архитектурами, оценка того, что важно для продукта, и решение о релизе остаются на стороне человека. Автономный прогон снимает рутину, но ответственность не переносит.
Критерии выбора харнеса под многодневные задачи
Готовых бенчмарков нет, зато есть список свойств, без которых многодневный прогон почти наверняка развалится. Проверять харнес стоит по ним, а не по демо-роликам.
Что должно быть в конфигурации харнеса
| Критерий | Зачем нужен | Как проверить |
|---|---|---|
| Изоляция контекста | Длинные логи не забивают основной диалог | Дать задачу с большим выводом и посмотреть, растёт ли основной контекст |
| Декларативная конфигурация в git | Правила меняются по ходу прогона и остаются в истории | Изменить конфиг на ходу: применится без перезапуска или нет |
| Белые и чёрные списки инструментов | Защита от лишних правок | Запретить Write и проверить, что запись невозможна и через Bash |
| Поддержка MCP | Blender, движки, генерация изображений | Подключить сервер и оценить объём служебного текста |
| Маршрутизация задач на разные модели | Рутина не жжёт бюджет старшей модели | Отправить сбор статистики на дешёвую модель и сравнить качество |
| Автопроверка и откат | Ошибки ловятся на шаге, а не через сутки | Спровоцировать падение теста и посмотреть на реакцию |
| Логирование и лимиты | Разбор инцидентов и контроль расхода | Найти в логах, что агент делал час назад |
Отдельно стоит посмотреть, как харнес обходится с описаниями сабагентов. В Claude Code граница обозначена прямо: при суммарном объёме описаний свыше 15 000 токенов среда выводит предупреждение при запуске. Это понятный ориентир для любого другого инструмента: служебный текст не должен вытеснять рабочую задачу.
Как сравнивать харнесы без готовых бенчмарков
Методика простая и не требует публичных тестов. Берётся один пилотный проект с быстрыми тестами и известным объёмом. Одинаковые лимиты токенов и времени для каждого харнеса. Затем замеряются: расход токенов на один успешный шаг, число шагов до первого падения тестов, число откатов, доля задач, доведённых до зелёной сборки без вмешательства. Результат сравнивается на своём коде и своём железе, потому что переносить чужие цифры на другой стек бессмысленно.
Полезно посмотреть, как другие решают ту же задачу декомпозиции. Один из подходов - оркестратор задач на CLI-сессиях Claude Code, git worktree и tmux с веб-дашбордом: там видно, какие метрики пришлось пересматривать, когда выяснилось, что недетерминизм модели ломает привычные оценки. Другой вариант - замена фреймворка оркестрации структурой директорий и markdown-промптами: меньше движущихся частей, но и меньше автоматики.
Что проверить до запуска многосуточного прогона
Чек-лист перед запуском занимает час, а экономит сутки машинного времени.
Пилотный прогон перед многодневным запуском
- Запустить цикл на 2-4 часа на реальной задаче, а не на hello world.
- Снять расход токенов на шаг и экстраполировать на планируемую длительность.
- Проверить реакцию на падение теста: агент откатывается, чинит или зацикливается.
- Убедиться, что лимиты инструментов работают: попытка записи в запрещённую директорию должна провалиться.
- Проверить откат к последнему коммиту на копии репозитория.
- Посмотреть, что попадает в логи, и хватит ли их для разбора через сутки.
- Проверить мониторинг VRAM и температуры, если модель крутится локально.
- Задать точки остановки: по времени, по расходу токенов, по числу неудачных попыток.
- Убедиться, что в конфигурации нет сценариев с вопросами к пользователю в фоне: интерактивные инструменты у фоновых сабагентов отключаются автоматически.
Если пилотный прогон сжёг бюджет на четыре часа и не дал зелёной сборки, многосуточный запуск это не исправит. Лучше потратить время на декомпозицию задачи и на тесты, чем на второй прогон с теми же настройками.
Ограничения подхода: когда автономный харнес не оправдан
Небольшая задача не стоит многодневного прогона. Настройка, мониторинг и разбор инцидентов занимают время, а выигрыш в рутине будет нулевым, если работы на пару часов. Ручная правка с ассистентом в редакторе здесь дешевле.
Нет автопроверки - нет автономности. Если в проекте не запускаются тесты или сборка длится дольше, чем модель успевает наделать правок, ошибки накопятся почти гарантированно. Первым делом нужны быстрые проверки, и только потом длинный прогон.
Железо ставит потолок. Локальная модель, у которой длинный контекст не помещается в VRAM или генерация идёт слишком медленно, превратит многодневный цикл в медленное накопление мусора: к третьим суткам агент будет работать с обрезанным контекстом и повторять одни и те же ошибки.
Харнес для автономных задач кодинга - это инженерная обвязка, и её качество важнее выбора конкретной модели. Начинать стоит с пилотного проекта на несколько часов, с работающих тестов, с ограниченных инструментов и файлового состояния, а не с покупки ещё одной видеокарты.