pstrongКоротко:/strong SLO для AI‑агентів перетворюють розмиті очікування на продакшн‑контракт: чіткі цілі за затримкою, пороги якості, нижні межі безпеки, межі автономії та ліміти витрат, яких агент має дотримуватися, щоб залишатися увімкненим. Ми визначаємо індикатори рівня сервісу (SLI), що відбивають успішність завдань і безпеку, встановлюємо кількісні цілі та призначаємо бюджети помилок, які керують релізами й відкатами. Ми вбудовуємо ці SLO в гейти CI/CD, канарейкові політики та інструкції з реагування на інциденти, щоб зміни виходили в продакшн лише тоді, коли агент тримається під реалістичним навантаженням. Ми розглядаємо автономію як фічу, що розгортається та розширюється або звужується залежно від виконання SLO. Зі впровадженими SLO для AI‑агентів команди закривають розрив між хайпом і продакшном і зберігають надійність агентів перед користувачами./p pstrongКлючові висновки/strong/p ul liSLO для AI‑агентів мають охоплювати якість, затримку, безпеку, автономію та вартість, адже агенти поєднують міркування з виконанням інструментів./li liБюджети помилок дають командам практичний важіль випускати покращення, обмежуючи вплив на користувачів, коли агент падає нижче цілей./li liДобрі SLI поєднують офлайн‑оцінки, онлайн‑успішність завдань, спрацювання гардрейлів, частоту помилок інструментів і сигнали передачі людині./li liSLO мають керувати фічефлагами та рівнями автономії, щоб агент безпечно деградував до відмови./li liСприймайте SLO як код: інструментуйте, додавайте гейти в CI/CD, канарейкуйте за когортами та пов5яжіть із реагуванням на інциденти й відкатом./li /ul h2Що таке SLO для AI‑агентів і чому це важливо саме зараз?/h2 pSLO (цільові рівні сервісу) для AI‑агентів — це вимірювані цілі для якості, затримки, безпеки, автономії та вартості, що визначають надійну поведінку в продакшні. Традиційні SLO зосереджені на доступності та затримці; SLO агентів додатково охоплюють якість результатів і безпечне використання інструментів, адже агенти планують, викликають інструменти та вносять зміни./p pАгент, що відповідає швидко, але бронює не ту зустріч чи готує неправильне замовлення, — не є надійним. Агент, що точний, але повільний або небезпечний, також не готовий до продакшну. SLO узгоджують бізнес‑результати з вимірюваними сигналами, які ми можемо моніторити, ставити як гейти в релізах і використовувати для рішень про розширення автономії. Без SLO розгортання агентів перетворюється на некеровані експерименти, що спалюють довіру й бюджет./p h2SLO для AI‑агентів/h2 pФормулюйте SLO у термінах, зрозумілих користувачам і операторам, а тоді підкріплюйте їх SLI, які ви можете надійно збирати./p ul listrongЦілі за затримкою:/strong Кінцевий час відгуку для типових завдань плюс покрокові бюджети для планування, отримання й виконання інструментів. Користувачі відчувають p95; задайте цілі, видимі користувачам, і відстежуйте внутрішні фази, щоб знаходити вузькі місця./li listrongПороги якості:/strong Частка успіху завдань, виміряна офлайн‑оцінками та онлайн‑підтвердженнями (напр., користувач прийняв чернетку, тікет закрито без переробки). Якісні SLO мають корелювати з бізнес‑результатами, а не лише з оцінками моделей./li listrongНижні межі безпеки:/strong Максимальний рівень порушень політик, відхилень чутливих дій або спрацювань гардрейлів. SLO безпеки захищають користувачів і системи, коли автономія зростає./li listrongМежі автономії:/strong Обмеження на кількість кроків, викликів інструментів і дій із записом на завдання та на сесію користувача. SLO автономії запобігають безкінечним циклам і каскадним відмовам./li listrongЛіміти вартості:/strong Витрати на токени й інструменти на одне вирішене завдання плюс місячні бюджетні стелі на середовище або тенанта. SLO вартості захищають маржу й утримують експерименти в межах./li listrongЦілі стабільності:/strong Рівні успішного відновлення з контрольної точки та ідемпотентного повторення для частково виконаної роботи. Такі SLO роблять довготривалі процеси стійкими й безпечними до повторів./li /ul h2Які SLI відстежувати, щоб ці SLO працювали?/h2 pSLI (індикатори рівня сервісу) мають бути спостережними, атрибутованими та придатними для рішень. Обирайте індикатори, які можна міряти без ручного оцінювання кожного запуску й які відображають результати для користувача./p ul listrongSLI успіху завдання:/strong Відсоток завдань, вирішених без людських правок або з мінімальними редагуваннями. Використовуйте офлайн‑набори оцінювання для калібрування, а потім підтверджуйте онлайн через підтвердження користувачів і результати в системах нижче за потоком./li listrongSLI спрацювання гардрейлів:/strong Частота спрацювань політик безпеки (напр., обробка персональних даних (PII), вихід за межі інструментів, захист від ін9єкцій підказок). Зростання цього показника — раннє попередження: зменшуйте автономію або відкочуйте зміни./li listrongSLI успіху інструментів:/strong Частка викликів інструментів, що виконуються без помилок і повертають очікувані схеми або постумови. Це ізолює міркування LLM від якості інтеграцій./li listrongSLI повторів/ескалацій:/strong Частота внутрішніх повторів, викликів запасних моделей і передачі людським агентам. Вищі значення вказують на регрес якості чи інтеграцій до того, як поскаржаться користувачі./li listrongSLI затримки:/strong p50/p95 від початку до кінця плюс затримки по фазах (планування, отримання, зовнішні API). Фазові SLI виявляють повільні кроки./li listrongSLI підґрунтя (за використання RAG):/strong Частка відповідей із цитатами, що проходять перевірки посилань. Підґрунтовані відповіді корелюють із меншою переробкою./li listrongSLI вартості:/strong Токени, витрати на інструменти та інфраструктуру на одне вирішене завдання. Відстежуйте по маршруту, по тенанту й по шляхах відмов./li listrongSLI стабільності:/strong Рівень успішного відновлення з контрольної точки та ідемпотентного повторення для довготривалих завдань./li /ul h2Як встановити бюджети помилок для агентів без ілюзії точності?/h2 pБюджети помилок кількісно визначають, скільки ненадійності ми готові прийняти, перш ніж зупинити релізи або зменшити автономію. Для агентів бюджет охоплює якість, безпеку й затримку, оскільки кожен режим відмови по‑різному впливає на користувачів./p ol listrongВиберіть первинні SLO для кожної користувацької подорожі./strong Для чернеток домінує якість; для тріажу — затримка; для дій із записом — безпека./li listrongВиражайте бюджети як ковзні вікна./strong Наприклад, невелика частка завдань на тиждень може перевищити поріг якості до того, як ми поставимо релізи на паузу. Тримайте вікна достатньо довгими, щоб згладити шум, але достатньо короткими, щоб реагувати./li listrongРозділяйте бюджети за серйозністю./strong Порушення безпеки — висока серйозність із майже нульовою толерантністю. Дозволяйте більше простору для маловпливових сплесків затримки./li listrongПов5язуйте бюджети з діями./strong Коли бюджет згорів, заморожуйте ризиковані зміни, зменшуйте рівні автономії або спрямовуйте більше трафіку на людську перевірку, доки не відновитеся./li listrongПоєднуйте офлайн‑ і онлайн‑сигнали./strong Використовуйте офлайн‑оцінки для захисту якості під час розробки, а онлайн‑SLI нехай визначають фінальний гейт, щойно буде достатньо трафіку./li /ol h2Як упровадити SLO від початку до кінця?/h2 pМи сприймаємо SLO як код і прошиємо їх крізь життєвий цикл агента: дизайн, розробку, розгортання та операції./p ol listrongІнструментуйте агента./strong Емітуйте структуровані події для кроків, викликів інструментів, підказок, відповідей, рішень гардрейлів, витрат і підтверджень користувачів. Нехай ідентифікатори трас проходять крізь зовнішні системи, щоб ви могли поєднати результати з прогонами агента./li listrongВизначайте SLI в коді./strong Обчислюйте SLI зі стримів подій і зберігайте їх із версійованими визначеннями. Зміна SLI — це pull‑request, а не нотатка з наради./li listrongГейтте релізи SLO./strong У CI запускайте офлайн‑оцінки, прив5язані до ваших SLO якості. У проміжних середовищах дублюйте трафік або запускайте канарейку на малій когорті й блокуйте промоушн, якщо SLI деградують. Розширте пайплайн збірки перевірками змін SLO перед злиттям./li listrongКанарейкуйте за ризиком і можливостями./strong Починайте з автономії лише для читання та обмежених когорт. Розширюйте права на запис і когорти лише тоді, коли SLO тримаються на репрезентативних навантаженнях./li listrongАвтоматизуйте безпечну деградацію./strong Коли SLI дрейфують, автоматично перемикайте моделі, звужуйте межі інструментів, зменшуйте ліміти кроків або передавайте на людську перевірку, доки бюджет помилок не відновиться./li listrongПід5єднайте до реагування на інциденти./strong Піднімайте пейджер на порушення меж безпеки, відкривайте тікети за стійких падінь якості та додавайте плейбуки, що спершу зменшують автономію, а за потреби відкочують код./li /ol pДля детальнішого розбору гейтів релізів і канарейок див. наш практичний плейбук у a href="/blog/ci-cd-for-ai-agents"CI/CD для AI‑агентів: продакшн‑пайплайн, що тримає/a. Про операційний бік, коли SLO просідають, ми розповідаємо про on‑call і відкати в a href="/blog/ai-agent-incident-response"Реагування на інциденти з AI‑агентами: плейбуки, on‑call та відкат/a./p h2Які цілі доречні на кожному етапі зрілості?/h2 pЦілі SLO мають еволюціонувати зі зрілістю, бо якість сигналів і вплив на користувача змінюються зі масштабом./p ul listrongПрототип:/strong Фокус на проходженні офлайн‑оцінок і тестах гардрейлів безпеки. Затримка гнучка; автономія обмежена й лише для читання. Успіх — стабільне покращення на кураторських наборах оцінок./li listrongТіньовий режим:/strong Додайте онлайн‑SLI з дзеркального трафіку. Ставте консервативні пороги якості й жорсткі межі безпеки. Цілі за затримкою та вартістю формуються з реальних навантажень./li listrongОбмежений GA:/strong Зафіксуйте користувацькі SLO якості та затримки для конкретних подорожей. Тримайте людину в циклі для ризикованих дій. Виконуйте бюджети помилок і розширення канарейок, прив5язані до досягнення SLO./li listrongШирокий GA:/strong Підтягуйте цілі за затримкою та вартістю, підвищуйте пороги якості зі зростанням даних. Розширюйте автономію лише для когорт і маршрутів, що підтримують SLO на ковзних вікнах./li /ul h2Як SLO керують автономією, інструментами та витратами?/h2 pАвтономія — це прапорець фічі під час виконання, а не бінарний перемикач. SLO визначають умови для безпечного розширення або звуження./p ul listrongСтелі кроків та інструментів:/strong Встановіть максимальні ліміти кроків і викликів інструментів на завдання. Підвищуйте їх, коли якість тримається, а спрацювання гардрейлів низькі./li listrongПрава на запис як віхи:/strong Розблокуйте дії із записом (надіслати лист, оновити запис, зробити замовлення) за окремими SLO безпеки й успіху завдань. Якщо бюджети безпеки згорають, повертайтеся до режиму лише чернеток./li listrongМаршрутизація з урахуванням вартості:/strong Спрямовуйте на дешевші моделі чи кешовані шляхи, коли маєте запас за якістю; на сильніші моделі — коли наближаєтеся до мінімумів якості. Прив5яжіть вибір моделі до лімітів витрат на завдання./li listrongПлавна деградація:/strong За дрейфу SLO зменшуйте автономію, збільшуйте підтвердження та додавайте людську перевірку, доки SLI не відновляться. Деградуйте, перш ніж вимикати./li /ul h2Управління: хто відповідає за SLO і як ми їх переглядаємо?/h2 pSLO не працюють без чіткої відповідальності. Продакт відповідає за користувацькі SLO; інженерія — за SLI, застосування та бюджети помилок; ризик/комплаєнс затверджує межі безпеки та аудити. Ми документуємо відповідальних на рівні кожної користувацької подорожі й можливості інструментів./p pМи проводимо регулярні огляди SLO на публічному дашборді. Розбираємо порушення, визначаємо кореневі причини (модель, підказка, інструмент чи дані) і вирішуємо, як змінювати автономію або чи відкочуватися. Ми архівуємо всі зміни визначень SLO і бюджетів, щоб відстежувати зсуви політик щодо історії інцидентів. Гарне управління — це письмово фіксувати, хто що змінює, коли і чому, — і робити ці зміни придатними до аудиту. /p h2Типові помилки, яких слід уникати/h2 pБільшість команд спотикаються на знайомих пастках. Ми бачимо ці патерни заздалегідь і запобігаємо їм./p ul listrongРозмиті цілі якості:/strong Якщо ваша ціль — «бути корисним», ви не зможете гейтити релізи. Прив5яжіть якість до конкретних результатів, як‑от «тікет закрито без переробки»./li listrongПереобучення на офлайн‑оцінках:/strong Офлайн‑оцінки потрібні, але недостатні. Просувайтеся лише після того, як онлайн‑SLI тримаються на репрезентативних когортах./li listrongІгнорування меж безпеки:/strong Одна ризикована дія із записом може знищити місяці довіри. Розглядайте безпеку як окремий SLO з майже нульовою толерантністю./li listrongОдин глобальний SLO на всі подорожі:/strong Чернетка й бронювання мають різні пороги. Діліть SLO за подорожами користувача та типами дій./li listrongВідсутність шляху деградації:/strong Якщо автономія перемикається з «увімкнено» на «вимкнено», ви обиратимете між поганим UX і поганими інцидентами. Спроєктуйте ступені зниження заздалегідь./li listrongПриховані витрати:/strong Якщо ігнорувати витрати на завдання, покращення якості можуть тихо знищити маржу. Відстежуйте й обмежуйте SLI вартості до масштабування./li /ul h2Як Moai Team підходить до цього/h2 pМи починаємо з важливих користувацьких подорожей і пишемо SLO так, щоб і продакт‑менеджер, і SRE однаково їх читали. Ми визначаємо SLI зі схемами, готовими до SQL, інструментуємо агента для трасованості та версіонуємо SLO як код. Ми вбудовуємо SLO‑гейти в пайплайн збірки й запускаємо канарейок за можливостями, а не лише за відсотком трафіку, тож автономія зростає лише там, де вона тримається./p pМи прив5язуємо бюджети помилок до дій. Коли бюджети згоряють, автоматизація спершу зменшує автономію, а далі переходить до відкату, якщо якість чи безпека не відновлюються. Ми узгоджуємо плейбуки інцидентів, дашборди та політики релізів із цими бюджетами, щоб операції були передбачуваними. Результат — чіткий, примусовий контракт для агентів, що закриває розрив між хайпом і продакшном./p h2Поширені запитання/h2 pstrongУ чому різниця між SLO та SLA для AI‑агентів?/strong/p pSLO — це внутрішні цілі, що спрямовують інженерні рішення; SLA — договірні гарантії для клієнтів. Ми використовуємо SLO, щоб вирішувати, коли випускати, канарейкувати або зменшувати автономію. Якщо публікуєте SLA, встановіть його нижче своїх SLO, щоб зберегти запас безпеки в продакшні./p pstrongЯк вимірювати «якість» AI‑агента без людського оцінювання кожного запуску?/strong/p pПоєднуйте офлайн‑набори оцінювання з онлайн‑проксі, що відображають реальні результати. Онлайн — підтвердження користувачів, перевірки в нижніх системах і частка переробок; офлайн — підтримуйте кураторські завдання з очікуваними виходами. Калібруйте проксі періодичним людським переглядом, щоб сигнали залишалися надійними./p pstrongЯк часто слід перекалібровувати SLO для агента?/strong/p pПовертаються до SLO, коли змінюються навантаження, суміш моделей, набір інструментів або очікування користувачів. Більшість команд спочатку переглядає щомісяця, а потім щокварталу, коли агент стабілізується. Будь‑яка суттєва зміна автономії чи прав на запис має одразу запускати переоцінку SLO./p pstrongЧи сповільнюють SLO ітерації агента?/strong/p pSLO пришвидшують безпечні ітерації, бо прояснюють, що таке «достатньо добре для релізу». Команди припиняють сперечатися про відчуття й випускають, щойно SLI досягають цілей. Бюджети помилок зберігають темп експериментів і обмежують масштаб наслідків регресій./p pstrongЯкі інструменти чи платформи потрібні, щоб відстежувати SLO агента?/strong/p pВикористовуйте будь‑що, що дозволяє емітувати структуровані події та надійно обчислювати SLI: трасування кроків і інструментів, сховище логів із запитами та систему метрик для алертів. Ключове — узгоджені схеми, версійовані визначення SLI та дашборди, прив5язані до гейтів релізів і плейбуків інцидентів./p pstrongЧи може мала команда вести SLO для AI‑агентів без повної SRE‑функції?/strong/p pТак. Почніть із кількох SLI (успіх завдань, спрацювання гардрейлів, затримка й вартість) і під5єднайте їх до канарейок і базових алертів. Із ростом трафіку додайте зрілість через бюджети помилок, ступінчасту автономію та on‑call плейбуки./p pemХочете SLO, які справді допомагають випускати агентів? Поспілкуйтеся з Moai Team про визначення, інструментування та дотримання вашого контракту надійності агента: a href="https://moaiteam.com/contacts"https://moaiteam.com/contacts/a./em/p