Better Harness от Qoder: как проверять не код ИИ-агента, а весь процесс вокруг него

Better Harness — это открытый проект Qoder для проверки и улучшения процесса работы вокруг ИИ-агента, который пишет код. Он оценивает не один ответ модели и не отдельный diff, а среду, в которой агент действует: инструкции в репозитории, правила, инструменты, ограничения, тесты, проверки поставки и, если они доступны, записи реальных сессий. Цель — обнаружить слабое звено, предложить ограниченное исправление и затем проверить его повторным запуском. 124

По сообщениям о запуске, Qoder открыл исходный код Better Harness на GitHub 28 июля 2026 года. 5

Главное: оценивается не только модель, но и её рабочая среда

Даже сильная модель будет работать ненадёжно, если задача сформулирована расплывчато, тесты не встроены в процесс, разрешения слишком широкие, а выводы после неудачной попытки исчезают вместе с чатом. Qoder называет совокупность таких условий harness — рабочей «обвязкой» агента.

В неё могут входить инструкции репозитория, правила, навыки (skills), хуки, плагины, коннекторы, скрипты, команды тестирования, проверки релиза и этапы ревью человеком. 2 Better Harness ищет не просто файлы конфигурации, а операционные разрывы: например, тестовая команда существует, но неясно, когда агент обязан её запускать; правило есть, но агент им не пользуется; опыт неудачных задач никак не сохраняется. 145

Три уровня Better Harness

Qoder представляет проект как трёхуровневую систему, связывающую инженерные практики, модель оценки и исполнимую реализацию. 5

1. Практики Harness Engineering

Первый уровень охватывает механизмы, которые задают условия работы агента: работу с сессиями и CLI, наблюдаемость, правила, skills, конфигурацию MCP, память, хуки и автоматизацию. 5

На практике здесь возникают вопросы:

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

Проверка начинается с карты текущей обвязки: целей, контекста, точек запуска, контуров обратной связи, механизмов поставки и накопления опыта. 1

2. Оценка Agent Work Loop

Второй уровень переводит эти практики в оценку пяти связанных аспектов поставки: понимания задачи, контролируемого выполнения, валидации изменений, надёжной поставки и сохранения знаний. 14

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

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

3. Исполнимая реализация

Третий уровень нужен, чтобы практики и модель оценки не остались только методикой на бумаге. Better Harness запускается через coding-агента, собирает данные о проекте и — там, где это поддерживается, — данные сессий, после чего формирует приоритетные следующие шаги, которые можно проверить. 4

В актуальных материалах проекта заявлена поддержка десяти host-адаптеров; в публикациях о запуске среди сред были названы Claude Code, Codex, Qoder и Cursor. 56 Список интеграций может меняться, поэтому поддержку конкретной среды стоит сверять с текущей документацией адаптеров. В предоставленных источниках нет подтверждения поддержки OpenClaw.

На каких данных строятся выводы

Важная особенность подхода — разделение сбора данных и итоговой оценки. По данным Qoder, основной поток анализа сначала собирает исходные данные, затем передаёт их трём независимым подагентам в режиме только для чтения и лишь после этого объединяет результаты. 1

Используются три перспективы:

• Project Harness — инженерная основа репозитория: инструкции, скрипты, проверки и средства контроля поставки;
• Agent Customization — настройки самого агента: правила, skills, хуки и другие конфигурации;
• Session Evidence — следы того, что агент действительно делал в рабочих задачах, если такие данные доступны.

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

Почему «настроено» ещё не значит «работает»

Ключевой принцип Better Harness: само существование артефакта не доказывает его эффективности.

Допустим, в репозитории есть автотесты. Это означает, что проверка потенциально доступна. Но из одного лишь факта наличия тестового набора нельзя заключить, что агент запустил релевантные тесты после изменения, корректно интерпретировал результат и не допустил плохую поставку. То же относится к правилам, хукам, skills и этапам согласования. 15

Поэтому отчёт должен сохранять цепочку доказательств явной. Подтверждённые пробелы превращаются в приоритетные findings — выводы с описанием влияния, ожидаемого результата, границами исправления и критериями приёмки. Недостающие данные не маскируются уверенной оценкой. 46

Полезный вывод можно проверить по четырём пунктам:

1. Что именно наблюдалось в проекте, конфигурации или журнале сессии.
2. Почему это важно для полного цикла поставки.
3. Какое узкое исправление предложено: правило, skill, хук, скрипт, автоматизация или ручное согласование.
4. Как подтвердить результат после внедрения.

Цикл улучшения: проверить, исправить, измерить снова

Better Harness задуман не как разовый аудит. Его цикл выглядит так:

1. Построить карту текущей обвязки.
2. Найти разрывы процесса и пробелы в доказательствах.
3. Создать ограниченную задачу на исправление подтверждённой проблемы.
4. Проверить исправление по заданным критериям приёмки.
5. Запустить ревизию повторно и изучить обновлённые данные. 14

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

Как трактовать проверку 30 GitHub-проектов

В сообщениях о запуске говорилось о первоначальном применении фреймворка к 30 реальным проектам на GitHub. 5 Это разумно воспринимать как исследовательскую апробацию, а не как контролируемое доказательство того, что Better Harness повышает качество каждого агента или репозитория.

Первичная документация подтверждает модель работы с доказательствами, структуру findings и итеративный процесс исправлений. Но предоставленных источников недостаточно, чтобы независимо оценить отбор этих 30 проектов, протокол выставления оценок или сводные результаты. Это важно учитывать при сравнении Better Harness с формальными бенчмарками и при любых широких заявлениях о производительности. 14

Зачем это Qoder

Более широкая идея Qoder — развивать Harness Engineering как инфраструктуру качества для разработки с ИИ: с общим языком описания контролей процесса, наблюдаемыми доказательствами, сопоставимыми измерениями поставки и повторяемыми циклами улучшения. 12

Better Harness предлагает прикладную версию этой идеи. Он помогает командам обсуждать не впечатления от агента, а наблюдаемые данные; проверять условия, в которых агент работает; и смотреть, выдерживает ли предполагаемое исправление следующий запуск. Его ценность не в гарантии успеха каждого изменения, а в том, что процесс работы агентов становится проверяемым, обсуждаемым и опровержимым. 46