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

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

Попереджувальний сценарій: оплата за кожне „ні“

Причиною є архітектура, яку ніхто не описав письмово. Щоб „стежити“ за скринькою вхідних повідомлень, кожні дві хвилини запускався запланований завдання, яке збирало останні повідомлення та запитувало у моделі, чи потребують вони уваги. За місяць це траплялося близько двадцяти двох тисяч разів. Майже кожна відповідь була ретельно обґрунтованим „ні“. Одинадцять відповідей „так“ були чудовими, але рахунок переважно складався з негативних результатів. Найдорожчою дією системи, у приблизно три порядки величини, було підтвердження того, що нічого не змінилося.

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

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

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

Кожен запит вже є подією

Запит у чаті здається природною відправною точкою для агента, але за ним криється багато „безкоштовної“ роботи. Людина, яка його надіслала, зробила три речі ще до обробки будь-якого символа: вона вирішила, що ситуація варта дії (це і є триаж), узагальнила її в кілька речень (це створення контексту) та надіслала його у певний момент часу (це таймінг). Чат-агент насправді є агентом, який працює на основі шару подій, створеного людиною.

Агенти навколишнього середовища — термін, який LangChain запровадив для агентів, що споживають потік подій та реагують на нього, можливо, обробляючи кілька подій одночасно, — виключають людину з процесу. Усі три безкоштовні сервіси зникають. Що залишається, — це інженерна проблема з п’ятьма різними типами вхідних даних, кожен з яких поводиться по-різному:

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

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

Стеження. Зміни стану: запит на об’єднання став придатним, документ було відредаговано, клієнт перестав відповідати. Ніщо не надсилає це вам. Хтось має це помітити, а для цього потрібні зусилля.

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

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

Інструмент пробудження: триаж як сходи

Ключовим економічним фактом є те, що виклик моделі є найдорожчим умовним запитом, який ви коли-небудь будете створювати. Запит до моделі про те, „чи має це значення?“, коштує приблизно в п’ять–сім порядків більше, ніж фільтр бази даних, який відповідає на те саме запитання щодо структурованих даних. Тож робоча архітектура ніколи не є прямою лінією від події до моделі. Це конус: серія етапів, кожен з яких дешевший за наступний та видаляє більшу частину інформації, що до нього надходить.

Перший етап: структурні правила

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

Друга стадія: debounce та об’єднання

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

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

Примітка щодо моніторингу: опитування та порівняння, ніколи не опитування та оцінка

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

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

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

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

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

Третій етап: дешева класифікація

Те, що виживає після дії правил та процесу об’єднання, потрапляє до невеликої, швидкої та недорогої моделі з навмисно вузьким запитом, щось на кшталт „Відповісти одним словом: терміново, релевантно чи ігнорувати“. Це знайома каскадна система маршрутизації моделей, застосована до систем попереджень: недорогий рівень поглинає неоднозначності, яких не можуть виразити фіксовані правила, і лише результати типу „релевантно“ та „невизначено“ передаються на вищі рівні. Невелика модель, яка правильно відповідає приблизно у 92% випадків, яка працює перед моделлю більшого розміру, вартість якої у тридцять разів вища, — ось сутність цього рівня. Щоб дізнатися більше про те, звідки походять витрати на агентів, перегляньте модель витрат для агентського ШІ, засновану на архітектурі.

Четвертий етап: агент

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

П’ятий етап: людина

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

Арифметика редизайну

Застосуйте це до команди з самого початку. Припустимо, вони змінять спосіб отримання повідомлень з опитувань на вебхуки та додадуть структурні правила, що призведе до видалення близько 70% первинних подій, оскільки це будуть розсилки та автоматизовані листи. Об’єднання за темами видаляє ще близько 60% того, що залишилося. Потім невеликий класифікатор позначає близько 85% решти як „ігнорувати“. Тепер модель працює приблизно тридцять разів на місяць, замість двадцяти двох тисяч, проте все ще відбувається ті самі одинадцять корисних дій. Витрати на кожну корисну активність знижуються більш ніж у десятки разів.

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

Якісний сон: чому неактивний агент не коштує нічого

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

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

Відновити годинник

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

Розглядайте пам’ять як можливо застарілу

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

Знову орієнтуватися на мету

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

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

Що має містити хороший контекст пробудження

„Реконструкція“ звучить абстрактно, поки ви її не створите. Добре складений запит на пробудження нагадує інструкцію, яку система складає частинами:

• Файл цілей, у нередагованому вигляді. Причина існування цього агента та обмеження щодо того, що йому дозволено робити.

Годинник. Текущий час у часовій зоні керівника, а також час створення попереднього спрацювання.

Ситуація. Узагальнений огляд, який призвів до цього спрацювання. Це не сорок первинних подій, а опис їхньої структури.

Сучасний стан. Текущі значення всього, що пов’язане з ситуацією; вони отримуються у момент спрацювання та кожне з них позначається часом оновлення.

Релевантна пам’ять. Невеликий набір постійних записів, залишених попередніми спрацюваннями, наприклад «цей клієнт віддає перевагу дзвінкам увечері» або «останнього разу, коли спрацював цей сигнал, причиною була кеш-пам’ять». Їх отримують за потребою, а не накопичують.

Бюджет. Обмеження на кількість токенів, доступні інструменти та верхня межа автономії для цього конкретного спрацювання.

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

Гарантії надання послуг із особливостями LLM

Процес пробудження також означає успадкування класичних проблем розподілених систем.

Доставка відбувається принаймні один раз, тому кожна дія має бути ідемпотентною. Очереді та сервіси webhook мають право надіслати вам одне й те саме повідомлення двічі. Для безстанового сповіщувача дублікат є просто шумом. Для агента, який використовує інструменти, дублікат може означати виконання однієї й тієї самої незворотної дії двічі. Рішення є стандартним: отримати ключ ідемпотентності з події та перевірити його перед виконанням будь-якої дії, яку неможливо скасувати. Якщо вам потрібно оновлення знань щодо цього механізму, перегляньте як працюють ключі ідемпотентності у Node.js POST-кінцевих точках.

Ейєнтам у середовищі також потрібна друга перевірка на рівні ситуації. Ейєнт, якого було розбуджено через те, що „PR #482 можна об’єднати“, повинен підтвердити, що цей pull request все ще можна об’єднати, перш ніж діяти. Час розбудження може становити кілька хвилин, і інша особа чи ще один ейєнт вже могли цим зайнятися. Конкуренція у момент розбудження є звичайною конкуренцією за спільний стан із більшою затримкою між причиною та наслідком.

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

Складніші проблеми: агресори, увага, конкурунтність та кризи

Джерелом проблем є поверхня атак

Перегляньте п’ять типів вхідних даних з урахуванням аспектів безпеки. Будь-хто, хто може надіслати подію, фактично може активувати агента. Полезайми Webhook, тіла електронних листів та коментарі до проблем, які можуть спричинити активацію, є ненадійним текстом, і вони потрапляють до моделі з доступом до інструментів. На відміну від чату, під час активації немає людини, яка б помітила, що щось не так. Ретельно складений „терміновий“ електронний лист не лише марнує час активації; він також визначає, що буде думати агент, і це є першим кроком майже кожної послідовності введення команд.

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

Людина — найбільш дефіцитний ресурс у цьому ланцюгу

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

• Повідомити. Лише для отримання інформації; дій не потрібно.
• Задати запитання. Агенту потрібен один факт, щоб продовжити роботу.
• Переглянути. Агент підготував дію та хоче отримати схвалення.

Ключова ідея, пов’язана з конкретним контекстом, полягає у тому, що ця „драбина“ водночас є показником якості. Записуйте, як люди реагують на кожне переривання: чи беруть вони заходів, ігнорують його чи просягають. Це дає вам точні показники для всього процесу. Агент, чиї сповіщення ігноруються у 80% випадків, не просто марнує 80% часу – це також навчає людей вимикати їх, і як тільки вони це роблять, корисні 20% також зникають. Втома від сповіщень підривала ефективність моніторингу протягом десятиліть ще до появи мовних моделей, і витончені тексти сповіщень нічого не змінюють у цьому.

Конкурентність: суперсила з притаманною їй небезпекою

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

Засоби пом’якшення проблем, у приблизному порядку пріоритету:

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

Записи маршруту через єдиного записувача — коли розділення недостатнє.

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

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

Режим шторму

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

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

Вимірюйте неактивних агентів, як продукт

Найважливішими є два показники:

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

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

Автономія, залежна від часу

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

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

Закодуйте це як пошук у механізмі, який поєднує рівень довіри до тригеру, серйозність дії та доступність людини, і прив’яжіть їх до одного з трьох результатів: діяти негайно, відкласти на ранок чи повідомити негайно. Опція відкладення на ранок є непоміченим героєм. Більшість речей, які помічає агент у 3 години ранку, цілком підходять як елемент для перегляду о 8:55 ранку, вже упакований разом із запропонованою агентом дією, і надходить приблизно тоді, коли готується перша кава.

Патерни в реальних системах

Асистент електронної пошти з скринькою для своїх користувачів

Референтний агент LangChain для роботи з електронною поштою складає відповіді, зберігає повідомлення та передає їх на вищий рівень обробки. Його дизайн взаємодії є більш навчальним, ніж функція складання текстів. Команда, яка його створила, розглядає участь людини не як поступку, а як засіб, що знижує ризики, полегшує впровадження, будує довіру та поповнює довгострокову пам’ять. Їхня функція Agent Inbox — єдине місце для перегляду всіх відкритих діалогів між людиною та її агентами — є фізичним втіленням механізму сповіщень, постановки запитань та перегляду. Постійний жарт цього проекту про те, що якщо вас ігнорують, це точно вина агента, відображає суть економіки уваги: агент існує для того, щоб людина використовувала свою увагу розумніше, а жарти з’являються тоді, коли це не вдається.

Заплановані агенти в інструментах для програмування

Основні платформи для кодування постійно додають агентів, які працюють за графіком чи під впливом подій у репозиторії замість вхідних команд; рутини Claude Code та запуски, викликані GitHub, є прикладами, з якими стикалися багато розробників. Перевірте актуальну документацію, адже ці функції швидко розвиваються. У них спостерігається два типові підходи до проектування, обидва з яких підтримують цю ідею. Кожен запуск починає нову сесію, причому континуїтет зберігається у файлах та пам’яті, а не у безкінечних записах. А шар запуску — це класична інфраструктура, така як вирази cron, фільтри webhook та умовний YAML; моделей у процесі виконання немає. Інтелектуальні технології є дорогими, тоді як прості механізми — дешевими, тому продукти тримають їх окремо.

Спостерігачі за інфраструктурою

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

Команда з перевірки через чверть року

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

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

Вибір основних елементів

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

• Інфраструктура запуску. Cron та його аналоги з керуванням; шини подій та черги, такі як EventBridge, Pub/Sub, Kafka чи звичайні webhooks; а також графіки та сигнали в двигунах робочих процесів, таких як Temporal, Restate чи Inngest, які також забезпечують надійне зберігання даних. Перший та другий етапи конвеєра безпосередньо відповідають функціям цих інструментів.

Каркас для роботи з агентами в середовищі. LangGraph із підтримкою зберігання даних, переривань та запланованих завдань через cron, а також відкритий інструмент Agent Inbox; запланований та спусковий режими основних кодувальних агентів, таких як рутини Claude Code та інтеграції GitHub Actions; а також все більше з’єднувачів, які перетворюють електронну пошту чи webhooks на виконання агентом завдань. Оцінюйте всі ці інструменти за трьома критеріями: де відбувається сортування інформації (воно має відбуватися до обробки моделлю), що відновлюється після припинення роботи, та що в кінцевому підсумку бачить користувач.

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

Поштова скринька. Використовуйте Agent Inbox від LangChain, якщо потрібна готова платформа, або поточні канали вашої команди — Slack, електронну пошту чи систему заявок, причому три основні дії мають залишатися чіткими та вимірними.

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

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

async def on_event(evt):
    if not rules_pass(evt):            return                  # stage 1: free
    sit = coalesce(evt, window="10m")                          # stage 2: situations, not events
    if sit is None:                    return                  # burst still settling
    if triage_small_model(sit) == "ignore": return             # stage 3: cheap
    if seen(sit.idempotency_key):      return                  # at-least-once armor
    ctx = rebuild(now(), goal_file, fresh_reads(sit))          # stage 4: wake = reconstruction
    outcome = await agent.run(sit, ctx, budget=WAKE_BUDGET)
    inbox.deliver(outcome.verb, outcome.summary)               # notify | question | review

Зверніть увагу на місце перевірки ідемпотентності: після дешевих фільтрів, але перед будь-якими дорогими чи незворотними операціями. Її також можна розмістити раніше; головне — щоб жодні дублікати не потрапляли до agent.run. У реальній системі саме тут також має відбуватися перевірка перед виконанням дії, оскільки саме тоді стає доступним новий стан.

Посібник зі способів виникнення помилок

• „Вогнище опитувань“. Дорога модель неодноразово проситься перевірити нічого. Рішення: правила та об’єднання даних перед кожним викликом моделі, а потім — дешева модель перед дорогою.
• „Гурт грому“. Одна збоя поширюється на тисячі наслідків. Рішення: режим бурі з детектором частоти, повне об’єднання даних, один агент та одне сповіщення.

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

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

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

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

Тиха прогалина. Webhook припинив надсилати дані кілька місяців тому, і ніхто цього не помітив, доки не минув термін оновлення. Рішення: перевіряти затримки, шукати правду та виконувати повільну процедуру узгодження, припускаючи, що потік даних містить помилки.

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

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

Тижневий план для початку роботи

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

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

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

Забезпечити безпеку процесів. Додайте ключі ідемпотентності, механізм перевірки перед виконанням дії та процедуру реконструкції: годинник, свіжі дані, файл цілей.

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

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

Підсумки: сприйняття навколишнього середовища, людська віддача

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

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

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

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