Harness Lens показывает устройство кодирующих агентов

Что именно показывает Harness Lens

Меня здесь цепляет не очередная витрина моделей, а попытка разложить по полкам слой, который обычно остается за интерфейсом кодирующего агента. В README и репозитории Harness Lens на Hugging Face проект описан как интерактивный инструмент анализа harness-систем: Codex, OpenCode, pi, Qwen Code и Claude Code.

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

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

У проекта есть и дисциплина происхождения данных. В доступных материалах описаны извлечение промптов из закрепленных ревизий, проверка ссылок на исходные строки, строгая валидация схемы и таксономии. Команды extract, verify и validate относятся к целостности данных, а не к качеству решения задач.

Поэтому считать Harness Lens автоматическим benchmark suite было бы ошибкой. По состоянию на 7 ноября 2026 года в доступных источниках нет стандартизированных результатов по точности, задержке, стоимости, SWE-bench или pass rate самого инструмента. Это слой сравнительной наблюдаемости и документации, не таблица лидеров.

Почему сравнивать нужно оболочку, а не только модель

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

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

Ограничение тоже ясное: хорошая прослеживаемость источников не доказывает эффективность агента. Закрепленный промпт можно проверить посимвольно, но из этого не следует, что оболочка быстрее, дешевле или надежнее в реальном репозитории. Главный нерешенный вопрос теперь звучит точнее: какие различия в harness-архитектуре действительно дают измеримый эффект?

Pydantic Monty показывает, как безопасно запускать код, сгенерированный LLM, без контейнеров. Это дополняет Harness Lens, где наряду с экспериментами важен контроль среды выполнения.