Модель зрілості агентів: людський нагляд, інженерія керування, оркестрація.
П’ять рівнів зрілості агентів, перевірених у реальних умовах: людський нагляд, інженерія керування, оркестрація кількох агентів та проблеми, які досі залишаються нерозв’язаними.
Джерела: Agentic Architectures — Article 15: The Maturity Model Revisited
Модель зрілості агента легко намалювати, але важко впровадити в практику. На папері вона виглядає чистою: це драбина, яка починається з простих інструментів для виклику та закінчується самовдосконалюваними системами виробництва. Фреймворки завжди виглядають охайними, поки хтось не спробує запустити їх під навантаженням. Як тільки за ними опиняється справжній код, та сама модель починає виглядати інакше. У ній не було помилок, але знання теоретично та знання на практиці — це різні види знань. Карта не може показати, як виглядає дорога о третій годині ночі, коли автоматичний вимикач не вимикається, а ви знаходитеся у черзі чергування.
Це огляд того моделювання після того, як були створені всі його складові: як рівні відповідають інженерним рішенням, які припущення не витримали тестування в умовах виробництва, як виглядає ієрархічна архітектура, та що залишилося нерозв’язаним. Код тут мінімальний. Мета — відступити на крок назад та побачити всю структуру цілком.
П’ять рівнів, кожен з яких ґрунтується на попередньому
Модель зрілості описує п’ять рівнів можливостей агента. Кожен рівень є не просто посиленою версією попереднього, адже він також залежить від усього, що знаходиться нижче. Неможливо пропускати етапи. Агент не може бути надійно автономним без інфраструктури для оцінки, а також не може покращувати себе без пам’яті. Ці рівні поєднуються між собою.
Ось як інженерні аспекти відповідають цим рівням:
+---------+---------------------+------------------------------------------+
| Level | Capability | Articles That Build It |
+---------+---------------------+------------------------------------------+
| Level 1 | Reactive | Article 4: Protocols (MCP, A2A) |
| | Responds to inputs, | Basic tool use, standard interfaces |
| | calls tools | |
+---------+---------------------+------------------------------------------+
| Level 2 | Assisted | Article 5: Harness Engineering |
| | Shaped behavior, | Article 13: Human-in-the-Loop |
| | human oversight | |
+---------+---------------------+------------------------------------------+
| Level 3 | Supervised | Article 6: Multi-Agent Orchestration |
| | Coordinated, | Article 8: Evaluation Pipelines |
| | evaluated, secured | Article 9: Security and Red-Teaming |
+---------+---------------------+------------------------------------------+
| Level 4 | Autonomous | Article 7: Memory Architectures |
| | Operates | Article 10: Cost Optimization |
| | independently at | Article 11: Deployment Patterns |
| | scale | Article 14: Goal-Directed Loops |
+---------+---------------------+------------------------------------------+
| Level 5 | Self-Improving | Articles 7 + 8 combined |
| | Learns from its own | Article 12: The frontier (not yet here) |
| | operation | |
+---------+---------------------+------------------------------------------+
Форма має більше значення, ніж мапування. Рівень 5, самосвідоме вдосконалення, не має окремого компонента, оскільки це не те, що можна побудувати безпосередньо. Воно виникає, коли пам’ять та оцінка працюють разом, але навіть тоді ця сфера ще не є повністю розвиненою. Верхня частина моделі все ще є частково амбітною метою. Самосвідоме вдосконалення сьогодні можна лише наблизити, але не досягти повністю.
Це не було очевидно, коли модель вперше була схематизована. Рівень 5 здавався кінцевою метою, яку можна досягти шляхом збирання правильних елементів. На практиці він більше схожий на горизонт, який віддаляється у міру наближення до нього.
Переконання, які були скориговані під час реалізації, від людини в процесі до оркестрації
Це та частина, яку документ фреймворку ніколи не зможе охопити, адже вона виникає лише в процесі створення. Кілька початкових припущень виявилися хибними або принаймні неповними.
Пам’ять була сильно недооцінена. У першому ескізі пам’ять розглядалася як окрема функція, яка допомагає агентам відчувати більшу послідовність у діях. Однак її розробка показала, що пам’ять є інфраструктурою, яка включає все, що це слово означає: проектування схем, якість пошуку інформації, правила зниження якості даних та ізоляцію користувачів. Далі слідував ще більш неприємний урок: навіть інфраструктура, яку ми вміємо створювати, не є ідеальною абстракцією. Команди використовують бази даних, розроблені для інших завдань, оскільки не існує спеціально створених рішень. Пам’ять була найбільш недооціненою складовою у початковій моделі.
Метою є прогнозованість, а автономія є другорядною. Це найглибша зміна. Спочатку прогрес вимірювався тим, наскільки агент міг діяти без людини, тож кожен додатковий елемент незалежності вважався проявом розвитку. Однак агент, який діє самостійно, але непрогнозовано, просто швидше завдає шкоди. У кожному серйозному застосуванні надійність під наглядом виявилася важливішою за просту незалежність. Одним із прикладів невдачі був агент, який автономно створював десятки дублікатів заявок. Системам у продакшені потрібна належна кількість автономії: обмежена, підлягаюча перевірці та прогнозована, з людьми, які приймають рішення, вартість яких вимагає уваги людини. Один із читачів колись стверджував, що оркестрація має прагнути до прогнозованості, а не до автономії, і з цим твердженням довелося довго погоджуватися.
Безпека є властивістю кожного шару. Початковий план розглядав безпеку як тему, яка стоїть ближче до кінця, щось, що додається після того, як система починає працювати. Введення команд ззовні виправляє цю ситуацію. Його цілі знаходяться в інших місцях: у місці виклику інструментів, у шляху запису пам’яті, у способі коригування цілей та у обміні даними між агентами. Кожен компонент має аспект безпеки. Аутентифікація на межі інструментів, ізоляція в пам’яті та контроль за коригуванням цілей — усе це є елементами безпеки, які поширені по всій системі, а не зосереджені в одному місці.
Цикл має вищий пріоритет, ніж запит. Цей урок був останнім та міг бути кориснішим на початку. Багато зусиль у цій галузі спрямовано на розробку запитів та пошук ідеальних формулювань. Але агент — це не запит. Це цикл, який досягає мети через кілька кроків, і ідеальний запит у пошкодженому циклі дасть вам витонченого агента, який ніколи не досягне мети. Як тільки ви почнете мислити у термінах циклів, багато проблем, які здавалися обмеженнями моделі, виявляються помилками в проектуванні циклів.
Наявність людини у процесі не є дефектом, який можна усунути шляхом інженерних заходів. Легко припустити, що участь людини — це тимчасова допомога, яку потрібно прибрати з розвитком технологій. Найкращі системи агентів для виробництва — це не найбільш автономні. Вони розміщують людське судження саме там, де воно потрібне, і ніде більше. Керівництво людини — це не етап, який потрібно пройти, щоб закінчити роботу. Це свідома, постійна риса будь-якої системи, помилки якої мають реальні наслідки.
Вся структура в одному зображенні
Якщо об’єднати все вищезазначене, зріла система агентів виглядає ось так:
+==========================================================================+
| HUMAN OVERSIGHT LAYER |
| Approval gates, escalation, audit trail (Article 13) |
+==========================================================================+
| | |
+==========================================================================+
| GOAL & LOOP LAYER |
| ReAct / Plan-Execute / Reflexion, goal revision (Article 14) |
+==========================================================================+
| | |
+==========================================================================+
| ORCHESTRATION LAYER |
| Supervisor-worker, pipeline, fan-out, debate (Article 6) |
+==========================================================================+
| | |
+==========================================================================+
| HARNESS LAYER |
| Self-verification, loop detection, reasoning routing (Article 5) |
+==========================================================================+
| | |
+--------------------------------------------------------------------------+
| MODEL LAYER |
| AWS Bedrock: Claude 3.7 / 3.5 / Haiku |
+--------------------------------------------------------------------------+
CROSS-CUTTING CONCERNS (touch every layer above):
+----------------+ +----------------+ +----------------+ +----------------+
| MEMORY | | EVALUATION | | SECURITY | | COST |
| Article 7 | | Article 8 | | Article 9 | | Article 10 |
| episodic, | | offline+online | | injection def, | | model routing, |
| semantic, | | LLM judge, | | guardrails, | | caching, |
| procedural | | regression | | red-teaming | | batch, budget |
+----------------+ +----------------+ +----------------+ +----------------+
+--------------------------------------------------------------------------+
| DEPLOYMENT LAYER (Article 11) |
| Blue-green, canary, state migration, model pinning, IaC |
+--------------------------------------------------------------------------+
Вертикальні шари утворюють шлях запиту. Завдання потрапляє сюди через людський контроль, формується під впливом цілей та циклів, координується між різними агентами, вдосконалюється за допомогою спеціальних інструментів та нарешті виконується щодо моделі. Проблеми, які стосуються всієї системи, досягають кожного шару. Пам’ять забезпечує як функціонування циклів, так і роботу інструментів. Безпека захищає межі інструменту та процес коригування цілей. Витрати визначають маршрутизацію моделі на кожному кроці. Розгортання об’єднує все це в єдине ціле.
Погляд на кожен шар окремо приховує те, наскільки тісно всі ці елементи взаємопов’язані. Зміна в одному елементі впливає на інші. Неможливо оптимізувати витрати, не розуміючи принципів функціонування циклів, адже дорогий запуск часто є наслідком циклу, який не закінчується. Для забезпечення безпеки також необхідне розуміння функціонування пам’яті, адже пошкоджений запис продовжує завдавати проблем навіть довго після свого створення. Слід розглядати ці шари як єдину взаємопов’язану структуру, а не набір окремих модулів.
Що ще ніхто не вирішив
Це, можливо, найкорисніший розділ, адже все, що описано вище, стосується того, що можна створити, тоді як тут описується те, що поки що неможливо. Чесна карта меж цінується вище, ніж ідеальна.
Пам’ять, притаманна агенту, не існує. Сучасна пам’ять складається з баз даних та векторних сховищ, створених для інших цілей. Справжня система, притаманна агенту, яка відстежує час, здійснює пошук за асоціаціями, навмисно забуває та дозволяє агенту вирішувати, що записувати, за деякими оцінками, ще за кілька років не з’явиться. Те, що існує, працює. Але це не те, що потрібно.
Агенти не можуть надійно визначити, коли їхні знання є актуальними. Це глибша форма проблеми застарілої пам’яті. Агент може знайти відповідну процедуру та з впевненістю застосувати її у ситуації, де вона не підходить, оскільки важко визначити момент, коли певні знання втрачають силу, а ще складніше перевірити це під час їх використання. Процедура, яка ефективна в одній юрисдикції, може бути неправильно застосована в іншій, і ні агент, ні, часто, користувач цього не помічають. Це фундаментальна обмеженість, а не просто технічна прогалина.
Самооцінка є ненадійною. Логіка ескалації та оцінка впевненості залежать від того, чи зможе агент точно оцінити власну впевненість. Іноді йому це вдається, а іноді він помиляється, вдаючи, що впевнений, що є найбільш шкідливим варіантом, адже це усуває всі захисні механізми, які залежать від усвідомлення агентом своїх обмежень. Поки що не існує надійного способу калібрування самооцінки.
Інструменти не передаються між моделями. Кожен інструмент налаштовується під поведінку конкретної моделі. Якщо змінити модель, потрібно заново налаштовувати запити, пороги виявлення циклів та критерії перевірки. У принципі це не мусить бути так, але ніхто ще не створив абстракцію інструментів, яка б залишалася функціональною після заміни моделі без корекцій. Оновлення моделі залишається окремим проектом, а не зміною конфігурації.
Не існує справжнього безперервного навчання. Процедурна пам’ять імітує навчання: успішні підходи зберігаються та використовуються знову. Проте ваги не змінюються, і агент не розвиває нових навичок завдяки досвіду. Він створює бібліотеку минулих рішень та черпає з неї. Агент, який справді покращує свої результати у певній категорії задач завдяки досвіду, — це те, чого сучасні продуктові системи поки не можуть досягти.
Витрати є непередбачуваними у крайніх випадках. Існують інструменти для керування витратами, і вони ефективні, але крайні значення розподілу залишаються складними для контролю. Невелика кількість виконань, ті, що потрапляють у патологічні цикли чи незручні крайні випадки, все ще споживають непропорційно багато ресурсів способами, які важко передбачити. Хоча можна обмежити ці витрати, їх завжди не вдається точно прогнозувати.
Жоден із цих факторів не є причиною для відкладань. Це краї поточної „карти“, і саме знання їхнього розташування відрізняє інженерію від утопічних мрій.
З чого почати: розвивайте інженерію перед оркестрацією агентів
Якщо ви створюєте систему агентів, не розглядайте ці елементи як послідовність кроків побудови. Вони групуються за концепціями, а не за порядком реалізації. Якщо будувати все у такій послідовності, ви створите „пам’ять“ ще до того, як у вас з’явиться засіб для її використання, а також механізм оцінки ще до того, як буде щось для оцінки.
Почніть з того рівня зрілості, на якому знаходиться ваша система.
- Агент, який виконує базові дії з викликом інструментів та є ненадійним, повинен спочатку розвивати інженерні аспекти, адже саме тут полягають більшість проблем з надійністю.
- Надійний одиночний агент, який досяг своїх меж, готовий до оркестрації кількох агентів.
Інструменти можна замінювати, а ідеї — ні
Приклади, які використовувалися під час цієї дискусії, були створені на основі AWS Bedrock, LangGraph та LangChain. Це були практичні вибори, зроблені через те, що саме ці технології використовувалися в продакшені, проте вони не є єдиними правильними варіантами. Більшість важливих аспектів не пов’язані саме з ними. Аутентифікація має знаходитися на рівні інструменту в будь-якій хмарі. У будь-якій платформі більше значення має логіка виконання завдань, ніж формулювання запиту. Рівні пам’яті, шаблони координації кількох агентів, категорії атак та критерії зворотності взаємодії з урахуванням витрат для людського контролю можуть бути застосовані до інших технологічних стеків.
Саме тому варто мати локальну альтернативу з Ollama та Docker. Це дозволяє запускати ці шаблони без необхідності платити за послуги хмари та доводить, що концепції можна відокремити від їхньої реалізації. Якщо архітектура пам’яті працює з локальною моделлю та локальним сховищем векторів, то такий дизайн взагалі нічим не зобов’язаний Bedrock. Він охоплює основну проблему, яка виглядає однаковою на будь-якій платформі. Те саме стосується шаблонів оркестрації – заміна LangGraph на інший фреймворк змінює синтаксис циклу, але не способи виникнення помилок, з якими потрібно боротися; те саме стосується інструментів оцінки, які можна налаштувати під будь-яку модель, що знаходиться за ними.
Що виявилося під час запису
Чітке та послідовне пояснення теми людині, яка не була присутня під час вашого навчання, виявляє прогалини у власному розумінні. Багато тем здаються оволодіними аж до моменту, коли намагаєшся їх записати.
Чесна картина ситуації в цій галузі полягає у тому, що вона водночас і захоплююча, і незріла. Зараз можливі речі, які не були можливими два роки тому, і легко обманути себе, адже вільне викладення ідей здається більш компетентним, ніж є насправді. Різниця між агентом, який добре демонструє свої можливості, та тим, який надійно працює в реальних умовах, є величезною, і більшість складнощів інженерії полягає саме в цій прогалині.
Якщо є одне повідомлення, яке варто надіслати назад на початок, то це те, що цікава робота не робить агентів потужнішими. Моделі вже є потужними та продовжують вдосконалюватися за графіком, який ви не контролюєте. Справжня робота полягає у тому, щоб зробити потужні моделі надійними, прогнозованими, безпечними та достатньо доступними, щоб покладатися на них у прийнятті реальних рішень. Це інженерія, а не магія: керування, цикли, пам’ять, оцінка та вся непримітна інфраструктура, яка перетворює здатну модель на щось, на що можна покластися.
Інтелект запозичується з моделі. Архітектуру доводиться будувати самостійно.
Пов’язана література
- Практичні нотатки: Агентні архітектури, Стаття 12: Чи готові ми до цього: Детальний огляд Практичних нотаток: Агентні архітектури, Стаття 12: Чи готові ми до цього: контракти, перевірки та шаблони коду для команд, які використовують цю модель.
- Участь людини у роботі AI-агентів: брами схвалення, ескалація, журнали аудиту: У випадках, коли агенту потрібне схвалення людини, описано чотири підходи (брами, ескалація, спільна редагування, вибірка даних), можливості призупинення та продовження роботи за допомогою LangGraph, таймаути, журнали аудиту та поширені проблеми.