Більшість команд ШІ, які прагнуть покращити роботу агентів, використовують ті самі важелі: більші ліміти контексту, більше документів і розумніші запити. У цій статті стверджується, що такий підхід докорінно хибний. Бракує не додаткової інформації. Бракує контролю. Саме добре спроєктований рівень контролю відрізняє агента, який працює в демонстрації, від агента, який працює у виробничому середовищі.
Більша пам’ять, більше документів або довший ліміт контексту не роблять агента ШІ розумнішим — лише повільнішим і дорожчим. Справжнє покращення з’являється, коли агент навчається вибирати, що й коли йому потрібно, замість споживати все одразу.
Надійність залежить від циклу, а не від моделі. Агента, який вражає під час демонстрації, від агента, який витримує реальну експлуатацію, відрізняє не якість ШІ, а здатність системи перевіряти власну роботу. Агенти, які на кожному кроці планують, діють, спостерігають і перевіряють, помічають власні помилки, а не впевнено видають хибні результати.
Більшість сучасних агентів ШІ — це фактично чатботи з додатковими кроками: вони не мають механізму, який дає змогу зрозуміти, чи рухаються вони правильно, коли слід зупинитися або спробувати інший підхід. Належний рівень контролю — чіткі критерії успіху, структурований стан і перевірки — перетворює об’єкт, схожий на агента, на систему, якій справді можна довіряти.
Що ви їли вчора на обід?
Ви навряд чи відтворювали всі свої спогади, доки не дійшли до «вчора + обід». Ви одразу звернулися до тієї частини досвіду, де зберігаються ці поняття. Це корисна ментальна модель для створення агентів:
Величезний ліміт контексту — це не пам’ять.
Купа отриманих документів — це не розуміння.
Довгий ланцюжок міркувань — це не надійність.
Це лише складники. Але агента робить агентом те саме, що не дає вашому мозку перебирати всю історію життя: контроль.
Нещодавній огляд — «Агентне міркування для великих мовних моделей» — чудово підсумував і назвав зміну, яку багато хто з нас відчував під час розробки: від міркування всередині моделі до міркування через взаємодію. Ця публікація — не резюме тієї статті. Це спроба втілити цю зміну в практичному проєктуванні систем:
Якщо будувати агентів як чатботів з інструментами, ви й надалі отримуватимете типові збої чатботів, але помилки коштуватимуть дорожче.
Тривалий час наш стандартний сценарій «зробити модель розумнішою» зводився до кращих запитів, ланцюжка міркувань, сам узгодженості / покращень на основі вибірки та, можливо, пошуку.
ReAct став переломним моментом, адже зробив послідовність «думка → дія → спостереження» природною. Але зверніть увагу на неявне обмеження: чимало з цього й досі зводиться до «виведення з одним прикладом, але з більшою кількістю токенів». Формулювання в огляді точніше: агентне міркування наголошує на масштабуванні взаємодії під час тестування, перетворюючи виведення на ітеративний процес, у циклі якого постійно залишаються модель, пам’ять і середовище.
Якщо ви створювали або використовували агентів, які вражають у демонстраціях, але виявляються крихкими в реальних процесах, ця стаття для вас.
Опишу шаблон, який я часто бачив і різні версії якого точно створював сам:
Візьміть хорошу чат-модель
Додайте кілька інструментів (пошук, запити до БД, можливо, виконання коду)
Додайте RAG
Додайте системний запит «ти — автономний агент»
Загорніть усе це в цикл while, який працює до зупинки або завершення часу очікування
Вітаємо, у вас є об’єкт, схожий на агента. Але він зазвичай дає збій передбачуваними способами:
Роздування контексту: кожне спостереження додається до попередніх, а запити перетворюються на археологічні шари.
Безладне використання інструментів: типовим режимом відмови стає «впевнено вибрати не той інструмент».
Немає умов зупинки: агент продовжує роботу, бо може, а не тому, що повинен.
Немає дисципліни заземлення: агент не помічає власної помилки, якщо його не змусити.
Пам’ять = історія чату: це фактично ведення журналів, яке називають навчанням.
Ось чому «агенти» часто здаються чарівними під час демонстрацій і безладними у виробничому середовищі. Наш досвід упровадження агентних систем у виробниче середовище також це підтверджує: щойно ви оцінюєте не модель, а систему, до режимів відмови належать навігація, належне використання інструментів, скорочення контексту й проєктування оцінювання, а не лише відповідь на запитання «чи правильно відповіла модель?».
Тож постає запитання: яким має бути цільовий агент?
Щоб зробити це менш абстрактним, розгляньмо простий робочий процес, який легко уявити: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Типова реалізація, що «нагадує агента», має такий вигляд:
Одразу отримує купу документів про правила авіакомпаній / подорожей, навіть якщо вони поки не потрібні.
Викликає інструмент пошуку, вставляє довгий список результатів у запит і «вибирає один».
Передчасно бронює квиток, не перевіривши обмеження щодо часу прибуття, багажу, місця й правил.
У разі невдачі повторює спробу дещо інакше, але без чіткого розуміння того, що змінилося або чого він навчився.
Проблема не в тому, що модель не здатна міркувати, а в тому, що система не контролює робочий процес.
У більш агентному варіанті завдання розглядається як інтерактивний процес із явним станом і перевірками:
ПЛАНУВАННЯ: повторити обмеження й перелічити відсутню інформацію (наприклад, «який аеропорт бажаний?» / «одна пересадка прийнятна?»).
ДІЯ: викликати пошук авіарейсів зі структурованим запитом (діапазон дат, обмеження часу прибуття, бюджет).
СПОСТЕРЕЖЕННЯ: зберегти результати в компактному об’єкті стану (5 найкращих варіантів із ціною, часом прибуття й пересадками), а не вставляти величезний масив даних.
ОНОВЛЕННЯ: уточнити запит, якщо обмеження не виконано (наприклад, «прибути до 18:00 надто складно — розширити часовий діапазон чи збільшити бюджет?»).
ПЕРЕВІРКА: запустити валідатори («прибуття < 18:00», «ціна ≤ £900», «відповідає правилам», «вибір місця доступний»).
ЗУПИНКА: лише після того, як API бронювання поверне підтвердження й усі валідатори успішно завершать перевірку.
Зміна ледь помітна, але вирішальна. Отримання даних відбувається за умовою, а не рефлекторно; контекстом керують — стан структурують, а не накопичують; перевірка входить до циклу, а не перекладається на користувача. Замініть «бронювання авіаквитка» на «створення замовлення на закупівлю», «повернення коштів», «зміну робочої конфігурації» або «випуск PR» — і суть не зміниться: щойно агент може діяти, цикл стає важливішим за запит.
У згаданому вище огляді агентне міркування поділено на три рівні: базовий (планування, використання інструментів, пошук), саморозвиток (зворотний зв’язок і пам’ять) та колективний (координація кількох агентів).
Але глибша ідея полягає в тому, що міркування стає організаційним принципом планування, ухвалення рішень і перевірки, а не просто генерування правдоподібного ланцюжка міркувань. Це звучить абстрактно, доки ви не зіставите цю ідею зі змінами у своїй архітектурі. Варто пам’ятати три основні тези:
Хороший агент не повинен завжди отримувати дані. Це має бути свідомим рішенням, а не рефлексом.
Ось практичне евристичне правило:
Якщо ваша система отримує дані на кожному кроці, ви створили не механізм отримання даних, а податок на контекст.
У реальній роботі це трапляється постійно. Під час налагодження виробничого інциденту ви не завантажуєте всі журнали в контекст, а на основі поточної гіпотези вирішуєте, які метрики чи журнали отримати далі. Це й називається «агентним отриманням даних». Ось конкретніший шаблон:
Вирішіть, чи потрібно отримувати дані
Якщо так: сформуйте запит, отримайте й перегляньте дані, виділіть потрібне
Якщо докази суперечливі: отримайте дані знову
Лише тоді узагальнюйте
Саме тут «агентний RAG» починає відрізнятися від традиційного RAG: отримання даних стає свідомим етапом міркування, а не стандартною стадією конвеєра.
Щойно ви припиняєте оцінювати «модель» і починаєте оцінювати «систему», відстеження стану й трасування набувають значення.
Галузь уже навчилася чіткіше підходити до спостережуваності робочих процесів агентів. Наприклад, SDK Agents від OpenAI має вбудоване трасування та панель Traces, яка записує запуски агентів (генерування, виклики інструментів, передавання завдань, захисні механізми, спеціальні події), щоб ви могли покроково налагоджувати й перевіряти те, що сталося.
Це не просто «приємний бонус». Саме цим система, яку можна налагодити, відрізняється від системи, яку можна оцінити лише інтуїтивно.
На мою думку, найпрактичніша частина огляду — це те, наскільки прямо в ньому йдеться про зворотний зв’язок. У ньому зворотний зв’язок поділено на три режими: рефлексивний (згенерувати → оцінити → виправити), параметричну адаптацію (навчання через тонке налаштування / RL) і зворотний зв’язок на основі валідатора (повторювати спроби до успішної перевірки).
Більшості команд варто почати зі зворотного зв’язку на основі валідатора, адже це нудно, зате дієво. Якщо ви можете написати будь-який валідатор, що виконує модульні тести, перевіряє схему, застосовує бізнес-правила / обмеження («повернення понад X потребують ескалації») або підтверджує правдивість («джерела обов’язкові»), то зможете перетворити недетермінований результат моделі на те, чому справді можна довіряти.
Одна з неочевидних змін тут проста: у світі агентів надійність часто більше залежить від циклу, ніж від моделі.
Ось найпростіша дисципліна циклу, яка, за моїм досвідом, стабільно покращує поведінку без навчання:
Працюйте поетапно: планування → дія → спостереження → оновлення,
Після кожної дії підсумовуйте спостереження в 1–3 пунктах,
Зупиніться, коли критерії успіху виконано або бюджет вичерпано; поверніть найкращий відомий результат і перелік решти невизначеностей.
Ідеться не про те, щоб змусити модель відповідати багатослівно. Ідеться про те, щоб зробити систему зрозумілою та змусити її на кожному кроці «звірятися з реальністю». Зрозумілий кожному інженеру приклад — заземлення із замкненим циклом у стилі CI:
Планування: запропонувати перелік змін
Дія: запустити тести / лінтер
Спостереження: проаналізувати помилки
Оновлення: внести виправлення й повторити спробу
Кілька запитань, які зазвичай викривають випадкові конструкції агентів:
«Мій агент сам вирішує, що отримувати, чи я завжди отримую дані?»
Якщо отримання даних відбувається безумовно, ви платите за це затримкою, вартістю, розмиванням контексту й вищим ризиком отримати сміття на виході через сміття на вході.
«Чи може мій агент помітити власну помилку?»
Якщо єдиний сигнал зворотного зв’язку для вашого агента — «користувач дратується», ви застосовуєте RL ціною людських страждань. Цикл повторних спроб із валідатором — найпростіший спосіб змусити агента звірятися з реальністю.
«Чи можна записувати дані в пам’ять і чи покращується вона з часом?»
Якщо ваша «пам’ять» лише доповнює історію чату, то ви фактично просто ведете журнали. Важливо, як огляд описує пам’ять: вона стає динамічно зростаючим контекстом, який агенти з часом удосконалюють, а не просто стенограмою.
Журнали розповідають, що сталося, а пам’ять — що робити наступного разу. Історія чату — це стенограма. Пам’ять — це політика, що розвивається й визначає, що варто зберегти на майбутнє.
Для початку підійде невелика таблиця «засвоєних уроків»: ключ складається з типу завдання, інструмента й режиму відмови, а значення описує, що спрацювало та чого слід уникати. Мета не в тому, щоб побудувати ідеальний граф знань. Мета — створити накопичувальний ефект: пам’ять і зворотний зв’язок перетворюють агентів із «помічників без стану» на системи, які з часом удосконалюються.
Виникає спокуса залучити до проблеми більше агентів, але часто це лише примножує витрати на координацію. Хороший шаблон «мінімально життєздатної команди»:
Координатор: розбиває завдання й розподіляє їх
Виконавець: викликає інструменти / вносить зміни
Критик / оцінювач: перевіряє правильність і ризики
Хранитель пам’яті: записує й упорядковує засвоєні уроки
Якщо ви не можете пояснити, за що відповідає кожен агент, імовірно, кілька агентів вам поки не потрібні.
Якщо ми справді приймаємо зміну парадигми, то, імовірно, перестанемо запихати все в запити, вважати збої остаточними результатами й оцінювати агентів як чатботів. Натомість почнемо ставитися до агентів відповідно до їхньої суті: як до програмних систем, де мова слугує площиною керування, а надійність забезпечує цикл.
Перш ніж додавати ще одну модель, додайте ще один цикл оцінювання. Перш ніж отримувати всі дані, зробіть їх отримання умовним. Випустіть один валідатор, перш ніж випускати десять. Ставтеся до пам’яті як до політичних рішень, а не як до бази даних. А переходячи до кількох агентів, почніть із двох, а не двадцяти. Це не правила, а шаблони, які витримали перевірку виробничим середовищем.