Harness-инженерия: Полное руководство по созданию систем, которые заставляют ИИ-агентов работать по-настоящему
Март 2026 — Если 2025 год был годом, когда ИИ-агенты доказали, что умеют писать код, то 2026 стал годом, когда мы поняли, что самое сложное — это не агент, а его оснастка (harness).
Команда OpenAI Codex только что создала production-приложение объемом более 1 миллиона строк кода, в котором ноль строк было написано руками человека. Инженеры не писали код. Они проектировали систему, которая позволяла ИИ писать код надежно. Эта система — ограничения, петли обратной связи, документация, линтеры и управление жизненным циклом — это то, что индустрия теперь называет harness (оснастка).
Harness-инженерия — это новая дисциплина проектирования таких систем. И она меняет само понимание того, что значит быть инженером-программистом.
Что такое Harness-инженерия?
Метафора с лошадью
Термин "harness" пришел из конской сбруи — вожжи, седло, удила — полный набор снаряжения для управления мощным, но непредсказуемым животным в нужном направлении. Метафора выбрана не случайно:
- Лошадь — это ИИ-модель: мощная, быстрая, но сама по себе не знающая, куда идти.
- Оснастка (harness) — это инфраструктура: ограничения, защитные барьеры, петли обратной связи, которые продуктивно направляют мощь модели.
- Всадник — это инженер-человек: он задает направление, а не бежит сам.
Без оснастки ИИ-агент — это породистый скакун в чистом поле. Быстрый, впечатляющий и совершенно бесполезный для выполнения конкретной работы.
Формальное определение
Harness-инженерия — это проектирование и реализация систем, которые:
- Ограничивают то, что ИИ-агент может делать (архитектурные границы, правила зависимостей).
- Информируют агента о том, что он должен делать (контекстная инженерия, документация).
- Проверяют, правильно ли агент выполнил задачу (тестирование, линтинг, валидация CI).
- Исправляют агента, когда он ошибается (петли обратной связи, механизмы самовосстановления).
Мартин Фаулер описывает это как "инструментарий и практики, которые мы используем для контроля ИИ-агентов", но это больше, чем просто безопасность. Хорошая оснастка делает агентов более способными, а не просто более контролируемыми.
Почему Harness-инженерия важна именно сейчас
Модель — это товар. Оснастка — это конкурентное преимущество.
Вот неудобная правда, с которой сталкивается ИИ-индустрия: базовая модель имеет меньшее значение, чем система вокруг нее.
LangChain доказал это окончательно. Их кодинг-агент поднялся с 52,8% до 66,5% в Terminal Bench 2.0 — перепрыгнув из Топ-30 в Топ-5 — ничего не меняя в модели. Они изменили только оснастку:
| Изменение | Что было сделано | Результат |
|---|---|---|
| Цикл самопроверки | Добавлен middleware с чек-листом перед завершением | Ошибки отлавливались до отправки кода |
| Контекстная инженерия | Картирование структуры каталогов при запуске | Агент понимал кодовую базу с самого начала |
| Детекция циклов | Отслеживание повторяющихся правок файлов | Предотвращение "бесконечных циклов" |
| "Сэндвич" рассуждений | Высокий reasoning для планирования/проверки, средний для реализации | Лучшее качество в рамках временных затрат |
Та же модель. Другая оснастка. Кардинально лучшие результаты.
Доказательство от OpenAI на 1 миллион строк
Эксперимент OpenAI — самое убедительное доказательство на сегодняшний день:
- 5 месяцев разработки.
- 1 млн+ строк кода в финальном продукте.
- Ноль написанных вручную строк — каждая строка была создана агентами Codex.
- Создано примерно в 10 раз быстрее, чем это сделали бы люди.
- Продукт имеет внутренних ежедневных пользователей и внешних альфа-тестеров.
- Он выпускается, развертывается, ломается и чинится — всё силами агентов внутри оснастки.
Работа инженеров? Проектирование оснастки. Спецификация намерений. Предоставление обратной связи. А не написание кода.
Три столпа Harness-инженерии
Фреймворк OpenAI разделяет harness-инженерию на три основные категории:
1. Контекстная инженерия
Контекстная инженерия заключается в обеспечении агента нужной информацией в нужное время.
Статический контекст:
- Локальная документация репозитория (архитектурные спецификации, контракты API, стайлгайды).
- Файлы
AGENTS.mdилиCLAUDE.md, кодирующие правила конкретного проекта. - Перекрестно связанные проектные документы, проверяемые линтерами.
Динамический контекст:
- Данные наблюдаемости (логи, метрики, трассировки), доступные агентам.
- Карта структуры каталогов при запуске агента.
- Статус CI/CD пайплайнов и результаты тестов.
Критическое правило: С точки зрения агента, всего, к чему у него нет доступа в контексте, не существует. Знания в Google Docs, тредах Slack или в головах людей невидимы для системы. Репозиторий должен быть единственным источником истины.
2. Архитектурные ограничения
Здесь harness-инженерия наиболее резко расходится с традиционным промптингом. Вместо того чтобы говорить агенту "пиши хороший код", вы механически принуждаете его к тому, как должен выглядеть хороший код.
Слои зависимостей:
Types → Config → Repo → Service → Runtime → UI
Каждый слой может импортировать данные только из слоев слева от него. Это не предложение — это правило, поддерживаемое структурными тестами и валидацией CI.
Инструменты обеспечения ограничений:
- Детерминированные линтеры — кастомные правила, автоматически помечающие нарушения.
- Аудиторы на базе LLM — агенты, проверяющие код других агентов на соответствие архитектуре.
- Структурные тесты — похожи на ArchUnit, но для кода, сгенерированного ИИ.
- Pre-commit хуки — автоматические проверки перед фиксацией любого кода.
Почему ограничения улучшают результат: Парадоксально, но ограничение пространства решений делает агентов более продуктивными, а не менее. Когда агент может генерировать что угодно, он тратит токены на исследование тупиковых путей. Когда оснастка определяет четкие границы, агент быстрее сходится к правильному решению.
3. Управление энтропией ("Сборка мусора")
Это самый недооцененный компонент. Со временем кодовые базы, созданные ИИ, накапливают энтропию — документация расходится с реальностью, конвенции именования нарушаются, накапливается мертвый код.
Harness-инженерия решает это с помощью периодических агентов-уборщиков:
- Агенты согласованности документации — проверяют соответствие документации текущему коду.
- Сканеры нарушений ограничений — находят код, который проскочил через ранние проверки.
- Агенты соблюдения паттернов — выявляют и исправляют отклонения от установленных шаблонов.
- Аудиторы зависимостей — отслеживают и устраняют циклические или ненужные зависимости.
Эти агенты запускаются по расписанию — ежедневно, еженедельно или по триггеру событий — поддерживая здоровье кодовой базы как для людей-ревьюеров, так и для будущих ИИ-агентов.
Harness-инженерия на практике: как это делают команды
Подход OpenAI: Ноль человеческого кода
Структура команды OpenAI для harness-инженерии:
| Роль | Традиционная разработка | Harness-инженерия |
|---|---|---|
| Написание кода | Основная работа | Никогда |
| Проектирование архитектуры | Часть работы | Основная работа |
| Написание документации | Второстепенно | Критически важная инфраструктура |
| Ревью PR | Код-ревью | Анализ вывода агента + эффективности оснастки |
| Отладка | Чтение кода | Анализ паттернов поведения агента |
| Тестирование | Написание тестов | Проектирование стратегий тестирования для агентов |
Подход Stripe: Миньоны в масштабе
Внутренние кодинг-агенты Stripe, называемые Minions, теперь создают более 1000 мерж-реквестов в неделю:
- Разработчик публикует задачу в Slack.
- Миньон пишет код.
- Миньон проходит CI.
- Миньон открывает PR.
- Человек проверяет и подтверждает слияние.
Никакого взаимодействия с разработчиком между шагами 1 и 5. Оснастка берет на себя всё — выполнение тестов, валидацию CI, соблюдение стиля и обновление документации.
Подход LangChain: Middleware прежде всего
LangChain структурирует свою оснастку как слои компонуемых middleware:
Запрос агента
→ LocalContextMiddleware (картирует кодовую базу)
→ LoopDetectionMiddleware (предотвращает повторения)
→ ReasoningSandwichMiddleware (оптимизирует вычисления)
→ PreCompletionChecklistMiddleware (обеспечивает проверку)
→ Ответ агента
Каждый слой middleware добавляет определенную возможность без изменения основной логики агента. Этот модульный подход делает оснастку тестируемой и развиваемой.
Создание вашей первой оснастки: практический план
Уровень 1: Базовая оснастка (Для одного разработчика)
Если вы используете Claude Code, Cursor или Codex для индивидуальных проектов:
Что настроить:
- Файл
CLAUDE.mdили.cursorrulesс конвенциями проекта. - Pre-commit хуки для линтинга и форматирования.
- Тестовый набор, который агент может запускать для самопроверки.
- Четкая структура каталогов с последовательным именованием.
Время на настройку: 1-2 часа Эффект: Предотвращает самые частые ошибки агентов.
Уровень 2: Командная оснастка (Для небольшой команды)
Для команд из 3-10 разработчиков, работающих над одной кодовой базой:
Добавить к Уровню 1:
AGENTS.mdс общекомандными соглашениями.- Архитектурные ограничения, проверяемые в CI.
- Общие шаблоны промптов для типичных задач.
- Документация как код, валидируемая линтерами.
- Чек-листы код-ревью специально для PR, созданных агентами.
Время на настройку: 1-2 дня Эффект: Единообразное поведение агентов во всей команде.
Уровень 3: Продакшн-оснастка (Для инженерной организации)
Для организаций, запускающих десятки параллельных агентов:
Добавить к Уровню 2:
- Кастомные слои middleware (детекция циклов, оптимизация рассуждений).
- Интеграция с observability (агенты читают логи и метрики).
- Агенты управления энтропией по расписанию.
- Версионирование оснастки и A/B тестирование.
- Дашборды мониторинга производительности агентов.
- Политики эскалации на случай, если агенты застрянут.
Время на настройку: 1-2 недели Эффект: Агенты работают как автономные участники разработки.
Типичные ошибки Harness-инженерии
1. Переусложнение потока управления (Control Flow)
"Если вы переусложните поток управления, следующее обновление модели сломает вашу систему".
Модели совершенствуются быстро. Возможности, требовавшие сложных пайплайнов в 2024 году, теперь решаются одним промптом в окне контекста. Стройте свою оснастку так, чтобы её компоненты были заменяемыми — вы должны иметь возможность удалить "умную" логику, когда модель станет достаточно умной, чтобы не нуждаться в ней.
2. Отношение к оснастке как к статичному объекту
Оснастка должна развиваться вместе с моделью. Когда новая версия модели улучшает логику рассуждений, ваш middleware для оптимизации рассуждений может стать контрпродуктивным. Пересматривайте и обновляйте компоненты оснастки при каждом крупном обновлении моделей.
3. Игнорирование слоя документации
Самое эффективное улучшение оснастки часто оказывается самым простым: улучшение документации. Если ваш AGENTS.md расплывчат, результат работы агента будет таким же. Инвестируйте в точную, машиночитаемую документацию, которая служит для агента единственным источником истины.
4. Отсутствие петли обратной связи
Оснастка без обратной связи — это клетка, а не руководство. Агенту нужно знать, когда он преуспевает, а когда терпит неудачу. Внедрите:
- Шаги самопроверки перед завершением задачи.
- Выполнение тестов как часть рабочего процесса агента.
- Метрики успешности агента по типам задач.
5. Документация "только для людей"
Если ваши архитектурные решения живут в головах людей или на страницах Confluence, к которым у агента нет доступа, в оснастке есть пробел. Всё, что нужно агенту, должно быть в репозитории.
Harness-инженерия в сравнении с другими концепциями
| Концепция | Охват | Фокус |
|---|---|---|
| Prompt Engineering | Одиночное взаимодействие | Создание эффективных запросов |
| Context Engineering | Окно контекста модели | Какую информацию видит модель |
| Harness Engineering | Вся система агента | Среда, ограничения, ОС, жизненный цикл |
| Agent Engineering | Архитектура агента | Внутренний дизайн агента и роутинг |
| Platform Engineering | Инфраструктура | Развертывание, масштабирование, операции |
Harness-инженерия включает в себя контекстную инженерию и черпает идеи из промпт-инженерии, но работает на более высоком уровне — речь идет о целостной системе, которая делает агентов надежными, а не только о входных данных для одного взаимодействия.
Что это значит для разработчиков
Профессия меняется
Harness-инженерия представляет собой реальную эволюцию того, чем занимаются программисты:
| Раньше | Сейчас |
|---|---|
| Писать код | Проектировать среды, где ИИ пишет код |
| Отлаживать код | Отлаживать поведение агентов |
| Ревьюить код | Ревьюить результат агента + эффективность оснастки |
| Писать тесты | Проектировать стратегии тестирования |
| Вести документацию | Строить документацию как машиночитаемую инфраструктуру |
Это не значит, что инженеры становятся менее техническими специалистами. Напротив, harness-инженерия требует более глубокого архитектурного мышления — вы проектируете системы, которые должны работать без вашего постоянного вмешательства.
Навыки, которые имеют значение
Основываясь на нашем опыте создания продуктов с поддержкой ИИ в NxCode:
- Системное мышление — понимание того, как взаимодействуют ограничения, петли обратной связи и документация.
- Проектирование архитектуры — определение границ, которые являются контролируемыми и продуктивными.
- Написание спецификаций — формулирование намерений достаточно точно для выполнения агентами.
- Наблюдаемость (Observability) — создание мониторинга, выявляющего паттерны поведения агентов.
- Скорость итераций — быстрое тестирование и доработка конфигураций оснастки.
Наш опыт: что работает на практике
Мы создаем веб-приложения на базе ИИ, используя несколько агентских систем (Claude Code, Codex, Cursor). Паттерны, которые принесли нам наибольшую пользу:
- Документация "репозиторий прежде всего": Каждое архитектурное решение, конвенция именования и процесс развертывания находятся в репозитории. Ничего не живет в Slack или Google Docs.
- Инкрементальное наращивание ограничений: Начните с базового линтинга, добавляйте архитектурные ограничения по мере появления паттернов, не пытайтесь сразу спроектировать идеальную оснастку.
- Чек-листы ревью для агентов: У кода, созданного ИИ, другие типы ошибок, чем у человеческого кода. Наш процесс ревью учитывает общие паттерны агентов (избыточная абстракция, ненужная обработка ошибок, расхождение с документацией).
- Мультипровайдерный дизайн оснастки: Наша оснастка работает с моделями Claude, GPT и Gemini. Независимый от провайдера дизайн означает, что мы можем менять модели без перестройки всей системы.
Основные выводы
- Harness-инженерия — это новая дисциплина проектирования систем, делающих ИИ-агентов надежными: ограничения, петли обратной связи, документация и управление жизненным циклом.
- Модель — это товар; оснастка — это преимущество. LangChain поднялся в бенчмарках с Топ-30 до Топ-5, изменив только оснастку.
- OpenAI создала 1 млн+ строк без человеческого кода, доказав, что harness-инженерия работает в масштабах продакшена.
- Три столпа: Контекстная инженерия, архитектурные ограничения и управление энтропией.
- Начинайте с простого: Хороший
AGENTS.mdи pre-commit хуки дают больше эффекта, чем сложные middleware. - Роль инженера эволюционирует — от написания кода к проектированию сред, в которых ИИ пишет код.
- Стройте модульные оснастки — избыточное усложнение мешает при улучшении моделей; сохраняйте адаптивность.
Связанные ресурсы
- Объяснение агентного веба: AGENTS.md, MCP против A2A — Протокольный слой, на котором строится harness-инженерия.
- Облачные агенты Cursor: автономное кодирование на виртуальных машинах — Облачные оснастки агентов на практике.
- Дистанционное управление Claude Code: руководство по передаче терминала — Удаленное управление сессиями агентов.
- Создайте свой сайт с NxCode — Веб-разработка на базе ИИ с мультипровайдерной архитектурой оснастки.
