Агентні шаблони проектування: книга, яка змусила мене переосмислити питання: «Що саме таке Агент?»

Автор: Yanhua

Антоніо Гуллі — інженерний директор у Google. Він написав 453-сторінкову книгу, яка розбиває розробку AI-агентів на 21 шаблон проектування.

Але це не рецензія на книгу. Моя мотивація для її прочитання дуже конкретна: я писав про Harness Engineering, ділився своїми помилками з Clawdbot і обговорював сім поворотних моментів з теми «AI-агенти — це не магія», які ведуть від спалювання токенів до реальної користі. Після кожного тексту в мене залишалося питання, над яким я не до кінця замислився: чи існує логіка, що лежить в основі цих речей і яку можна повторно використовувати?

Ця книга дала мені відповідь, і вона виявилася глибшою, ніж я очікував.

Можливо, ви взагалі не пишете Агента

Найсуворіше судження в книзі приховане у передмові.

Більшість того, що люди називають «AI», — це лише Рівень 0: гола LLM без інструментів, без пам'яті та без дій. Якщо ви запитаєте її, який фільм став найкращим на «Оскарі» у 2025 році, вона буде вгадувати. Книга чітко стверджує: Рівень 0 — це не Агент.

Рух вгору — це те, де знаходяться справжні Агенти:

• Рівень 1: Користувач інструментів

  Агент починає використовувати інструменти: пошук, API, бази даних. Але справа не лише в «здатності викликати інтерфейси»; він також має оцінювати, коли викликати, що викликати і як використовувати результати. Книга наводить дуже конкретний приклад: коли користувач запитує: «Які нові шоу з'явилися останнім часом?», Агент розуміє, що цієї інформації немає в навчальних даних, і проактивно викликає інструмент пошуку, щоб знайти її, а потім синтезує результат. Ключовий крок — це «самостійне усвідомлення». Це не людина каже йому «шукай», а він сам вирішує, що йому потрібно шукати. Ця здатність до судження є порогом для Рівня 1.

• Рівень 2: Стратегічний мислитель

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

  У книзі є речення, яке я перечитав кілька разів: «Щоб досягти найвищої точності з AI, йому потрібно надати короткий, сфокусований і потужний контекст». Контекстна інженерія саме про це.

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

• Рівень 3: Співпраця мультиагентів

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

Прочитавши про ці чотири рівні, я раптом зрозумів, чому багато хто каже: «Мій Агент не корисний». Проблема не в моделі; проблема в тому, що ви ставитеся до нього як до чат-бота, і він, можливо, навіть не досяг Рівня 1.

Контекстна інженерія: найбільш недооцінена концепція в книзі

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

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

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

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

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

4. Четвертий шар: цикл зворотного зв'язку. Після кожного виводу Агент автоматично оцінює якість і коригує стратегію контексту для наступного разу. Книга називає це «автоматизованою оптимізацією контексту», а Vertex AI Prompt Optimizer від Google є інженерною реалізацією цієї ідеї.

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

Рефлексія: два Агенти справді кращі за одного

Для мене це найбільш практично цінний шаблон у всій книзі.

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

Книга надає повний приклад коду.

• Промпт Виробника: «Ти Python-розробник, напиши функцію для обчислення факторіала, обробляючи крайові випадки та винятки».

• Промпт Критика: «Ти прискіпливий старший інженер, переглянь код рядок за рядком, перевіряючи на наявність помилок, стилю, пропущених крайових випадків та областей для покращення. Якщо все ідеально, виведи CODE_IS_PERFECT; інакше перелічи всі проблеми».

• Потім йде цикл for: Виробник пише код → Критик перевіряє → Виробник вносить зміни на основі відгуків → Критик перевіряє знову → поки Критик не скаже CODE_IS_PERFECT або не буде досягнуто максимальної кількості ітерацій.

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

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

Мультиагентність не стає кращою від більшої складності

Що мені найбільше сподобалося в розділі про співпрацю мультиагентів, так це шість діаграм топології комунікації. Багато людей відразу кидаються у складність, але в більшості сценаріїв достатньо трьох типів:

1. Один Агент (незалежне виконання): завдання можна розбити на незалежні підзавдання, кожен Агент обробляє своє. Просто і легко підтримувати.

2. Однорангова мережа (Peer-to-Peer): Агенти спілкуються безпосередньо один з одним, без центрального вузла керування. Децентралізовано і стійко до відмов; якщо один Агент виходить з ладу, це не впливає на всю систему. Однак витрати на координацію високі, і це легко може стати хаотичним.

3. Супервізор (центральна координація): Агент-супервізор керує групою Агентів-виконавців. Він розподіляє завдання, збирає результати та вирішує конфлікти. Чітка ієрархія та легке керування. Однак Супервізор є єдиною точкою відмови та вузьким місцем продуктивності.

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

Мій досвід показує, що багато людей витрачають 80% свого часу на протоколи комунікації при створенні мультиагентів, забуваючи поставити більш фундаментальне питання: чи дійсно це завдання потребує кількох Агентів? Книга чітко стверджує, що одного Агента 2-го рівня з рефлексією часто достатньо. Рівень 3 призначений для сценаріїв, з якими один Агент справді не може впоратися.

Трирівнева модель пам'яті: я відчував це, але не міг назвати

Розділ про пам'ять найбільше відгукнувся мені, тому що, коли я писав статті про Obsidian + Claude, я постійно розмірковував над питанням: як має бути структурована пам'ять Агента?

Книга дає відповідь:

1. Сесія (шар розмови): контекстне вікно поточної розмови, яке є найкоротшою пам'яттю і зникає після завершення розмови. Моделі з довгим контекстом просто збільшують це вікно, але по суті воно все ще тимчасове, і кожне виведення має обробляти все вікно, що дорого і повільно.

2. Стан (шар стану): тимчасові дані під час поточного завдання. Наприклад: «Яке поточне завдання?», «Як далеко воно просунулося?», «Які дані були згенеровані в процесі?». Довший за сесію, але очищується після завершення завдання; книга використовує механізм стану Google ADK як повний приклад.

3. Пам'ять (постійний шар): довготривала пам'ять, що охоплює сесії та завдання. Уподобання користувача, набутий досвід, важливі історичні рішення, що зберігаються в базах даних або векторних сховищах, із семантичним пошуком. Книга підкреслює важливий момент: пам'ять — це не лише зберігання; вона також вимагає розробки повної стратегії того, «що зберігати, коли зберігати і як витягувати». Зберігання занадто великої кількості створює шум, а занадто малої — недостатньо.

У моїй попередній статті про Clawdbot я згадував «файли стану» та «документи робочої області», які, по суті, були моїми спробами вручну створити шари стану та пам'яті, і книга структурувала цей процес.

П'ять припущень, п'яте — найбільш абсурдне

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

П'яте припущення шокувало мене: Трансформація мультиагентів.

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

Книга називає це «керованою метою, самотрансформованою мультиагентною системою». Вона не виконує план, який ви написали; вона генерує власні плани, коригує їх і самостійно реорганізовує команду виконання.

Це нагадує мені AutoResearch від Karpathy: напишіть program.md, визначте цілі, метрики та межі, і натисніть «старт». Люди поза циклом. Але ця книга йде далі: навіть те, як формується та реорганізовується команда Агентів, залишається на розсуд системи. Люди лише заявляють, «чого вони хочуть».

Три дії, які ви можете зробити негайно

Після закінчення цієї книги я маю три негайні дії, які можу впровадити:

• По-перше, додайте Критика до вашого поточного Агента. Незалежно від того, чи використовуєте ви Claude Code, CrewAI або фреймворк, який ви створили самі, додайте крок у кінці вашого існуючого робочого процесу: нехай інший Агент (з іншим системним промптом) перегляне результат попереднього кроку. Генерація коду плюс перегляд коду, написання статті плюс перевірка фактів, планування плюс оцінка здійсненності. Це додає ще один виклик LLM, але покращення якості часто подвоюється. Модель «Виробник-Критик» у книзі готова до використання.

• По-друге, почніть займатися контекстною інженерією, а не лише промпт-інженерією. Озирніться на файли інструкцій, які ви написали для Агента. Якщо це лише правила про те, «як ви повинні це робити», без контексту про те, «з яким середовищем ви зараз стикаєтеся», заповніть це. Скажіть Агенту, у якому проекті він зараз бере участь, які рішення були прийняті раніше і які вподобання користувача. Розділ про контекстну інженерію в книзі та ваш AGENTS.md — це два вирази одного й того самого.

• По-третє, не поспішайте з мультиагентами. Доведіть свого одного Агента до Рівня 2: з інструментами, рефлексією та пам'яттю. Книга неодноразово підкреслює, що один Агент 2-го рівня в поєднанні з «Виробником-Критиком» та контекстною інженерією може охопити переважну більшість практичних сценаріїв. Рівень 3 призначений для завдань, які справді вимагають крос-доменного, багатоетапного та паралельного розподілу праці. Проблема більшості людей не в тому, що їм не вистачає Агентів, а в тому, що вони не оптимізували одного Агента.

Ця книга має 453 сторінки і буде опублікована Springer у 2025 році. Приклади коду охоплюють LangChain/LangGraph, Google ADK, CrewAI та OpenAI API. Передмову написав віце-президент Google Cloud AI, а також є рекомендація від CIO Goldman Sachs, яка написана напрочуд добре.

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

Хтось уже намалював для вас карту; залишилося лише пройти нею.

Чи використовуєте ви AI-агентів для розробки? На якому рівні знаходиться ваш поточний Агент?