Harness vs context engineering: чем харнес-инжиниринг отличается от промпт- и контекст-инжиниринга

Коротко: три уровня одной задачи

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

Путаница возникает потому, что все три меняют поведение модели. Но рычаги у них разные. Если агент не умеет запустить тесты, никакая формулировка промпта этого не исправит. Если агент забывает вчерашние решения, проблема не в словах запроса, а в том, где хранится состояние. Понимание разницы harness vs context engineering экономит недели: вы перестаёте переписывать инструкции там, где сломано окружение.

Промпт-инжиниринг: формулировка одного запроса

Промпт-инжиниринг — это работа с текстом запроса: роль, задача, формат ответа, примеры (few-shot), ограничения, порядок шагов. Единица работы — один вызов модели. Результат оценивают по ответу: правильный ли он, в нужном ли формате, не ушла ли модель в сторону.

Типичные приёмы:

• явно описать формат вывода (JSON-схема, таблица, список);
• дать 2–3 примера «вход → правильный выход»;
• попросить рассуждать по шагам перед ответом;
• разделить инструкцию и данные понятными разделителями;
• перечислить, чего делать нельзя.

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

Контекст-инжиниринг: что попадает в окно модели

Контекст-инжиниринг — это управление содержимым контекстного окна на каждом шаге. Окно ограничено, а агент за длинную сессию накапливает вывод команд, содержимое файлов, историю диалога. Задача — чтобы в каждый момент там было нужное и не было лишнего.

Сюда относятся:

• отбор: какие файлы, документы и фрагменты кода подгрузить под задачу (поиск, RAG, чтение по требованию);
• сжатие: суммаризация длинной истории, обрезка вывода команд, компактизация сессии;
• структура: входной файл инструкций как оглавление, а детали — в отдельных документах, которые агент открывает, когда они нужны;
• изоляция: вынос подзадачи в сабагента с собственным чистым контекстом, чтобы основной поток не засорялся.

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

Харнес-инжиниринг: всё, что вокруг модели

Харнес (harness, «упряжь») — это окружение, в котором работает агент. Модель в нём — один компонент, который входит в контур один раз. Всё остальное — инструкции, инструменты, среда, состояние и обратная связь — проектирует инженер. Харнес-инжиниринг отвечает за то, чтобы агент мог не только написать код, но и запустить его, проверить, узнать об ошибке и продолжить работу в следующей сессии с того же места.

Удобно раскладывать харнес на пять подсистем:

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

Таблица сравнения

Почему одного промпта и контекста не хватает

Классическая история: команда видит, что агент ошибается, и неделю пишет AGENTS.md на пять страниц. Агент по-прежнему не запускает линтер перед коммитом. Причина не в тексте: у агента просто нет доступа к shell с нужными правами, а линтер не установлен в образе. Это проблема инструментов и среды, а лечили её инструкциями.

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

Третья история — самая дорогая: агент пишет «готово», юнит-тесты зелёные, а фича не работает. Ни промпт «проверь внимательно», ни лишние документы в контексте не дадут агенту независимую проверку. Её даёт только обратная связь от машины: сквозной тест, скрипт верификации, отдельный оценщик без доступа к рассуждениям исполнителя.

Общий вывод: промпт и контекст влияют на то, что модель думает. Харнес влияет на то, что модель может сделать и о чём узнаёт после действия.

Почему не помогает замена модели

Частая реакция на нестабильного агента — взять модель помощнее. Обычно это не лечит: одна и та же модель в хорошо устроенном репозитории работает как уверенный senior, а в репозитории без команд проверки и без описания стека путается. Более сильная модель не угадает конвенции вашей команды, не получит доступ к базе, которого нет, и не узнает о сломанной миграции, если её никто не прогонял.

При этом харнес не устаревает с выходом новых моделей. Инструкции, воспроизводимая среда и проверки нужны любой модели. Меняется только то, сколько ручного микроменеджмента можно убрать: сильной модели достаточно инвариантов («данные валидируются на границе домена»), а не пошаговых указаний.

Как понять, какой уровень чинить

Диагностика по симптомам быстрее любых экспериментов:

С чего начинать харнес

Если строить с нуля, практичный порядок такой: обратная связь → инструкции → состояние → среда → инструменты. Обратная связь первой, потому что без неё нельзя измерить эффект остальных изменений. Пока нет команды, которая честно отвечает «работает или нет», любые улучшения инструкций оцениваются на глаз.

Минимальный старт выглядит так:

# AGENTS.md (фрагмент)
## Как проверить
- make check   # линт, типы, юнит-тесты
- make e2e     # сквозные сценарии
Фича готова, только если обе команды завершились с кодом 0.

## Правила
- MUST: все SQL-запросы параметризованы
- MUST: перед коммитом запускать make check
- Подробности по платежам: docs/payments.md (читать, когда задача касается оплаты)

Обратите внимание на последнюю строку: это и есть контекст-инжиниринг внутри харнеса. Входной файл — карта, а не учебник; детали подгружаются по условию «когда».

Как измерить вклад каждой части

У харнеса есть метрика, которой нет у промпта: доля задач, которые агент объявил готовыми, но независимая проверка не подтвердила. Её называют verification gap. Возьмите 10 задач подряд, после каждой отметьте, заявил ли агент «готово» и прошла ли проверка, — получите число, с которым можно сравнивать изменения.

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

Типичные ошибки

• Считать харнесом файл с промптом. Инструкции — одна подсистема из пяти. Полка с рецептами ещё не кухня.
• Лечить отсутствие инструментов текстом. «Всегда запускай тесты» бесполезно, если тесты не запускаются в окружении агента.
• Раздувать инструкции. Чем длиннее входной файл, тем выше шанс, что важное правило не будет прочитано. Важные правила лучше превращать в исполняемые проверки.
• Верить самоотчёту агента. Модель, оценивающая свою же работу, склонна её завышать. Проверять должен скрипт или отдельный агент с чистым контекстом.
• Настроить харнес один раз. Он устаревает, как код: правила расходятся с реальностью, команды меняются. Его нужно ревизовать регулярно.

Итог

Промпт-инжиниринг улучшает формулировку, контекст-инжиниринг — отбор сведений в окне модели, харнес-инжиниринг — всё окружение агента, включая инструменты, среду, состояние и проверки. Когда агент работает долго и сам меняет код, главным становится харнес: он превращает «агент сказал готово» в «система проверила, что работает». Выбор в споре harness vs context engineering поэтому не «или–или»: контекст — часть харнеса, и чинить нужно ту подсистему, на которую указывают симптомы. Эта тема разобрана на практике в курсе по харнес-инжинирингу на сквозном проекте платёжного бэкенда.