Агенти та асистенти ШІ

Складність: [QUICK]

Час на виконання: 30–40 хв

Передумови: Практичне використання інструментів ШІ, базова впевненість у роботі з командним рядком і базовий словник Kubernetes

Результати навчання

Порівнювати робочі процеси чату, асистента, копілота й агента за автономністю, доступом до інструментів і підзвітністю.
Проєктувати драбину делегування агентові з контрольними точками перевірки, відкатом і обмеженими дозволами Kubernetes.
Діагностувати, коли агент додає координаційні витрати, а коли асистент або скрипт безпечніший.
Реалізувати обмежене практичне оцінювання агентного робочого процесу за допомогою захищених специфікацій інструментів і критеріїв успіху.

Чому цей модуль важливий

Гіпотетичний сценарій: ваша платформна команда розглядає пропозицію щодо помічника ШІ для реагування на інциденти. Одна версія відповідає на запитання про логи, інша складає команди усунення несправностей, які має переглянути людина, а третя може обстежити кластер Kubernetes 1.35, викликати інструменти й підготувати запит на зміну. Усі три на нараді описують як «агент», тож команда починає обговорювати якість моделі ще до того, як домовитися про те, що системі дозволено робити.

Ця проблема найменування не косметична. Якщо інструмент лише підсумовує розбір інциденту, неправильна відповідь зазвичай є проблемою якості інформації. Якщо інструмент може відкривати тікети, запитувати метрики продакшену, застосовувати маніфести або ротувати секрет, те саме хибне міркування може стати операційною зміною. Інженерне питання зміщується з «чи звучала модель корисно?» на «який цикл ми створили, які дозволи ми надали і хто відповідає за рішення, коли цикл сягає ризикованого кроку?».

Цей модуль дає вам практичний словник для такого рішення. Ви розрізнятимете чат, асистентів, копілотів і агентів за формою циклу, який вони виконують, а не за назвою бренду на продукті. Ви також побудуєте безпечнішу драбину делегування для вибору мінімально корисного рівня автономності, а потім перевірите цю драбину на конкретних сценаріях, де агент або допомагає, або створює зайві координаційні витрати.

Важлива звичка — визначати робочий процес до вибору інструмента. Зріла команда не запитує, чи може вона використовувати агента всюди. Вона запитує, де делеговані дії зменшують рутину, де обмежене використання інструментів покращує зворотний зв’язок, а де перевірка людиною залишається найдешевшим засобом контролю. Ця дисципліна не дає ШІ-орієнтованій роботі перетворитися ні на страх перед автоматизацією, ні на сліпу довіру до автоматизації.

Докладніше: Про шари гарнеса, систему запису й те, як цикли агента розташовані всередині контрольованих середовищ виконання, див. Основи гарнеса.

Спектр автономності

Люди часто вживають слова чатбот, асистент, копілот і агент так, ніби вони взаємозамінні. Вони пов’язані, але це не той самий операційний шаблон. Різниця не в тому, чи модель вражає і чи інтерфейс виглядає діалоговим. Різниця в тому, хто керує циклом, який контекст надходить у систему, які інструменти можна викликати і що відбувається після того, як модель видає відповідь.

На найнижчому рівні чат допомагає вам мислити. Ви приносите запитання, вставляєте контекст, читаєте відповідь і самі вирішуєте, який крок буде наступним. Це корисно для пояснення концепції, складання нотатки чи порівняння двох варіантів. Модель може помилятися, але вона не діє, доки ви не скопіюєте її вихідні дані кудись інде. Людина залишається виконавцем циклу, тим, хто викликає інструменти, і підзвітним оператором.

Асистент допомагає в межах обмеженого робочого процесу. Він може мати сталі інструкції, доступ до схвалених документів або вузький контекст завдання — репозиторій, тікет, транскрипт наради чи runbook. Він може створювати чернетки й рекомендації з меншою кількістю копіювань-вставлянь, бо робочий процес уже надає релевантний контекст. Навіть тоді асистент зазвичай зупиняється на пропозиції чи підготовці, залишаючи виконання й схвалення людині.

Копілот — це асистент, вбудований у робоче середовище. В IDE, терміналі, редакторі документації чи консолі підтримки він може використовувати навколишній контекст — поточний файл, виділений текст, відкриті буфери, сусідній код чи нещодавні команди. Ця інтеграція створює відчуття, що він розумніший за порожнє вікно чату, але вона ж і формує пастку: локальний контекст — це не глобальне розуміння. Копілот може розуміти рядок, який ви редагуєте, але не помічати політику розгортання, ризик міграції даних чи runbook продакшену.

Агент допомагає виконувати обмежений процес. Він може тримати ціль активною впродовж кроків, обирати інструменти, спостерігати результати й вирішувати, що робити далі. Це не робить його магією й не усуває потреби в проєктуванні. Це означає, що робочий процес тепер містить цикл виконання зі станом, тож команда має визначити дозволені інструменти, умови зупинки, контрольні точки перевірки, логування й шляхи відкату.

Ця відмінність полягає передусім у структурі циклу та ступені інтеграції інструментів. Чатбот дотримується шаблону «запит–відповідь», де людина є ітеративним рушієм. Натомість агент має цикл міркування, часто реалізований за допомогою фреймворків виклику інструментів, де модель визначає, які підзадачі потрібні для досягнення високорівневої цілі, виконує їх через зовнішні API, спостерігає результати, а потім вирішує, яким буде наступний крок. Цей перехід від генерації вихідних даних до досягнення цілі змінює вашу роль із безпосереднього оператора на наглядача за обмеженим процесом.

Наведена нижче захищена траса показує форму цього циклу. Сприймайте її як трасу виконання, а не як shell-скрипт для вставляння в термінал. Модель рухається від спостереження до гіпотези й до чергового виклику інструмента, а питання безпеки — чи кожна дія є дозволеною, видимою та оборотною.

# Приклад траси виконання агента (внутрішня логіка)
THOUGHT: Pod 'api-gateway' у стані ImagePullBackOff.
ACTION: kubectl describe pod api-gateway
OBSERVATION: "Failed to pull image 'registry/api-gw:v1.2': 401 Unauthorized"
THOUGHT: Секрет реєстру, ймовірно, прострочений або відсутній у цьому неймспейсі.
ACTION: kubectl get secret regcred
OBSERVATION: "Error from server (NotFound): secrets 'regcred' not found"
ACTION: kubectl get secret regcred --namespace=shared-services
FINAL_RESPONSE: Завантаження образу не вдалося, бо 'regcred' відсутній. Я знайшов його у 'shared-services'; скопіювати його сюди?

Зверніть увагу на останнє речення траси. Безпечніший дизайн зупиняється перед мутацією і запитує схвалення, бо копіювання секрета реєстру змінює стан кластера. Слабший дизайн дозволив би агенту копіювати облікові дані між неймспейсами без перевірки політики, власності чи практики ротації секретів. Модель не стала небезпечною через те, що вжила слово «агент»; вона стала операційно значущою, бо цикл сягнув межі дії.

Зупиніться й спрогнозуйте: як гадаєте, що станеться, якщо цей самий цикл зможе виконувати kubectl apply без списку дозволених неймспейсів, контрольної точки перевірки чи журналу змін? Імовірний збій — це не просто погана відповідь. Це неконтрольована зміна в продакшені, задум якої важко відтворити заднім числом. Ось чому спектр автономності є також спектром відповідальності.

Корисна ментальна модель — це делегована відповідальність. Чат допомагає вам мислити, асистенти допомагають працювати, копілоти допомагають усередині живого середовища, а агенти допомагають виконувати обмежений процес. Кожен крок може бути цінним, але кожен крок також підвищує потребу в обмеженнях, спостережуваності, перевірці та відновленні. Команда, яка визначає ці засоби контролю рано, може впроваджувати агентів поступово, а не виявляти межі довіри під час інциденту.

Цей спектр також допомагає з рішеннями щодо закупівель і платформи. Постачальник може позиціонувати продукт як агентний, бо той може викликати інструменти, але ваш внутрішній робочий процес може використовувати лише асистентську частину цього продукту. Інший інструмент може виглядати скромно, бо з’являється в терміналі, проте він може виконувати команди, записувати файли й повторювати спроби після помилок. Класифікація за можливостями не дає команді запозичити чужий словник, не запозичивши й моделі безпеки, якої цей словник вимагає.

Той самий словник покращує комунікацію між інженерами, рецензентами з безпеки та власниками продукту. Коли інженер каже «асистент», рецензент має розуміти, що система готує чи пояснює роботу, але не завершує операційний крок. Коли хтось каже «агент», наступні запитання мають стосуватися ідентичності інструментів, меж схвалення, логів і завершення. Чітка мова прискорює перевірки, бо група може обговорювати реальний ризик, а не сперечатися про розмитий ярлик.

Доступ до інструментів змінює характер збою

Найважливіша відмінність між асистентом і агентом — не особистість чи красномовність. Це наявність інструментів, які перетворюють текст на наслідки. Модель без інструментів усе одно може ввести читача в оману, але наступну дію має виконати читач. Модель з інструментами може запитати кластер, оновити тікет, викликати API, створити pull request чи запустити робочий процес. Це змінює радіус ураження звичайних помилок моделі.

Доступ до інструментів зазвичай описують як виклик функцій (function calling), виклик інструментів (tool calling), дії (actions), плагіни чи конектори. Механізм різниться залежно від платформи, але проєктна задача незмінна. Ви надаєте моделі іменовані можливості, структуровані аргументи та описи того, коли слід використовувати кожну можливість. Навколишній застосунок отримує запитаний виклик, валідує його, виконує детермінований код і повертає спостереження для наступного кроку моделі.

Модель ніколи не слід сприймати як межу безпеки. Вона може обирати з-поміж інструментів, але саме звичайне програмне забезпечення має забезпечувати, які інструменти існують, які аргументи є дійсними, яка ідентичність використовується і які обмеження частоти застосовуються. Якщо обгортка інструмента приймає довільний shell-текст, моделі надано надто широкий інтерфейс. Якщо обгортка надає вузьку операцію на кшталт «перелічити поди в схвалених неймспейсах», агент усе одно може допомагати, залишаючись легшим для осмислення.

Технічно цей перехід спирається на структуровані архітектури виклику інструментів. Агентові надають реєстр виконуваних функцій, часто визначених за допомогою схем JSON, які він може викликати, коли його внутрішня логіка вважає це потрібним. На відміну від пасивного асистента, агент проактивно керує перетвореннями даних між цими інструментами, беручи на себе частину «клейової» роботи, яка раніше вимагала, щоб інженер-людина копіював результати з одного вікна термінала в інше.

{
  "thought": "Користувач хоче усунути несправність пода 'auth-service'. Спершу я перелічу всі поди в неймспейсі 'security', щоб визначити точну назву та стан.",
  "tool": "kubectl_get_pods",
  "parameters": {
    "namespace": "security",
    "label_selector": "app=auth-service"
  },
  "expected_outcome": "Список назв подів та їхніх поточних фаз."
}

Ця JSON-подібна траса корисна, бо відокремлює міркування від виконуваної операції. Міркування може бути неповним, але запит на інструмент усе одно можна перевірити. Чи існує цей неймспейс у списку дозволених? Чи достатньо обмежений селектор міток? Чи це інструмент лише для читання? Чи має користувач повноваження запитувати ці дані? Ці перевірки належать до детермінованого коду застосунку, а не до сподівання, що модель завжди пам’ятатиме політику.

У роботі з Kubernetes межі інструментів мають відповідати реальним операційним межам. Діагностичний помічник лише для читання може перелічувати поди, отримувати події, перевіряти стан навантаження та отримувати логи з приховуванням чутливих даних. Асистент для підготовки змін може згенерувати патч і виконати перевірку в режимі dry-run, але зупинитися перед його застосуванням. Агент з вищою автономністю може відкрити pull request, запустити тести й запитати схвалення у власника коду. Мутація продакшену має залишатися останнім щаблем, а не типовою точкою старту.

Перш ніж запускати цей уявний експеримент, вирішіть, які вихідні дані ви очікуєте від кожного виклику інструмента: чи має система повертати сирі дані кластера, підсумоване спостереження чи відредагований результат з анотаціями політики? Сирі вихідні дані дають моделі більше контексту, але можуть розкрити секрети чи зайві деталі. Підсумки знижують ризик, але можуть приховати сигнал, потрібний для діагностики. Правильна відповідь залежить від робочого процесу та класифікації даних.

Найбезпечніші команди сприймають кожен інструмент як маленький API-продукт. Він має призначення, схему вхідних даних, правило авторизації, журнал аудиту й чіткий характер збою. Якщо модель просить заборонену дію, інструмент має відмовити з корисним поясненням. Якщо інструмент вичерпує час очікування, агент не повинен нескінченно повторювати спроби. Якщо інструмент повертає неочікувані дані, агент має виявити невпевненість, а не вдавати, що спостереження підтверджує його план.

Саме тут у дизайн входять вартість і затримка. Відповідь у чаті може вимагати одного виклику моделі, тоді як цикл агента може вимагати багатьох викликів плюс зовнішні запити до інструментів. Ці накладні витрати виправдані, коли завдання має повторювану структуру й реальне збирання інформації. Вони марнотратні, коли людина вже має потрібний контекст або коли простий скрипт дав би той самий результат детерміновано. Доступ до інструментів цінний лише тоді, коли цикл виправдовує свою складність.

Дизайн інструментів також має враховувати мінімізацію даних. Читачеві логів не завжди потрібні цілі логи пода, а інструменту підсумовування тікетів не завжди потрібен кожен коментар, будь-коли написаний у проєкті. Менші відповіді інструментів знижують вартість у токенах, зменшують імовірність витоку чутливих даних у промпти й полегшують інспекцію міркувань агента. Коли інструмент може повернути сфокусоване спостереження з посиланнями на повніші докази, рецензенти отримують і безпеку, і простежуваність.

Версіонування має значення, бо інструменти стають контрактами. Якщо ви зміните інструмент з діагностики лише для читання на мутацію або розширите фільтр неймспейсів, наявні промпти та припущення щодо схвалення можуть перестати бути дійсними. Сприймайте такі зміни як зміни API: документуйте їх, перевіряйте й тестуйте на репрезентативних запусках. Несподіване оновлення інструмента може непомітно перетворити безпечний асистентський робочий процес на ризикованіший агентний.

Найнадійніші обгортки інструментів роблять недійсні запити нудними. Якщо агент просить обстежити неймспейс поза межами свого діапазону, обгортка має повернути чітку відмову за політикою, а не розмитий збій. Якщо агент просить деструктивну операцію через інструмент лише для читання, обгортка має повідомити, що ця операція недоступна. Чіткі відмови навчають цикл, де пролягають межі, і дають рецензентам-людям докази того, що забезпечення політики працює.

Асистенти, копілоти та агенти в роботі з Kubernetes

Kubernetes робить цю відмінність конкретною, бо той самий запит природною мовою може відповідати дуже різним робочим процесам. «Допоможи мені зневадити це розгортання» може означати пояснити помилку в YAML, підсумувати набір подій, підготувати безпечну діагностичну команду чи самостійно обстежити кластер. Правильний шаблон залежить від ризику, неоднозначності, доступного контексту й того, чи вимагає завдання дій у кілька кроків.

Використовуйте чат, коли робота — це дослідницьке мислення. Якщо ви вивчаєте, чому Deployment створює ReplicaSet, порівнюєте налаштування послідовного оновлення чи просите простими словами пояснити помилку, чату достатньо. Ви надаєте контекст і вирішуєте, чи відповідь підходить. Модель — це репетитор чи партнер зі складання чернеток, а не оператор із доступом до системи, яку ви обговорюєте.

Використовуйте асистента, коли робочий процес обмежений, а людина залишається інтегратором. Приклади: підсумовування нотаток про інцидент, реорганізація runbook, пояснення маніфеста, перевірка, чи опис політики зрозумілий, або складання опису pull request з відомого diff. Ці завдання виграють від підказок і контексту, але не потребують автономних дій. Асистент знижує когнітивне навантаження, не перебираючи контроль над середовищем.

Використовуйте копілот, коли головна перевага — локальний контекст. Копілот в IDE може вивести домовленості щодо найменування із сусіднього коду, запропонувати тести поряд із функцією, яку ви редагуєте, чи допомогти доповнити маніфест, поки ваші руки в редакторі. Його слабкість така сама, як і сила: він оптимізує навколо найближчого контексту. Вам усе одно потрібна перевірка для міжсервісних контрактів, політики безпеки, порядку розгортання та інших питань поза поточним вікном.

Використовуйте агента, коли робота має кілька кроків, стабільну ціль, повторювану структуру, чіткі межі інструментів і значущий зворотний зв’язок після кожного кроку. Обстеження кодової бази, пропонування патча, запуск тестів і підсумовування результату можуть вписатися в цей шаблон. Збирання артефактів для регулярного звіту про відповідність теж може підійти. Застосування фіксованої рубрики перевірки до багатьох модулів з контрольними точками — ще один розумний агентний робочий процес, бо завдання повторюється, а умови зупинки можна визначити.

Уникайте агентів, коли завдання — це переважно одноразове міркування, вимоги ще розмиті, ціна помилкової дії висока або власність людини незрозуміла. Ці умови не доводять, що агент неможливий, але означають, що дизайн процесу ще не готовий. Якщо ніхто не може сказати, що агенту можна робити, чого йому не можна робити і хто схвалює наступний крок, бракує саме керування, а не спроможності моделі.

Наведений нижче захищений приклад асистента показує обмежений допоміжний робочий процес. Він просить допомоги в генеруванні логіки фільтрації, але інженер залишається відповідальним за рішення, чи результат правильний і де його запускати. Це зовсім інший профіль ризику, ніж в агента, який може виконати запит, вивести спосіб усунення й змінити стан кластера.

# Використання асистента для генерування складної логіки фільтрації
# Завдання: перелічити всі образи, використовувані в неймспейсі 'production', відсортовані за вузлом
kubectl get pods -n production -o json | assistant-tool "Згенеруй
jsonpath, який повертає список унікальних образів контейнерів,
зіставлених із nodeName, на якому вони запущені."

Це має значення під час інцидентів, бо тиск заохочує надмірне делегування. Команда бачить повільний ручний процес і припускає, що агент має його перебрати. Іноді це правильно, особливо для повторюваного збирання доказів. Іноді краща відповідь — асистент лише для читання, який швидше готує контекст, залишаючи рішення щодо усунення командиру інциденту. Різниця не філософська; це вибір щодо стримування збоїв.

Kubernetes 1.35 також нагадує нам, що сама платформа є мінливою поверхнею API. Корисний агент має знати, проти якої версії кластера, контролів допуску, політик ресурсів і домовленостей контролерів він працює. Якщо модель спирається на застарілі припущення чи загальні поради щодо Kubernetes, валідація інструментів стає важливішою, а не менш важливою. Кластер має відхиляти недійсні ресурси, але зрілий робочий процес виловлює багато помилок ще до того, як вони сягнуть API-сервера.

Який підхід ви обрали б тут і чому: асистент, який складає пояснення NetworkPolicy, копілот, який редагує YAML поруч із вами, чи агент, який валідує політику проти staging-кластера й відкриває запит на перевірку? Найкраща відповідь залежить від того, чи ціль — навчання, редагування чи виконання повторюваного циклу валідації. Називання цієї цілі спершу не дає команді сприймати автономність як символ статусу.

Практичне викочування Kubernetes часто використовує кілька шаблонів одночасно. Чат може допомогти новому інженеру зрозуміти, чому важливі проби готовності, копілот може допомогти написати конфігурацію проби, асистент може скласти пояснення до pull request, а агент може запустити валідацію по набору сервісів. Таке поєднання є нормальним. Помилка — припускати, що один шаблон має замінити всі інші. Зріла ШІ-орієнтована робота компонує різні рівні автономності навколо ризику кожного кроку.

Те саме завдання також може рухатися вздовж спектра з часом. Під час раннього дослідження людина може вставляти логи в чат, щоб зрозуміти форму збою. Після того як команда бачить той самий збій неодноразово, вона може створити асистента, який збирає потрібні поля й складає діагноз. Якщо діагноз стає надійним, а межі інструментів вузькі, команда може згодом побудувати агента лише для читання. Робочий процес заслуговує на автономність, спершу довівши себе в безпечніших формах.

Ось чому «людина в циклі» потребує точності. Людина, яка отримує фінальну відповідь без доказів, не є значущо в циклі. Людина, яка бачить спостереження, запропоновану дію, ризик, нотатку про відкат і перевірку політики, може ухвалити реальне рішення. Якість контрольної точки важливіша за гасло. Контрольні точки перевірки слід проєктувати для швидкого осмислення, а не для церемоніального схвалення.

Проєктування обмежених циклів агента

Цикл агента слід проєктувати як маленьку площину керування. Він має вхідні дані, дозволені дії, спостереження, стан і правила завершення. Модель постачає гнучке міркування, але навколишня система постачає рейки. Без цих рейок агент може ганятися за нерелевантними доказами, повторювати дорогі виклики чи сприймати слабку гіпотезу як дозвіл діяти.

Поширений шаблон міркування іноді називають «міркуй і дій» (reason and act). Агент спостерігає ціль, міркує про наступний корисний крок, викликає інструмент, отримує спостереження й оновлює свій план. Це потужно, бо модель може адаптуватися, коли реальність не збігається з першою здогадкою. Це також ризиковано, бо кожна ітерація створює чергову можливість для дрейфу, витрат, розкриття даних чи несанкціонованої дії.

# Приклад специфікації інструмента для ШІ-агента
name: k8s_resource_validator
description: "Валідує маніфест Kubernetes проти схеми API цільового кластера."
parameters:
  type: object
  properties:
    manifest_yaml:
      type: string
      description: "Повний YAML-вміст ресурсу для валідації."
    namespace:
      type: string
      description: "Контекст неймспейсу для валідації."
  required: ["manifest_yaml"]

Добре спроєктована специфікація інструмента виконує три завдання. По-перше, вона повідомляє моделі, яка можливість існує, щоб агент міг обрати її за потреби. По-друге, вона повідомляє застосунку, як валідувати аргументи перед виконанням детермінованого коду. По-третє, вона повідомляє рецензентам, що агент міг зробити, коли вони інспектують логи після запуску. Якщо опис інструмента розмитий, усі три завдання ускладнюються.

Обмежені цикли потребують явних умов зупинки. Діагностичний агент може зупинитися після збирання подій, логів, стану розгортання й однієї гіпотези. Агент коду може зупинитися після створення патча, запуску тестів репозиторію й підсумовування збоїв. Агент звітування може зупинитися після підготовки чернетки й переліку відсутніх даних. Без правила зупинки «спробувати щось іще» стає типовою поведінкою, і система може споживати час чи змінювати стан, не підвищуючи впевненості.

Контрольні точки «людина в циклі» мають з’являтися там, де змінюється тип ризику. Читання логів і пропонування пояснення може потребувати легкої перевірки. Запис до репозиторію, відкриття зовнішнього тікета, зміна об’єкта кластера чи сповіщення клієнтів потребує сильнішого схвалення. Контрольна точка має бути частиною робочого процесу, а не додатком, доданим тоді, коли хтось починає нервувати. Хороші контрольні точки конкретні: схвалити цей патч, у цьому неймспейсі, з цієї причини, із цим шляхом відкату.

Дизайн відкату є частиною дизайну агента. Якщо агент готує патч, він також має пояснити, який попередній стан він спостерігав і як скасувати зміну. Якщо він відкриває pull request, він має включити результати тестів і будь-які команди, які не запускав. Якщо він не може визначити безпечний відкат, ця невпевненість є причиною зупинитися. Ціль — не зробити агента боязким; ціль — зробити делеговану дію придатною для інспекції.

Спостережуваність має значення, бо збої агента часто є збоями процесу. Вам потрібні логи, що показують запит користувача, обрані інструменти, аргументи після валідації, результати інструментів, відмови за політикою, схвалення й фінальні вихідні дані. Ці логи мають уникати розкриття секретів, але вони мають бути достатньо детальними, щоб відтворити шлях. Якщо рецензент бачить лише фінальну відповідь, у робочого процесу немає аудиторського сліду.

Ідемпотентність — ще одна практична вимога. Якщо інструмент створює чи оновлює ресурси, повторні спроби не повинні дублювати роботу чи залишати недороблені об’єкти. Контролери Kubernetes уже вчать цього уроку: цикли бажаного стану працюють, бо повторне узгодження має сходитися, а не примножувати побічні ефекти. Інструменти агента мають запозичити цю дисципліну. Повторна спроба має бути безпечною, або інструмент має чітко сказати, що він не придатний до повторення.

Коли ви проєктуєте агента, почніть із найменшого корисного циклу. Спершу дайте йому інструменти лише для читання, потім додайте інструменти підготовки, потім додайте дії перевірки, і лише згодом розгляньте обмежене виконання в низькоризикових контекстах. Ця драбина тримає довіру відкаліброваною. Вона також створює докази для наступного рішення: якщо цикл лише для читання не може давати надійних діагнозів, надання доступу на запис не виправить глибинного дизайну.

Керування станом є частиною цього найменшого корисного циклу. Агент має знати, яку ціль він переслідує, які спостереження належать до поточного запуску і які припущення ще не доведені. Він не повинен переносити застарілі висновки з попереднього інциденту в новий, якщо робочий процес явно не надає цього контексту. Пам’ять у межах запуску не дає агенту звучати впевнено лише тому, що він пам’ятає старий шаблон, який більше не підходить.

Обробку помилок слід проєктувати до демонстрацій успіху. Якщо інструмент повертає помилку дозволу, агент має повідомити про відхилену дію й зупинитися або обрати дозволений діагностичний шлях. Якщо інструмент валідації повертає помилку схеми, агент має пояснити поле, що не пройшло, а не вигадувати проблему кластера. Якщо мережевий виклик не вдається, цикл має уникати повторних сліпих спроб. Це звичайні питання надійності програмного забезпечення, застосовані до потоку керування, керованого моделлю.

Оцінювання має вимірювати якість процесу, а не лише фінальні відповіді. Хороший тестовий набір включає прості випадки, неоднозначні випадки, випадки з відмовою за політикою, випадки із застарілим контекстом і випадки, де правильна поведінка — зупинитися. Для кожного запуску рецензенти можуть оцінити, чи агент обрав релевантні інструменти, дотримався меж, зберіг докази й виявив невпевненість. Така форма оцінювання корисніша, ніж запитувати, чи фінальний текст звучав упевнено.

Шаблони та антишаблони

Для швидкого модуля найкорисніший шаблон — це шаблон обмеженого делегування. Оберіть стабільний робочий процес, визначте ціль в операційних термінах, надайте лише інструменти, потрібні для цієї цілі, і вимагайте контрольної точки з людиною перед змінами стану. Цей шаблон працює, бо звужує світ агента. Модель усе одно може адаптуватися всередині циклу, але система навколо неї не дає циклу стати універсальним оператором.

Другий шаблон — спочатку лише читання. Перш ніж агент зможе застосувати патч, дайте йому зібрати докази, пояснити свої міркування й створити запропоновану зміну. Перевіряйте якість цих запусків так само, як ви перевіряли б нотатки молодшого оператора. Якщо докази стабільно релевантні, а запропоновані дії консервативні, ви маєте підставу додати більше можливостей. Якщо докази зашумлені, наступний крок — кращі інструменти чи промпти, а не ширші дозволи.

Третій шаблон — підзвітність для конкретного інструмента. Кожен інструмент має мати власника, аудиторський слід, валідацію вхідних даних і задокументований характер збою. Це звучить важко для маленького прототипу, але це не дає прототипам тихо ставати шляхами в продакшен. Коли інструмент має власника, хтось може оновити його, коли поведінка Kubernetes змінюється, облікові дані ротуються чи правила політики стають суворішими.

Головний антишаблон — театр автономності. Команда загортає простий контрольний список у цикл агента, бо «агент» звучить просунуто, хоча детермінований скрипт був би швидшим, дешевшим і легшим у тестуванні. Результат — робочий процес із більшою кількістю рухомих частин і меншою передбачуваністю. Якщо завдання має фіксовані вхідні дані, фіксовані кроки й не потребує розуміння мови, напишіть скрипт і використовуйте ШІ, щоб його задокументувати чи перевірити.

Ще один антишаблон — дизайн «спочатку дозволи». Команда надає широкий доступ, щоб агент «розібрався сам», а потім намагається додати безпеку через інструкції в промпті. Це перевертає правильний порядок. Дозволи мають випливати з потреб робочого процесу, а не з цікавості моделі. Промпт може просити обережності, але авторизацію має забезпечувати шар інструментів, система ідентичності й політика середовища.

Тонший антишаблон — пасивне прийняття копілота. Користувач отримує правдоподібну пропозицію в редакторі й приймає її так, ніби інструмент оцінив усю систему. Копілоти чудові в локальному прискоренні, але вони не є автоматично рецензентами, архітекторами чи менеджерами релізів. Краща альтернатива — сприймати вихідні дані копілота як чернетку: інспектувати її, тестувати й проганяти той самий процес перевірки, який ви застосували б до змін, написаних людиною.

Останній антишаблон — невидима робота. Агент, який збирає дані, ухвалює рішення й повідомляє лише відшліфовану фінальну відповідь, може здаватися ефективним, але залишає рецензентів нездатними відрізнити докази від висновку. Безпечніший агент повідомляє важливі спостереження, відхилені варіанти, обмеження політики й залишкову невпевненість. Прозорість — це не зайва паперова робота; це те, як команда вирішує, чи делегування заслуговує на довіру.

Ще один корисний шаблон — оборотна підготовка. Дайте агенту виконувати роботу, що створює придатні для перевірки артефакти: патч, чернетку звіту, підсумок результатів тестів чи запропоноване оновлення runbook. Ці артефакти можна інспектувати, обговорювати, змінювати й відхиляти, не торкаючись продакшену. Оборотна підготовка перетворює гнучкість мовної моделі на звичайний матеріал для інженерної перевірки — а це саме та сфера, де в команд уже є сильні звички.

Ще один антишаблон — сприймати схвалення як єдиний широкий дозвіл. «Ти можеш полагодити кластер» — надто розмито, щоб бути безпечною контрольною точкою. Краще схвалення вузьке й контекстне: «ти можеш відкрити pull request, який змінює цей маніфест, для цього сервісу, на основі цього результату валідації». Вузькі схвалення зменшують неоднозначність для агента й знижують навантаження на перевірку для людини, бо дозволену дію легко верифікувати.

Рамка ухвалення рішень

Почніть із форми завдання. Якщо запит — це одноразове пояснення, використовуйте чат або простий асистент. Якщо завдання потребує локального контексту, але людина редагує й перевіряє, використовуйте копілот. Якщо завдання повторюється по багатьох елементах, потребує викликів інструментів і виграє від спостереження проміжних результатів, розгляньте агента. Якщо завдання змінює стан продакшену, вимагайте сильніших контрольних точок незалежно від того, який інтерфейс ви використовуєте.

Потім класифікуйте ризик. Низькоризикова робота включає складання чернеток, підсумовування, форматування та інспекцію не чутливих даних лише для читання. Середньоризикова робота включає підготовку pull request, запуск тестів, створення тікетів чи валідацію маніфестів у staging. Високоризикова робота включає записи в продакшен, поводження з обліковими даними, сповіщення клієнтів, зміни білінгу й деструктивні операції. Що вищий ризик, то більше система потребує обмеженої ідентичності, перевірки, аудиторських логів і відкату.

Далі запитайте, чи справді потрібне мовне міркування. Агенти корисні, коли робочий процес вимагає судження над безладними вхідними даними — логами, кодом, тікетами, документацією чи частковими спостереженнями. Вони менш корисні, коли робота вже детермінована. Якщо cron-завдання, контролер, рушій політик чи скрипт можуть виконати роботу надійніше, використовуйте цей детермінований інструмент, а ШІ залиште для пояснення, тріажу чи обробки винятків.

Нарешті, оберіть мінімальний ефективний рівень делегування. Драбина така: лише чат, асистент із пропозиціями, асистент з обмеженим використанням інструментів, агент із явними контрольними точками перевірки та агент з обмеженим автономним виконанням у низькоризикових контекстах. Пропуск щаблів створює проблеми довіри, бо в команди немає доказів того, як система поводиться за менших обов’язків. Поступове сходження дає змогу вчитися на безпечних збоях.

Використовуйте це речення як перевірку дизайну: «Система може робити X за допомогою інструментів Y до умови Z, після чого вона має запитати схвалення B в особи A». Якщо ви не можете заповнити це речення, робочий процес не готовий до агента. Якщо ви можете заповнити його чітко, ви маєте начерк придатного для перевірки дизайну.

Ця рамка також застосовується після розгортання. Перевіряйте запуски агента так само, як ви перевіряєте інциденти й pull request. Шукайте зайві виклики інструментів, слабкі докази, відсутні посилання, повторні спроби, розмиті фінальні підсумки й надто широкі схвалення. Система делегування має покращуватися з часом, бо команда бачить, де цикл допоміг, а де змарнував увагу.

Коли рішення непросте, віддавайте перевагу менш автономному варіанту й збирайте докази. Хороший асистентський робочий процес згодом може стати агентним, якщо потреба в повторному використанні інструментів стане очевидною. Передчасний агентний робочий процес складніше спростити, бо користувачі можуть почати покладатися на поведінку, яка ніколи не була належно керована. Консерватизм тут — це не страх перед автоматизацією. Це те саме мислення поетапного розгортання, яке інженери вже застосовують до змін інфраструктури.

Ви також можете порівняти робочий процес з наявними шаблонами керування Kubernetes. Контролерам довіряють, бо їхній бажаний стан, дозволи, правила узгодження та події придатні для інспекції. Агент не повинен отримувати більше довіри, ніж контролер, пропонуючи менше гарантій. Якщо бажаний стан агента розмитий, його дозволи широкі, а його події відсутні, система потребує більше інженерії, перш ніж заслужити операційні повноваження.

Чи знали ви?

У 2023 році стаття ReAct популяризувала поєднання трас міркування із зовнішніми діями, що допомогло багатьом інженерам описувати цикли агента як спостерігай, міркуй, дій і спостерігай знову.
Kubernetes 1.35 продовжує шаблон, за яким поведінка кластера залежить від версії API, контролю допуску й узгодження контролерами, тож інструменти агента мають валідувати проти фактичного цільового середовища.
Багато агентних систем продакшен-рівня використовують вузькі інструменти замість необмеженого доступу до shell, бо структуровані вхідні дані легше авторизувати, логувати, тестувати й обмежувати за частотою.
Настанови Anthropic щодо агентів і практичний посібник OpenAI за адресою https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ обидва наголошують на відповідності робочому процесу: додаткова автономність цінна, коли завдання виграє від використання інструментів, стану й придатних для перевірки проміжних кроків.

Поширені помилки

Помилка	Чому це стається	Як це виправити
Називати кожну діалогову ШІ-систему агентом	Інтерфейс має форму чату, тож люди класифікують за виглядом, а не за структурою циклу.	Класифікуйте за автономністю, доступом до інструментів, станом і підзвітністю, перш ніж обирати засоби контролю.
Надання агенту широкого доступу до продакшену під час пілота	Команди хочуть швидко продемонструвати цінність і припускають, що інструкцій у промпті достатньо.	Почніть із доступу лише для читання, додайте вузькі інструменти й вимагайте схвалення перед будь-якою мутацією продакшену.
Сприймати пропозиції копілота як перевірку архітектури	Пропозиція з’являється всередині робочого процесу й здається обізнаною з контекстом.	Перевіряйте вихідні дані копілота проти системних обмежень, тестів і політики розгортання.
Використання агента для детермінованого контрольного списку	Брендинг «агент» здається сучаснішим за скрипт.	Використовуйте скрипти, контролери чи рушії політик для фіксованих робочих процесів, а ШІ — для безладного тлумачення.
Приховування проміжних спостережень від рецензентів	Команди оптимізують під чисту фінальну відповідь і забувають про придатність до аудиту.	Логуйте виклики інструментів, валідовані аргументи, спостереження, відмови, схвалення й невпевненість.
Додавання інструментів запису до того, як визначено умови зупинки	Команда зосереджується на спроможності й відкладає межі робочого процесу.	Визначте правила зупинки, ліміти повторних спроб, шляхи ескалації й нотатки про відкат, перш ніж вмикати запис.
Дозволяти моделі забезпечувати політику безпеки	Спокусливо закодувати політику в промпті, бо її швидко змінювати.	Забезпечуйте політику в детермінованих обгортках інструментів, системах ідентичності, контролях допуску й контрольних точках перевірки.

Тест

Ваша команда хоче ШІ-систему, яка підсумовує транскрипт інциденту, реорганізує хронологію й складає зрозуміліші подальші нотатки, але вона не повинна оновлювати тікети чи викликати зовнішні інструменти. Який шаблон вам слід обрати?

Оберіть асистента, а не агента. Робочий процес обмежений, насичений мовою й цінний без автономних дій. Чат теж міг би допомогти, але асистент із доступом до транскрипту й шаблону нотаток підходить краще, бо може працювати всередині робочого процесу звітування. Агент додав би координаційні витрати без вигоди від використання інструментів.

Платформний інженер пропонує систему, яка виявляє невдале розгортання, перевіряє стан викочування, отримує логи, порівнює помилку з нещодавніми змінами конфігурації, пропонує патч, запускає тести, а потім запитує схвалення. Це робота чату, асистента, копілота чи агента?

Це робота агента, бо вона має стабільну ціль, кілька кроків, виклики інструментів, спостереження й контрольну точку перевірки перед дією. Крок схвалення важливий, бо позначає межу між діагностикою та мутацією. Копілот міг би допомогти відредагувати патч, а асистент — пояснити логи, але описаний цикл проносить процес крізь кілька кроків, підкріплених інструментами.

Ваш керівник просить агента пояснити одну помилку валідації YAML у маніфесті, який уже вставлено в чат. Що вам слід діагностувати щодо цього запиту?

Діагностуйте це як невідповідність між формою завдання та автономністю. Одноразове пояснення не потребує використання інструментів зі станом, повторних спостережень чи делегованих дій. Промпт у чаті або обмежений асистент дешевші й легші для перевірки. Використання агента тут додає церемонії й може відвернути від реальної цілі — зрозуміти й виправити маніфест.

Копілот в IDE пропонує зміну до файлу розгортання Kubernetes, а розробник припускає, що пропозиція враховує політику продакшену, порядок відкату й міжсервісну поведінку. Який тут характер збою?

Характер збою — пасивне прийняття копілота. Копілот може мати корисний локальний контекст, але локальний контекст — це не те саме, що повна архітектурна перевірка. Розробник має сприймати пропозицію як чернетку, а потім перевірити політику, тести, послідовність розгортання й вимоги до перевірки. Проблема не у використанні копілота; проблема в наданні йому підзвітності, якої він не має.

Агент просить скопіювати секрет реєстру в неймспейс після спостереження ImagePullBackOff. Яка контрольна точка перевірки має існувати, перш ніж дія відбудеться?

Контрольна точка має вимагати, щоб людина схвалила точний неймспейс, джерело секрета, причину копіювання й план відкату чи ротації. Копіювання секрета змінює стан кластера й може порушити правила власності облікових даних. Діагностику лише для читання можна автоматизувати раніше, але переміщення облікових даних заслуговує на явне схвалення й аудиторське логування. Безпечніший дизайн агента зупиняється на запропонованій дії, якщо політика не дозволяє саме цю операцію.

У вашої команди є регулярний звіт про відповідність, який вимагає збирання схвалених метрик, перевірки їх за рубрикою, складання підсумку й прохання до рецензента схвалити фінальний текст. Чому агент тут може бути розумним вибором?

Агент може бути розумним вибором, бо завдання повторюване, підкріплене інструментами й структуроване навколо проміжних доказів. Ціль стабільна, а робочий процес може зупинитися на контрольній точці перевірки людиною перед публікацією. Команда може надати вузькі інструменти читання для схвалених метрик і вимагати від агента перелічувати відсутні дані. Це робить делеговану роботу корисною, не надаючи їй неконтрольованих повноважень.

Прототип агента неодноразово викликає діагностичні інструменти після отримання зашумлених результатів і ніколи не досягає чіткої точки зупинки. Яку зміну дизайну вам слід зробити?

Додайте явні умови зупинки, ліміти повторних спроб і правила ескалації. Агент має знати, скільки спостережень достатньо для першої гіпотези і коли невпевненість треба повідомити людині. Більше викликів інструментів не створює автоматично кращої діагностики; вони можуть збільшити вартість і шум. Обмежений цикл має зупинитися, підсумувати докази й запитати напрямок, коли впевненість залишається низькою.

Практична вправа

Сценарій вправи: ви консультуєте команду, яка хоче ввести допомогу ШІ в операційний робочий процес Kubernetes 1.35. У них є три завдання-кандидати: пояснення маніфестів новим інженерам, підготовка pull request для регулярних оновлень політики й діагностика невдалих викочувань у staging-кластері. Ваше завдання — класифікувати кожне завдання, встановити мінімальний корисний рівень делегування й визначити засоби контролю, перш ніж розглядати будь-який доступ до продакшену.

Почніть зі створення невеликої оцінювальної нотатки у власному редакторі. Для цієї вправи вам не потрібен доступ до кластера, бо ціль — проєктування робочого процесу, а не виконання команд. Для кожного завдання-кандидата запишіть ціль завдання, дані, потрібні системі, інструменти, які вона може використовувати, точку, де вона має зупинитися, і особу, яка схвалює наступну дію. Це та сама дисципліна проєктування, яку ви застосували б перед підключенням реальних інструментів до циклу агента.

Для завдання діагностики викочування будьте особливо конкретними щодо меж. Безпечна перша версія могла б читати стан Deployment, стан ReplicaSet, події подів і нещодавні логи зі staging-неймспейсу, а потім видавати гіпотезу й запропоновану наступну команду. Вона не повинна перезапускати навантаження, редагувати маніфести, копіювати секрети чи змінювати теги образів. Якщо ваш дизайн включає ці дії, перенесіть їх за окрему контрольну точку схвалення й поясніть шлях відкату.

Для завдання оновлення політики відрізняйте підготовку від виконання. Агент може шукати уражені маніфести, скласти патч, запустити валідацію й відкрити запит на перевірку, нічого не об’єднуючи. Це все одно економить час, бо повторюване збирання доказів делеговано. Рецензент-людина залишається відповідальним за прийняття зміни, а звичайні тести репозиторію й захист гілок залишаються частиною системи контролю.

Для завдання пояснення маніфестів опирайтеся спокусі перебудувати. Хороший асистент із невеликою кількістю контексту може бути найкращим інструментом, бо тому, хто навчається, потрібне пояснення, а не автономна дія. Якщо команда згодом помітить повторювані запитання, вона може додати пошук по схваленій документації чи прикладах. Це все ще територія асистента, доки система не почне обирати інструменти й нести ціль крізь кроки.

Порівняйте робочі процеси чату, асистента, копілота й агента в матриці делегування для трьох завдань-кандидатів.
Спроєктуйте драбину делегування агентові з контрольними точками перевірки, нотатками про відкат і обмеженими дозволами Kubernetes для завдання діагностики викочування.
Діагностуйте, де агент додає координаційні витрати, а де асистент чи детермінований скрипт безпечніший.
Реалізуйте обмежений план оцінювання агентного робочого процесу за допомогою захищених специфікацій інструментів і вимірних критеріїв успіху.
Запишіть критерії успіху для аудиторських логів, умов зупинки, схвалень людиною та якості доказів перед будь-якою мутацією продакшену.

Пропоноване рішення

Для пояснення маніфестів оберіть чат або обмеженого асистента, бо ціль — навчання й перевірка, а не дія. Для регулярних оновлень політики оберіть асистента з обмеженим використанням інструментів або агента, який готує pull request і запускає тести, а потім зупиняється для перевірки. Для діагностики викочування в staging оберіть агента лише для читання, який може перевіряти стан викочування, події й логи, а потім пропонувати наступні кроки, не застосовуючи змін. Мутація продакшену має залишатися поза межами, доки команда не матиме доказів із безпечних запусків.

Перевірка контрольного списку критеріїв успіху

Сильна відповідь називає рушія циклу, межу інструментів, власника схвалення й умову зупинки для кожного завдання. Вона уникає широкого доступу до продакшену під час пілота й не покладається на інструкції в промпті як на межу безпеки. Вона також відрізняє детерміновані кроки, як-от запуск фіксованої команди валідації, від насичених мовою кроків, як-от підсумовування зашумлених логів. Найкращі відповіді включають нотатки про відкат навіть тоді, коли перша версія лише для читання, бо мислення про відкат покращує подальший дизайн.

Джерела

Наступний модуль

Перейдіть до Проєктування робочих процесів ШІ, щоб перетворити драбину делегування на повні ШІ-орієнтовані дизайни робочих процесів.