
Не кожна компанія може або повинна створювати власну передову мовну модель штучного інтелекту. Однак, система управління (harness), яка контролює модель, є тим, що більшість підприємств можуть і повинні налаштувати відповідно до своїх специфічних потреб.
Звісно, це легше сказати, ніж зробити. Системи управління агентами досі здебільшого налаштовуються через ручне, несистематичне налагодження — процес, який сильно покладається на інтуїцію, а не на систематичні цикли зворотного зв’язку, що ускладнює підтримку темпу швидкозмінних великих мовних моделей (LLM).
Для вирішення цієї проблеми дослідники з Лабораторії штучного інтелекту в Шанхаї представили “Self-Harness” — нову парадигму, в якій агент на основі LLM систематично вдосконалює власні правила роботи. Аналізуючи власні траєкторії виконання для внесення змін, система замінює ручне вгадування емпіричними доказами.
Системи управління, що самовдосконалюються, можуть дозволити командам розробників розгортати надійних кастомних агентів, які постійно адаптують власні протоколи виконання для подолання слабких місць, специфічних для моделі.
Виклики інженерії систем управління
Продуктивність агента на основі LLM визначається не лише базовою моделлю, але й його системою управління (harness): навколишньою системою, яка надає контекст та дозволяє моделі взаємодіяти з середовищем. Система управління включає такі компоненти, як системні підказки, інструменти, пам’ять, правила верифікації, політики виконання, логіку оркестрації та процедури відновлення після збоїв.
Цей шар є критично важливим, оскільки багато типових збоїв агента виникають через систему управління, а не саму модель. Наприклад, агент може повідомити про успіх, не перевіривши відповідь моделі (наприклад, виконання коду для перевірки проходження тестів), або він може багаторазово повторювати невдалу дію. Система управління також відповідає за запобігання деградації контексту або перевантаженню, коли історія взаємодії агента стає дуже великою. Прикладами популярних систем управління є SWE-agent, Claude Code, Codex та OpenHands.
Інженерія систем управління залишається значним викликом, але вузьким місцем не обов’язково є те, що люди надто повільні або нездатні.
Насправді, Ханфан Чжан, провідний автор статті про Self-Harness, повідомив VentureBeat, що «у багатьох випадках досвідчений інженер з глибокими знаннями предметної області все ще може запропонувати кращі зміни, ніж LLM сьогодні».
Натомість, справжнім вузьким місцем ручної інженерії є те, що вона значною мірою покладається на вибіркове налагодження, а не на перевірений, емпіричний цикл зворотного зв’язку. «Глибша проблема полягає в тому, що поточна парадигма інженерії систем управління часто позбавлена систематичного циклу зворотного зв’язку», — пояснив Чжан. «Багато правок робляться на основі інтуїції, кількох спостережуваних збоїв або вибіркового налагодження».
З огляду на швидкий випуск нових моделей, залежність від людської інтуїції для ручного налаштування специфічних для моделей систем управління стає все більш дорогою та нежиттєздатною. Хоча деякі підходи використовують сильніші моделі для покращення систем управління слабших цільових агентів, ця залежність від зовнішнього керівництва має свої виклики, оскільки ці моделі можуть бути дорогими, недоступними для передових моделей або невідповідними до режимів збоїв цільової моделі.
Як працює Self-Harness
Парадигма Self-Harness дозволяє агенту на основі LLM вдосконалювати власну систему управління без залучення інженерів-людей або сильніших зовнішніх моделей.
Ця безперервна самостійна еволюція керується триетапним ітеративним циклом, який перетворює поведінкові докази на оновлення системи управління:
-
Виявлення слабких місць: Починаючи з початкової системи управління, агент виконує набір завдань, створюючи траєкторії виконання з верифікованими результатами. Агент класифікує невдалі траєкторії та намагається виявити патерни збоїв, специфічні для моделі.
-
Пропозиція змін до системи управління: На основі цих патернів збоїв агент використовує роль “пропонента” для генерації набору різноманітних, але мінімальних модифікацій системи управління, кожна з яких пов’язана з конкретним механізмом збою, щоб уникнути надто загальних виправлень.
-
Валідація пропозицій: Система оцінює кандидатні модифікації за допомогою регресійних тестів. Редагування просувається лише в тому випадку, якщо воно покращує продуктивність, не спричиняючи вимірюваної деградації на завданнях, що не брали участі в навчанні. Якщо кілька кандидатних модифікацій проходять регресійні тести, вони об’єднуються в наступну версію системи управління, яка потім слугує відправною точкою для наступної ітерації.

Щоб проілюструвати, чому це потрібно підприємству, уявіть собі автоматизованого агента для виправлення проблем, який читає внутрішню документацію, пише патчі та відкриває пул-реквести. Якщо компанія оновлює стиль своєї документації, агент може раптово вийти з ладу, витягуючи неправильний контекст або пишучи погані патчі.
На перший погляд, агент просто виглядає зламаним. Але Self-Harness перетворює цей неоднозначний збій на вирішувану проблему. «Траєкторії збоїв виявляють, де агент неправильно використовує новий формат документації; пропоненція може згенерувати цільову правку системи управління… і оцінювач може вирішити, чи покращує ця правка випадки збоїв, не спричиняючи регресії в інших випадках», — сказав Чжан.
Self-Harness у дії
Дослідники оцінили Self-Harness на Terminal-Bench-2.0, бенчмарку, який тестує загальне виконання з використанням інструментів, включаючи управління артефактами, використання команд, поведінку верифікації та відновлення після помилок виконання. Вони застосували Self-Harness з MiniMax M2.5, Qwen3.5-35B-A3B та GLM-5.
Щоб ізолювати вплив самостійно еволюціонуючої системи управління, вони почали з мінімальної системи управління, побудованої на SDK DeepAgent, що містила лише системний промпт, орієнтований на бенчмарк, та стандартні файлові системи та інструменти оболонки. Базова модель, набір інструментів, середовище бенчмарку та оцінювач залишалися незмінними, тоді як змінювалася лише система управління.
Кількісні результати показують, що агенти покращили свою продуктивність за допомогою автоматизованих правок системи управління. На завданнях, що не брали участі в навчанні, продуктивність значно зросла в усіх сферах, коливаючись від 33 до 60 відсотків відносного поліпшення для різних моделей.

Важливо, що явне правило прийняття просуває лише ті редагування, які покращують продуктивність, не вносячи неприйнятних регресій. Те, що робить Self-Harness потужним для корпоративних додатків, це те, що він не просто робить промпт довшим або додає загальні інструкції. Натомість, він вносить цілеспрямовані зміни, які відображають повторювані проблеми, з якими стикається кожна модель під час виконання.
Наприклад, під базовою системою управління MiniMax M2.5 застрягав, нескінченно досліджуючи конфігурації наборів даних, поки середовище виконання не вичерпало час, не виробляючи жодних результатів. За допомогою Self-Harness система визначила цей конкретний недолік і внесла “переривач циклу” до своєї політики виконання, змушуючи агента зупинитися і перенаправити свій підхід після 50 викликів інструментів. Вона також додала правило для якомога раннього створення початкової версії необхідних артефактів.
З іншого боку, Qwen-3.5 мав тенденцію до помилки перезапису файлу, а потім сліпо повторював ту саму команду, зрештою видаляючи необхідні файли через плутанину, перш ніж зупинитися. Самостійна система управління виправила це, впровадивши сувору дисципліну повторного виконання команд (забороняючи точні дублікати команд) та механізм, який змушував агента негайно відтворювати будь-які відсутні артефакти, якщо виникала помилка файлу.
GLM-5 мав труднощі зі збереженням змін середовища між різними командами і часто витрачав час на масивні завантаження або завершував завдання, навіть коли перевірки справності не проходили. Його самостійно створена система управління впровадила правила, що інструктують агента зберігати змінні PATH між сесіями оболонки, обмежувати зовнішні обчислення та виправляти будь-які невдалі перевірки справності перед завершенням роботи.
Приховані витрати автоматизованих систем управління
Хоча Self-Harness автоматизує кропітку роботу з відстеження специфічних збоїв моделі, керівникам необхідно реалістично оцінювати компроміси. Заміна людської інженерії автоматизованими спробами та помилками вимагає значних обчислювальних витрат.
«Self-Harness замінює частину людського інженерного навантаження повторною генерацією пропозицій, паралельною оцінкою кандидатів та регресійним тестуванням», — сказав Чжан. «Це може означати більше токенів API, більше затримок під час оптимізації та більше інфраструктури для виконання завдань оцінки».
Крім того, ця система покладається на точність свого конвеєра оцінки. Під час експериментів на Terminal-Bench-2.0 дослідники покладалися на суворі, детерміновані верифікатори, щоб гарантувати, що правки агента були справді корисними. Без цієї ретельної істини автоматизована система ризикує просувати погані оновлення. «[Система] оцінки не є необов’язковим компонентом; саме вона дозволяє нам обміняти людську інтуїцію на емпіричні докази», — сказав Чжан.
Ця залежність від суворих верифікаторів також визначає, де слід розгортати Self-Harness. «Найкращі цілі розгортання сьогодні — це середовища, де збої можна виміряти, і де спроби та помилки є відносно безпечними», — сказав Чжан, вказуючи на кодування, автоматизацію внутрішніх робочих процесів та конвеєри даних DevOps як ідеальні випадки використання.
Навпаки, підприємства повинні уникати повної автоматизації систем управління у сферах з високими ставками або суб’єктивних областях. «Найчіткішими червоними прапорцями є домени, де оцінка є суб’єктивною, відкладеною, недетермінованою або дорогою, якщо помилитися, як-от прийняття медичних рішень, критично важлива інфраструктура безпеки або юридичні рішення».
Від налаштовувачів промптів до архітекторів зворотного зв’язку
Впровадження агентів, що самовдосконалюються, не означає, що процес кодування або корпоративні робочі процеси раптово стануть безлюдними. Якість співпраці між інженером-людиною та ШІ все ще є першочерговою і важко вимірюваною за допомогою автоматизованих бенчмарків.
Натомість, інженерна професія піднімається на рівень абстракції. «Роль інженерів підприємства зміститься від ручного виправлення окремих промптів або викликів інструментів до проектування систем зворотного зв’язку, які роблять можливим вдосконалення агентів», — прогнозував Чжан. У майбутньому «інженер стає менш налаштовувачем промптів і більше архітектором зворотного зв’язку».
У міру того, як фундаментальні моделі стають потужнішими, вони природним чином поглинуть багато можливостей, які зараз вимагають ручної інженерії систем управління. «Але коли це станеться, система управління не зникне; її сфера діяльності зміститься назовні, щоб зв’язати модель з більш багатими зовнішніми середовищами», — сказав Чжан. «Доки ця межа не вийде за межі того, що люди можуть оцінити, люди залишатимуться критично важливими постачальниками зворотного зв’язку».
Як захиститися (Порада CryptoDom): Ретельно перевіряйте всі оновлення програмного забезпечення та налаштувань, особливо якщо вони пов’язані з автоматизованими системами або AI. Використовуйте надійні інструменти моніторингу безпеки для виявлення незвичайних дій або потенційних спроб втручання.
Оригінал статті: venturebeat.com
