Замініть GPT-5 на Claude у робочому агенті — і в більшості випадків поведінка майже не зміниться. Змініть спосіб обробки повторних спроб, що ви подаєте у вікно контексту або коли він вирішує зупинитися — і весь агент поводитиметься інакше. Ця розбіжність є показовою: модель — це найменша та найлегше замінювана частина робочого агента. Цікава інженерія живе у всьому, що її оточує.
Тепер у цього wrapper є назва. Практики зупинилися на слові «harness» для шару, який перетворює генератор тексту на щось, що виконує дії з часом, а не запускає фіксований скрипт. Термін швидко поширився в Twitter та інженерних блогах на початку 2026 року — що також означає, що його вживали нечітко, і те саме слово робило трохи різну роботу в кожному пості, який ви читали. Ця стаття дає точне визначення: що таке harness, з чого він складається, чим відрізняється від «framework» та «scaffold», і чому більша частина якості вашого агента захована в harness, а не в моделі.
Коротко
- Agent harness — це програмне забезпечення навколо LLM, яке керує циклом виконання, інструментами, пам'яттю, контекстом, станом, обробкою помилок та обмежувачами. Модель генерує текст; harness вирішує, що бачить модель, що вона може робити, коли зупинитися і що відбувається, коли щось ламається.
- У production виклик моделі часто є найменшою видимою частиною поверхні системи. Слабша модель у добре побудованому harness може перевершити сильнішу модель у недбалому, особливо на тривалих задачах з великою кількістю інструментів.
- Harness має приблизно від дев'яти до одинадцяти повторюваних компонентів. Більшість із них — це речі, яких модель ніколи не торкається безпосередньо.
- «Harness» — це не те саме, що «framework». Framework (LangGraph, agents SDK) — це бібліотека, за допомогою якої ви будуєте; harness — це робочий шар, який ця бібліотека допомагає вам зібрати.
Що таке Agent Harness?
Agent harness — це програмна інфраструктура навколо мовної моделі, яка керує циклом виконання, доступом до інструментів, пам'яттю, контекстом, збереженням стану, обробкою помилок та обмежувачами. Модель генерує текст. Harness вирішує, що бачить модель на кожному ходу, які дії вона може вчиняти, коли зупинитися і що відбувається, коли крок завершується невдачею.
Найчіткіше формулювання надає LangChain, зводячи це до рівняння: Agent = Model + Harness. Модель забезпечує інтелект. Обгортка — це те, що дозволяє цьому інтелекту діяти у реальному світі.
«Harness — це весь код, конфігурація та логіка виконання, які не є самою моделлю.»
— LangChain, Анатомія харнесу агента
Межу найлегше відчути через одне запитання: коли ваш агент робить щось не те, чи була неправильною власна логіка моделі, або система навколо неї передала моделі неправильний контекст, неправильні інструменти чи не залишила можливості відновитися? У більшості випадків у реальній системі це друге. Модель правильно міркувала над поганими вхідними даними. Harness контролює вхідні дані.
Ключовий висновок: Модель генерує — harness керує. Цей поділ і є суттю всієї концепції.
Які компоненти має харнес агента?
Кожен production-харнес збирає ті самі повторювані частини: цикл виконання, який веде модель хід за ходом, доступ до інструментів для дій, пам'ять між ходами, управління контекстом для поточного стану, збереження стану, щоб робота зберігалася між сесіями, обробка помилок для невдалих кроків та обмежувачі, що обмежують можливі дії. Production-системи додають цикли верифікації та оркестрацію підагентів.
Корисний перелік, складений на основі того, як практики описують реальні системи:
- Цикл виконання / керування: те, що керує агентом крок за кроком. Викликати модель, прочитати вивід, виконати запрошений інструмент, повернути результат, повторювати до умови зупинки.
- Доступ до інструментів: функції, API, виконання коду та файлова система, доступні моделі.
- Пам'ять: те, що агент зберігає між ходами та між сесіями.
- Управління контекстом: що завантажується у вікно моделі на кожному ході і що стискається при переповненні.
- Збереження стану / контрольні точки: збереження стану агента, щоб перерваний або призупинений запуск міг відновитися.
- Обробка помилок: повторні спроби, резервні варіанти та відновлення при збої виклику інструменту або моделі.
- Захисні обмежувачі: обмеження на дії агента, зокрема дозволені інструменти, ліміти кроків та валідація виводу.
- Цикли верифікації: агент (або harness) перевіряє власну роботу перед тим, як оголосити її завершеною.
- Оркестрація субагентів: запуск субагентів, делегування їм завдань та збір результатів при виконанні більших задач.
Не всі з них є універсальними. Цикл виконання, інструменти, обробка контексту та обробка помилок присутні навіть у прототипі вихідного дня. Збереження стану, верифікація та оркестрація субагентів — це те, де прототипи і виробничі системи розходяться. Прототип може їх пропустити; довготривалий виробничий агент — ні. Матеріал Anthropic про довготривалі агенти — огляд частин, характерних лише для продакшну: як агент відновлює своє розуміння з файлу прогресу після скидання контекстного вікна і як тестування вбудовується в цикл.
Для тих, хто хоче академічний місток, нещодавній огляд архітектур агентів складає ту саму механіку в менший формальний кортеж базових компонентів. Список практика і структура огляду — це два рівні масштабування однієї й тієї самої структури: огляд стискає, наведений вище список розширює. Сприймайте рахунок від дев'яти до одинадцяти як компоненти, які поділяє більшість виробничих harness, а не як ратифікований стандарт; галузь ще нічого не ратифікувала.
Ключовий висновок: Більшість рухомих частин агента знаходяться в harness, а не в моделі. Модель — один компонент серед багатьох.
Чому обв'язка важливіша за модель?
Слабша модель у добре спроектованій обв'язці нерідко перевершує сильнішу модель у погано спроектованій. Причина механічна, а не магічна: end-to-end надійність агента — це добуток надійності кожного кроку, і більшість цих кроків (вибір інструменту, збирання контексту, відновлення після помилок) — завдання обв'язки, а не моделі. Покращте їх — і вся ланцюжок стане надійнішою, незалежно від того, яка модель всередині.
Арифметика робить це конкретним. Припустимо, що кожен крок у десятикроковому завданні успішний 99% часу. Наскрізний успіх — не 99%. Це 0,99 у десятому степені, близько 90%. Підніміть кожен крок до 99,9% — і наскрізний показник стрибне приблизно до 99%. Надійність на кроці накопичується, і надійність на кроці — це переважно властивість обв'язки. Ось чому оптимізація обробки помилок та управління контекстом окупається більше, ніж заміна на модель, що на пів бала краща в якомусь бенчмарку.
Є виробничий сигнал, що вказує в тому самому напрямку. MongoDB, посилаючись на кейс Vercel, повідомляє, що Vercel скоротила більшу частину інструментів свого агента і побачила, як показник успіху різко зріс на тій самій моделі, з меншою та чистішою обв'язкою. Сприймайте це як збіжне свідчення, а не доказ: це один виробничий випадок, а не контрольований експеримент, але він вказує в тому самому напрямку, що й накопичувальна арифметика та дослідницька робота вище.
Це евристика, до якої я як інженер платформи постійно повертаюся: контекст є вузьким місцем, а не сирими можливостями моделі, і будівельні ліси, побудовані для маскування нинішніх прогалин моделі, мають тенденцію поглинатися в міру вдосконалення моделей. Будуйте довговічні частини обв'язки (цикл, стан, відновлення) і дозвольте моделі всередині вдосконалюватися за власним розкладом.
Ключовий висновок: Коли ваш агент дає збій, підозрюйте обв'язку раніше за модель. Ймовірність на її боці.
У чому різниця між обв'язкою, будівельними лісами і фреймворком?
Ці три терміни використовуються як взаємозамінні, хоча не повинні. A framework — це бібліотека або SDK, з якою ви працюєте, наприклад LangGraph або agents SDK. A harness — це працюючий шар виконання та управління навколо моделі, який фреймворк допомагає вам зібрати. A scaffold — найрозмитіший з трьох: іноді майже синонім harness, іноді його прототипна версія, іноді конкретно шар prompt і описів інструментів.
Термінологія справді не усталена, і найкраще — зафіксувати варіанти вживання, а не нав'язувати один. Глосарій HuggingFace Глосарій агентів говорить про це прямо:
«Багато з цих термінів ще не мають загальноприйнятих визначень, і різні фреймворки використовують одне й те саме слово по-різному.»
— HuggingFace, Глосарій агентів
| Термін | Що означає | Зв'язок |
|---|---|---|
| Framework | Бібліотека або SDK, з якою ви працюєте (LangGraph, SDK агентів) | Інструмент для збирання harness |
| Harness | Виконуваний шар навколо моделі: цикл, інструменти, контекст, стан, обмежувачі | Те, що ви постачаєте та запускаєте |
| Scaffold | Вживається широко: майже синонім harness, або версія рівня прототипу / шару промптів | Перетинається з harness; менш точний |
| Цикл | Цикл виконання всередині harness | Компонент harness |
Практичний висновок для міркувань про власну систему: коли хтось каже «framework», запитайте, чи має він на увазі бібліотеку або те, що виконується. Коли хтось каже «scaffold», запитайте, чи має він на увазі весь harness або лише шар prompt-and-tool. Цінність тут — усунення неоднозначності, а не претензія на останнє слово.
Як LangGraph реалізує патерн harness?
LangGraph — популярна реалізація патерну harness на Python з відкритим вихідним кодом. Вона моделює виконання агента як орієнтований граф вузлів і ребер з типізованим станом, що передається між ними, і можливістю створення checkpoint на кожному переході. Якщо абстрактні компоненти вище здаються розмитими, LangGraph — місце, де можна побачити їх у конкретній формі в реальному інструменті.
Відповідність близька до один-до-одного. Вузли і ребра — це цикл виконання: кожен вузол виконує роботу, кожне ребро вирішує, куди переходить управління. Типізований об'єкт стану, що передається між вузлами, — це компонент context-and-state, зроблений явним. Створення checkpoint-ів (LangGraph зберігає стан через savers як його реалізація на основі Postgres) — це компонент збереження стану. Налаштований ліміт кроків — це guardrail умови зупинки, що запобігає нескінченному циклу агента, що неправильно поводиться. Ті самі компоненти, названі і з'єднані конкретною бібліотекою.
Якщо ви хочете запустити агент LangGraph на власному сервері цілодобово, це питання розгортання, а не концептуальне. Дивіться наш Linux VPS guide для цього шляху. Тут LangGraph — лише опрацьований приклад: доказ того, що «цикл виконання», «збереження стану» і «guardrail» — це не абстракції, а речі, на які можна вказати в реальному коді.
Часті запитання
Що таке Agent Harness?
Agent harness — це програмне забезпечення навколо мовної моделі, яке перетворює її на агента. Воно керує циклом виконання, доступом до інструментів, пам'яттю, контекстом, збереженням стану, обробкою помилок і захисними бар'єрами. Модель генерує текст; harness вирішує, що бачить модель, що вона може робити, коли зупинитися і що відбувається при збої.
Чи є обгортка агента тим самим, що й фреймворк агента?
Ні. Фреймворк — це бібліотека або SDK, з яким ви будуєте, наприклад LangGraph або SDK агентів. Обгортка — це запущений шар виконання та управління навколо моделі (цикл, інструменти, контекст, стан та обмежувачі), який фреймворк допомагає вам зібрати. Ви використовуєте фреймворк для побудови обгортки.
Які компоненти має кожна обгортка агента?
Більшість обгорток мають спільне повторюване ядро: цикл виконання, доступ до інструментів, пам'ять, управління контекстом, збереження стану, обробку помилок та обмежувачі. Виробничі обгортки додають цикли перевірки та оркестрацію субагентів. Прототипи можуть пропустити елементи лише для продакшну, але цикл, інструменти, обробка контексту та обробка помилок зустрічаються майже скрізь.
Що означає «LLM — найменша частина вашої агентної системи»?
Це означає, що більша частина поведінки агента та його надійності походить від обгортки, а не від моделі. Наскрізна надійність — це добуток показників успішності кожного кроку, і більшість кроків є роботою обгортки. MongoDB, посилаючись на кейс Vercel, повідомляє про стрибок показника успішності лише за рахунок змін обгортки на тій самій моделі. Це доказ того, що виправлення обгортки ефективніше за виправлення моделі.
Де живе якість вашого агента
Обгортка — це місце, де зосереджена більшість якості агента, і тепер у вас є словниковий запас для пошуку проблем у власній системі. Ви можете визначити обгортку, назвати її компоненти, відрізнити її від фреймворку та скаффолду, а також міркувати про те, чи є конкретний збій проблемою моделі або обгортки.
Тому наступного разу, коли ваш агент поводиться неналежним чином, спочатку перевірте шар обгортки: контекст, який ви йому подаєте, інструменти, які ви відкрили, умови зупинки, які ви встановили, спосіб відновлення після невдалого кроку. Переходьте до більшої моделі лише після перевірки цього шару. Найчастіше це не буде потрібно.
