Припиніть сподіватися, що підказки врятують дизайн агентів. Ви можете називати це контекст‑інжинірингом чи loop‑інжинірингом, але це лиш прохання до моделі «не халюцинувати». Так ви збільшуєте точки зсуву і помилок. Інший шлях простіший і надійніший. Сприймайте агентів як програмне забезпечення з чіткою логікою виконання. Побудуйте хомут, що вирішує, коли і як викликати LLM. У цій статті розберемо контекст і пам’ять, стійке виконання та перевірку прогресу.
Контекст і пам’ять: з чого починається надійний агент?
Надійний агент починається з керованого контексту і явної пам’яті. Кожен запит пересилає повну історію розмови, тож «чат» — це лише інтерфейс. Ви швидко впираєтесь у вікно контексту, отримуєте обрізання, «гниття» і дрейф. Рішення — тримати вікно семантично щільним, переносити релевантне між агентами та відкидати «мислення», що не додає цінності.
Повний пересил контенту спрощує керування і дозволяє переставляти акценти в межах вікна. Навіть із великим вікном дрейф нікуди не зникає. Корисний наслідок — ви можете взяти контекст одного агента, передати іншому і продовжити сесію без зайвих викликів інструментів, зберігаючи лише семантично важливе.
Контекст має життєвий цикл: системний промпт, визначення інструментів, користувацькі запити, міркування, виклики інструментів. Важливо розуміти, що саме потрапляє у вікно. Gumloop пропонує лічильник використання контексту з категоріями на кшталт System, AI Instructions, Abilities, Tools, Skills, Subagents, Conversation. У довгих сесіях частка розмови зростає, а системні визначення лишаються стабільними.
Коли контекст зростає, стискайте його. Обрізайте нерелевантні токени, узагальнюйте великі шматки в компактні еквіваленти. Google’s ADK Context Compaction стискає контекст, підсумовуючи старші події за ковзним вікном і порогами кількості інвокацій. Проте постійно узагальнювати не можна. Час від часу хомут має виконати повний скидання контексту і зібрати наступний запит із витривалих артефактів.
«Досвід чату — це інтерфейс. Ілюзія користувача™.»
LLM є безстанковими, тому ефемерний контекст зникає з сесією. Записуйте контекст у постійне сховище. Ідеально — у незмінні журнали, де агент може писати і читати, але не змінювати чи видаляти. Дозволи ви визначаєте детерміністично. Що саме зберігати — вирішуєте ви: повне вікно, підсумки, тільки заголовки.
У межах Google’s EAP генерація пам’яті поєднує кілька рішень. Extraction витягує найважливіше, а не все підряд. Consolidation зливає нове зі старим, дозволяючи пам’яті еволюціонувати. Generation працює асинхронно, без блокування агента. Event ingestion безперервно стрімить події та тригерить генерацію за правилами пакетування. Extraction налаштовується: ви визначаєте теми і few‑shot приклади, що вважати значущим.
Зі збереженим контекстом журнал слугує механізмом реконструкції. Нова сесія читає план, нотатки прогресу та апенд‑лише реєстр подій і відновлює «де я». Структурований план сам несе контекст: «Я на кроці 3 з 7, чекав перевірку санкцій, і результат надійшов».
«Як каже Cloudflare, ви можете звільнити 20% співробітників і замінити їх ШІ, використавши план Агента як контекст.»
У Google’s EAP кероване сховище та вибірка додають ізоляцію пам’яті за ідентичністю, сталість між середовищами, вибірку подібності в межах ідентичності, TTL для застарілого, автоматичні ревізії та IAM‑умови. Ідентичність — окрема турбота контекст‑менеджменту. Обсяг пам’яті задається під час створення і незмінний, що робить її витривалою між задачами і сесіями.
У Cloudflare ідентичність Durable Object переживає гібернацію і рестарт без перевстановлення. Це якір, що дозволяє знайти стан задачі і пам’ять після збою. Ця витривалість потребує механізмів для безперервності між інстансами й у точках відмови. Саме їх ми розберемо далі.
Стійке виконання: як агенти виживають збої без лупів?
Стійке виконання спирається на детерміноване відновлення, а не на прохання до моделі «продовжити». Довготривалий агент не працює постійно. Він прокидається за подією, тримає план, стан і контекст, потім знову засинає. Завдання хомута — так структурувати дані, щоб модель діяла послідовно від кроку до кроку.
Що має пережити виклики? За прикладом Cloudflare, це стан агента, усі таблиці SQLite, заплановані задачі, що піднімають тривоги, та стани WebSocket‑з’єднань. Що не зобов’язане? Оперативні змінні, таймери, відкриті HTTP‑виклики, колбеки й ланцюжки промісів. Ідентичність і стан — сталі. Обчислення — за подією.
Джерела «пробудження» прості. Вебхук‑колбек: агент запускає зовнішню роботу, реєструє свій URL і гібернує до прибуття колбека. Полінг із бекофом — коли колбеків немає. Агент планує опитування, збільшує інтервали, обмежує максимум. Широкі пайплайни з незалежними ретраями варто віддавати движку робочих процесів, а не змішувати в агенті.
Підагенти отримують цю ж витривалість. Кожна дитина має свій стан, розклади, життєвий цикл і дані, розміщені поруч із батьком. Батько не мусить бути активним, поки дитина працює. Збій не «валить» усю родину: кожна ідентичність відновлюється окремо. Моніторинг токенів і лімітів дає прогностичні сигнали: хомут може чекпоїнтити, тротлити чи міняти модель до удару в ліміт.
«Довготривалий агент не працює довго. Він працює за потреби, відстежуючи задачі і контекст.»
Відновлення починається з простого: сесія читає журнал на старті і відповідає «де я». Далі ви фіксуєте рядок на час роботи кроку, зберігаєте проміжний стан у контрольних точках і відновлюєтесь із останньої при рестарті. Ідемпотентність критична, особливо для агентів на вебхуках із повторними доставками, щоб уникати дубльованих побічних ефектів.
Загальний шаблон — event‑sourcing і журналювання. Є незмінний журнал плану задач і окремий апенд‑лише журнал виконання: кожен виклик інструмента, кожна відповідь моделі, кожен перехід стану. Його можна детерміністично програти для реконструкції стану на будь‑якому процесі.
Цю ідею реалізують, зокрема, Restate з детермінованим реплеєм кроків і DBOS із чекпоїнтами в Postgres. Вони також пропонують компенсації і відкат, коли частину роботи потрібно скасувати після збоїв. У ландшафті витривалого виконання варто подивитись на DBOS, Restate, Inngest і порівняти підходи.
Загальні можливості включають призупинення‑та‑відновлення за зовнішніми подіями, контроль потоків і лімітів конкурентності, а також вираження витривалості в коді застосунку або як окремий оркестратор. Ви можете спроєктувати власну витривалу логіку в n8n: ретраї, постійне сховище, детерміністичні тригери на кшталт розкладів і вебхуків.
Ідентичність — ключ до витривалості. У моделі Cloudflare ім’я агента — маршрутизаційний ключ, що виживає гібернацію, рестарти й редеплої. Облікові дані скоплені по ідентичності агента або підагента. Перевага — атрибуція: кожний запис у журналі виконання прив’язаний до сталої ідентичності. На платформенному рівні Google’s Agent Identity and Registry відслідковують, яка ідентичність, у якій версії, виконує яку задачу.
Прогрес і оцінювання: як перевіряти роботу без LLM‑судді?
Спроба питати модель «чи все гаразд» — найлегший і найменш надійний шлях. Краще мінімізувати залежність від судження LLM і залишити йому вузькі, перевірювані ролі. Прогрес повинен підтверджуватися детерміністичними воротами, що читають стан системи або журнал виконання.
Почніть із чекліста. Кожен пункт має мати критерій завершення до старту виконання. Це блокує «переозначення готовності» агентом під час бігу. Супутнє правило — працювати над одним пунктом за прохід. Це фокусується на завершенні й спрощує перевірку: у кожному проході перевіряється рівно один перехід стану.
Далі — ворота валідації. Від простих до складних: коди статусів API, валідація схемою, перевірка крос‑полів, повторний запит для перевірки зміни стану, тести. Вони повертають булеві відповіді без участі моделі. Це надійніше та дешевше, ніж LLM‑оцінка.
Інші механізми теж корисні. Скінченні автомати як карта допустимих станів і переходів. Пісочниця і поведеневі базові лінії, після чого обмеження allowlist у продакшні. Некомбінаторні класифікатори без генерації тексту (родина BERT, зокрема DeBERTa, RoBERTa, ModernBERT) видають скаляр за порогом і дають вердикт без генеративної моделі. Моніторинг аномалій у патернах викликів інструментів зупиняє забіги з рекурсивними лупами, спайками токенів або порушенням порядку.
«LLM‑as‑judge — це найлегше виправлення і найменш надійне.»
Коли ж використання LLM як судді прийнятне? Лише коли намір визначений до старту. Це означає чіткий allowlist інструментів, визначену послідовність кроків або станів, вказані джерела даних, правила породження підагентів і визначені API та методи. Тоді оцінка зводиться до набору «так/ні» проти журналу виконання.
Якщо вже залучати LLM, обмежте задачу класифікацією на перевірювані категорії, наприклад «чи відповідає цей трейс таксономії X». Тут модель працює як «нечіткий компілятор», що мапить спостережувану поведінку на детерміновану категорію, а не вигадує «добре» на льоту.
Реалізація цього підходу охопить кілька продуктів і потребує постійної інженерії. Не сприймайте це як покрокову інструкцію або фреймворк побудови безпомилкових агентів. Це огляд детерміністичних компонентів, які часто ігнорують самопроголошені «loop‑інженери». Далі ми продовжимо дослідження цих тем для n8n і ширшого ринку. Автор вітає покращення, фідбек і виправлення, тож зв’яжіться з ним у LinkedIn.
На основі матеріалу наданого матеріалу.
