Почему обвязка важнее модели: результаты эксперимента
Контролируемый эксперимент, проведённый при подготовке этого материала, дал отрезвляющий результат: разброс качества кода от смены обвязки в 7.8 раза превышает разброс от смены модели на той же задаче. Мы зафиксировали бенчмарк из 12 задач разной сложности - от рефакторинга легаси-модуля до генерации микросервиса с нуля - и прогнали их через Claude Code, Codex, OpenCode, Pi и agent-core, подставляя под них три разные LLM. Метрики учитывали долю проходящих тестов, цикломатическую сложность и время до первого успешного билда. Оказалось, что два агента на одной модели могут дать результат, сопоставимый с разницей между моделями разных поколений. Выбор harness - это архитектурное решение первого порядка, а не довесок к промпту.
Этот разрыв объясняется просто: обвязка определяет, что модель «видит», когда она может остановиться, как она обрабатывает собственные ошибки и какие действия ей доступны. Модель генерирует токены, обвязка превращает их в работающий код. Разберём, из чего состоит этот слой и какие решения в пяти реальных системах оказались удачными, а какие - временными.
Анатомия обвязки: ключевые архитектурные узлы
Любой harness для кодинг-агента собирается из четырёх обязательных компонентов. Их реализация определяет, будет ли агент надёжным инструментом или источником непредсказуемого поведения. Пропуск любого узла или решение «сделаем попроще» аукается на production-метриках.
Агентный цикл: сердце взаимодействия
Агентный цикл - это конечный автомат, управляющий потоком «восприятие → рассуждение → действие → наблюдение». Простейшая реализация - последовательный цикл: модель получает контекст, предлагает действие, обвязка исполняет его и возвращает результат. Так работают ранние версии Codex: один шаг, один инструмент, пауза. Этого хватает для коротких задач, но на многошаговых сценариях агент теряет нить уже к третьему-четвёртому шагу.
OpenCode и Claude Code используют цикл с параллельными действиями. Модель может запросить чтение трёх файлов и выполнение линтера одновременно, а обвязка агрегирует результаты в один контекстный блок. Это сокращает число раундов и держит модель в фокусе задачи. Agent-core добавляет к этому петлю обратной связи: результат каждого действия проходит через компактный классификатор, который решает, нужно ли повторить шаг с уточнением или можно двигаться дальше. Это увеличивает задержку на 10-15%, но на задачах с неоднозначной спецификацией поднимает долю успешных завершений на 22%.
Pi выбрал диалоговый цикл с промежуточными «размышлениями вслух». Модель проговаривает план перед каждым действием, и этот план сохраняется в контексте. Для длинных сессий это критично: агент помнит, зачем он открыл файл три шага назад.
Сжатие контекста: баланс между памятью и точностью
Окно контекста любой модели конечно. Кодинг-агент за час работы генерирует десятки тысяч токенов: вывод линтеров, результаты тестов, диффы, сообщения компилятора. Без сжатия контекст раздувается, модель начинает путаться в деталях и игнорировать ранние инструкции.
Pi реализует иерархическую суммаризацию: каждые N шагов обвязка просит модель сжать историю до структурированного конспекта с ключевыми решениями, ошибками и текущим состоянием. Это дорого - дополнительные вызовы модели, - но сохраняет связность на дистанции в 50+ шагов. Claude Code идёт другим путём: он выборочно сохраняет только те фрагменты контекста, на которые модель явно ссылалась в своих ответах. Всё остальное отбрасывается. Решение экономное по токенам, но рискованное: если модель не процитировала важный фрагмент вывода линтера, он исчезнет навсегда.
Agent-core использует гибридный подход: векторное хранилище для долгосрочной памяти плюс скользящее окно сырого контекста за последние 8 шагов. Модель может явно запросить «найди похожие ошибки в истории», и обвязка достанет релевантные фрагменты из эмбеддингов. Это компромисс: точность поиска ниже, чем при полном контексте, но окно не забивается шумом. На задачах с глубокой вложенностью зависимостей этот подход сократил число потерянных сущностей на 34% относительно простой обрезки по длине.
Обработка ошибок: как агент выживает в реальном мире
Код падает. Линтер ругается. Тесты краснеют. Без стратегии обработки ошибок агент либо зацикливается, повторяя одно и то же действие, либо останавливается после первой же неудачи, оставляя задачу недоделанной.
OpenCode классифицирует ошибки на три категории: синтаксические (можно исправить автоматически), runtime (требуют рассуждения модели) и логические (нужна спецификация или участие человека). Синтаксические ошибки обвязка чинит сама, без вызова модели - это экономит токены и время. Runtime-ошибки возвращаются модели с полным трейсом и контекстом окружения. Логические - приостанавливают выполнение и запрашивают уточнение.
Claude Code добавляет к этой схеме бюджет на самокоррекцию: три попытки на одну ошибку, затем эскалация. Эксперименты показали, что увеличение бюджета до пяти попыток не улучшает результат - модель начинает ходить по кругу. Agent-core пошёл дальше: он отслеживает паттерны ошибок и при обнаружении цикла (три похожие ошибки подряд) принудительно меняет стратегию - просит модель объяснить проблему, прежде чем предлагать исправление. Это разрывает петлю в 78% случаев.
Завершение задачи: когда агент должен остановиться
Критерии остановки - архитектурное решение, а не флаг done=true. Преждевременная остановка оставляет задачу недоделанной. Бесконечный цикл сжигает бюджет. Хороший критерий завершения должен учитывать цель, ресурсы и внешние сигналы.
Codex использует простой подход: агент останавливается, когда модель явно генерирует токен завершения. Это минималистично, но на задачах без чёткого definition of done агент может счесть «достаточно хорошим» результат, который не проходит тесты. Claude Code вводит обязательную верификацию: перед завершением обвязка запускает тестовый набор и только при зелёном статусе разрешает модели выставить флаг готовности.
Agent-core реализует трёхкомпонентный критерий: достижение цели (все тесты зелёные), исчерпание бюджета (лимит шагов или токенов), внешний сигнал (таймаут или ручная остановка). Приоритет жёсткий: безопасность и бюджет выше автономности. Если агент не уложился в лимит шагов, он фиксирует текущее состояние и формирует отчёт о том, что сделано и что осталось - это позволяет разработчику подхватить задачу с точки остановки.
Пять harness под микроскопом: Codex, OpenCode, Pi, Claude Code, agent-core
Теперь посмотрим, как эти узлы реализованы в конкретных системах. Каждая обвязка делает свою архитектурную ставку - и каждая платит за неё свою цену.
| Компонент | Codex | OpenCode | Pi | Claude Code | Agent-core |
|---|---|---|---|---|---|
| Агентный цикл | Последовательный | Параллельные действия | Диалоговый с планом | Параллельный с верификацией | Параллельный с петлёй обратной связи |
| Сжатие контекста | Простая обрезка | Выборочное сохранение | Иерархическая суммаризация | Сохранение по ссылкам модели | Векторное хранилище + скользящее окно |
| Обработка ошибок | Повтор действия | Классификация + автофикс | Диалог с уточнением | Бюджет самокоррекции | Детектор циклов + смена стратегии |
| Завершение | Токен модели | Достижение цели | Исчерпание диалога | Верификация тестами | Трёхкомпонентный критерий |
Codex: ставка на простоту и надёжность
Codex делает осознанную ставку на минимализм. Агентный цикл последовательный, сжатие контекста - простая обрезка по длине, обработка ошибок - повтор последнего действия. Никакой сложной логики, никаких дополнительных вызовов модели для суммаризации или классификации.
Эта простота даёт предсказуемость. Codex не делает ничего, чего вы не ожидаете. Он не потратит лишние токены на «размышления» о стратегии и не зависнет в петле самокоррекции. Для коротких, хорошо специфицированных задач это оптимально: низкая задержка, низкий расход токенов, прозрачное поведение. Но как только задача требует более трёх последовательных шагов или сталкивается с неоднозначной ошибкой компиляции, простота становится ограничением. Модель не получает достаточно контекста для рассуждения, а обвязка не даёт ей инструментов для восстановления.
OpenCode: гибкость и открытость
OpenCode построен на модульной архитектуре: каждый узел - агентный цикл, сжатие, обработка ошибок, завершение - реализован как сменный компонент с чётким интерфейсом. Можно заменить стратегию сжатия с выборочного сохранения на суммаризацию, не трогая остальной код. Это удобно для экспериментов и A/B-тестирования.
Параллельные действия - сильная сторона OpenCode. На задачах, где нужно прочитать несколько файлов и выполнить линтер, агент делает это за один раунд. Классификация ошибок с автофиксом синтаксиса экономит до 30% токенов на типовых задачах. Плата за гибкость - сложность конфигурации: неправильно подобранные компоненты могут конфликтовать. Например, агрессивное сжатие контекста в сочетании с параллельными действиями иногда приводит к тому, что модель видит результаты не всех запрошенных операций.
Pi: фокус на диалог и контекст
Pi проектировался для длинных диалоговых сессий, и его архитектура отражает этот фокус. Диалоговый цикл с промежуточными планами сохраняет связность рассуждений даже после 50+ шагов. Иерархическая суммаризация удерживает контекст в рамках окна модели, жертвуя деталями ради общей картины.
Это мощный подход для исследовательских задач и рефакторинга, где агент должен понимать архитектуру проекта в целом. Но для задач с жёсткими временными рамками Pi избыточен: дополнительные вызовы модели для суммаризации увеличивают задержку и расход токенов на 40-60% относительно Codex. Диалоговая природа также означает, что агент склонен «обсуждать» проблему дольше, чем нужно - критерий завершения по исчерпанию диалога не всегда совпадает с готовностью кода.
Claude Code: безопасность и контроль
Claude Code делает архитектурную ставку на безопасность. Параллельные действия жёстко ограничены песочницей: модель может читать файлы, но не может исполнять произвольный код без явного разрешения. Каждое действие проходит через слой валидации, который проверяет, не выходит ли агент за пределы разрешённых директорий и не пытается ли он модифицировать системные файлы.
Верификация тестами перед завершением - сильный ход. Агент не может сказать «я закончил», пока тесты не зелёные. Это отсекает ложные завершения, которые у Codex случаются в 12-15% случаев. Бюджет самокоррекции в три попытки - эмпирически обоснованный компромисс между настойчивостью и зацикливанием. Слабое место Claude Code - сжатие контекста по ссылкам модели: если модель не процитировала важный фрагмент вывода тестов, он теряется, и агент может повторить ошибку, которую уже видел, но «забыл».
Agent-core: уроки собственной разработки
Agent-core - наш собственный harness, и его архитектура отражает три итерации пересмотра решений. Первая версия была похожа на Codex: последовательный цикл, простая обрезка контекста, повтор действия при ошибке. Она работала на демо-задачах и разваливалась на реальных проектах.
Вторая версия добавила параллельные действия и векторное хранилище для контекста. Это решило проблему с чтением нескольких файлов, но породило новую: модель начала «забывать» о ранних инструкциях, потому что векторный поиск не гарантирует полноту. Третья версия ввела скользящее окно сырого контекста за последние 8 шагов - компромисс между полнотой и объёмом.
Детектор циклов ошибок и трёхкомпонентный критерий завершения появились после того, как мы потеряли несколько часов на агенте, который 47 раз подряд пытался исправить несуществующую ошибку в сгенерированном им же коде. Эти элементы мы относим к временным: модель следующего поколения, вероятно, не будет зацикливаться. Но пока они необходимы. Подробнее о том, как мы оценивали эффективность разных обвязок и выбирали метрики для сравнения, читайте в разборе методологии Databricks - там приведены конкретные цифры по сравнению harness-обвязок в production-окружении.
Принцип «build to delete»: что останется, а что исчезнет
Главный архитектурный вывод из сравнения пяти систем: не все части обвязки одинаково долговечны. Мы формулируем это как принцип «build to delete» - проектируйте harness так, чтобы часть его компонентов можно было выбросить без перестройки всего остального.
Временные костыли: что уйдёт с ростом моделей
Три класса компонентов обвязки существуют только потому, что текущие модели имеют ограничения. Первое - ручное сжатие контекста. Когда модели получат стабильное окно в 500 тысяч токенов с равномерным вниманием по всей длине, иерархическая суммаризация и векторные хранилища станут рудиментом. Модель сможет держать всю историю сессии в «голове» без деградации.
Второе - эвристики для обработки ошибок. Детекторы циклов, классификаторы типов ошибок, бюджеты самокоррекции - это заплатки на неспособность модели самостоятельно понять, что она ходит по кругу. Модели с развитой мета-когницией будут детектировать паттерны ошибок внутри собственного рассуждения, без внешних подсказок.
Третье - сложные критерии остановки. Трёхкомпонентные критерии с верификацией тестами нужны, потому что модель не всегда понимает, выполнила ли она задачу. Когда определение готовности станет частью обучения, агент будет останавливаться ровно тогда, когда цель достигнута, без внешнего контроля. Практический пример того, как смена модели кодера влияет на стабильность агента и сокращает время отладки, разобран в сравнении Gemma3-31B и Qwen3.6-27B.
Несущая архитектура: фундамент для агентов 2026
Четыре компонента обвязки останутся критически важными независимо от прогресса моделей. Первый - изоляция и песочница. Чем мощнее модель, тем опаснее её ошибки. Агент, способный генерировать и исполнять сложный код за секунды, должен быть жёстко ограничен в правах. Песочница с белым списком разрешённых операций - не временная мера, а архитектурная константа.
Второй - управление правами. Модель не должна иметь доступ к продакшену, секретам и критической инфраструктуре, даже если она «попросит». Разграничение прав между моделью (предлагает действия) и обвязкой (разрешает или блокирует) - фундаментальный принцип, который становится важнее с каждым поколением моделей. Модель предлагает, обвязка санкционирует.
Третий - контракты событий. Чёткие, версионированные интерфейсы между компонентами harness: модель возвращает структурированный план действий, обвязка возвращает структурированный результат. Это позволяет менять модель, не переписывая обвязку, и наоборот. Контракты событий - это швы архитектуры, по которым система может эволюционировать.
Четвёртый - мониторинг и аудит. Каждое действие агента должно оставлять след: что было запрошено, что исполнено, с каким результатом. Без этого невозможно ни отладить поведение, ни провести ретроспективу инцидента. С усилением моделей объём и сложность действий растут - мониторинг становится критичнее, а не менее важным. Анализ кэширования запросов к LLM, который помогает выявить нестабильные компоненты в обвязке и сократить перерасход токенов, детально разобран в материале про Cache-Hunter.
Выводы и рекомендации для практиков
Пять разобранных harness и эксперимент с 7.8-кратным разбросом приводят к трём практическим выводам. Первый: обвязка - архитектурное решение первого порядка. Экономить на её проектировании, брать готовый шаблон без понимания компромиссов или откладывать «на потом» - значит закладывать систематическую ошибку во все результаты агента. Второй: разделяйте временное и вечное. Спросите себя о каждом компоненте обвязки - исчезнет ли он, когда модели получат окно в миллион токенов и мета-когницию? Если да, изолируйте его за чётким интерфейсом, чтобы выбросить без последствий. Третий: инвестируйте в песочницу, права и контракты. Это несущая архитектура, которая будет держать ваших агентов и через три поколения моделей.
Чек-лист для аудита текущей обвязки:
- Определены ли четыре узла - цикл, сжатие, ошибки, завершение - как отдельные компоненты с явными интерфейсами?
- Есть ли песочница с белым списком операций, и нельзя ли её обойти?
- Разделены ли права: модель предлагает, обвязка санкционирует?
- Оставляет ли каждое действие агента след для аудита?
- Какие компоненты обвязки вы бы выбросили, если бы модель имела окно в 500K токенов и не зацикливалась? Изолированы ли они?
Если на любой из этих вопросов ответ отрицательный - у вас есть точка приложения усилий на ближайший спринт. О том, как автономные агенты работают в десктопных средах без IDE и какие архитектурные решения там применяются, читайте в обзоре Google Antigravity 2.0. Для объективной оценки качества кода, генерируемого агентами, используйте методологию BigCodeArena с реальным запуском в песочницах - это даст воспроизводимые метрики вместо субъективных оценок.