Что такое harness и почему это инженерная дисциплина

Модель у всех одна и та же. Результаты у команд разные, и разница почти целиком объясняется средой вокруг модели: что агент видит, чем может проверить себя, что ему запрещено и кто ловит ошибки до человека. Эту среду называют обвязкой агента (harness). Курс о том, как её строить, — для сеньоров, техлидов и техдиров, которые отвечают за то, чтобы агенты в команде давали предсказуемый результат, а не случайный.

Агент = модель + harness

Биргитта Бёкелер (Thoughtworks) в статье «Harness engineering for coding agent users» от 2 апреля 2026 приводит ставшее расхожим короткое определение: harness — всё в агенте, кроме самой модели. Формула «агент = модель + harness» снимает старый спор, «умная» ли модель. Оцениваете агента — оцениваете связку.

В этой связке два слоя:

• Внутренний harness поставляет вендор. У Codex это агентный цикл, сборка промпта, исполнение инструментов в песочнице (sandbox), компакция, MCP, навыки (skills), персистентность тредов. Майкл Болин из OpenAI в статье «Unrolling the Codex agent loop» называет harness именно цикл и логику исполнения, общие для CLI, IDE и облака.
• Внешний harness строите вы из возможностей агента: AGENTS.md, документация в репозитории, планы, линтеры, структурные тесты, хуки, окружения на задачу, evals.

Внутренний слой вы не меняете, но обязаны понимать: от него зависит, что дойдёт до модели и сколько это стоит. Этому посвящён первый модуль. Внешний слой — ваша зона ответственности, ему посвящён весь остальной курс.

Откуда термин

Отправная точка — статья Райана Лопополо «Harness engineering: leveraging Codex in an agent-first world» (OpenAI, 11 февраля 2026; есть официальный русский перевод). Команда пять месяцев делала внутренний продукт, где ни одна строка не написана руками. По их данным — около миллиона строк и около 1 500 PR, начинали три инженера, потом стало семь, в среднем 3,5 PR на инженера в день. Время, по оценке самой команды, — примерно десятая часть от ручной разработки.

Важно, что авторы пишут о старте: вначале прогресс был медленнее ожиданий. Причину они видят не в слабости модели, а в недоописанной среде — агенту не хватало инструментов, абстракций и структуры. Когда агент буксовал, решение почти никогда не звучало как «попробуй ещё раз». Вопрос был другой: какой возможности не хватает и как сделать её понятной и обязательной для агента. Девиз статьи — «Humans steer. Agents execute.»

Наш вывод. Эти цифры — опыт одной команды на greenfield-проекте, где среду строили под агентов с первого коммита. Сами авторы оговариваются: такое поведение не переносится на другие репозитории без сопоставимых вложений. Бенчмарком для своей команды их брать нельзя. Переносить стоит метод: провал агента — сигнал о дыре в среде, и чинят среду, а не результат.

Направляющие и датчики

Бёкелер делит внешний harness на два типа контролей, и эта рамка пройдёт через весь курс:

Вторая ось — вычислительные контроли (детерминированные и дешёвые: тесты, линтеры) против выводных (inferential: ревью моделью, LLM-as-judge). Первые надёжнее, вторые покрывают то, что не формализуется.

Почему это инженерия, а не набор советов

У среды для агентов те же свойства, что у любого кода:

• Она версионируется. Всё, чего агент не видит в репозитории, для него не существует — договорённость в чате бесполезна (подробно в уроке о системе записи).
• Она тестируется. Ссылки в документации, размер AGENTS.md, архитектурные границы проверяются в CI, а не на глаз.
• Она стареет. Anthropic в материале о harness для длинных задач прямо пишет: с каждой новой моделью конструкцию надо пересматривать, убирать то, что перестало нести нагрузку.
• У неё есть стоимость. Каждый токен инструкций занимает место в контексте и ломает или сохраняет кэш. Это считается, а не угадывается.

Как устроен курс

1. Как устроен агент: агентный цикл, сборка промпта и кэш, контекстная инженерия, компакция.
2. Направляющие: читаемость для агента, AGENTS.md как оглавление, система записи, планы исполнения, spec-driven development.
3. Датчики и ограничения: инварианты, петли обратной связи, наблюдаемость, окружения, проверка поведения.
4. Масштаб: длинные задачи, оркестрация, энтропия, мерж при большом потоке.
5. Оценка и управление: evals, бенчмарки, самоулучшающийся harness, дорожная карта.

Мы опираемся на первоисточники — OpenAI, Anthropic, Thoughtworks — и в каждом уроке разделяем, что говорит источник и что мы советуем сами. Примеры — из работы агентства: PHP-сайт на OctoberCMS, мобильные приложения, GitLab CI, задачи из Kaiten.