У 2026 році в індустрії ШІ з’явився новий консенсус: те, що визначає, чи буде AI-продукт хорошим чи поганим, — це більше не сам по собі модельний рівень, а те, що знаходиться поверх моделі, шар під назвою «harness». Коли Claude Code, Cursor, OpenClaw використовують дедалі ближчі за характеристиками базові моделі, реальну різницю в якості продуктів формує саме дизайн harness. Технічний блог Мартіна Фаулера, керівник продукту Anthropic trq212 та нещодавні висловлювання Андрея Карпаті — усі вказують в одному напрямку: наступне поле бою для ШІ — Harness Engineering.
Що таке Agent Harness
Агент ШІ можна розкласти на дві частини: модель (Model) і Harness. Модель — це мозок, який відповідає за розуміння мови та міркування. Harness — це все, що є поза моделлю: виклики інструментів, керування пам’яттю, збирання контексту, збереження стану, обробка помилок, захисні огорожі безпеки, планування завдань, керування життєвим циклом.
Наочна метафора: LLM — це кінь, а harness — кінська збруя: ремінці, сідло та конструкція для з’єднання з возом. Без збруї, яким би сильним не був кінь, він не зможе тягнути воза. Так само й агент ШІ: навіть якщо модель розумна, без якісного harness вона не зможе надійно виконувати реальні завдання.
Акшай Пачар у широко розповсюдженому твіті запропонував ще одну метафору: «Голий LLM — це як CPU без операційної системи — він може рахувати, але сам по собі не здатен зробити будь-що корисне». Harness — це та операційна система.
Чому в 2026 році Harness Engineering раптом стало настільки важливим
Є три причини:
Перша: можливості моделей дедалі більше вирівнюються. Розрив між GPT-5.4, Claude Opus 4.6 та Gemini 3.1 Pro у більшості тестів уже скоротився до одиниць відсоткових пунктів. Коли модель більше не є вузьким місцем, диференціація продукту природно зміщується в рівень harness.
Друга: агент переходить із експериментів у виробництво. У 2025 році більшість агентів були demo; у 2026 році агент має працювати в корпоративних середовищах — потрібно вміти обробляти відновлення після збоїв, довгі запуски, багатокрокові завдання, контроль доступу. Усе це — робота harness.
Третя: LLM за своєю природою безстатеві. Кожна нова сесія починається з нуля, і модель не пам’ятає попередньої розмови. Harness відповідає за збереження пам’яті, контексту та прогресу роботи, завдяки чому агент може безперервно працювати як справжній «колега».
Ключові компоненти Harness
Повний agent harness зазвичай містить такі шари:
Компонент Функція Аналогія Orchestration Loop Керує циклом «роздуми → дії → спостереження» в agent, контролюючи роботу головного циклу як основний цикл в операційній системі Tool Management Керує інструментами, які може використовувати agent (читання/запис файлів, виклики API, керування браузером тощо) керуючі програми Context Engineering Визначає, яку інформацію потрібно передавати моделі під час кожного виклику та яку інформацію відсікати керування пам’яттю Memory management Див. вище — керування пам’яттю State Persistence Зберігає прогрес роботи, історію діалогів і проміжні результати жорсткий диск Error Recovery Виявляє збої та автоматично повторює або відкатує назад обробка винятків Safety Guardrails Обмежує діапазон дій agent, щоб не допустити небезпечних операцій міжмережевий екран Verification Loops Змушує agent самостійно перевіряти якість виводу модульне тестування
Три рівні інженерії: Prompt, Context, Harness
Практики інженерії навколо LLM можна розділити на три концентричні шари:
Найвнутрішній шар — Prompt Engineering: проектування інструкцій, які надсилаються моделі, і визначення того, «як» саме вона міркує. Це був провідний навик у 2023 році.
Середній шар — Context Engineering: керування тим, «що» бачить модель. Воно визначає, яку інформацію й у який момент передавати в context window, а яку потрібно відсікати. Коли context window розширився до мільйона токенів, важливість цього шару почала проявлятися у 2025 році.
Найзовнішній шар — Harness Engineering: охоплює попередні два, а також всю базову інфраструктуру застосунку: оркестрацію інструментів, збереження стану, відновлення після помилок, цикли верифікації, механізми безпеки, керування життєвим циклом. Це ключове поле битви 2026 року.
Приклад: чому той самий модельний підхід у різних продуктах показує кардинально різні результати
Claude Opus 4.6 у Claude Code може за одну-дві години переписати весь кодовий репозиторій. Але якщо під’єднати ту саму модель через API до примітивного harness, вона може навіть не впоратися з виправленням багів, що зачіпають файли з різних модулів. Різниця не в моделі — різниця в harness.
Що зробив harness у Claude Code?
Автоматично знаходить у всьому репозиторії відповідні файли, а не змушує користувача вказувати їх по одному
Перед внесенням змін спочатку читає вміст файлів, а після змін запускає тести для перевірки
Якщо тести падають, автоматично аналізує помилку і повторює
Підключає зовнішні інструменти через MCP (GitHub, бази даних тощо)
Система пам’яті зберігає вподобання користувача та контекст проєкту між сесіями
Advisor-стратегія дозволяє моделям із різними рівнями можливостей працювати разом у розподіленому режимі
Усе це — заслуга harness.
Feedforward і Feedback: два режими керування harness
Згідно з аналізом у технічному блозі Martin Fowler, механізми керування harness поділяються на два типи:
Feedforward (передвісний контроль) — заздалегідь налаштовує правила ще до дій agent, щоб запобігати небажаним результатам. Наприклад: правила поведінки в system prompt, білий список інструментів, дозволи доступу до файлів.
Feedback (контроль із зворотним зв’язком) — перевіряє результат після того, як agent виконав дію, і дозволяє самокорекцію. Наприклад: виконати тести й підтвердити правильність коду, порівняти вивід із очікуваним форматом, виявити галюцинації та згенерувати знову.
Добрий harness одночасно використовує обидва типи контролю: і обмежує діапазон дій, і залишає гнучкість.
Продуктове впровадження Harness Engineering: як це робить Anthropic
Оновлення продуктів, які Anthropic дуже активно випускала в квітні 2026 року, майже всі — це продуктове втілення harness engineering:
Managed Agents — перетворює інфраструктуру harness (пісочниця, планування, керування станом) на керовану послугу, тож розробникам потрібно лише задати поведінку agent
Advisor-стратегія — архітектура змішування моделей на рівні harness, яка автоматично визначає, коли варто звернутися до сильнішої моделі
Корпоративна версія Cowork — надає повний harness (контроль доступу, керування витратами, аналітика використання) для користувачів без технічної підготовки, щоб їм не потрібно було розуміти базові технічні деталі
Формулювання керівника продукту Anthropic trq212 є найточнішим: «Prompting — це навичка спілкування з agent, але вона опосередковується harness. Моя ключова мета — збільшити пропускну здатність (bandwidth) між людьми й agent».
Значення для розробників: нова професія та нові навички
Harness Engineering перетворюється на самостійний інженерний напрям. Набір навичок, який він потребує, відрізняється від традиційної backend-інженерії або ML-інженерії:
Розуміння меж можливостей LLM і сценаріїв відмови
Проєктування надійних потоків виклику інструментів і обробки помилок
Керування context window — коли що саме вставляти
Побудова спостережуваності (observability) — відстеження траєкторій рішень agent і використання інструментів
Безпековий дизайн — обмежувати діапазон дій agent, не душачи його здібності
Для тих, хто вчиться Vibe Coding або використовує інструменти ШІ для розробки, розуміння концепції harness допоможе вам ефективніше співпрацювати з agent’ами ШІ — адже ви будете знати, чи проблема в моделі, чи в harness, і як покращити результат, коригуючи налаштування harness (а не нескінченно переписувати prompt).
Висновок: боротьба за базову інфраструктуру наступного десятиліття
Конкуренція між AI-моделями не зупиниться, але гранична користь зменшується. Конкуренція на рівні harness тільки починається — хто зможе побудувати найнадійніший, найгнучкіший і найбезпечніший harness, той і перетворить ті самі можливості моделей на кращий досвід продукту.
Це також пояснює, чому Anthropic, OpenAI і Google переходять від «компаній моделей» до «платформених компаній»: вони продають не лише API моделей, а повну інфраструктуру harness. Для розробників розуміння harness engineering — не опція, а ключова компетенція для створення продуктів у епоху ШІ.
Ця стаття «What is Harness Engineering? AI’s next battle isn’t the model, but the layer of architecture outside the model» вперше з’явилася на ChainNews ABMedia.
