Harness engineering: почему обвязка AI-агента важнее самой модели

Harness engineering: почему обвязка AI-агента важнее самой модели

Четырёхлетний ребёнок усваивает знания о мире быстрее, чем лучшие LLM усваивают текст. Почему? Дело не только в весах модели, а в том, как устроен процесс обучения и применения. Эта идея лежит в основе свежей статьи Лилиан Вэнг — она предлагает перестать фокусироваться на «мозге» и начать изучать обвязку, которая заставляет его работать. Harness engineering, по её мнению, может стать главным драйвером рекурсивного самоулучшения AI.

Что такое harness engineering

Harness — это система вокруг базовой модели. Она решает, как модель думает и планирует, какие инструменты вызывает, как воспринимает и управляет контекстом, где хранит артефакты и как оценивает результаты. Ранние агентные фреймворки описывали агента как «LLM + память + инструменты + планирование + действие». Harness идёт дальше: он добавляет workflow-дизайн, оценку, контроль разрешений и управление состоянием между запусками.

Если раньше инженерия сводилась к промптам, то теперь это проектирование runtime. Можно провести аналогию с операционной системой: сложная логика прячется внутри, а интерфейс остаётся простым. Модель — процессор. Harness — всё остальное, что превращает процессор в полезное устройство.

Почему harness может быть важнее raw intelligence

Вэнг выделяет простой, но контринтуитивный тезис: разрыв между сырым интеллектом и реальным результатом часто больше, чем мы думаем. Модель может блестяще справляться с бенчмарками сразу после предобучения, но в продакшене теряется из-за неправильного контекста, неудачной декомпозиции задачи или отсутствия обратной связи. Успех таких продуктов, как Claude Code и Codex, доказывает, что именно обвязка превращает LLM в рабочий инструмент.

Рекурсивное самоулучшение тоже перестаёт быть только про переписывание весов. В современной трактовке это цикл, в котором модель улучшает тренировочный конвейер и систему развёртывания — а они, в свою очередь, порождают более сильную следующую версию. Это не фантастика: лаборатории вроде Anthropic и OpenAI уже ускоряют исследования с помощью AI-инструментов, то есть сами становятся частью этого цикла.

Этот сдвиг важен понимать, потому что он меняет экономику AI-разработки. Если раньше главным драйвером прогресса считались масштаб данных и вычислений, то теперь всё больше ценности создаётся на уровне системного дизайна. Компания, которая умеет строить эффективные harness, может получать больше от менее мощной модели, чем конкурент с более сильной, но плохо упакованной моделью. Это делает область более демократичной и одновременно усложняет конкуренцию: побеждает не тот, у кого больше GPU, а тот, у кого лучше организован цикл обучения и развёртывания.

Три паттерна harness-дизайна

Первый паттерн — автоматизация рабочего процесса. Модель работает в цикле: планирует, выполняет, наблюдает, тестирует, улучшает и повторяет. Этот подход хорошо виден в репозитории Andrej Karpathy autoresearch, где агент исследует тему, пока не достигнет цели. Важно, что цикл не «про форму»: он заканчивается не текстом, а проверяемым результатом — кодом, числом, выводом.

Второй паттерн — файловая система как постоянная память. Вместо того чтобы пытаться удержать весь контекст в контекстном окне, агент записывает промежуточные результаты на диск. Это не просто кэш: это внешняя рабочая память, к которой модель может обращаться, редактировать и дополнять. Текстовые файлы, логи, сгенерированные артефакты — всё становится частью мышления.

Третий паттерн — субагенты и фоновые задачи. Сложная задача декомпозируется на подзадачи, которые выполняются параллельно или асинхронно. Это позволяет агенту не ждать, пока одна операция закончится, а работать над несколькими аспектами проблемы одновременно. Фоновые задачи особенно важны для долгих вычислений, поиска или взаимодействия с внешними системами.

Эти три паттерна не работают изолированно. Workflow задаёт ритм, файловая система хранит состояние, субагенты позволяют масштабировать работу. Вместе они формируют минимальную жизнеспособную обвязку для автономного агента. Без workflow агент хаотично переключается между задачами. Без памяти он каждый раз начинает с чистого листа. Без субагентов он не может справляться со сложностью, которая превышает его контекстное окно.

Harness и core intelligence: где граница

Вопрос, который задаёт Вэнг, звучит так: агентные способности — это часть базовой модели или часть обвязки? Сейчас ответа нет. Можно построить мощный coding agent, используя относительно стандартную модель, но с продвинутой обвязкой. И наоборот: суперсильная модель без хорошего harness будет тратить интеллект на нерелевантные детали и ошибки интерфейса.

Эта разница имеет практический смысл. Когда вы выбираете модель для агента, важно не только смотреть на leaderboard, но и понимать, какую обвязку вы можете к ней приложить. Хороший harness делает среднюю модель продуктивной, а плохой — гасит потенциал сильной. Для бизнеса это означает, что инвестиции в workflow-инженерию могут принести больше, чем инвестиции в более дорогую модель.

Проблема в том, что граница между моделью и harness размыта и меняется со временем. Сегодня планирование и декомпозиция задач реализуются в обвязке, потому что модели плохо справляются с длинными цепочками рассуждений. Завтра, при лучших моделях, часть этой логики может уйти в базовую модель. Но обратное тоже верно: по мере усложнения продуктов в обвязке появляются новые слои — оркестрация, совместная работа нескольких агентов, контроль соответствия политикам. Harness не исчезает, а эволюционирует.

Поэтому важно думать о компетенциях, а не о границах. Инженер, который умеет строить harness, разбирается в моделях, потому что должен знать их сильные и слабые стороны. Исследователь моделей, который не думает о системе, упускает половину возможностей. В долгосрочной перспективе успешные команды будут объединять оба типа экспертизы.

Оптимизация harness: от контекста до workflow

Оптимизация harness проходит по двум направлениям. Первое — контекстная инженерия. Какой контекст подавать модели, в какой момент и в каком формате? Необязательно давать всё сразу: часто лучше структурировать информацию по ролям, задачам или стадиям процесса. Правильный контекст уменьшает ошибки, связанные с недостатком информации или её избытком.

Второе — дизайн workflow. Это выбор, когда модель думает, когда действует, когда запрашивает подтверждение, когда откатывает изменения. Каждое решение влияет на надёжность, скорость и автономность. Хороший workflow делает ошибки восстанавливаемыми, а не фатальными. Например, агент может сначала генерировать план, затем запускать его на небольшом тесте, и только потом применять к основной задаче.

Между этими двумя направлениями есть ещё одно — инструментарий. Harness должен предоставлять модели правильный набор инструментов: поиск, запуск кода, чтение документации, взаимодействие с внешними API. Но инструменты сами по себе не решают проблему. Важно, как они интегрированы в workflow и какую информацию возвращают обратно в контекст. Инструмент без хорошей обратной связи — это чёрный ящик, который увеличивает неопределённость.

Ещё один ключевой элемент — оценка. Без метрики улучшить систему невозможно. Harness должен уметь проверять результаты действий модели и сравнивать их с ожидаемым. Это может быть автоматический тест, верификация человеком или сравнение с базовым решением. Оценка замыкает цикл обучения и позволяет отбирать лучшие конфигурации harness.

Самоулучшающиеся harness и эволюционный поиск

Следующий шаг — сделать harness самоулучшающимся. Это не означает, что модель переписывает саму себя. Harness может улучшать промпты, инструменты, правила оценки или декомпозицию задач на основе обратной связи. Эволюционный поиск программ — один из способов: генерируются варианты обвязки, тестируются на задачах, отбираются лучшие, и цикл повторяется.

Более амбициозная идея — совместная оптимизация harness и весов модели. Если обвязка влияет на то, как модель используется, то её можно учитывать при обучении. Это размывает границу между системой и моделью. Но и здесь Вэнг сохраняет осторожность: это перспективное направление, а не готовая рецептура.

Как harness меняет отрасль

Если взглянуть на текущее состояние AI-индустрии, становится видно, что лидеры не всегда используют самые большие модели. Их преимущество — в том, как они встроены в продукт. Claude Code, Cursor, Codex, Perplexity — все они оборачивают LLM в тщательно спроектированную обвязку, которая ограничивает ошибки, управляет контекстом и предоставляет нужные инструменты. Пользователь видит не «сырую модель», а рабочий интерфейс, который делает сложные возможности доступными.

Для разработчиков это означает, что навык построения harness становится так же важен, как умение работать с API моделей. Нужно понимать, как разбивать задачи, как проектировать обратную связь, как организовывать память и как делегировать подзадачи. Это требует знаний из software engineering, ML-опса и продуктового дизайна одновременно. Чистых ML-исследователей, которые не думают о системе, становится недостаточно.

Для бизнеса harness — это способ дифференцироваться. Модели вскоре могут стать товаром: GPT-4o, Claude, Gemini — всё это API с похожими способностями. Продуктовая ценность будет создаваться тем, как эти модели встраиваются в рабочие процессы клиента. Компания, которая сделает лучший harness под конкретную профессию, победит компанию, которая просто предоставит доступ к модели.

Ограничения и открытые вопросы

Harness engineering — молодая область, и у неё много нерешённых проблем. Как измерять качество harness отдельно от качества модели? Какие паттерны универсальны, а какие специфичны для конкретных задач? Как контролировать безопасность, когда агент может сам себя модифицировать? В статье нет окончательных ответов, но есть чёткая повестка: смотреть на AI-систему как на целое, а не как на языковую модель с приставкой.

Кроме того, harness не отменяет проблемы базовых моделей. Галлюцинации, предубеждения, ограниченный рассуждение — всё это остаётся. Обвязка может смягчить, но не устранить. Важно не переоценивать её роль и не рассматривать как волшебное решение.

Часто задаваемые вопросы

Чем harness отличается от обычного агентного фреймворка?

Агентный фреймворк обычно предоставляет память, инструменты и планирование. Harness добавляет к этому дизайн workflow, оценку результатов, контроль разрешений и управление состоянием между сессиями. Это более зрелая инженерная дисциплина.

Может ли хороший harness заменить сильную модель?

Нет, но он может значительно повысить эффективность средней модели. Harness и модель — комплементарные компоненты. Оптимальная стратегия — развивать оба, а не один в ущерб другому.

Как это применить в продакшене?

Начать с аудита текущего workflow: где теряется контекст, какие ошибки повторяются, какая обратная связь используется. Затем внедрить явные стадии планирования, тестирования и оценки, добавить постоянную память и рассмотреть декомпозицию через субагентов.

Итог

Статья Лилиан Вэнг ставит harness engineering на место ключевого направления в развитии AI. Если recursive self-improvement когда-либо станет реальностью, главным её двигателем, скорее всего, станет не волшебное самопереписывание модели, а системная обвязка, которая учится делать всё остальное лучше. Для инженеров и продуктовых команд это означает одно: пора развивать не только навыки промптинга, но и навыки проектирования агентных систем.

← Все записи