Что такое харнесс и Harness Engineering? Проектирование слоя вокруг LLM в эпоху ИИ-агентов

Harness engineering — термин, который быстро распространился в феврале 2026 года. 5 февраля 2026 года Митчелл Хашимото (автор терминала Ghostty и сооснователь HashiCorp) назвал так привычку: каждый раз, когда агент ошибается, вы строите решение, чтобы он больше никогда не повторил эту ошибку. Через шесть дней OpenAI вынесла термин в заголовок отчёта своей команды Codex. Anthropic ещё раньше публиковала устройство механизмов вокруг долго работающих агентов под названием «harness». Если в 2025 году говорили, что после промптов идёт context engineering, то harness engineering занимается слоем ещё дальше снаружи.

В этой статье мы разбираем, что такое харнесс (harness) и что на самом деле такое harness engineering, чем он отличается от prompt engineering и context engineering, какие шесть компонентов составляют упряжь, какие реальные упряжи опубликовали OpenAI и Anthropic, даём практический чек-лист проектирования и сравнение ведущих инструментов — фундамент, который нужен, если вы всерьёз используете или строите ИИ-агентов.

1. Что такое harness engineering?

«Harness» (по-русски его часто так и называют — харнесс, а дословно это «упряжь») изначально означает сбрую и снаряжение для лошади — оснастку, направляющую силу животного туда, куда нужно вам. Термин в ИИ работает ровно как метафора того же рода: полный набор «снаряжения», который заставляет мощную, но неуправляемую LLM приносить пользу.

Конкретно сюда входит:

• Инструменты: операции с файлами, веб-поиск, выполнение кода — средства, которыми LLM может действовать.
• Управление контекстом: стратегия того, что попадает в промпт, а что сжимается или отбрасывается.
• Системы памяти: устойчивые знания и пользовательские предпочтения, переживающие сессии.
• Agent loop: цикл «воспринять → рассудить → действовать → наблюдать».
• Guardrails: права, sandbox, Hooks, потоки подтверждений.
• Формат вывода: markdown, JSON, цитаты, стриминг.

Совместное проектирование всего этого мы и называем harness engineering. Вместо обучения или улучшения самой LLM это ремесло повышения практической полезности через инженерию всего, что окружает LLM. Claude Code, Cursor, Devin, Codex CLI — все они работают примерно на одних и тех же моделях, и тем не менее их поведение и производительность резко расходятся именно из-за разницы в упряжах.

Где начинается и где заканчивается слово «упряжь», хорошо сформулировала Биргитта Бёклер из Thoughtworks на martinfowler.com (2 апреля 2026 года): упряжь — это всё в агенте, кроме модели, то есть Agent = Model + Harness. Anthropic использует то же слово для собственного облачного сервиса: Claude Managed Agents описан как настраиваемая упряжь для агентов.

2. Harness engineering против prompt engineering

Prompt engineering никуда не делся — но область применения принципиально иная.

Если prompt engineering — это ремесло того, «что сказать LLM», то harness engineering — это ремесло того, «что дать LLM и как ею оперировать». Они не конкурируют — они наслаиваются. Промпт — лишь один компонент внутри упряжи.

Второй термин, который часто путают, — context engineering. В публикации от 29 сентября 2025 года Anthropic назвала его естественным продолжением prompt engineering. Бёклер описывает построение упряжи для агента-программиста как частную форму context engineering. Вместе они вкладываются друг в друга: промпт (что вы говорите) ⊂ контекст (что видит модель) ⊂ упряжь (что ей дают, как проверяют её работу и как её останавливают). Особенность упряжи — часть, которая механически проверяет результаты и возвращает ошибки агенту, например линтеры и тесты.

3. Шесть компонентов «упряжи»

1. Tool Use

Средства, которыми LLM действует на мир: чтение и запись файлов, выполнение кода, поиск в вебе, вызовы API. Ошибитесь в интерфейсе инструмента — именах, аргументах, возвращаемых значениях — и LLM не сможет им корректно пользоваться. Конкретно:

• Однозначные имена-глаголы (например, read_file).
• Явное разделение обязательных и необязательных аргументов, со значениями по умолчанию.
• Структурированные сообщения об ошибках при сбое (говорите модели, что делать дальше).
• Явные предупреждения об операциях с побочными (разрушительными) эффектами.

2. Управление контекстом

Внимание LLM конечно — то, что вы ей показываете, определяет то, что она говорит. Конкретно:

• Фильтрация по релевантности: подтягивайте только части, относящиеся к задаче, а не файлы целиком.
• Сжатие: суммируйте длинные диалоги, чтобы их сохранить.
• Интеграция RAG: подтягивайте нужное через векторный поиск.
• Кеширование: режьте стоимость повторных системных промптов с помощью таких средств, как prompt cache от Anthropic.

Связанное: Что такое RAG?

3. Система памяти

Удержание знаний между сессиями. CLAUDE.md у Claude Code, .cursor/rules у Cursor и AGENTS.md у Codex — всё это примеры проектной памяти. Помимо этого:

• Краткосрочная память: недавняя история диалога.
• Долгосрочная память: профиль пользователя, прошлые решения.
• Фактические знания: доменные базы знаний.

4. Agent Loop

Ядро, благодаря которому «ИИ-агент» вообще работает. Базовая форма — цикл «воспринять → рассудить → действовать → наблюдать»:

1. Принять цель пользователя.
2. Проанализировать текущее состояние (при необходимости собрать информацию инструментами).
3. Спланировать следующее действие.
4. Действовать через инструмент.
5. Наблюдать результат; проверить, достигнута ли цель.
6. Если нет — повторить, если да — завершить.

Насколько умным окажется ваш агент, зависит от того, заложите ли вы перепланирование, самокритику и декомпозицию подцелей.

5. Guardrails

Механизмы, не дающие поведению пойти вразнос. Как разбирается в статье Почему ИИ игнорирует ваши .md-правила, форсировать поведение через окружение значительно надёжнее, чем вежливо просить в прозе:

• Режим подтверждений: человек подтверждает опасные операции до их запуска (например, настройки разрешений в Claude Code, режимы подтверждения в Codex CLI).
• Sandbox: ограничьте доступ к файловой системе и сети.
• Hooks: произвольные проверки до и после вызовов инструментов.
• Rate limiting: минимизируйте ущерб, если что-то пойдёт не так.

6. Output UX

Подача результатов в форме, которую пользователь способен понять и проверить. Рендеринг markdown, цитирование источников, блоки кода с подсветкой синтаксиса, потоковый вывод, видимые рассуждения (thinking), структурированный вывод (JSON) и так далее. Получить «правильный ответ» недостаточно — задача упряжи в том, чтобы доставить его в форме, которой пользователь может доверять и которую может проверить.

4. Почему harness engineering и почему именно сейчас?

Всплеск интереса к работе над упряжью двигают три силы.

1. Показано, что одна и та же модель даёт очень разные результаты в зависимости от окружения. В эксперименте, который Anthropic опубликовала 24 марта 2026 года, одной и той же модели Claude Opus одной фразой поручили сделать редактор ретро-игр в 2D. Одиночный агент справился за 20 минут и 9 $, но созданный уровень нельзя было пройти. Упряжь из планировщика, генератора и оценщика работала 6 часов и стоила 200 $ — и выдала игру, где персонажем действительно можно было управлять (физика оставалась грубой). Стоимость выросла более чем в 20 раз, но и разница в качестве оказалась огромной. Выбор между качеством и стоимостью теперь в той же мере зависит от упряжи, что и от модели.

2. Накапливаются проблемы, которые промптами в одиночку не решить. «Слишком много инструментов, модель выбирает не тот». «Контекст набит так, что важный сигнал зарыт». «На длинных задачах агент теряет нить на полпути». Это не проблемы, которые чинятся более удачной формулировкой в одной реплике — это проблемы дизайна.

3. Меняется сама работа инженера. Команда Codex в OpenAI рассказала, что пять месяцев строила внутренний продукт без единой строки кода, написанной вручную, и дошла примерно до миллиона строк и около 1 500 pull request (11 февраля 2026 года). Вывод команды: главная работа сместилась от написания кода к проектированию среды, формулированию намерения и построению циклов обратной связи. Claude Code, Codex, Cursor, Devin и другие крупные продукты соревнуются в том, как устроено всё вокруг модели.

5. Опубликованные примеры: три реальные упряжи

Harness engineering легко уходит в абстракции. Вот три примера, авторы которых опубликовали подробности, — описанные на уровне того, что они действительно сделали.

1. Команда Codex в OpenAI: AGENTS.md как карта, правила через линтеры

• AGENTS.md ограничили оглавлением примерно на 100 строк, а источником истины для дизайна, планов и заметок о качестве сделали каталог docs/ в репозитории. Один гигантский файл вытеснял задачу из контекста, быстро устаревал и не поддавался механической проверке.
• Чтобы документация не устаревала, линтеры и CI проверяют перекрёстные ссылки и структуру, а регулярный агент ищет описания, расходящиеся с кодом, и открывает PR с исправлениями.
• Слои, направление зависимостей, структурированные логи, предельный размер файлов и многое другое обеспечиваются собственными линтерами и структурными тестами. Сообщения об ошибках прямо говорят, как исправить проблему, чтобы агент прочитал их и сам поправил свою работу.

2. Anthropic: передача работы между сессиями долго работающих агентов

Когда разработка растягивается на много контекстных окон, агенты пытались сделать слишком много сразу или объявляли работу законченной на полпути. Anthropic (26 ноября 2025 года) решила это так:

• Только первая сессия запускает агента-инициализатора со своим промптом. Он готовит список функций (feature_list.json), журнал прогресса (claude-progress.txt), init.sh для запуска dev-сервера и первый git-коммит.
• Каждая следующая сессия читает журнал прогресса и git log, чтобы сориентироваться, реализует только одну функцию и заканчивается коммитом и обновлением журнала.
• Список функций хранится в JSON, а не в Markdown: модель реже переписывала его без спроса. Менять разрешено только поле «пройдено/не пройдено» (passes).
• Функция отмечается готовой только после того, как её проверили от начала до конца через автоматизацию браузера, так, как это сделал бы пользователь.

3. Митчелл Хашимото: одна и та же ошибка не должна повториться

Автор термина работает в меньшем масштабе. Если агент допускает простую ошибку, он добавляет строку в AGENTS.md; в проекте его терминала Ghostty каждая строка этого файла соответствует прошлому неудачному поведению, и это почти полностью их устранило. Когда текста недостаточно, он пишет настоящие скрипты — для скриншотов, для запуска отфильтрованных тестов — и даёт их агенту.

Общее у всех трёх: упор сделан на механизмы, которые проверяют и возвращают работу, а не на письменные просьбы. Чек-лист ниже помогает решить, сколько стоит превращать в механизм.

6. Практический чек-лист проектирования упряжи

7. Сравнение основных «упряжей»

Каждая из этих упряжей работает на примерно одних и тех же LLM (Claude / GPT / Gemini), и тем не менее их сильные стороны резко расходятся из-за различий в философии дизайна упряжи. «Какая упряжь?» важнее, чем «какая LLM?» — вот настоящее поле битвы эпохи агентов.

8. Антипаттерны

1. Слишком много инструментов

Чем больше инструментов, тем легче LLM выбрать не тот. В документации Anthropic сказано, что точность выбора инструментов у Claude падает, когда их доступно больше 30–50, и предлагается поиск инструментов, чтобы подгружать только нужные по мере необходимости. Руководство компании по написанию инструментов тоже напоминает, что больше инструментов не значит лучше: вместо того чтобы оборачивать каждый эндпоинт API, объединяйте похожие функции.

2. Запихивать всё подряд в контекст

«Покажу всё на всякий случай» контрпродуктивно. Прогоняйте всё через фильтр релевантности и включайте только необходимое. Контекст — это устройство для выявления важного сигнала, а не складское помещение.

3. Реализовывать безопасность одними промптами

«Пожалуйста, не выполняй опасных операций» рано или поздно проигнорируется — в зависимости от ситуации. Правильный ответ — сделать это физически невозможным на уровне окружения: sandbox, Hooks, ограничения прав.

4. Никогда не пересматривать добавленное

Каждая добавленная деталь делает упряжь тяжелее, медленнее и дороже. После эксперимента, описанного выше, Anthropic убирала компоненты по одному и сравнивала результаты, оставив только то, что по-прежнему помогало (планировщик и оценщик). Её мысль: каждый компонент упряжи отражает предположение о том, чего модель не умеет сама, а такие предположения быстро устаревают по мере улучшения моделей. Сменив модель, проверьте по одному, приносят ли пользу все добавленные проверки и разбиения.

Итог

Harness engineering — это ремесло проектирования слоя «снаружи» LLM. Prompt engineering — лишь один компонент внутри упряжи. Осознанная работа над шестью элементами — определением инструментов, управлением контекстом, памятью, циклом, guardrails, output UX — может преобразить реальную производительность одной и той же базовой LLM.

На 2026 год основное поле битвы для продакшен-ИИ-агентов однозначно сместилось в упряжь. Создание «умных упряжей» — а не просто написание «умных промптов» — станет тем, что отличит инженеров следующего поколения.

FAQ

Q1. Значит, prompt engineering больше не нужен?

Неверно. Он по-прежнему критичен — как один компонент внутри упряжи. Описания инструментов, системные промпты, сообщения об ошибках — всё это поверхности дизайна промптов. Устарел сам подход «починю это лучшим промптом».

Q2. С чего начать изучение harness engineering?

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

1. Записывайте каждую ошибку агента (при какой инструкции и что пошло не так).
2. Для простых ошибок добавьте строку в CLAUDE.md / AGENTS.md / .cursor/rules.
3. Повторяющиеся или опасные ошибки останавливайте механически с помощью Hooks, линтеров или тестов — и пишите способ исправления прямо в сообщении об ошибке.
4. Дайте агенту ту же задачу ещё раз и убедитесь, что ошибка исчезла.

Q3. Упряжь — это то же, что фреймворки вроде LangChain?

Близко, но не одно и то же. Фреймворк — это набор инструментов реализации; упряжь — это инженерная дисциплина и образ мышления. LangChain, LlamaIndex, Claude Agent SDK и им подобное — это инструменты для построения упряжей.

Q4. Строить свою упряжь или использовать готовую?

В большинстве случаев готовая упряжь (Claude Code, Cursor и т.п.) плюс кастомизация достаточна. Строить с нуля имеет смысл только под корпоративные требования, нишевые домены или экстремальную оптимизацию стоимости.

Q5. Станет ли «harness engineer» реальной должностью?

Устоявшегося названия должности пока нет. Сам Хашимото писал, что не знает, существует ли общепринятый в отрасли термин. Но команда Codex в OpenAI сообщает, что главная работа инженера сместилась к проектированию среды, формулированию намерения и построению циклов обратной связи: содержание работы меняется раньше, чем закрепляется название.