Інженерія керування агентами: стан, перевірка та контроль навколо моделі
Перегляд роботи агентів у продакшені в реальному часі: чому запити та контекст недостатні, і як стабільний стан, забезпечення виконання, перевірка та спостережуваність заповнюють цю прогалину.
Джерела: Agent Harness Engineering: The Runtime Architecture Behind Reliable AI Agents
Коли навіть потужна модель зазнає невдач
Уявіть агента з найкращою на ринку моделлю, ретельно налаштованим системним запитом, десятками інструментів та вікном контексту, достатньо великим для всього кодового базису. Він все одно може зазнати невдачі під час виконання завдання, яке будь-який компетентний інженер вважатиме рутинним. Він обирає правильну дію, але виконує її неправильно. Він знаходить ключову інформацію, а потім втрачає її під час скидання контексту. Він правильно редагує десять файлів, але при цьому в одинадцятому вносить непомітну регресію. Він витрачає годину на дебаггінг проблеми, яку сам створив. Він навіть може написати переконливий звіт про завершення роботи, хоча нічого не перевірив.
Звичайною реакцією є праця над запитом: ще одне завдання, ще один приклад, більше контексту, прохання бути обережним. Це допомагає деякий час, а потім більше не допомагає. Глибша проблема полягає у ментальній моделі, яка розглядає модель як агента, а все навколо неї — як налаштування. Цей підхід руйнується, коли агент мусить постійно працювати в реальному середовищі.
Агент виробництва — це не просто модель, оточена певними інструкціями. Це система часу виконання: вона зберігає стани, виконує дії, спілкується з зовнішніми системами, справляється з несправностями, отримує зворотний зв’язок та потребує способів відновлення, перевірки та керування. Дисципліна, яка формується навколо цього механізму часу виконання, називається інженерією керування агентом. Порівняйте її з роботою з інструкціями. Інженерія інструкцій стосується того, як наказати моделі поводитися, тоді як інженерія керування агентом стосується створення середовища, де модель може надійно досягати мети. Це не просто покращена інструкція — це інша абстракція, яка охоплює як те, що пише модель, так і те, що може робити система, що залишається після несправностей, що дозволено та що вважається завершеним.
Система часу виконання для стохастичної моделі
Найпростіша картина агента — це модель із запитом та кількома інструментами. Це підходить для розуміння окремого висновку, але недостатнє для продуктивного агента, якого краще розглядати як систему виконання, побудовану навколо ймовірнісної моделі.
Модель виконує міркування. Механізм керування визначає умови, за яких ці міркування перетворюються на виконання: що бачить модель, до чого вона може дістатися, які дії дозволені, який стан зберігається та які докази потрібні, перш ніж можна буде оголосити про успіх.
Візьмемо агента для програмування, чия інструкція передбачає спочатку перевірку архітектури, запуск тестів та недоторканність несуміжних компонентів. Ці рядки визначають намір, але нічого не забороняють. Інструментарій може зробити певні файли записуваними, а інші — ні, запускати перевірку після кожної зміни, блокувати заборонені операції, зберігати прогрес та відмовлятися закривати завдання без доказів. Таким чином, інструкція визначає, що має робити агент, тоді як інструментарій вирішує, що дозволить система та що вважатиметься завершеним. Модель надає інтелект, а інструментарій перетворює його на щось, з чим можна працювати.
Три рівні інженерії
Інженерія агентів пройшла три етапи все більшої абстракції: спочатку інструкції, потім контекст, а потім інструментарій.
Інженерія запитів полягає у визначенні того, що має робити модель. Вона покращує інструкції, приклади, описи інструментів та обмеження поведінки, і для простих завдань працює дуже ефективно. Однак запит є лише інструкцією та не має сили її виконати. Агенту, якому сказано проводити тести, все одно можна стверджувати про успіх без їх виконання. Вимога не чіпати файли продакшну мало що значить, якщо система надає йому необмежений доступ. Прохання запам’ятати рішення на шість годин ставить цю вимогу у конфлікт із усім іншим, що потрапляє до контексту.
Інженерія контексту вирішує наступну проблему — що саме має знати модель у момент прийняття рішення. Функції отримання інформації, навички, пам’ять, результати роботи інструментів, структурований стан, поступове розкриття інформації та її компактування сприяють створенню кращого контексту для прийняття рішень, причому мета поступово зміщується від простого наявності контексту до його покращення. Проте модель все одно може обрати неправильну дію, пошкодити стан, пропустити перевірку, застрягти в циклі чи занадто рано оголосити про успіх.
Саме тоді починається інженерія керування, з питання про те, яка система має оточувати модель, щоб завдання виконувалося надійно. Вона забезпечує те, чого не можуть самостійно надати запити та контекст: стабільний стан, обмежені інструменти, дозволи, ізоляцію, перевірку, відновлення, оцінку та можливість спостереження. Вона також змінює цикл інженерних робіт. Невдача більше не вимагає лише переформулювання запиту; вона ставить питання про те, який елемент керування бракувало, а відповіддю може бути валідатор, суворіші умови використання інструментів, межі політики, контрольні точки, стратегія відновлення чи краща видимість. Кожна невдача призводить до змін у системі.
Результатом є рatchet-механізм для кріплення: спочатку виникає збій, потім брак керування, далі вдосконалюється сам кріпильний пристрій, після цього відбувається перевірка, і нарешті створюється більш міцна основа. Інженерія запитів покращує те, що повідомляється моделі, а інженерія контексту — те, що вона знає. Інженерія кріплення покращує умови, за яких працює модель, та робить систему поступово менш схильною до повторних збоїв у тому ж форматі.
Що відповідає за роботу системи
Якщо кріпильний пристрій — це система роботи, то що вона підтримує? Замість переліку запитів, інструментів, пам’яті та коду оркестрації корисніше визначити обов’язки самої системи роботи.
- Контекст визначає, що моделі потрібно знати для наступного рішення: інструкції, отриманий матеріал, навички, результати роботи відповідних інструментів та поточні спостереження.
Це не сім окремих функцій, і їх не обов’язково мусить бути сім сервісів. Разом вони утворюють контрольний цикл навколо ймовірнісної моделі. Коли цей цикл працює годинами, а не хвилинами, долаючи обмеження контексту, збої, повторні спроби та зміни працівників, архітектура починає нагадувати щось, що інженери вже добре знають — розподілену систему.
Вікно контексту — це не сховище стану
Однією з найпоширеніших помилок у проектуванні агентів є розгляд вікна контексту як пам’яті.
Це спокуслива звичка. Модель може бачити всю розмову, попередні виклики інструментів, рішення та проміжні результати, тож додавання ще інформації здається безневинним. Проте цей простір є робочою зоною, а не базою даних. Ніщо в ньому не є стабільним: перезапуск, скорочення обсягу чи процедура компактування можуть зменшити його обсяг або навіть повністю замінити його. Розширення цього простору додає ємність, але не покращує стабільності інформації.
Для агента, який працює тривалий час, авторитетний стан завдання має зберігатися в іншому місці: цілі, завершена та незавершена робота, рішення, результати, контрольні точки, результати перевірки та посилання на зовнішні ресурси. Контекст потім відновлюється на основі цього стану відповідно до потреб моделі у даний момент. Різниця проста: контекст — це те, що бачить модель, а стан — це те, що знає система.
Компактування робить це очевидним. Агент, який витратив три години на зміни в репозиторії, може накопичити сотні викликів інструментів, незавершені підходи та спостереження. Скорочення цієї історії може зробити наступний контекст придатним для використання, але узагальнення все одно є інтерпретацією того, що сталось, тому критичний стан не повинен залежати від того, що залишив компактор. Натомість цей механізм може створити новий контекст на основі стабільного стану у такому порядку: стан завдання, відповідні елементи, поточні спостереження, навички та нарешті контекст моделі.
Чекпоїнти застосовують той самий принцип під час збоїв процесів, а структурована передача даних — між агентами чи працівниками. Наступнику потрібен стан, необхідний для правильного продовження роботи, а не весь історій обміну даними з попередником. Архітектурне питання полягає у тому, яка інформація має зберігатися незалежно від контексту, і як тільки це запитання поставлено, управління контекстом перетворюється на проблему управління станом.
Довготривалі агенти — це розподілені системи
Коли агент працює годинами чи днями, звичний модель запиту та відповіді перестає функціонувати. Процес може зупинитися. Інструмент може досягти тайм-ауту. Робітник може зникнути після завершення операції, але до її повідомлення. Два робітники можуть взятися за одне й те саме завдання. Контекст моделі може зникнути на півдорозі. Усе це не є чимось екзотичним, адже це класичні проблеми розподілених систем, і система, яка працює тривалий час, потребує чітких семантик виконання для їх вирішення.
Якщо робота може існувати довше, ніж робітник, необхідно встановити обмеження щодо її власності. Лізинг дозволяє робітнику брати на себе завдання на обмежений час, а сигнали активності надають зовнішньому спостерігачеві інформацію про те, що робітник живий. Коли робітник зникає, лізинг закінчується, і інший робітник може продовжити роботу зі стабільного стану.
Повторні спроби виклику потребують ретельного підходу. Уявіть агента, який надсилає запит на розгортання, і виклик закінчується до того, як можна побачити будь-який результат. Несвідома повторна спроба може призвести до двократного розгортання. Тому інструменти агентів потребують тих гарантій, які існують у інших розподілених системах: ідентифікатори операцій, ідемпотентність, чіткі стани збою та визначений власник для керування повторними спробами.
Далі йде відновлення. Довге завдання має представлятися у вигляді стійкого прогресу, а не як розмова в пам’яті, згідно з циклом перевірки стану, виконання, спостереження, збереження та продовження. Якщо виконання зупиняється на півдорозі, система має визначити, чи можна безпечно спробувати виконати поточний крок знову, чи він вже збережений, чи частково виконаний, чи потребує компенсації. Відновлення не означає повторного виконання всього — це означає відновлення мінімального стану, необхідного для безпечного продовження. Передача обов’язків відбувається за тим самим принципом: новий працівник отримує завдання, рішення, результати роботи, стан перевірки та незавершену роботу, але не історію розмов попереднього працівника.
Це визначає основний рівень надійності. Як тільки агент може існувати довше, ніж його процес, процес більше не є одиницею надійності — надійністю є саме довготривале завдання.
Перевірка — це інша половина агентства
Агент може писати код, запускати розгортання, створювати запити до бази даних чи змінювати інфраструктуру. Створення чогось — це не те саме, що його правильне виконання, і небезпечно дозволяти агенту бути остаточним суддею щодо того, чи вдалося йому виконати завдання, наприклад у повідомленні про те, що процес автентифікації завершено та всі тести пройдені. Система керування не повинна сприймати це як доказ. Вона має запустити тести. Так само твердження про те, що сервіс у належному стані, має спричинити перевірку його стану, а не завершити завдання; крім того, міграцію даних слід оцінювати за схемою та інваріантами даних, а не за тим, як модель інтерпретує власні виклики інструментів. Впевненість агента у своєму успіху не є надійним сигналом про завершення роботи.
Саме тому у процесі виробництва використовуються три окремі ролі. Планувальник вирішує, що має бути зроблено. Виконавець виконує певні завдання. Оцінювач визначає, чи відповідає стан системи отриманим вимогам. Одна модель може виконувати всі три ролі, але їхні обов’язки залишаються окремими.
Перевірка має ґрунтуватися на тих аспектах, які можна спостерігати, і детерміністичні докази є першим варіантом там, де вони доступні: компілятори, засоби для виконання тестів, верифікатори схем, перевірки стану системи, інформація про статус розгортання, перевірки політик чи прості твердження. Оцінювання на основі моделей є корисним, коли правильність має семантичний характер, але воно потребує конкретних критеріїв, а не розпливчастих запитань про те, чи виглядає результат гарним. Тоді завершення стає властивістю самої системи, а не чимось, що стверджує модель: вимоги виконані, верифікація пройдена, необхідні елементи наявні, перевірки політик пройдені, і лише після цього завдання вважається виконаним. Іншими словами, перевірка забезпечує докази, а оцінювач читає їх, щоб вирішити, чи можна продовжувати виконання, тож оцінювач виступає у ролі датчика в замкнутому циклі зворотного зв’язку. Агент просуває процес, тоді як система забезпечує необхідні докази.
Від інструкцій до забезпечення дотримання
Агента можна попросити не робити щось, не унеможливлюючи при цьому виконання цієї дії. Фрази на кшталт „Не змінюйте продукцію“, „Пишіть лише у робочому просторі“ та „Ніколи не розголошуйте облікові дані“ є корисними, проте жодна з них не є межею безпеки, якщо середовище виконання все одно дозволяє цю операцію. Інструкції передають наміри, а забезпечення дотримання встановлює незмінні принципи.
Дизайн інструменту чітко показує цю різницю. Якщо агент отримує універсальний функціонал execute_sql(), його можливості суттєво відрізняються від можливостей агента, який має обмежений інтерфейс для читання даних. Обмежений інтерфейс дає можливість перевіряти авторизацію, верифікувати параметри, аудитувати операції та зменшувати ризик поширення наслідків. Інструменти MCP, API, файлові системи, шелли та зовнішні сервіси працюють аналогічно: модель пропонує дію, а механізм керування вирішує, чи може ця дія відбутися та за якою ідентичністю, з якими дозволами, у якому середовищі та відповідно до якої політики.
Зручне правило допомагає класифікувати обмеження за рівнем витрат:
- Якщо порушення обмеження є прийнятним, може вистачити лише інструкції.
- Якщо порушення є дорогим з точки зору витрат, необхідно додати перевірку.
- Якщо порушення є небезпечним, його потрібно обмежити на рівні входу.
Сендбоксинг додає другий вимір. Авторизація вирішує, чи дозволена певна дія. Сендбокс визначає, що станеться, якщо агент буде поводитися неналежним чином. Межі файлової системи та мережі, обмеження ресурсів та вузько спрямовані облікові дані допомагають мінімізувати наслідки неочікуваної поведінки. Більш розвинені системи також забезпечують контроль за переходами між етапами роботи, а не лише за викликом окремих інструментів. Розгортання в продакшен може залишатися недоступним, поки не пройдуть тести, стадія розробки буде у належному стані та хтось не схвалить його. Модель може запропонувати такий крок, але правила роботи визначають його законність. Це більше схоже на машину станів, ніж на довіру до рядка природної мови. Мета не в тому, щоб обмежувати інтелект, а в тому, щоб обмежити можливості та масштаб впливу.
Ви не можете керувати тим, чого не можете спостерігати
Звичайна спостережуваність стосується перевірки того, чи є сервіс у належному стані, де зростає затримка та яка з залежностей не функціонує. Системам з агентами потрібен додатковий рівень спостережуваності. Коли агент зазнає невдачі, виникають запитання про те, що саме сталося та чому саме так склалося. Що він намагався досягти? Який контекст у нього був? Які інструменти він використовував? Які правила дозволяли чи блокували ці виклики? Який стан змінився? Які докази переконали його, що завдання виконано? Це і є спостережуваність траєкторії.
Стандартні метрики LLM, такі як кількість токенів, затримка, витрати, версія моделі та вхідні/вихідні дані, є необхідними, але недостатніми, оскільки один виклик моделі — це лише окрема подія у більшому ланцюжку: намір, контекст, рішення, дія, спостереження, стан, перевірка та результат. Припустимо, агент витрачає сорок хвилин на міграцію сервісу, а потім зазнає невдачі. Інформація про те, що було використано 80K токенів, майже нічого не говорить. Корисний опис процесу може показати, що інструмент використав застарілий посібник з міграції, агент обрав устарілий API, розгортання технічно вдалося, але перевірки інтеграції провалилися, і процес відновлення спробував ту саму стратегію знову. Це справжня діагностика.
Це означає, що контекст потребує походження: способу бачити, які навички, документи, стани та результати роботи інструментів вплинули на певне рішення. Виклики інструментів також потребують причинно-наслідкового контексту, який включає крок завдання, що їх спричинив, ідентифікатор, який використовувався, політику, яка була оцінена, та наслідки. Рішення щодо політик та зміни станів також мають бути видимими, разом із діями, які увінчалися успіхом. Найбільш інформативними показниками виявляються поведінкові: частка успішного виконання завдань, помилки перевірки, успішність відновлення, передчасне завершення, відмови політики, повторювані моделі невдач, ситуації, коли потрібна допомога людини, та кількість кроків за одне успішне завдання.
Спостережуваність — це те, що доповнює механізм кріплення. Порушення має залишати щось більше, ніж просто запис у журналі. Його траєкторія повинна дозволяти класифікувати причину проблеми та визначити відсутній елемент керування — чи то джерело контексту, оцінювач, політика, межі інструменту, контрольна точка чи стратегія відновлення. Метою є система, яка не може зламатися так само двічі.
Нова дисципліна систем
Якщо запитати, як зробити агентів кращими у роботі, відповідь стає ширшою з ростом автономії. Інженерія запитів налаштовує інструкції. Інженерія контексту налаштовує інформацію, доступну під час прийняття рішень. Інженерія кріплення налаштовує всю траєкторію виконання: стан, дії, межі, зворотний зв’язок, відновлення, перевірку та спостережуваність. Вони не замінюють одна одну, а є все більш широкими сферами застосування.
Корисний розподіл обов’язків є основою всього механізму: модель відповідає за міркування в умовах невизначеності, а час виконання — за збереження інваріантів. Файл, який ніколи не повинен змінюватися, має власні межі у файловій системі. Продуктивна система, яку не можна переписувати, проходить перевірки авторизації. Міграція, яка мусить вдатися, перевіряється за результатом досягнутого стану, а стан завдань, який має зберегтися після перезапуску, фіксується. Гарантії того, що час виконання зможе надавати послуги більш надійно, не слід вимагати від моделі.
Агенти виробництва будуть зазнавати невдач, і ознакою зрілої системи є те, як вона реагує на це. Кожна невдача впливає на процес виконання. Якщо та сама помилка продовжує траплятися, для неї створюється окремий механізм оцінки. Якщо певна дія виявляється ризикованою, можливості, які за нею стоять, звужуються. Якщо прогрес втрачається, з’являється контрольна точка там, де він був відсутній, а якщо спроби відновлення продовжують провалюватися, починає діяти політика ескалації. Виконання створює докази, ці докази виявляють відсутні механізми контролю, а ці механізми роблять наступну спробу виконання більш надійною.
Це також змінює спосіб оцінки агентів. Питання більше не полягає у тому, наскільки хороший модель, а у тому, наскільки надійно весь системний комплекс виконує цей тип завдань. Інженерія керування — це не ще одна платформа для оркестрації. Це системна дисципліна, спрямована на забезпечення надійності ймовірнісного інтелекту. Демонстрація доводить, що агент може щось зробити один раз. Проте продуктивна система мусить робити це надійно, підлягаючи перевірці, з можливістю відновлення та багаторазово, причому кожна несправність має покращувати наступну спробу. Більша частина найскладніших завдань залишається поза межами самого запиту — у архітектурі стану, зворотного зв’язку, перевірки, відновлення та контрольних циклів, які перетворюють міркування агента на стабільну поведінку системи.