Harness engineering (харнесс-инжиниринг) — настройка среды вокруг ИИ-агента: инструкций, инструментов, прав и проверок. Harness-Driven Development (HDD) — рабочий метод на его основе: каждая ошибка агента становится правилом этой среды.
Три этапа
Промпт
рольформатпример
чинятодин запрос
Контекст
документыпроектпамять
чинятчто модель знает
Харнесс
инструментытестыправилаправа
чинятвсе следующие запуски
Вывод
В этом примереПромпт исправляет один ответ, контекст — знания модели, харнесс — каждый следующий запуск агента.
В общем случаеHarness-Driven Development — работа на третьем этапе: разработчик меньше пишет код и больше настраивает среду, в которой агент его пишет, проверяет и исправляет.
Что сделатьВыпишите три последние ошибки агента и отметьте, на каком этапе каждую можно было исправить раз и навсегда.
Петля HDD
Принцип Митчелла Хашимото: если агент ошибся, харнесс меняют так, чтобы эта ошибка не повторилась Faros
Вывод
В этом примереОшибка, которую поймали датчики, уходит в харнесс новым правилом, и агент получает его на каждом следующем запуске.
В общем случаеИсправленный вручную результат помогает один раз. Правило в харнессе — инструкция, тест или хук — действует для всех будущих задач, поэтому харнесс со временем становится точнее без смены модели.
Что сделатьЗаведите правило: каждую ошибку агента, которую пришлось исправлять руками, в тот же день превращать в строку инструкции или в тест.
Устройство харнесса: 3 × 3
Три домена контура и три контекста в каждом — девять канонов. У каждого канона ровно один домен и один контекст.
Спекачто должно быть верно
Скиллкак действовать
Памятьна что опереться
Ожиданиечто должно быть
Спекажанры, схемыуровни требованийпаспорт числа
Скиллпредсказание до действия
Памятьроли актуатораlive · MCP
Наблюдениечто измерено
Спекаранг доказательстваформат находкишкала
Скиллсенсор записывает факт
Памятьтолько live
Лупсравнить и решить
Спекакритерии полноты правилареестр находок
Скиллсравнитьпосчитать повторпатч или пересмотр
Памятьпока пусто
ОжиданиеНаблюдение
Луп✕ обратной ссылки нет
патчпересмотр правил
→скилл → спека своего домена·направление проверяет скрипт на коммит
snapshotтаблица, обновляется по факту нового измерения
liveпротокол, каждый раз заново, без хранения
Вывод
В этом примереКонтур раскладывается на Ожидание, Наблюдение и Луп, у каждого свои спека, скилл и память. Луп читает два других домена, они Луп не читают.
В общем случаеЭто контур отрицательной обратной связи: заданное значение сравнивается с измеренным, и меняется что-то только при расхождении. Жёсткое направление ссылок не даёт доменам запутаться друг в друге, а повтор одного понятия в двух доменах дефектом не считается.
Что сделатьРазложите файлы своего харнесса по девяти клеткам и проверьте, что ни один файл Ожидания или Наблюдения не ссылается на Луп.
Двойная петля
одинарная петляисправить действие по тем же правилам
двойная петляизменить сами правила
Подгонки без нового предсказаниячинить правилом
Несколько жалобсначала тест на общую причину
Новое правилопринимается, если старые случаи выводятся
Без внешней проверкиотбросить с записью
Луп применяется и к себе: каждый прогон заканчивается остаточным риском, статус «готово» он не ставит.
Вывод
В этом примереСерия подгонок, жалобы, новое правило и внешняя проверка — четыре проверяемых принципа, по которым Луп решает, чинить действие или менять правила.
В общем случаеОдинарная петля исправляет результат в рамках старых правил. Двойная меняет сами правила, и делает это по проверяемым принципам: так харнесс учится, но не расползается от случайных правок.
Что сделатьКогда одна и та же правка повторяется третий раз, остановитесь и спросите, какое правило её вызывает. Меняйте правило, только если оно объясняет и старые случаи.
Направляющие и датчики
Направляющиедо действия
Датчикипосле действия
Вычислимыебыстро · надёжно
типышаблоны кодагенераторы
тестылинтерпроверка типов
Через ИИгибко · дороже
AGENTS.md · CLAUDE.mdскиллыспеки
ИИ-ревьюмодель-судья
Деление по Martin Fowler: Harness engineering
Вывод
В этом примереЧетыре клетки: направляющие задают курс до работы агента, датчики ловят отклонения после, и каждая бывает вычислимой или через ИИ.
В общем случаеВычислимые проверки срабатывают за секунды и не ошибаются, поэтому их ставят везде, где правило можно записать формально. Проверки через ИИ оставляют для смысла: стиль, понятность, соответствие замыслу.
Что сделатьДля каждого правила из инструкции агента спросите, можно ли проверить его тестом или линтером. Если можно — перенесите.
Три слоя проверок
Качество кодазрелый
Архитектурарастёт
Поведениесложнее всего
Зрелость слоёв по Martin Fowler
Вывод
В этом примереКачество кода проверять научились лучше всего, поведение продукта — хуже всего.
В общем случаеЛинтеры и форматтеры закрывают первый слой почти сразу. Архитектуру проверяют правилами зависимостей и требованиями к скорости. Поведение по-прежнему требует хороших тестов на сценарии и взгляда человека.
Что сделатьНачните с первого слоя: подключите линтер и форматтер к каждому запуску агента, затем добавьте одно правило на границы модулей.
Раньше — дешевле
До работыинструкции · спеки$
При записихуки · линтер$$
В CIтесты · сборка$$$
На ревьючеловек$$$$
Вывод
В этом примереОдна и та же ошибка стоит дешевле всего до начала работы агента и дороже всего на ревью человеком.
В общем случаеБыстрые проверки ставят как можно раньше: агент исправляется сам, пока контекст задачи у него перед глазами, и до человека доходят только спорные места.
Что сделатьПодключите тесты и линтер как хук, который агент запускает после каждой правки, а не только в CI.
Где нужен человек
Харнесс
стиль · типы · тесты · границы
Человек
архитектура · продукт · новые правила
«Хороший харнесс оставляет человека в контуре и направляет его внимание туда, где оно важнее всего» — пересказ Martin Fowler
Вывод
В этом примереБольшую часть проверок берёт харнесс, человеку остаются решения и улучшение самого харнесса.
В общем случаеОпытный разработчик держит в голове неявный харнесс: знание архитектуры, привычки команды, чутьё на риск. HDD переносит это знание в явные правила, и его получает каждый запуск агента.
Что сделатьПосле каждого ревью кода агента выпишите одно замечание, которое повторялось, и оформите его правилом.
HDD и спеки
Спекакакой результат нужен
Харнесскак проверить, что он получен
Принятый кодбез ручного контроля каждой строки
«Спеки задают целевое состояние, харнесс — систему контроля» — Loiane Groner. Про спеки — доклад Spec-Driven Development на практике
Вывод
В этом примереСпека отвечает на вопрос «что строим», харнесс — «как убедиться, что построили».
В общем случаеБез спеки харнессу нечего проверять, без харнесса спека остаётся документом. Вместе они позволяют принимать код агента по проверкам, а не по чтению каждой строки.
Что сделатьДля каждого требования из спеки запишите, какой тест или проверка подтвердит его выполнение.
С чего начать
- 1Файл инструкций для агентаAGENTS.md или CLAUDE.md в корне проекта: как собирать, как тестировать, что нельзя
- 2Линтер и тесты после каждой правкихук, который агент запускает сам, до того как отдать результат
- 3Журнал ошибок агентакаждая исправленная вручную ошибка — строка с причиной
- 4Ошибка → правилораз в неделю перенести записи журнала в инструкции, тесты или хуки
- 5Файл прогресса для долгих задачсписок фич со статусом и история коммитов, чтобы новая сессия продолжила с того же места Anthropic
Вывод
В этом примереПять шагов: два настраивают харнесс сразу, три запускают петлю «ошибка → правило».
В общем случаеХарнесс не проектируют целиком заранее. Он растёт из реальных ошибок агента в вашем проекте, и через несколько недель агент перестаёт повторять самые частые из них.
Что сделатьСегодня создайте файл инструкций и журнал ошибок. Через неделю перенесите первые записи журнала в правила.
Дальше по теме
Этап 1–2
Промпты для рабочих задач
как составить один запрос и подать данные
Этап 3
Сравнение харнессов
Claude Code, Codex, Cursor, Hermes и чат
Ещё почитать: Martin Fowler · Anthropic: Harness design · Becoming a Harness-Driven Developer · awesome-harness-engineering