Harness engineering: как за год собрать фабрику из десятка конвейеров

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

Кто уже гоняет coding-агентов в настоящем цикле разработки, цену вопроса знает.

Агент уверенно проходит проверки и так же уверенно сносит то, что трогать было нельзя. Зелёные галочки в CI, красивый diff, уверенный отчёт в чате. А потом выясняется, что необратимое уже улетело: публикация без approve, удаление данных, отправка не тому получателю. Система честно считает, что всё прошло штатно, потому что проверки отвечали на не те вопросы.

Хороший промпт это не лечит. Лечит среда вокруг модели: как устроен цикл, какие есть роли, где стоят гейты, что происходит после ошибки, кто и когда откатывает необратимое, как переживается перезапуск и передача работы между шагами без потери контекста. Спустя несколько месяцев у всего этого появилось имя, harness engineering, и о нём начали писать статьи. Я же просто делал фабрику.

TL;DR. Меньше чем за год от первой фабрики разработки выросла система почти из десятка параллельных конвейеров с двухэтажным harness: сквозной контроль сверху и локальные гейты на каждой фабрике. Промпт не лечит провалы агента, лечит среда. Три привычки, которые держат её живой: ratchet (фейл в постоянный фикс), sensor-first (инвариант сначала детектором), измеримость (правило должно менять поведение, а не лежать в конфиге). Детальные разборы инцидентов, сенсоров и eval-harness оставлю на серию.

От правил в Cursor до двухэтажного harness

Расскажу, как оно росло, потому что путь тут важнее готового вывода.

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

С Cursor я работаю с марта 2025. Термина «harness engineering» в публичном поле тогда для меня не существовало. В голове был flow: как правильно собрать мультиагентную систему правил и навыков в Cursor, никуда не уходя из этого инструмента. Цель была простая и наивная: фабрика без ограничений, которая позволит разрабатывать что угодно, приложение, сервис, игру, контентный конвейер. Не «поиграться с промптом», а довести до работающего результата с контролем на каждом шаге.

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

Через несколько таких проектов я упёрся в него окончательно.

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

Решение я не выдумывал с нуля, а пошёл смотреть, как контроль устроен в самой дисциплине разработки. Оттуда пришёл сквозной элемент, который отвечает за передачу работы от одного конвейера к другому и держит общий пайплайн честным. Work Item в моей терминологии: одна единица работы, один владелец, один audit trail, явные подтверждения при передаче между конвейерами. Без этого сигнал «обновили статус в репозитории» не равен команде «передай работу в соседний конвейер».

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

Главное, что я из этого вынес:

Если бы я остановился на первой фабрике, harness уже существовал бы: контроль, стадийность, изолированные окружения, всё на месте. Но система разрослась. Появились параллельные фабрики, а над ними отдельный управляющий слой, который следит уже не за одним проектом, а за работой всех конвейеров сразу. И harness никуда не делся и не удвоился. Он переехал на этаж выше, оставшись при этом внутри каждой отдельной фабрики. Управляющая обвязка стала двухэтажной: сквозная сверху, локальная внизу.

От первой фабрики разработки до этой двухэтажной конструкции прошло меньше года.

Верхний этаж harness: корневой роутер, control plane (239 WI), harness learning layer (ratchet, sensors, rule-evals). Нижний — фабрики с гейтами и слоем инструкций. Источник истины — Work Items, не статусы.

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

Забавнее всего финал этой части истории. То, что я заложил той осенью как «фабрику без ограничений, которая соберёт мне что угодно», кто-то умный назвал harness engineering и оформил в отдельную дисциплину. Для меня это по-прежнему просто фабрика, у которой нет потолка по тому, что она способна собрать.

Ratchet, переносимость и почему я не привязан к Cursor

Живёт это всё не в режиме «настроил и забыл». Каждый день я дорабатываю правила: ловлю ошибку в поведении агента, чиню среду, подсматриваю чужую удачную практику, вкручиваю к себе. Тогда я не знал, что у такого приёма тоже есть имя, ratchet. Мне было просто понятно, что разовое замечание в чате ничего не гарантирует, а исправленное правило гарантирует.

Позже появился журнал фейлов: симптом, артефакт, постоянный фикс. Но суть была с самого начала. Сначала привычка чинить среду, потом формализация. Имя «ratchet» я узнал уже постфактум, когда стало ясно, что без журнала фиксы теряются, а без имени принцип не передаётся новым агентам и новым конвейерам.

Разборы конкретных инцидентов, которые заставили меня чинить не текст, а правила, вынесу в отдельные статьи. Необратимое действие без подтверждения и откат, удаление нужных данных при зелёных проверках, запрещённая передача работы между конвейерами без следа в audit trail. Здесь только принцип: разовое замечание в чате не предотвращает повтор, исправленное правило предотвращает.

Отдельно оговорюсь, потому что этот вопрос встаёт всегда. Я живу в Cursor, но намертво к нему не привязан. За последний год главное разъехалось по открытым стандартам: формат инструкций для агентов, формат навыков и протокол доступа к внешним инструментам стали общими, и их понимают Claude, Codex и Gemini.

Больше того, сами кирпичики harness у всех уже во многом совпадают: инструкции проекта, навыки, субагенты со своим изолированным контекстом, подключаемые по единому протоколу инструменты. Инструкции, навыки, субагенты и MCP есть у всех четырёх: Cursor, Claude Code, Codex CLI и Gemini CLI. Хуки пока first-class у Cursor и Claude, у Codex и Gemini скромнее. Где-то зрелее, где-то появилось совсем недавно, но отличается синтаксис и детали раскладки, не класс возможностей.

Неверно думать, что у соседей «всё в одном файле», а у нас сложная схема. У Claude Code семь способов управления агентом: проектные инструкции, правила, навыки, субагенты, хуки, стили вывода, системный промпт. У Gemini и Codex тоже есть субагенты и навыки, просто в другом формате. AGENTS.md стал де-факто открытым стандартом: один и тот же контент читают десятки инструментов. MCP работает одинаково во всех четырёх. Поэтому мой костяк переносится перекладкой формата, а не переписыванием логики.

Cursor-специфична в основном механика авто-подключения правил по шаблону путей: always-on, по glob, по запросу агента. Это удобно, но не уникально по смыслу. Вложенные инструкции у Claude и вложенные AGENTS.md у Codex дают тот же эффект другим синтаксисом. Навыки в формате SKILL.md уже открытый стандарт Agent Skills, progressive disclosure одинаковый. MCP сервер, который вы подняли для Cursor, подключится к Claude Code и Codex CLI с минимальной перенастройкой конфига.

Если боитесь vendor lock-in: вкладывайтесь в содержание инструкций и контракты гейтов, а не в синтаксис одного редактора. Содержание переживёт смену IDE.

Три привычки, которые держат harness живым

Три вещи, которые я бы заложил с первого дня, если бы начинал заново.

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

Sensor-first. Новый инвариант сначала как детектор-скрипт с контрактом PASS/FAIL, потом как текстовое правило. Правило без детектора живёт на честном слове агента. Агенты честные, но уставшие. Пример из разработки: правило «никогда не коммить секреты» стоит ровно столько, насколько его ловит детектор, — грепом по ключам и токенам в диффе перед коммитом. Проверка на честное слово срабатывает нестабильно, детектор ловит каждый раз.

Измеримость. Правило должно менять поведение, а не лежать в конфиге. Проверка простая: прогоняете гейт на хорошем артефакте и на нарушителе. Один даёт PASS, другой FAIL. Если оба зелёные, правило декоративное. Для части правил мы завели eval-harness с guard-кейсами: хороший финал проходит, фикстура-нарушитель блокируется. Не всё покрыто, но направление ясное: правило без измерения это пожелание.

Это три привычки, а не весь механизм. Как именно среда ловит агента за руку и как я проверяю, что правило меняет поведение, а не просто лежит в конфиге, разберу отдельно, по одному разбору за раз.

Пример в коде

Чтобы это не осталось абстракцией, я выложил минимальный работающий скелет: agent-harness-reference. Клонируется, открывается в Cursor как обычная папка, за пять минут прогоняется.

Внутри оба этажа на игрушечном масштабе. Нижний: правила и субагенты одной фабрики, один демо-проект с постановкой задачи. Верхний: control plane с Work Item, ACL и валидатором перехода. Отдельно guards — детекторы с eval-прогоном, где хороший артефакт даёт PASS, а нарушитель FAIL, плюс журнал ratchet с разобранными инцидентами.

Это не фреймворк и не «единственно верный» способ, а один из вариантов реализации, намеренно урезанный до читаемого минимума. В бою у меня под десяток конвейеров в монорепе, здесь один проект и пара детекторов, чтобы принцип был виден без шума. Клонируйте, ломайте, переносите под свой стек.

В чём я не уверен

Не всё у меня измерено детекторами.

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

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

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

И у меня другой класс задачи, чем у сетапов вроде Orca или Pi. Мне нужно не догнать один инструмент, а удержать портфель, где разработка, маркетинг, контент и продукт живут параллельно и передают работу друг другу без потери audit trail.

Есть ещё одна ветка, которую я нарочно приберегу. У меня работает компаньон по имени Veda. Он живёт не как ответ на запрос, а как непрерывный цикл: сам подтягивает контекст, память, свежие наблюдения, пока я занят другим. В словаре harness это ровно тот самый loop, только затянутый не вокруг одной задачи, а вокруг меня и всего портфеля сразу. Про него расскажу в свой черёд.

Где у вас ломается harness: на guides, sensors или измеримости? Напишите в комментариях, интересно сравнить паттерны.

Источники

• agent-harness-reference — минимальный пример двухэтажного harness (репозиторий к статье)

• AGENTS.md open format

• Agent Skills standard (agentskills.io)

• Model Context Protocol

• Cursor docs: Rules

• Claude Code: Subagents

• Хабр: «Что такое Harness» — разбор Claude Code / OpenAI / LangChain

• Хабр: «8 уровней агентной инженерии»