Harness Lens показує будову кодових агентів

Що саме показує Harness Lens

Тут привертає увагу не чергова вітрина моделей, а спроба впорядкувати шар, який зазвичай залишається за інтерфейсом кодового агента. У README та репозиторії Harness Lens на Hugging Face проєкт описано як інтерактивний інструмент аналізу harness-систем: Codex, OpenCode, pi, Qwen Code і Claude Code.

Одночасно можна порівнювати від двох до чотирьох оболонок. Інтерфейс розміщує поруч системні промпти, режими та інструкції з компактизації, показує кількість токенів, перетини інструментів і відмінності у можливостях. Окрема таксономія охоплює формати редагування, керування контекстом, субагентів, дозволи, інструкції проєкту, розширюваність та інтеграції з провайдерами.

Це принципово не візуалізатор ваг, карт уваги чи активацій. Harness Lens показує архітектуру агентного продукту навколо моделі: чим їй дозволено користуватися, як вона змінює файли, що отримує в системному контексті та як стискає історію. Саме цей шар часто пояснює різницю між двома агентами на одній моделі краще, ніж гарна схема нейромережі.

У проєкті також є дисципліна походження даних. Доступні матеріали описують вилучення промптів із закріплених ревізій, перевірку посилань на рядки вихідного коду та сувору валідацію схеми й таксономії. Команди extract, verify і validate стосуються цілісності даних, а не якості розв'язання завдань.

Тому було б помилкою вважати Harness Lens автоматизованим набором бенчмарків. Станом на 7 листопада 2026 року в доступних джерелах немає стандартизованих результатів щодо точності, затримки, вартості, SWE-bench чи власного pass rate інструмента. Це шар порівняльної спостережуваності та документації, а не таблиця лідерів.

Чому слід порівнювати оболонку, а не лише модель

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

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

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

Pydantic Monty показує, як безпечно запускати згенерований LLM код без контейнерів. Це доповнює Harness Lens, де поряд з експериментами з моделями важливий контроль середовища виконання.