Harness-инженерия
ИИ-модели уже могут писать миллион строк кода. Настоящая задача уже не в том, чтобы заставить их писать лучше, а в том,как заставить их работать стабильно, надёжно и не теряя контроля. Эта методология построения систем ограничений, обратной связи и управления вокруг ИИ-агентов — это новая парадигма, которая стремительно охватила инженерный мир в начале 2026 года —Harness-инженерия。
1. Что такое Harness Engineering?
Harness Engineering— это систематическая инженерная практика проектирования и созданиямеханизмов ограничений, циклов обратной связи, управления рабочими процессами и циклов непрерывного улучшениявокруг ИИ-агентов.
Он не оптимизирует саму модель, а среду, в которой модель работает. Основная философия сводится к одной фразе:Человек направляет, агент выполняет。
Слово «harness» происходит от конской упряжи — поводьев, седла, удил — полного набора снаряжения, используемого, чтобы управлять сильными, но непредсказуемыми животными.Harness Engineering — это не ослабление возможностей ИИ, а ковка золотой упряжи для него, чтобы он мог бежать быстро и уверенно.
Эта концепция была впервые предложена соучредителем HashiCorp Митчеллом Хашимото 5 февраля 2026 года. Шесть дней спустя OpenAI официально приняла этот термин в отчёте об эксперименте с миллионом строк кода, а Мартин Фаулер затем написал углублённый анализ. В течение месяца он стал модным словечком в сообществе разработчиков.
harness engineering — это идея, что каждый раз, когда вы обнаруживаете, что агент совершает ошибку, вы тратите время на то, чтобы спроектировать решение, благодаря которому агент больше не совершит эту ошибку в будущем.
—— Митчелл Хашимото
Подтекст этого утверждения таков:Каждый сбой агента — это сигнал о том, что дизайн среды неполон.Правильная реакция — не переключиться на более мощную модель, а переработать среду, в которой он работает.
2. Зачем нам нужна Harness Engineering? Реальные данные говорят сами за себя
Случай LangChain особенно показателен: не был изменён ни один параметр базовой модели;лишь за счёт оптимизации внешней управляющей среды(структуры документации, циклов проверки, системы отслеживания), оценка кодирующего агента на Terminal Bench 2.0 взлетела с 52.8% до 66.5%, а его глобальный рейтинг поднялся с 30-го на 5-е место.
Пять независимых команд пришли к одному и тому же выводу:Узкое место — не интеллект модели, а инфраструктура.
3. Три смены парадигмы в AI-инженерии
Чтобы понять, почему Steering Engineering имеет значение, нам сначала нужно шаг за шагом увидеть, как мы к этому пришли.
| Парадигма | Основная проблема | Цель оптимизации | Режим взаимодействия |
|---|---|---|---|
| Промпт-инжиниринг | Как ясно формулировать | Формулировка промпта, формат, примеры | Вопрос-ответ |
| Контекстная инженерия | Как подавать информацию ИИ | Документы, фрагменты кода, история диалога | Внедрение информации → генерация |
| Инженерия управления | Как заставить агентов работать надёжно | Ограничения, циклы обратной связи, системы управления | Люди управляют, агенты исполняют |
Запоминающаяся аналогия:
- Промпт-инжиниринг —— Навык кричать команды лошади
- Контекстная инженерия —— Карта, показанная лошади
- Инженерия обвязки —— Строительство шоссе для лошади, включая отбойники, знаки ограничения скорости и заправочные станции
4. Распространённые режимы отказов агентов
В ходе длительной эксплуатации агентов инженеры Anthropic обобщили три типичных режима отказа — именно те ключевые болевые точки, которые должна решить инженерия обвязки:
Режим отказа 1: выполнение за один проход
Агенты склонны реализовывать всю функциональность за одну сессию. Результат — истощённое окно контекста, груда недокументированного незавершённого кода, и следующей сессии приходится тратить много времени на догадки о том, что было раньше.
Режим отказа 2: Преждевременное объявление победы
На позднем этапе проекта, когда часть функций уже готова, агент оглядывается вокруг и, увидев прогресс, сразу объявляет задачу выполненной — хотя многие функции ещё не реализованы.
Режим отказа 3: Преждевременная пометка функций как завершённых
Без явной подсказки агент помечает код как завершённый сразу после его написания, без сквозного тестирования. Прохождение модульных тестов или команд curl не означает, что функция действительно работает.
Кроме того, у агентов есть ещё одна опасная черта:Они чрезвычайно хорошо копируют паттерны. Он добросовестно воспроизводит и усиливает любые паттерны, существующие в кодовой базе — включая плохие паттерны и архитектурный дрейф. Это означает, что неограниченный агент накапливает технический долг с тревожной скоростью.
5. Четыре защитных барьера Harness Engineering
Опираясь на практики OpenAI, Anthropic, LangChain и Martin Fowler, Harness можно свести к четырём ключевым компонентам — четырём «защитным барьерам»:
Защитный барьер 1: Инженерия контекста — Справочник нового сотрудника
Подобно тому как новому сотруднику выдают подробное рабочее руководство,AGENTS.md— это первое руководство, которое AI-агент видит, входя в кодовую базу. Но это не статичное руководство на 1,000 страниц — контекст является дефицитным ресурсом, и слишком много указаний, наоборот, вытеснит место для задач, кода и связанной документации, превратив его в кладбище устаревших правил.
Лучший подход таков: предоставить стабильную, компактную точку входа, а затем научить агента извлекать и подтягивать больше контекста по мере необходимости, исходя из текущей задачи. В проекте Ghostty Митчелла Хасимото каждая строка в AGENTS.md соответствует историческому случаю отказа агента — документация представляет собой живую петлю обратной связи, а не статичный артефакт.
Защитный барьер 2: Архитектурные ограничения — Поводья
Команда OpenAI установила строгую иерархическую модель зависимостей:
Types → Config → Repo → Service → Runtime → UI
Нижние слои не могут иметь обратных зависимостей на верхние слои. Все архитектурные правила закодированы какПользовательские правила линтера; их нарушение приведёт к тому, что CI заблокирует слияние — независимо от того, написан код людьми или ИИ.
Есть ключевая деталь: сами сообщения об ошибках линтера — это тоже контекстная инженерия. Он не просто сообщает, что вы нарушили правило X, а объясняет, почему правило существует и каков правильный подход, чтобы, когда Агент читает ошибку, он мог понять и самостоятельно исправиться без вмешательства человека.
Ограничитель 3: цикл обратной связи — агенты проверяют агентов
В традиционной разработке инженеры-люди отвечают за проверку кода. В агентной инженерии эта работа становится взаимодействием агент-агент: Codex проверяет свои изменения локально, запрашивает дополнительную проверку и повторяет цикл, пока не пройдёт.
Хуки в цикле обратной связи могут запускать предопределённые наборы тестов и при неудаче возвращать управление модели с информацией об ошибке или предлагать модели самостоятельно оценить свой код. Если написанные ИИ тест-кейсы пропускают код с ошибками, Harness сочтёт тест недействительным, заставляя его переосмыслить границы тестирования.
Ограничитель 4: управление энтропией — сборка мусора
Со временем программные системы постепенно становятся хаотичными (энтропия растёт), а технический долг накапливается. OpenAI применяет стратегию непрерывных небольших погашений вместо того, чтобы дожидаться, пока проблемы станут серьёзными, и затем разбираться с ними централизованно — они образно называют этот подходпереработкой мусора, и считают, что технический долг подобен кредиту с высокими процентами.
Конкретные меры: регулярно запускать фоновые задачи Codex для сканирования отклонений, обновления оценок качества и инициирования целевых PR по рефакторингу. Кроме того, есть также специальный...Doc-gardening Agent(Document Gardener Agent) автоматически сканирует в фоне несоответствия между документацией и кодом и, когда находит устаревший контент, автоматически отправляет PR для его исправления — агенты поддерживают документацию для агентов.
6. Шесть общеотраслевых пунктов консенсуса
На основе множества независимых источников информации, включая OpenAI, Anthropic, LangChain, Stripe и HashiCorp, в отрасли сформировался чёткий консенсус по следующим шести аспектам:
| # | Консенсус | Ключевая точка зрения |
|---|---|---|
| 1 | Узкое место — в инфраструктуре, а не в интеллекте модели. | Пять независимых команд пришли к одному выводу. Простое изменение формата инструмента Harness может поднять балл модели с 6.7% до 68.3% |
| 2 | Документация должна быть живым циклом обратной связи | Статическая документация — это кладбище; только динамическая документация имеет ценность. Пусть фоновые агенты периодически очищают устаревшие документы и отправляют PR |
| 3 | Разделение мышления и исполнения | Сложные задачи невозможно выполнить в одном окне контекста; нужна многоуровневая архитектура Orchestrator + Worker с сохранением состояния во внешнем хранилище |
| 4 | Больше контекста — не всегда лучше | Контекст — это дефицитный ресурс. Огромные файлы инструкций вытесняют пространство задачи; извлекайте по требованию и внедряйте динамически |
| 5 | Ограничения должны быть автоматизированы | Ручная проверка — это узкое место. Guardrails должны быть закодированы в виде Linter, CI и систем типов, чтобы машины обеспечивали их соблюдение вместо людей |
| 6 | Роль инженера меняется | От автора кода к архитектору среды. Самая большая инженерная задача — спроектировать систему управления, которая заставляет агентов работать надёжно |
7. Связь между Harness и традиционными фреймворками
Harness — это не замена SDK, скаффолдам или фреймворкам для агентов, а скорееслой поверх них：
Традиционные фреймворки решаюткак создавать AI-агентов, тогда как слой Harness решает совершенно другую проблему:как надёжно запускать агентов。
Модели постепенно поглощают около 80% функциональности фреймворков (определение агента, маршрутизация сообщений, жизненный цикл задач...), но оставшиеся 20% —персистентность, детерминированное воспроизведение, контроль затрат, наблюдаемость, восстановление после ошибок— как раз и составляют ценность слоя Harness.
Итог
Harness Engineering — это не эксперимент одной компании, а смена парадигмы, которую переживает вся индустрия.
Резюме Биргитты Бёкелер — самое проницательное:
Чтобы достичь более высокой автономности AI, среда выполнения должна подчиняться более строгим ограничениям. Повышение доверия требует не большей свободы, а больших ограничений.
Как отбойники на шоссе — именно благодаря отбойникам вы осмеливаетесь разогнаться до 120 km/h.
| Основные компоненты | Решаемые проблемы | Показательные практики |
|---|---|---|
| Инженерия контекста Контекст | Агент не знает, на что смотреть и как это найти. | AGENTS.md: живой документ, извлечение по запросу. |
| Архитектурные ограничения Ограничения | Агент копирует и усиливает плохие паттерны. | Слоистые зависимости, кастомный линтер, блокировка, обеспечиваемая CI |
| Цикл обратной связи Обратная связь | Агент не знает, что сделал что-то не так. | Взаимное ревью агентов, автоматизированный набор тестов |
| Управление энтропией Энтропия | Технический долг и загнивание документации. | Агент по уходу за документацией, непрерывная сборка мусора |
Будущее разработки программного обеспечения, возможно, больше не будет связано с тем, насколько быстро и хорошо мы умеем писать код, а скорее с тем,Насколько умные и надёжные системы мы можем спроектировать, чтобы обуздать огромную мощь ИИ-агентов?。
Ценность инженеров смещается от исполнителей к тем, кто создаёт возможности, и системным мыслителям — от создания продуктов к созданию фабрик, которые могут создавать продукты.