Harness Engineering: Слой исполнения, который действительно нужен агентам ИИ

Митчелл Хашимото является основателем компании HashiCorp и одним из создателей Terraform. В феврале 2026 года он опубликовал в своем блоге сообщение, в котором описал привычку, выработанную им при работе с агентами ИИ: каждый раз, когда агент совершал ошибку, он встраивал в его окружение постоянное исправление. Он назвал это "инженерией ремней". Через несколько недель OpenAI и Anthropic опубликовали инженерные статьи, развивающие эту идею. Появился термин Harness Engineering.

Он вызвал резонанс, потому что называл проблему, с которой уже сталкивался каждый инженер, создающий агентов ИИ. Оперативная инженерия позволяет получить лучшие результаты за один оборот. Контекстная инженерия управляет тем, что видит модель. Но ни один из них не решает проблему, которая возникает, когда агент работает автономно в течение нескольких часов, принимая сотни решений без присмотра. Именно этот пробел заполняет Harness Engineering - и его работа почти всегда зависит от гибридного поиска (гибридного полнотекстового и семантического поиска).

Что такое Harness Engineering?

Harness Engineering - это дисциплина, связанная с разработкой среды выполнения для автономного агента ИИ. Она определяет, какие инструменты агент может вызывать, откуда он получает информацию, как он проверяет свои собственные решения и когда он должен остановиться.

Чтобы понять, почему это важно, рассмотрим три уровня разработки агентов ИИ:

Слой	Что он оптимизирует	Область применения	Пример
Проектирование подсказок	Что вы говорите модели	Однократный обмен	Несколько примеров, подсказки по цепочке мыслей
Контекстная инженерия	Что видит модель	Контекстное окно	Поиск документов, сжатие истории
Инженерия среды	Мир, в котором действует агент	Многочасовое автономное выполнение	Инструменты, логика проверки, архитектурные ограничения

Prompt Engineering оптимизирует качество одного обмена - формулировки, структуру, примеры. Один разговор, один результат.

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

Harness Engineering создает мир, в котором работает агент. Инструменты, источники знаний, логика проверки, архитектурные ограничения - все, что определяет, сможет ли агент надежно работать в сотнях решений без контроля со стороны человека.

Три уровня разработки агентов ИИ: Prompt Engineering оптимизирует то, что вы говорите, Context Engineering управляет тем, что видит модель, и Harness Engineering проектирует среду выполнения .

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

Это не конкурирующие подходы. Это последовательность действий. По мере роста возможностей агента одна и та же команда проходит все три уровня - часто в рамках одного проекта.

Как OpenAI использовала Harness Engineering для создания кодовой базы в миллион строк и какие уроки они извлекли

OpenAI провела внутренний эксперимент, который наглядно демонстрирует Harness Engineering. Они описали его в своем инженерном блоге: "Harness Engineering: Leveraging Codex in an Agent-First World". Команда из трех человек начала работу с пустым репозиторием в конце августа 2025 года. В течение пяти месяцев они не писали никакого кода сами - каждую строчку генерировал Codex, агент OpenAI по кодированию на основе искусственного интеллекта. Результат: миллион строк рабочего кода и 1 500 объединенных запросов на исправление.

Самое интересное - это не результат. А четыре проблемы, с которыми они столкнулись, и решения, которые они создали.

Проблема 1: отсутствие общего понимания кодовой базы

Какой уровень абстракции должен использовать агент? Каковы соглашения об именовании? К чему привело обсуждение архитектуры на прошлой неделе? Не имея ответов, агент неоднократно угадывал - и угадывал неправильно.

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

Решение: сократить AGENTS.md до 100 строк. Не правила - карта. Она указывает на структурированный каталог docs/, содержащий проектные решения, планы выполнения, спецификации продуктов и справочные документы. Линтеры и CI проверяют, чтобы перекрестные ссылки оставались нетронутыми. Агент переходит именно к тому, что ему нужно.

Основной принцип: если что-то не находится в контексте во время выполнения, оно не существует для агента.

Проблема 2: человеческий отдел контроля качества не успевал за работой агента

Команда подключила Chrome DevTools Protocol к Codex. Агент мог делать скриншоты путей пользовательского интерфейса, наблюдать за событиями во время выполнения, запрашивать журналы с помощью LogQL и метрики с помощью PromQL. Они установили конкретный порог: служба должна была запускаться менее чем за 800 миллисекунд, прежде чем задача считалась завершенной. Задачи Codex выполнялись более шести часов подряд - как правило, пока инженеры спали.

Проблема 3: Архитектурный дрейф без ограничений

Без защитных ограждений агент воспроизводил все шаблоны, которые находил в репозитории, в том числе и плохие.

Решение: строгая многоуровневая архитектура с единым направлением зависимостей - Types → Config → Repo → Service → Runtime → UI. Пользовательские линтеры обеспечивали соблюдение этих правил механически, а сообщения об ошибках включали инструкцию по исправлению в строку.

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

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

Проблема 4: молчаливый технический долг

Решение: закодировать основные принципы проекта в репозитории, затем запускать фоновые задачи Codex по расписанию для проверки отклонений и отправки PR-рефакторинга. Большинство из них автоматически сливались в течение минуты - небольшие постоянные выплаты, а не периодические расплаты.

Почему агенты ИИ не могут оценивать собственную работу

Эксперимент OpenAI доказал, что Harness Engineering работает. Но отдельное исследование выявило в нем один из сбоев: агенты систематически не умеют оценивать собственные результаты.

Проблема проявляется в двух формах.

Контекстное беспокойство. По мере заполнения контекстного окна агенты начинают преждевременно сворачивать задания - не потому, что работа сделана, а потому, что они чувствуют приближение границы окна. Команда Cognition, создавшая ИИ-кодировщика Devin, задокументировала такое поведение при перестройке Devin для Claude Sonnet 4.5: модель осознала свое контекстное окно и начала сокращать работу задолго до того, как в ней закончилось место.

Их решение было чисто инженерным. Они включили бета-версию контекста на 1 млн токенов, но ограничили фактическое использование 200 тыс. токенов, обманув модель, заставив ее поверить, что у нее достаточно места. Беспокойство исчезло. Никаких изменений в модели не потребовалось; просто более умная среда.

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

Предвзятость самооценки. Когда агенты оценивают свой собственный результат, они ставят ему высокие баллы. Даже в задачах с объективными критериями "прошел/не прошел" агент замечает проблему, убеждает себя в том, что она несерьезная, и одобряет работу, которая должна быть провалена.

Решение проблемы заимствовано из GAN (Generative Adversarial Networks): полностью отделите генератор от оценщика. В GAN две нейронные сети конкурируют - одна генерирует, другая оценивает, - и это состязательное напряжение заставляет повышать качество. Та же динамика применима к мультиагентным системам.

Anthropic проверила это с помощью трех агентов - планировщика, генератора и оценщика - против одиночного агента, которому поручили создать движок для двухмерной ретро-игры. Полностью эксперимент описан в статье "Harness Design for Long-Running Application Development" (Anthropic, 2026). Планировщик разворачивает короткую подсказку в полную спецификацию продукта, намеренно оставляя детали реализации неопределенными - завышенная спецификация на ранних этапах приводит к ошибкам на последующих этапах. Генератор реализует функции в спринтах, но перед написанием кода он подписывает контракт с Оценщиком: общее определение "сделано". Оценщик использует Playwright (фреймворк Microsoft для автоматизации браузера с открытым исходным кодом), чтобы просмотреть приложение, как настоящий пользователь, тестируя пользовательский интерфейс, API и поведение базы данных. Если что-то не получается, спринт проваливается.

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

Сравнение одиночного агента и трехагентной связки: одиночный агент работал 20 минут за девять долларов с неработающей основной функциональностью, а полная связка работала 6 часов за двести долларов, создавая полнофункциональную игру с функциями искусственного интеллекта .

Трехагентная архитектура обошлась примерно в 20 раз дороже. Выходные данные перешли от непригодных к пригодным. Это и есть основная сделка, которую совершает Harness Engineering: структурные накладные расходы в обмен на надежность.

Проблема поиска внутри каждого агента Harness

Оба паттерна - структурированная система docs/ и спринтерский цикл "Генератор/Оценщик" - имеют общую негласную зависимость: агент должен находить нужную информацию из живой, развивающейся базы знаний, когда она ему нужна.

Это сложнее, чем кажется. Возьмем конкретный пример: Генератор выполняет спринт 3, реализуя аутентификацию пользователей. Прежде чем писать код, ему нужны два вида информации.

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

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

Эти два запроса происходят одновременно. Их нельзя разделить на последовательные шаги.

Чистый векторный поиск не справляется с точным совпадением. Традиционный BM25 не справляется с семантическими запросами и не может предсказать, какой словарь будет использоваться в документе. До появления Milvus 2.5 единственным вариантом было использование двух параллельных поисковых систем - векторного и полнотекстового ин дексов, - работающих параллельно во время запроса с использованием пользовательской логики объединения результатов. Для живого репозитория docs/ с постоянными обновлениями оба индекса должны были оставаться синхронизированными: каждое изменение документа вызывало переиндексацию в двух местах, с постоянным риском несогласованности.

Как Milvus 2.6 решает проблему поиска агентов с помощью единого гибридного конвейера

Milvus - это векторная база данных с открытым исходным кодом, разработанная для рабочих нагрузок искусственного интеллекта. Sparse-BM25 в Milvus 2.6 сводит проблему поиска агентов с помощью двух конвейеров к одной системе.

При поступлении документов Milvus одновременно генерирует два представления: плотное вложение для семантического поиска и разреженный вектор с TF-кодировкой для BM25-скоринга. Глобальная статистика IDF обновляется автоматически по мере добавления или удаления документов - никаких ручных переиндексаций. При запросе на естественном языке оба типа векторов запроса генерируются самостоятельно. Взаимное слияние рангов (Reciprocal Rank Fusion, RRF) объединяет ранжированные результаты, и пользователь получает единый унифицированный набор результатов.

До и после: две отдельные системы с ручной синхронизацией, фрагментированными результатами и собственной логикой слияния против единого конвейера Milvus 2.6 с плотным встраиванием, разреженным BM25, слиянием RRF и автоматическим обслуживанием IDF, дающим единые результаты.

Один интерфейс. Один индекс для обслуживания.

В бенчмарке BEIR - стандартном оценочном наборе из 18 разнородных наборов данных для поиска - Milvus достигает в 3-4 раза большей производительности, чем Elasticsearch, при эквивалентном отзыве, и до 7-кратного улучшения QPS на определенных рабочих нагрузках. Для сценария спринта один запрос находит как принцип проектирования сессии (семантический путь), так и каждый документ с упоминанием validateToken (точный путь). Хранилище docs/ обновляется непрерывно; обслуживание BM25 IDF означает, что только что написанный документ участвует в оценке следующего запроса без пакетной перестройки.

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

Лучшие компоненты жгута рассчитаны на удаление

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

Эти предположения не оправдались. Трюк с контекстными окнами может стать ненужным, когда модели разовьют настоящую выносливость к длительным контекстам. По мере совершенствования моделей другие компоненты станут ненужными накладными расходами, которые замедляют работу агентов, не добавляя им надежности.

Harness Engineering - это не фиксированная архитектура. Это система, которая перестраивается с каждым выпуском новой модели. Первый вопрос после любого крупного обновления - не "что добавить?". А "что можно убрать?".

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

Каждый компонент хорошо построенной системы ожидает, что более умная модель сделает его ненужным. Это не проблема. Это цель.

Начните работать с Milvus

Если вы создаете агентскую инфраструктуру, которой нужен гибридный поиск - семантический поиск и поиск по ключевым словам в одном конвейере, - вот с чего следует начать:

• Прочитайте примечания к выпуску Milvus 2.6 для получения подробной информации о Sparse-BM25, автоматическом обслуживании IDF и контрольных показателях производительности.
• Присоединяйтесь к сообществу Milvus, чтобы задавать вопросы и делиться своими разработками.
• Запишитесь на бесплатную сессию Milvus Office Hours, чтобы обсудить свой вариант использования с экспертом по векторным базам данных.
• Если вы предпочитаете обойтись без настройки инфраструктуры, Zilliz Cloud (полностью управляемый Milvus) предлагает бесплатный уровень для начала работы с бесплатными кредитами в размере $100 после регистрации с указанием рабочей электронной почты.
• Отметьте нас на GitHub: milvus-io/milvus - 43k+ звезд и продолжает расти.

Часто задаваемые вопросы

Что такое рекрутинговая инженерия и чем она отличается от оперативной инженерии?

Prompt engineering оптимизирует то, что вы говорите модели в рамках одного обмена - формулировки, структуру, примеры. Harness Engineering создает среду выполнения вокруг автономного агента ИИ: инструменты, которые он может вызывать, знания, к которым он может обращаться, логику проверки, которая проверяет его работу, и ограничения, которые предотвращают дрейф архитектуры. Оперативная инженерия формирует один поворот разговора. Инженерия Harness определяет, сможет ли агент надежно работать в течение нескольких часов, принимая сотни решений без контроля со стороны человека.

Почему агентам ИИ нужны одновременно векторный поиск и BM25?

Агенты должны одновременно отвечать на два принципиально разных поисковых запроса. Семантические запросы - каковы принципы проектирования пользовательских сессий? - требуют плотных векторных вкраплений для сопоставления концептуально связанного контента независимо от словарного запаса. Запросы с точным соответствием - какие документы ссылаются на функцию validateToken? - требуют скоринга ключевых слов BM25, поскольку имена функций представляют собой произвольные строки, не имеющие смыслового значения. Поисковая система, работающая только в одном режиме, будет систематически пропускать запросы другого типа.

Как Milvus Sparse-BM25 работает для поиска знаний агентов?

При входе в систему Milvus одновременно генерирует плотное вложение и разреженный вектор с TF-кодировкой для каждого документа. Глобальная статистика IDF обновляется в режиме реального времени по мере изменения базы знаний - ручное переиндексирование не требуется. Во время запроса оба типа векторов генерируются внутри системы, Reciprocal Rank Fusion объединяет ранжированные результаты, и агент получает единый унифицированный набор результатов. Весь конвейер работает через один интерфейс и один индекс, что очень важно для постоянно обновляемых баз знаний, таких как репозиторий документации по коду.

Когда следует добавлять агента-оценщика в набор агентов?

Добавьте отдельного агента-оценщика, если качество выходных данных генератора не может быть проверено только автоматическими тестами, или если самооценка привела к пропуску дефектов. Ключевой принцип: оценщик должен быть архитектурно отделен от генератора - общий контекст вновь вызывает ту же самую предвзятость, которую вы пытаетесь устранить. Оценщик должен иметь доступ к инструментам времени выполнения (автоматизация браузера, вызовы API, запросы к базе данных), чтобы тестировать поведение, а не только просматривать код. Исследование Anthropic показало, что такое разделение, вдохновленное GAN, привело к повышению качества результатов от "технически запущено, но сломано" до "полностью функционально с функциями, которые агент-одиночка никогда не пытался реализовать".