Почему контекст заканчивается и что происходит дальше
При работе с кодовой базой на 200-300 тысяч токенов контекст переполняется за несколько часов. Решение - harness: обвязка, которая сама отслеживает заполнение окна, фиксирует состояние проекта и открывает новую сессию с готовым handover-документом. Ручной передаточный документ решает ту же задачу, но только пока вы сидите рядом и помните, что в него положить.
Механика переполнения проста. Агент читает файлы, диффы, вывод тестов и ваши правки. Каждый шаг добавляет токены в KV-кэш. Когда окно занято почти полностью, начинают выпадать ранние сообщения: системные инструкции, список задач, договорённости по стилю кода. Резкого провала нет: агент чаще ошибается и увереннее объясняет ошибку. На 80% заполнения следующий крупный файл вытеснит что-то нужное, поэтому продолжать в этой сессии рискованно.
Qwen 3 27B в Q4 с окном 300K и в Q6 с 200K дают разный запас, но оба варианта конечны. Крупная кодовая база с историей, тестами и документацией съедает такое окно за одну длинную сессию. Проблема не в размере контекста и не в модели. Проблема в том, что жизненный цикл сессии остался ручным.
Что такое harness и почему Agent = Model + Harness
Harness - обвязка вокруг модели, которая управляет пятью вещами: инструкциями, состоянием проекта, верификацией, границами scope и жизненным циклом сессии. Модель генерирует токены. Harness решает, что она видит, что считается сделанным и в какой момент сессия закрывается. Разбор слоёв обвязки, включая управление контекстом и гейты, есть в статье о harness engineering и управлении контекстом в AI-агентах.
Формула Agent = Model + Harness объясняет распределение ответственности. Если вы не модель, вы - harness. Всё, что вы делаете руками вокруг агента, придётся либо автоматизировать, либо повторять каждый день.
Надёжность длительных задач определяется обвязкой. В контролируемом эксперименте одну и ту же модель Opus 4.5 с одним промптом «build a 2D retro game editor» запускали дважды. Без harness: около $9 за 20 минут и сломанный вывод. С harness по схеме planner + generator + evaluator: около $200 за 6 часов и рабочий результат. Модель не менялась. OpenAI сообщает похожий сдвиг надёжности Codex в хорошо обвязанном репозитории: переход из состояния «ненадёжно» в надёжное, а не мелкая настройка.
Почему один большой AGENTS.md не спасает
Подход с одним огромным AGENTS.md ломается предсказуемо, по трём причинам:
- Контекст ограничен. Мануал на 1000 строк вытесняет саму задачу, а не помогает ей.
- Когда важным объявлено всё, важного нет. Агент не расставляет приоритеты, потому что приоритетов в файле не осталось.
- Информация устаревает. Агент не отличает действующее правило от пережитка месячной давности.
Ручной handover-документ страдает от той же болезни. Вы пишете его из памяти, часть деталей теряется, часть уже неверна, а следующая сессия начинается с разбора чужих заметок вместо работы. Лечится это не увеличением документа, а разбиением знаний на структурированные файлы, которые агент читает выборочно.
Пять подсистем harness для управления контекстом
Harness собирается из пяти подсистем: инструкции, состояние, верификация, scope и жизненный цикл сессии. Работают они вместе. Уберёте верификацию - получите автоматизированный поток с недостоверными отчётами. Уберёте состояние - каждая новая сессия начнётся с нуля. Как устроена двухэтажная архитектура управления агентами с control plane, локальными гейтами и принципом ratchet, разобрано в материале harness engineering: двухэтажная архитектура управления AI-агентами.
Инструкции и прогрессивное раскрытие вместо энциклопедии
Прогрессивное раскрытие (progressive disclosure) означает, что агент стартует с малым объёмом инструкций и подтягивает детали по мере надобности. Точка входа - короткий AGENTS.md как карта: где лежат архитектура, планы, конвенции, куда писать результаты. Глубина живёт в отдельных файлах: design docs, описание архитектуры, exec plans, критерии качества.
В экосистеме Claude Code ту же роль выполняет SKILL.md. Файл обязателен, управляет активацией навыка и ссылается на скрипты и примеры, которые подключаются только при вызове навыка. Такой подход позволяет держать в одном плагине десятки навыков: в примере с плагином по кибербезопасности их 22, и каждый тянет за собой Python-скрипты лишь тогда, когда нужен.
Практическое правило: AGENTS.md не длиннее экрана. Всё, что не влезло, становится отдельным файлом со ссылкой из карты.
Состояние: progress log, feature list, git log
Состояние проекта живёт в трёх артефактах.
- Progress log: что сделано, что в работе, что дальше, какие места сломаны и не проверены.
- Feature list: машиночитаемый список фич. Активна ровно одна. Закрыть фичу можно только с доказательством.
- Git log: история коммитов как источник правды. Если коммита нет, работа не существует для следующей сессии.
Эти три файла и есть handover-документ. Разница с ручным вариантом в том, что их пишет harness по ходу работы, а не человек по памяти в конце. Ведите прогресс-лог отдельно от feature list: первый отвечает на вопрос «как шли дела», второй - «что осталось».
Верификация: runnable proof вместо «я думаю, работает»
Без harness шаг verify превращается в фразу агента «выглядит нормально». С harness это тесты прошли, линтер чистый, типы сходятся. Агенты объявляют победу раньше времени системно, поэтому требование простое: runnable proof, то есть запускаемая проверка с выводом, а не пересказ результата.
Минимальный набор для проекта на коде: unit- и smoke-тесты, линтер, typecheck, для критичных сценариев e2e. Цикл implement → verify → fix крутится до зелёного состояния. Запись в progress log появляется только после этого.
Scope: одна фича за раз и защита от переписывания списка
Scope ограничивает машиночитаемый feature list. Одна активная фича за раз: агент не может параллельно «немного» дорабатывать три модуля. Завершение фиксируется только с доказательствами: имя теста, дата, фрагмент лога.
Отдельное правило - нельзя переписывать список, чтобы скрыть незавершённую работу. Удалить пункт или пометить его выполненным без прогона проверок означает сломать сам механизм. Definition of done должно быть явным: что считается готовым и чем это подтверждается.
Жизненный цикл сессии: от старта до автоматического handover
Жизненный цикл сессии описывается примерно шестнадцатью шагами и укладывается в четыре фазы: старт, реализация, верификация, handoff. На старте агент читает progress log, feature list и git log, выбирает активную фичу. Дальше идёт цикл implement → verify → fix до зелёного, запись доказательств, обновление прогресса и фичи, безопасный коммит. Завершается всё фиксацией того, что проверено не было.
Wrap-up checklist и формирование handover-документа
При достижении порога заполнения контекста (в вашем случае 80%) harness запускает wrap-up checklist. В handover попадает:
- активная фича и её статус: сделано, в процессе, сломано;
- ссылки на progress log, feature list и последние коммиты;
- список мест, которые не проверялись;
- открытые вопросы и следующий конкретный шаг.
Человек в этом процессе не участвует. Все данные уже лежат в структурированных файлах, harness только собирает их в один документ и закрывает сессию коммитом в безопасном состоянии.
Автоматический старт новой сессии
Новая сессия начинается с загрузки handover-документа. Агент читает состояние, видит активную фичу и продолжает с того места, где предыдущая сессия остановилась. Этот сценарий стоит сравнить с работой без harness. Вторая сессия без памяти либо повторяет уже сделанную работу, либо бродит по репозиторию, и в итоге вы мержите сломанный код. С harness вы ревьюите результат, а не спасаете прогон.
Тонкость: handover не должен содержать весь диалог. Передаётся состояние проекта, а не история разговора. Иначе новый контекст забьётся тем же мусором, что и старый.
Готовые harness и фреймворки: что выбрать под локальный стек
Готового фреймворка, который по звонку формирует handover при 80% заполнения контекста, в открытых описаниях нет. Есть инструменты с сильной обвязкой и есть паттерны, которые переносятся в любой стек. Как выбирать coding-агента под задачу и какой у них уровень автономности, разобрано в сравнении Claude Code и Codex.
Паттерн planner / generator / evaluator для длительных прогонов
Роли разделяются: planner строит план и режет задачу на фичи, generator реализует, evaluator проверяет результат по заранее заданным критериям. Эксперимент с Opus 4.5, о котором шла речь выше, показывает цену и эффект: 20 минут и $9 против 6 часов и $200, но рабочий код вместо сломанного. Разбор архитектурных узлов обвязки, которые дают такой разрыв, и принципа «build to delete» для разделения временных костылей и несущей архитектуры есть в статье об архитектурных ставках обвязки кодинг-агентов.
Для локального запуска схема работает так же, только вместо облачных вызовов вы платите временем GPU. Planner может быть моделью поменьше, evaluator стоит запускать на той же Qwen 3 27B, что и generator, но в отдельной сессии и с чистым контекстом.
Что дописать в deepseek harness и opencode
Оба инструмента из вашего стека требуют ручного контроля, поэтому автоматизацию проще достроить, чем менять стек. Конкретные доработки:
- Трекер заполнения контекста: harness получает текущий размер окна и сравнивает с порогом 80%.
- Триггер wrap-up: при переходе порога запускается чеклист из предыдущего раздела.
- Генератор handover: сборка документа из progress log, feature list и последних коммитов.
- Автозапуск сессии: новый инстанс стартует с handover, а не с пустого чата.
- Верификационные гейты: без зелёных тестов, линтера и typecheck фича не закрывается.
Без пятого пункта первые четыре дадут скорость без надёжности: вы будете быстрее накапливать непроверенный код. О том, как OpenAI двигает Codex к постоянно работающему режиму с сохранением контекста между сессиями, стоит прочитать отдельно: постоянно работающий режим Codex, возможности и риски.
Практика: настройка под Qwen 3 27B Q4/Q6 на ROCm
Порог 80% связывает выбор квантования с частотой handover. Считается это прямо:
| Вариант | Окно контекста | Порог 80% | Практический эффект |
|---|---|---|---|
| Q4 | 300K токенов | 240K токенов | реже handover, выше расход VRAM, ниже качество генерации |
| Q6 | 200K токенов | 160K токенов | качество выше, окно меньше, handover чаще |
На R9700 с 32 ГБ RAM и Ubuntu 24.04 больший контекст упирается в память, поэтому Q4 с 300K даёт запас на длинную сессию, а Q6 с 200K выигрывает по качеству на сложных правках. Для длительных задач с большой кодовой базой решающий фактор - не максимальное окно, а работающий handover. При 80% заполнения harness должен начинать wrap-up, а не ждать, пока окно заклинит.
Ограничения ROCm 7.14 и локального стека
ROCm 7.14 на Ubuntu 24.04 с R9700 поддерживает не все фреймворки одинаково хорошо. Перед доработкой harness проверьте три вещи: работает ли ваш рантайм inference с нужной KV-квантовкой, переживает ли он перезапуск сессии без потери прогретого кэша и совместим ли выбранный агентный фреймворк с вашей сборкой. Автоматизация handover требует стабильного рантайма: если процесс падает на середине wrap-up, handover-документ останется недописанным.
Когда автоматизация контекста не поможет: альтернативы и ограничения
Harness управляет контекстом и состоянием. Знаний и специализации он не добавляет. Если агенту не хватает доменной информации или он путает редкие API вашего проекта, обвязка это не вылечит.
RAG как дополнение к harness
RAG подтягивает документы на этапе инференса и не трогает веса. Для большой кодовой базы это способ дать агенту доступ к документации, истории решений и описаниям модулей без загрузки всего в окно. Связка получается такой: harness отвечает за состояние и жизненный цикл, RAG - за подачу нужного фрагмента знаний в момент запроса.
Fine-tuning: когда стоит идти дальше промпта и RAG
Адаптация идёт по лестнице: системный промпт и few-shot примеры, схема вывода, затем RAG, затем инструменты (калькулятор, SQL, вызовы API), и только потом изменение весов. Прыжок через ступени стоит денег и качества. Выбор неверной ступени означает либо перерасход GPU, либо модель, которая забыла общие знания.
Когда речь доходит до весов, работают LoRA и QLoRA: базовая модель замораживается, обучаемых параметров становится меньше, требования к VRAM падают. Тяжёлое SFT на одной задаче ухудшает другие. Митигации известны: LoRA с замороженной базой, multi-task миксы, меньший learning rate, короткое обучение. Ещё стоит помнить, что новая базовая модель (Qwen 3, Llama 4, Gemma 4) обесценивает ваш fine-tune, поэтому в бюджет закладывается переобучение. Для управления контекстом fine-tuning не нужен вообще: это задача harness.
Итог: что внедрить в первую очередь
Порядок действий для вашего стека:
- Завести три файла состояния: progress log, feature list, git log.
- Добавить трекер заполнения контекста с порогом 80%.
- Реализовать wrap-up checklist и сборку handover-документа из файлов состояния.
- Настроить старт новой сессии с автоматической загрузкой handover.
- Встроить верификацию в цикл: тесты, линтер, typecheck, запись доказательств.
- Для долгих прогонов добавить разделение ролей planner / generator / evaluator.
Начинать стоит с текущего инструмента, deepseek harness или opencode, а не с поиска готового решения. Эксперимент с Opus 4.5 показывает масштаб эффекта и его цену: 6 часов прогона вместо 20 минут. На локальной Qwen 3 27B вы платите не деньгами за токены, а временем GPU, поэтому выигрыш от автоматизации handover окупается на второй-третий день работы с крупной кодовой базой.