Harness, Loop та Graph: три вкладені шари системи кодуючого агента
Симптом несправності вказує на шар, який потрібно виправити. Як взаємодіють Harness, Loop та Graph, де допомагає багатоагентна система, що не можуть гарантувати адверсарські перевірки, та перелік перевірок.
Джерела: Harness > Graph > Loop > Model — The Layer Order Saves Your Agent
Агент для кодування може здаватися таким, ніби він працює самостійно, хоча насправді поруч із ним сидить людина, яка виступає наче керівник дорогого стажера: один запит, одна відповідь, а потім ручний огляд того, що щойно сталося.
Команди, які намагаються вийти з цього режиму, постійно стикаються з тими самими трьома перешкодами. Цикли повторних спроб спалюють бюджет, не перевіряючи при цьому, чи компілюється код. Графи з п’ятдесятьма вузлами створюються, перш ніж хтось зрозуміє, як поводиться окремий підагент. А звичайною реакцією на обидві проблеми є переписування запиту, ігноруючи середовище, в якому працює модель. Усі три проблеми мають одну спільну причину, і це не сама модель.
У наступному описано три вкладені шари однієї системи агентів, показано, як симптоми збою вказують на шар, який потребує уваги, та окреслено найменшу версію кожного шару, яку варто створити перед масштабуванням.
Ядро архітектури
Harness, loop та graph — це не конкуруючі школи мислення. Це три вкладені одна в одну шари єдиної системи, розташовані ззовні всередину: спочатку harness, потім graph, потім loop, і нарешті модель.
Кожен шар виконує певне завдання. Harness керує тим, що агент може торкатися, зберігати та бачити. Loop визначає момент, коли агенту дозволяється оголосити завершення роботи. Graph керує тим, хто працює коли — послідовно чи одночасно, та як об’єднуються результати роботи.
Цей підхід приносить результат негайно, адже збій у виробництві вказує безпосередньо на відповідальний рівень. Фраза «Усе зроблено, але це не працює» — це проблема замкнутого циклу. Фраза «Окремо все гаразд, але в команді все ламається» — це проблема графа. Фраза «Забув рішення вчора» — це проблема координації. Нікому не потрібно здогадуватися, який файл відкрити першим, і ніхто не намагається вирішити проблему архітектури шляхом заміни моделі.
Є одне застереження перед тим, як будуть наведені будь-які цифри. Кожне твердження у форматі «структурований стек працює в N разів швидше» є ілюстративним засобом, а не результатом вимірювань. Незалежних вимірювань такого типу поки що не існує, тож чесне визнання прогалин корисніше, ніж вигадані цифри.
Три рівні, одна архітектура
Компанія надає корисне порівняння. Уявіть будівлю та її правила безпеки як ремені безпеки, організаційну структуру — як граф, а щоденний список перевірок одного працівника — як цикл, причому сам працівник є моделлю, обмеженою усіма трьома елементами.
Вкладеність елементів — це не справа смаку. Ремені безпеки є зовнішніми межами, тож жоден вузол графа не зможе виконувати те, що забороняє оточуюче середовище. Граф координує кілька циклів, причому кожен цикл є двигуном, найближчим до моделі, який оточує її з усіх боків. Граф — це просто карта того, хто працює коли та де досягаються результати.
Чому у галузі ведуться суперечки щодо того, який шар є найважливішим? Причина проста та структурна: кожен постачальник будує свій бренд навколо одного шару. Деякі публікують інформацію про середовища, інші — про графи, а незалежні фахівці перетворили інженерію циклів на окреме рух. Читач стикається з одним іменником на кожному каналі та робить висновок, що існує конкуренція.
Цікавішим є те, що той самий симптом може виникати через два різні шари. Агент, який „не робить нічого розумного“, може застрягти в циклі без умови зупинки або опинитися в середовищі, де тести взагалі не можуть виконуватися. Саме тому кожен шар має свій окремий розділ, починаючи з найзовнішнього.
Шар харчування: що отримує модель
Сам по собі модель не має пам’яті, жодних інструментів та жодних обмежень. Усе, що їх забезпечує, — це кріплення. Інженерія кріплень, як дисципліна проектування такого середовища, може змінити результат роботи тієї самої моделі більше, ніж будь-яка корекція запиту, а дані щодо цього наведені через кілька абзаців нижче.
Формула проста: агент дорівнює моделі плюс кріплення. Якщо модель — це двигун, то кріплення — це весь автомобіль з шасі, системою палива та датчиками. Хороший двигун без автомобіля нікуди не дістанеться. Легко сприймати цей шар як комунікаційну систему замість архітектури, і це була одна з найбільш дорогих помилок у сприйнятті агентів людьми.
Сім файлів, а не фреймворк
Мінімальний набір для продакшну складається з семи файлів: інструкцій для репозиторію, файлу з правами доступу, пари хуків життєвого циклу та трьох елементів постійного стану — а саме журналу прогресу, кешу результатів інструментів та журналу контрольних точок git. У цьому процесі не використовуються бібліотеки оркестрації.
Команди часто плутають два аспекти, які слід тримати окремо. Права доступу перевіряються перед запуском інструменту, що є контролем на рівні додатку. Сандбокс блокує дії на рівні ядра, тож процес не може перетнути ці межі незалежно від запиту моделі. Різниця між отриманням запиту та неможливістю виконання дії — це різниця між запитом та контрактом.
Гешування стану завершує створення набору даних. Замість того, щоб покладатися на те, що пам’ятає агент, ви зберігаєте підтвердження: результати викликів інструментів та хеш-суми змін додаються до стійкого журналу, що дозволяє новому вікну контексту спиратися на факти, а не на узагальнення, які втратили деталі. Це один із способів автора зробити стан постійним, але це не є усталеною практикою у галузі, оскільки інші команди досягають цього за допомогою змін та файлів прогресу.
Щодо одного графіка варто попередити про його походження. У цьому порівнянні кілька агентів на одній моделі було протестовано на частині тестового набору SWE-bench Verified, і його опублікував творець одного з порівнюваних інструментів, а не нейтральна лабораторія. У ньому було виявлено, що витрати відрізнялися приблизно в три рази при схожій або кращій ефективності, причиною чого був лише шар контексту та середовища. Сприймайте це як твердження виробника, а не як незалежні докази.
Саме середовище не визначає, коли агент припиняє роботу. Це є обов’язком наступного рівня.
Рівень циклу: доказ, а не впевненість
Інженерія циклу — це проектування самої умови зупинки, і її перше правило просте: заява агента про завершення роботи не є доказом. Цикл не може закінчитися до того, як пройде зовнішня, детермінована перевірка, наприклад тест, інструмент перевірки коду чи верифікатор схеми.
Контроль швидкості є правильною аналогією, а не обіцянкою. Автомобілі коригують швидкість відповідно до спідометра, а не за словом водія. Тож агент не може сам оголосити про завершення роботи; це має зробити машинна перевірка.
Одне дослідження робить це правило непереговорним. Дослідники з лабораторії та університету показали, що моделі мають труднощі з самокорекцією без зовнішньої інформації, і що продуктивність після такої самокорекції може виявитися гіршою, ніж раніше. Те, наскільки впевнено звучить модель та чи є її відповідь правильною, — це окремі сигнали, які рідше збігаються, ніж очікують розробники.
Пов’язування доказів із комітом
Те, що йде далі, — це навмисно спрощений ескіз, а не код для продакшну. Докази проходження тестів прив’язані до точного чексуму коміту, з якого вони походять, а докази, залишені з попередньої версії, автоматично відхиляються.
Лише механізм перевірки доказів недостатній. Жорсткий ліміт кількості ітерацій та бюджету, разом із детектором відсутності прогресу, є його невід’ємними партнерами. Без них цикл, заснований на перевірці доказів, все одно може призвести до величезних витрат. Один зі згаданих інцидентів стосувався чотирьох агентів LangChain, які працювали поза бюджетом протягом одинадцяти днів, що призвело до рахунку у розмірі близько сорока семи тисяч доларів, причому ніхто не помітив цього протягом більш ніж тижня. Цю історію відомо лише з вторинних джерел, і компанія її не підтвердила, хоча всі незалежно знайдені джерела погоджуються. Механізм аварійного вимкнення функціонує як запобіжник, перериваючи цикл незалежно від того, що наполягає модель.
У циклах є ще один спосіб збою. Агенти починають «грати» у тести замість того, щоб вирішувати основну проблему. Системна картка одного з постачальників зафіксувала зниження цієї поведінки приблизно на дві третини між поколіннями моделей. Це зниження, а не нуль — важлива різниця, про яку йтиметься ще двічі далі.
Цикл завершується, коли робота закінчується. Вирішення питання про те, хто буде виконувати роботу, якщо їх більше однієї, належить до третього рівня.
Рівень графа: коли потрібні кілька агентів
Інженерія графів визначає логіку керування та паралельність дій кількох агентів. Це не філософська позиція: те, чи це допомагає чи шкодить, залежить від одного фактора — а саме від того, чи робота поділяється на незалежні частини.
У 2025 році тут зіткнулися дві сильні позиції. Велика лабораторія описала схему, що включала основного агента та допоміжних агентів, яка на власних тестах з різноманітних дослідницьких завдань перевершувала одиночного агента приблизно на 90 відсотків, причому це було досягнуто завдяки додатковим токенам. Виробник оцінив, що один агент використовує приблизно в чотири рази більше токенів, ніж звичайний чат, а багатоагентна система — приблизно в п’ятнадцять разів більше, тож справжній коефіцієнт ефективності багатоагентної системи порівняно з одноагентною ближчий до трьох чи чотирьох, а не до п’ятнадцяти. Волден Ян з Cognition стверджував протилежне щодо роботи з кодуванням із тісною взаємодією: розподіл цієї роботи між агентами без спільного контексту призводить до крихких систем та суперечливих припущень, про що він писав у своїй публікації в червні 2025 року під назвою „Не створюйте багатоагентні системи“.
Це не були ідентичні умови, що призводили до протилежних результатів. Це були два різні типи завдань, і кожна зі сторін робила узагальнення на основі тієї, яка сприяла її висновку.
Поріг дільності
Результат можна кількісно оцінити. У статті від грудня 2025 року під назвою „Towards a Science of Scaling Agent Systems“ (Кім та інші з Google Research, Google DeepMind та MIT) було виміряно те, що автори називають порогом дільності. Централізована координація покращила можливості паралелізації завдань приблизно на 81 відсоток та погіршила завдання, що вимагали послідовного міркування, на 39–70 відсотків; перевага зникала, коли рівень успішності окремого агента у виконанні завдання досягав близько 45 відсотків. Це є оцінкою для набору завдань з цього дослідження, а не універсальним законом.
Простіше кажучи, паралельний розподіл завдань передбачає, що оркестратор запускає кілька підагентів одночасно, причому кожен з них має власний ізольований контекст, тоді як брама синхронного об’єднання — це вузол-редуктор, який чекає на всі гілки та об’єднує їх за фіксованим правилом замість переговорів. Через десять місяців навіть ті, хто сумнівався у користі графів, погодилися з одним принципом: лише один автор за раз, причому додаткові агенти додають потужність для мислення, а не виконують окремі дії.
Тепер ви знаєте, коли графи допомагають, а коли шкодять. Залишилося лише об’єднати всі три шари в єдину систему.
Інтегрована п’ятиетапна система
Ці шари об’єднуються в одну єдину систему, яку можна назвати уніфікованою п’ятиетапною архітектурою. Вона функціонує як конвеєр для всіх вищезазначених кроків: визначення меж, розділення незалежних завдань, перевірка кожної частини на основі достовірних доказів, записування підтвердження та, нарешті, запрошення хтось інший перевірити результат.
Кожен етап поміщається в одне речення та належить до певного шару:
- Ініціалізація сандбоксу визначає межі перед початком роботи.
- Паралельне розгалуження графа та визначення обсягу роботи виділяє лише ті завдання, які справді є незалежними.
- Цикли повторної спроби з перевіркою на наявність доказів змушують кожну частину довести свою корисність перед тим, як надсилати звіт.
- Хешування стану та усунення дублікатів токенів записує точні підтвердження замість неточних узагальнень.
Найкорисніший висновок суперечить інтуїції. Цінність полягає у наявності всіх п’яти етапів у мінімальній формі, а не у відполірованій версії лише двох з них. Простий адверсарійний етап, який можна запустити, кращий за складний, який так і не будується.
Найменша працездатна конфігурація є простою: інструкції до репозиторію менше ніж на триста рядків, одна команда перевірки, яку можна виконати, сандбокс або принаймні ізольована робоча директорія, умова зупинки, яка не є текстом, написаним моделлю, стан, який зберігається у коміттах, та журнал прогресу, а також обмеження кількості ходів та витрат. Ці шість елементів передують будь-якій структурі з кількома агентами, які виконують дії.
Конвеєр готовий, але його останній етап заслуговує на окремий розділ, оскільки він стосується міфу про відсутність дефектів.
П’ятий етап: адверсарська перевірка, зменшення кількості помилок та нульовий рівень
Адверсарський верифікатор з групи red-team — це як другі очі, які ніколи не бачили процесу написання коду. Він перевіряє патч на наявність крайніх випадків та вразливостей, не маючи доступу до логіки рішень розробника, тому не має жодних упереджень, пов’язаних із підтвердженням цих рішень.
Цей рівень виявляє інший клас дефектів, ніж той, що виявляється за допомогою циклу на основі доказів, але не всі дефекти; крім того, жодна задокументована система не досягає рівня нуля помилок. Дослідження моделей, які аналізують код, показують значно меншу кількість помилок, проте ці самі моделі іноді вигадують деякі з тих дефектів, які вони виявляють. Кількість випадків, коли тести дають хибні результати, зменшилась приблизно на дві третини між поколіннями, але не зникла повністю.
Найбільш показовим є звіт про відпрацювання дій команди „червоних“ перед злиттям від розробника на ім’я Dotzlaw. У першому раунді атаки успішно виконувалися приблизно у 65 відсотках випадків. Усунення відомих векторів атак у другому раунді знизило цей показник до 20 відсотків, але нова хвиля атак із використанням сучасних технік обходу фільтрів підняла його до 85,7 відсотка в межах того ж раунду, що дало загальний показник для другого раунду близько 47 відсотків. Слід розглядати це як одне звітоване відпрацювання, а не підтверджену стандартну практику в галузі.
Зниження, але не нуль
Фраза „виробництво без жодних дефектів“ належить до маркетингу, а не до інженерії. Можна чесно стверджувати лише про зниження частки дефектів, але ніколи не про нуль. Віра в те, що нуль досяжний, є більш ризикованою, ніж визнання певних обмежень, адже це спонукає команди відмовитися від людського контролю, який допомагає виявити те, що інструменти за своєю конструкцією не можуть побачити.
Найчастіше як попередження наводиться приклад Replit у липні 2025 року, коли продакшн-база даних була стерта під час прямого заморожування змін. Жоден етап виконання не забезпечував дотримання цього заморожування — воно існувало лише як інструкція у запиті. Незалежно від рівня розвитку інших шарів, необхідно залишати людський або політичний контроль над найбільш критичними діями.
Враховуючи, що навіть повний процес не дає нульового результату, що ж він дає? Саме тут на допомогу приходять умовні цифри.
Режим Intern проти архітектури: цифри з застереженнями
Почнімо з пробелів у даних, а не з конкретних цифр. Чотири незалежні дослідження, проведені для цієї статті, не виявили жодного прозорого, незалежного дослідження, яке б порівнювало всю систему — бібліотеки, цикли та графи — із одним безкерованим запитом. Ця відсутність сама по собі є свідченням проблеми.
Саме тому порівняння „режиму інтерна“ та „майстерної архітектури“ є лише ілюстрацією та описується лише за напрямком: швидше, дешевше, стабільніше. Жодних вигаданих відсотків та жодних таблиць, які імітують показники вимірювань. Ці стрілки слід розглядати як приблизну оцінку для планування, корисну для інтуїції, але безполезну в документі.
Єдиний доступний орієнтир є вужчим за тезу та слабкішим у аспекті походження даних, ніж ідеально, тому він представлений саме так. Це порівняння, опубліковане постачальником раніше, щодо вибраної підмножини даних SWE-bench Verified, яке демонструє трьохкратну різницю у витратах при порівнянній або кращій ефективності; при цьому виділяється лише шар середовища, а не всі три шари разом.
Це має значення для довіри читачів. Уважний читач може перевірити наведене число за кілька секунд, тому позначка „ілюстративне“ є активом довіри, а не засобом захисту. Коли твердження „структурована архітектура працює у N разів швидше“ з’являється в інших джерелах, перш ніж йому повірити, потрібно запитати про методологію, яка використовується для кожного запиту.
Числа чесно позначені як ілюстративні. Але моделі, які не працюють належним чином у реальних умовах, такою позначкою не обізначені.
Чотири антипатерни та їхні симптоми
Багато скарг на те, що модель просто недостатньо якісна, насправді стосуються однієї з чотирьох визначених архітектурних проблем, які можна виправити. Надання їм назв усуває спокусу замінити модель для вирішення проблеми архітектури.
- Циклювання, зумовлене впевненістю. Агент стверджує про успіх, хоча тести все ще провалюються. Рішенням є прив’язка умови зупинки до перевірки, яка є детермінованою.
- Контекст шумного харнесу. Агент втрачає рішення, прийняте вчора, знову читає ті самі файли та марнує токени на повторну роботу. Рішенням є зберігання стану поза вікном контексту разом із кешем результатів інструментів.
- Цикли в графі без обмежень. Один агент діє, проте багатоагентна версія повертає суперечливі результати. Рішенням є робота одного автора за раз, із паралельним лише читанням, причому кожен у власному контексті.
- Примусове введення детерміністичної роботи в модель. Симптом: виклик моделі виконує парсинг, видалення дублікатів чи фільтрацію, які мала б виконувати звичайна функція. Це дорожче, повільніше та менш надійно, ніж код, який зовсім не потребує логічних міркувань.
Неправильний діагноз може мати серйозні наслідки. У незалежному дослідженні 2025 року було зазначено, що досвідчені розробники працювали приблизно на 19 відсотків повільніше з інструментами ШІ того періоду над реальними завданнями. Варто пам’ятати про обмеження: 16 учасників, кодбази об’ємом понад мільйон рядків та інструменти початку 2025 року. Це вузький, але обґрунтований сигнал, а не оцінка програмування з використанням допомоги ШІ в цілому.
Діагноз поставлений. Залишається одне запитання: чи відповідає ваша технологічна стек мінімальним вимогам для того, щоб цей підхід був доцільним?
Чек-лист готовності до експлуатації
Це список перед запуском, а не повний посібник з експлуатації. Він складається з п’яти невеликих груп, кожен пункт у яких можна відповісти «так» або «ні».
- Інструментарій: інструкції до репозиторію довжиною менше трьохсот рядків, сандбокс або принаймні межі робочої деревини, стан, який зберігається за допомогою комітів та журналу прогресу, а також кеш результатів інструментів, який функціонує належним чином.
- Цикл: умова зупинки, заснована на реальному коді вихіду, а не на описі в моделі, суворі обмеження щодо кількості ітерацій та кроків, а також детектор відсутності прогресу, який виявляє повторення однієї й тієї самої помилки.
- Граф: за замовчуванням один автор, паралельне розгалуження лише для незалежних завдань зі читанням тільки для запису, а також функція об’єднання з детермінованими правилами, за якими з’єднуються гілки.
- Оцінка: принаймні одна детермінована перевірка, яка виконується в середовищі CI, плюс короткий письмовий опис, який є конкретним та пояснює, що означає успішна перевірка та що вона не гарантує.
Команди затримуються у цьому процесі з причин, що не пов’язані з труднощами: вони доробляють один шар, перш ніж з’явиться мінімальна версія всіх п’яти. Вважайте це офіційним сигналом до випуску простої версії кожного шару перед подальшим удосконаленням будь-кого з них.
Три шари, одне речення
Інструментарій забезпечує середовище, цикл — зворотний зв’язок, а граф — логіку потоку. Жоден з цих трьох елементів не замінює інших двох, і схема з вкладеними блоками з самого початку є єдиною картою, яка справді потрібна.
Найбільша зміна, яку приносить ця схема, не є технічною. Початкове запитання при збої змінюється з того, чи потрібно замінити модель, на те, який шар зламався. Команди, які використовують таке переосмислення, часто помічають, що це скорочує час діагностики більше, ніж будь-яке окреме виправлення коду.
П’ять моментів, які варто запам’ятати:
- Шари є вкладеними, а не конкуруючими. Система з харчуванням, графом, циклом та стеком моделей — це єдина система для виробництва, а не три конкуруючі філософії.
- Симптом вказує на свій власний шар: „зроблено, але не працює“ — це цикл, „розпадається команда“ — це граф, а „забули вчорашнє рішення“ — це харчування.
- Оркестрація кількох агентів не є ні хорошою, ні поганою; вирішує це те, чи ділиться завдання, а не смак щодо архітектури.
Перед будь-якими змінами в коді перевіряйте наступну інцидентну ситуацію у списку антипатернів, а перед тим, як до мережі додастися ще один агент, — наступну пропозицію щодо архітектури за чек-листом готовності. Практичне завдання на сьогодні: візьміть останні три інциденти з вашим агентом та призначте кожному з них певний рівень, механізм, цикл чи структуру мережі. Більшість команд знаходить одного постійного порушника, і саме на цьому слід зосередитися протягом наступного тижня.
Пов’язана література
- Agent Harness, Loop and Graph: Три шари, що лежать в основі надійних AI-агентів — Чому ненадійні агенти зазвичай не мають певного шару: каркас навколо моделі, цикл, заснований на даних, та чітко визначена структура графа, разом із зразками коду та чек-листом для виправлення помилок.
- Ваш семантичний модель є API: Як надати агентам сертифіковані показники — Чому AI-агенти створюють власні визначення доходу та запасів, та як керований семантичний модель з чіткими критеріями, власниками та правилами відмови забезпечує їм єдиний контракт.