Почему мощная нейросеть может работать плохо: что такое харнесс и как он меняет возможности AI-агентов

Откуда взялось слово «харнесс»

Harness переводится как «упряжь» или «сбруя». В научной работе Сандерсона Оливейры де Масиеду, посвященной определению термина, прослежена его история. Слово пришло из старофранцузского harneis ― «доспехи, боевое снаряжение». К началу XIV века так стали называть ремни, которыми запрягают тягловое животное в повозку. Переносное значение ― «направить силу на полезную работу» ― появилось в конце XVII века.

В программировании термин прошел несколько этапов.

1. Тестовый харнесс ― набор скриптов, заглушек и имитаций, которые запускают код в контролируемой среде и фиксируют его поведение.
2. Харнесс для оценки моделей ― набор задач со стандартной проверкой результата. К этой категории относятся бенчмарки вроде SWE-bench и WebArena.
3. Харнесс агента ― та же метафора, но контроль работает во время выполнения задачи, а не после нее.

Образ упряжи хорошо передает суть. Языковая модель ― это сила, которая сама по себе никуда не едет. Чтобы она выполнила работу, ее нужно «запрячь»: дать инструменты, задать направление и ограничить там, где она может навредить.

Модель и харнесс: как это устроено

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

Вивек Триведи в статье «Анатомия харнесса агента» дал самое широкое определение. Харнесс ― это «весь код, конфигурация и логика выполнения, которые не являются самой моделью». В этой логике даже обычный чат-бот ― простейший харнесс: цикл, который хранит историю сообщений и добавляет к ней новые реплики пользователя.

Типичный харнесс современного агента включает несколько слоев:

• системный промпт ― базовые инструкции, которые модель получает перед каждой задачей;
• инструменты ― чтение и запись файлов, терминал, веб-поиск, браузер, подключения через MCP;
• среда выполнения ― файловая система и песочница, где агент запускает код; 
• управление контекстом ― сжатие длинной истории (компакция), вынос объемных результатов в файлы, подгрузка навыков только по необходимости;
• память ― файлы вроде AGENTS.md или CLAUDE.md, которые загружаются в начале каждой сессии и сообщают агенту правила проекта;
• оркестрация ― запуск субагентов, передача задач между ними, выбор модели под конкретный шаг;
• хуки и проверки ― код, который срабатывает без участия модели: запускает тесты, линтер или запрашивает подтверждение у пользователя.

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

Четыре признака харнесса

Система считается харнессом агента, только если во время работы выполняет четыре условия одновременно.

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

Интерфейс инструментов. Модель может не только читать, но и изменять внешнюю среду ― редактировать файлы, запускать команды. Доступ только на чтение тест не проходит.

Управление контекстом. Система сама решает, что попадет в контекст модели, а что из него уйдет, исходя из задачи. Простое обрезание истории по длине не считается.

Механизмы контроля. Есть хотя бы одно ограничение, проверка или детерминированное действие, которое работает без «согласия» модели.

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

Claude Code и Codex CLI являются харнессами, но различаются механизмами контроля. Claude Code запрашивает подтверждение перед потенциально разрушительными действиями. Codex CLI использует ступенчатые режимы разрешений.

Как выглядят харнессы на практике

Самый известный пример харнесса ― Claude Code. В сентябре 2025 года Anthropic переименовала Claude Code SDK в Claude Agent SDK и прямо описала его как «харнесс, на котором работает Claude Code». Компания объяснила: тот же механизм подходит не только для программирования, но и для агентов любого другого типа. Базовый цикл Anthropic описывает четырьмя шагами: собрать контекст, выполнить действие, проверить работу, повторить.

О масштабах такой обвязки можно судить по инциденту 31 марта 2026 года. Из-за ошибки при публикации пакета в реестре npm оказался доступен исходный код Claude Code.

Claude code source code has been leaked via a map file in their npm registry!

Code: https://t.co/jBiMoOzt8G pic.twitter.com/rYo5hbvEj8

— Chaofan Shou (@shoucccc) March 31, 2026

В Anthropic назвали произошедшее ошибкой упаковки релиза по вине человека, а не взломом, и заменили пакет. Для понимания темы важна сама цифра: полмиллиона строк ― это код вокруг модели, а не модель.

Похожие харнессы есть у других компаний:

• Codex от OpenAI ― агент для программирования в терминале, приложении и облаке;
• Gemini CLI и Antigravity от Google ― терминальный агент и среда разработки с агентами;
• OpenCode ― открытый терминальный агент, к которому подключаются модели разных провайдеров;
• DeepSeek Harness ― открытый агент DeepSeek, в котором любая функция оформлена как плагин.

DeepSeek на странице своего агента описывает разделение ролей образно. Модель ― «душа» агента, а харнесс позволяет ему понимать окружение, пользоваться инструментами и работать в реальных условиях.

У большинства перечисленных агентов модель можно сменить. В OpenCode или DeepSeek Harness подключаются Claude, GPT, Gemini, Kimi, GLM и другие модели. Поэтому вопрос «какая модель лучше» в агентских задачах всегда неполный. Правильнее спрашивать, какая модель в каком харнессе показывает лучший результат.

Почему харнесс важен не меньше модели

Долгое время прогресс ИИ измеряли почти исключительно качеством моделей. Бенчмарки сравнивали GPT, Claude и Gemini, а обвязке уделяли мало внимания. В 2026 году несколько экспериментов показали, что разница между харнессами сопоставима с разницей между поколениями моделей.

Эксперимент LangChain. В феврале 2026 года команда LangChain описала, как улучшала своего агента Deep Agents. Модель ― gpt-5.2-codex ― оставалась неизменной. Ключевая фраза статьи: «Мы изменили только харнесс». Результат в бенчмарке TerminalBench 2.0 вырос с 52,8% до 66,5%, а агент поднялся из топ-30 в топ-5 рейтинга.

Изменения были прикладными. В системный промпт добавили цикл «спланировать ― построить с тестами ― сверить со спецификацией ― исправить». Отдельный модуль перехватывал агента перед завершением задачи и заставлял провести проверку. Другой модуль отслеживал повторные правки одного и того же файла и предлагал сменить подход. Команда также распределила объем рассуждений по этапам: максимальный ― на планирование и проверку, высокий ― на реализацию. Работа только на максимальном уровне дала 53,9% из-за превышения лимитов времени, а на высоком ― 63,6%.

Эксперимент Anthropic. В марте 2026 года инженер Anthropic Притхви Раджасекаран описал харнесс из трех агентов для разработки приложений. Планировщик превращает короткий запрос из нескольких предложений в полную спецификацию. Генератор пишет код. Оценщик через MCP «прокликивает» запущенное приложение как пользователь и возвращает замечания.

Сравнение на примере конструктора ретро-игр показательно. Claude Opus 4.5 без дополнительной обвязки справился за 20 минут и $9, но основной игровой режим в результате не работал. Полный харнесс трудился 6 часов и потратил $200, зато выдал рабочее приложение. В Anthropic отдельно отметили: «Разделение агента, который выполняет работу, и агента, который ее оценивает, оказалось сильным рычагом». И добавили, что без дополнительной настройки Claude ― слабый тестировщик собственного кода.

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

Что такое харнесс-инжиниринг

Термин «харнесс-инжиниринг» закрепился в феврале 2026 года. 5 февраля Митчелл Хашимото, создатель Terraform, Vagrant и терминала Ghostty, описал свой путь к работе с ИИ-агентами. Один из этапов он назвал «Спроектируйте харнесс». Суть подхода: каждый раз, когда агент ошибается, нужно потратить время и сделать так, чтобы эта ошибка больше не повторялась.

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

Через шесть дней, 11 февраля, OpenAI опубликовала статью «Харнесс-инжиниринг: Codex в мире, где агенты на первом месте». Автор, Райан Лополо, описал эксперимент: за пять месяцев команда создала внутренний бета-продукт, не написав вручную ни строчки кода. Объем кодовой базы ― около миллиона строк. Агенты открыли и смержили около 1500 пулл-реквестов. Команда начинала с трех инженеров, затем выросла до семи, а средняя производительность составила 3,5 пулл-реквеста на инженера в день.

Ключевые практики OpenAI вписываются в ту же логику.

1. AGENTS.md как карта, а не энциклопедия. Файл длиной около 100 строк служит оглавлением и указывает, где лежат подробные документы. В OpenAI сформулировали это так: «Дайте Codex карту, а не инструкцию на 1000 страниц».
2. Репозиторий как единственный источник знаний. Дизайн-документы, планы и спецификации хранятся в папке docs. Все, к чему агент не может получить доступ во время работы, для него «фактически не существует».
3. Механическое соблюдение правил. Собственные линтеры и проверки следят за архитектурой и актуальностью документации. Сообщения об ошибках сразу содержат инструкцию по исправлению ― для агента.
4. «Сборка мусора». Фоновые агенты ищут отклонения от правил и открывают небольшие пулл-реквесты с рефакторингом. До автоматизации команда тратила на исправление «ИИ-мусора» каждую пятницу ― около 20% рабочего времени.

Главный тезис статьи OpenAI ― «люди направляют, агенты выполняют». Работа инженера смещается от написания кода к проектированию среды, в которой агенты пишут его надежно.

Харнессы, которые улучшают себя сами

Если харнесс так сильно влияет на результат, логично поручить его доработку самому ИИ. В 2026 году появились первые системы, которые делают это автоматически.

В марте 2026 года исследователи под руководством Челси Финн представили Meta-Harness. Система перебирает варианты харнесса, запускает их и анализирует полные журналы работы, а не сжатые сводки. В задаче онлайн-классификации текстов найденный харнесс превзошел лучшую существующую систему управления контекстом на 7,7 пункта и использовал в четыре раза меньше токенов.

В задачах по математике олимпиадного уровня один найденный харнесс поднял точность в среднем на 4,7 пункта для пяти разных моделей. В агентском программировании найденные варианты обошли лучшие ручные решения в TerminalBench-2.

Как применить идею харнесса в своей работе 

Харнесс-инжиниринг касается не только команд, которые строят агентов с нуля. Любой пользователь Claude Code, Codex, Gemini CLI или DeepSeek Harness уже работает внутри харнесса и может его настраивать. Ниже ― три простых шага, которые повторяют подход Хашимото и OpenAI. Промпты подходят для любого из перечисленных агентов. 

Шаг 1: Создайте AGENTS.md как карту проекта

Откройте папку проекта в агенте и попросите его изучить содержимое и составить файл с правилами. Следуя совету OpenAI, файл стоит держать коротким. 

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

Шаг 2: Превращайте каждую ошибку в правило

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

Со временем файл превращается в журнал реальных проблем проекта. По опыту Хашимото, такие правила почти полностью устраняют повторяющиеся ошибки.

Шаг 3: Добавьте автоматическую проверку перед завершением

Самая частая проблема агентов, по данным LangChain и Anthropic, ― преждевременное «готово». Агент пишет решение, перечитывает собственный код и считает задачу выполненной без реальной проверки. Исправить это можно правилом в промпте или настоящим хуком. В Claude Code для этого есть хуки ― команды, которые срабатывают на определенных событиях без участия модели.

Это и есть «сенсор» в терминологии Бекелер: проверка, которую модель не может пропустить или «забыть». Три шага вместе дают минимальный харнесс-инжиниринг ― карту для ориентации, накопленные правила и обязательную проверку результата.

Ограничения подхода 

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

Стоимость. Сложный харнесс расходует больше токенов и времени. В эксперименте Anthropic полный харнесс обошелся в $200 против $9 у одиночного запуска, то есть более чем в 20 раз дороже. Для небольших задач такая обвязка избыточна.

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

Безопасность. Харнесс дает модели доступ к файлам, терминалу и сети. От его настроек зависит, сможет ли агент удалить данные или отправить их наружу. Поэтому в Claude Code, Codex и других агентах предусмотрены режимы разрешений и песочницы, а в Anthropic учетные данные держат отдельно от среды, где выполняется сгенерированный код. Чем больше автономии получает агент, тем важнее эти механизмы.

Ни одно из ограничений не отменяет сам подход. Они лишь напоминают, что харнесс ― инженерная система, которую нужно проектировать под задачу, измерять и поддерживать.

Почему о харнессах будут говорить все чаще

Еще недавно ИИ-агента воспринимали как «модель плюс немного кода». Опыт 2026 года показал обратное: обвязка вокруг модели ― отдельный и большой слой продукта со своими методами, бенчмарками и исследованиями. В Claude Code это полмиллиона строк кода, а смена харнесса способна поднять агента из топ-30 в топ-5 рейтинга без замены модели.

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