Автор: Yanhua
Антоніо Гуллі — директор з інженерії у Google. Він написав книгу обсягом 453 сторінки, у якій розбив розробку AI Agent на 21 шаблон проектування.
Але це не огляд книги. Моя мотивація читати цю книгу була дуже конкретною: я писав про Harness Engineering, про досвід з Clawdbot, про статтю «AI-агенти — це не магія», де розказував про сім переломних моментів від витрачання токенів до справді корисного результату. Після кожного написаного матеріалу залишався незавершений питання: чи існує за цим усім єдина повторно використовувана базова логіка?
Ця книга дала мені відповіді, і глибше, ніж я очікував.
Те, що ти написав, може взагалі не бути агентом
Найбільш жорстке твердження в книзі приховане в прологу.
Більшість людей використовують «ШІ», який є рівнем 0: чистий LLM без інструментів, без пам’яті, не здатний діяти. Коли ви запитуєте його, який фільм отримає Оскар 2025 року, він гадає. У книзі це сказано дуже прямо: рівень 0 — це не агент.
Вгору — це справжній агент:
Рівень 1: Користувач інструментів
Агент починає використовувати інструменти: пошук, API, бази даних. Але це не просто «може викликати інтерфейси» — він має самостійно визначати, коли викликати, що викликати та як використовувати результати. У книзі наведено конкретний приклад: користувач запитує «Які нові серіали з’явилися останнім часом?» Агент сам усвідомлює, що ця інформація відсутня в тренувальних даних, і активно викликає інструмент пошуку, а потім синтезує результат. Ключовий етап — «саме усвідомлення». Це не людина каже йому: «Зайди і пошукай», а він сам вирішує, що потрібно шукати. Ця здатність до прийняття рішень — це поріг рівня 1.
Рівень 2: Стратегічний мислитель
Додалися дві речі: планування та Context Engineering. У книзі визначено Context Engineering: не накопичувати інформацію, а обирати, обрізати та упаковувати контекст. Приклад чудовий: користувач шукає кав’ярню між двома місцями. Агент спочатку викликає інструмент карти, отримуючи великий обсяг даних, а потім сам вирішує, що «на наступному етапі достатньо лише назв вулиць», обрізає вивід карти до короткого списку і передає його локальному пошуковому інструменту. Кожен крок здійснює шумоподавлення інформації.
У книзі є одне речення, яке я кілька разів перечитував: «Щоб досягти найвищої точності штучного інтелекту, потрібно надавати йому короткий, зосереджений і потужний контекст». Context Engineering — це саме про це.
На цьому рівні агент здатний до саморефлексії. Після виконання завдання він сам перевіряє результат і виправляє помилки. Пізніше я детально розповім про це.
Рівень 3: Взаємодія кількох агентів
Позиція книги є чіткою: не намагайтеся створити універсального супер-агент. Насправді надійний підхід — це побудова команди, як у проекті: агент-менеджер проекту + агент-дослідник + агент-дизайнер + агент-копірайтер. У книзі наведено приклад запуску нового продукту: «агент-менеджер проекту» координує загальні дії та розподіляє завдання між «агентом ринкових досліджень», «агентом дизайну продукту» та «агентом маркетингу». Ключовим є зв’язок: як агенти обмінюються даними, синхронізують статуси та вирішують конфлікти. У цьому розділі наведено шість типів комунікаційних топологій — від найпростішої одноагентної до найбільш гнучкої користувацької гібридної, і для кожної пояснено, які сценарії вона підходить.
Після того як я ознайомився з цими чотирма рівнями, я раптом зрозумів, чому багато людей кажуть: «Мій агент не працює». Модель у порядку, проблема в тому, що ви використовуєте її як чат-бота — вона, можливо, навіть не досягла рівня 1.
Контекстне інженерія: Найменш оцінена концепція в книзі
Я писав про Harness Engineering, де йшлося про те, що дизайн траси важливіший, ніж потужність двигуна. Після прочитання цієї книги я зрозумів, що Context Engineering — це відображення Harness Engineering на рівні prompt.
Традиційне Prompt Engineering стосується лише «як ви запитуєте». Context Engineering з книги стосується «що агент бачить перед собою перед запитом». Вона включає чотири рівні інформації:
Перший рівень, system prompt. Визначає, хто такий агент, який тон і які межі. Більшість людей пише лише цей рівень.
Другий рівень, зовнішні дані. Документи, отримані за допомогою RAG, результати викликів інструментів, дані з реального API. Це місце, де застрягають більшість: вони знають, що потрібно подавати дані, але не знають, як це зробити, щоб не затопити модель.
Третій рівень, неявні дані. Ідентифікатор користувача, історія взаємодій, стан оточення. Те, що ви не виражаєте прямо, але агент повинен знати. Наприклад, коли ви кажете агенту: «Допоможи мені надіслати листа Джону, щоб підтвердити зустріч завтра», він повинен знати, яка зустріч у вашому календарі завтра і які стосунки у вас з Джоном.
Четвертий рівень, зворотний зв’язок. Після кожного виводу агента автоматично оцінюється якість та налаштовується стратегія контексту для наступного разу. У книзі це називається «автоматизована оптимізація контексту», а Prompt Optimizer Google Vertex AI — це інженерна реалізація цієї ідеї.
Коли я читав це, мені спало на думку, як я раніше писав статтю «AI-агенти — це не магія», де один із досвідів був: «Вашому агенту потрібні правила, і багато правил». Зараз, дивлячись назад, ці правила були суттєво ручною версією Context Engineering, яку в цій книзі систематизовано.
Рефлексія: Два агенти справді краще, ніж один
Це найбільш практично корисний шаблон для мене в цій книзі.
Суть Reflection проста: агент після виконання завдання сам перевіряє себе та виправляє помилки. Але спосіб реалізації має значення. У книзі чітко зазначено: Producer і Critic повинні бути двома різними агентами з різними system prompt. Один і той самий персонаж не може ефективно перевіряти власну роботу — завжди будуть сліпі зони. Якщо ви попросите той самий LLM спочатку написати код, а потім перевірити його, він, найімовірніше, скаже: «Дуже добре».
У книзі наведено повний приклад коду.
Продюсер запитав: «Ти Python-розробник, напиши функцію для обчислення факторіала, яка обробляє граничні умови та винятки».
Помітка Critic: «Ти — висококваліфікований інженер, який докладно перевіряє код рядок за рядком, шукаючи баги, порушення стилю, пропущені граничні умови та місця для покращення. Якщо код ідеальний, виведи
CODE_IS_PERFECT, інакше перелічи всі проблеми».Потім — цикл for: Producer пише код → Critic перевіряє → Producer вносить зміни згідно з зауваженнями → Critic перевіряє знову → доки Critic не скаже
CODE_IS_PERFECTабо не буде досягнуто максимальну кількість ітерацій.
Це дуже просто. Але в книзі звертається увага на одну легко знехтувану витрату: кожен цикл рефлексії — це новий виклик LLM, і чим більше ітерацій, тим дорожче. Крім того, із зростанням історії діалогу контекстне вікно заповнюється попередніми версіями та зауваженнями, і реальний доступний простір для міркувань скорочується. Тому найкращою практикою для Reflection є: встановити розумну максимальну кількість ітерацій (у книзі використовується 3), і зупинитися, як тільки Critic задоволений — не прагніть до ідеалу.
Застосування виходять далеко за межі написання коду. Написання статей, складання планів, підсумовування документів, розв’язання логічних задач — модель Producer-Critic підходить для всього цього. У книзі наведено сім сценаріїв застосування, і їхня основна логіка однакова: спочатку створити, потім перевірити, а потім виправити.
Multi-Agent не означає, що чим складніше, тим краще
Мені найбільше сподобалася ця глава про співпрацю багатоагентних систем із шістьма типами комунікаційних топологій. Багато хто одразу звертається до складних рішень, але насправді для більшості сценаріїв достатньо трьох:
Один агент (незалежне виконання): завдання можна розбити на незалежні підзадачі, кожен агент вирішує свою. Просто, легко підтримувати.
Пір-до-пір (Peer-to-Peer): агенти взаємодіють безпосередньо, без центрального вузла керування. Децентралізовано, висока стійкість до відмов, відключення одного агента не впливає на всю систему. Але витрати на координацію високі, легко виникає хаос.
Супервізор (центральне планування): Супервізорний агент керує групою агентів-виконавців. Розподіляє завдання, збирає результати, вирішує конфлікти. Чітка ієрархія, зручне управління. Але супервізор — це єдина точка відмови та обмеження продуктивності.
Ще три (Supervisor-as-Tool, ієрархічна, користувацька гібридна) — це варіації та комбінації перших трьох. У книзі чесно зазначено: вам потрібна топологія, яка відповідає складності вашого завдання. Чим більше ви розбиваєте завдання на частини, тим вищими стають витрати на зв’язок, і на певному етапі модель Supervisor стає ефективнішою, ніж ієрархічна.
Мій досвід показує, що багато хто, створюючи Multi-Agent, витрачає 80% часу на протоколи зв’язку, забуваючи задати більш фундаментальне питання: чи дійсно це завдання вимагає кількох агентів? У книзі чітко сказано, що одного агента рівня 2 з Reflection часто вистачає. Рівень 3 призначений для сценаріїв, де один агент справитися не може.
Модель пам’яті з трьома рівнями, яку я раніше неявно відчував, але не назвав
Ця глава про пам’ять мені найбільше симпатична, бо коли я писав дві статті про Obsidian + Claude, я постійно думав над питанням: як має бути розподілена пам’ять агента?
У книзі є відповідь:
Сеанс (сесійний рівень): контекстне вікно поточного діалогу — це найкоротша пам’ять, яка зникає після завершення діалогу. Моделі з довгим контекстом лише розширюють це вікно, але за суттю воно залишається тимчасовим, і кожен висновок вимагає обробки всього вікна, що є дорогим і повільним.
State (стан): тимчасові дані, що зберігаються під час виконання поточного завдання. Наприклад, «яке завдання зараз виконується», «на якому етапі вже завершено», «які дані були отримані проміжно». Тривалість довша, ніж у Session, але очищається після завершення завдання. У книзі повний приклад використання механізму State від Google ADK.
Пам’ять (постійний рівень): довгострокова пам’ять, що працює між сеансами та завданнями. Переваги користувача, здобуті досвід, важливі історичні рішення зберігаються в базі даних або векторному сховищі з семантичним пошуком. У книзі підкреслюється важливий момент: пам’ять — це не просто зберігання, а розробка цілісної стратегії «що зберігати, коли зберігати та як шукати». Занадто багато даних — багато шуму, занадто мало — недостатньо для використання.
У статті про Clawdbot, яку я писав раніше, я згадував «файл стану» та «документи робочого середовища» — суттєво це було ручне створення шарів State та Memory, а в книзі цей процес було структуровано.
П’ять припущень, п’яте — найбільш абсурдне
У кінці книги наведено п’ять припущень щодо майбутнього агентів; перші чотири ще знаходяться в межах раціональних передбачень: універсальні агенти переходять від написання коду до керування проектами, глибока персоналізація та активне виявлення ваших потреб, ембодіровані інтелектуальні системи виходять за межі екрана до фізичного світу, агенти стають незалежними економічними суб’єктами.
П’ятий, що мене вразив:变形 Multi-Agent.
Ви лише визначаєте мету, наприклад: «Створити електронну комерційну справу з продажу преміального кави». Система автоматично вирішує: спочатку створити «Агента ринкових досліджень» та «Агента бренду». Після проходження одного циклу даних система самостійно визначає, що Агент бренду не потрібен, і розбиває його на три нові: «Агент дизайну логотипу», «Агент створення сайту», «Агент ланцюга поставок». Якщо Агент створення сайту стає обмеженням, система автоматично копіює три паралельних Агенти, які одночасно працюють над різними сторінками. У процесі система безперервно автоматично оптимізує промпти кожного Агента та постійно переформовує архітектуру команди.
У книзі це називають «цілеспрямованою, самотрансформуючою багатоагентною системою». Вона не виконує план, який ви написали, а сама генерує план, сама його коригує та сама переформовує команду виконавців.
Це нагадує AutoResearch від Karpathy: напишіть program.md, визначте мету, показники, межі, і запустіть. Людина знаходиться поза циклом. Але ця книга йде ще далі: навіть те, як створювати та переформовувати команду агентів, залишається на розсуд системи. Людина лише оголошує «що потрібно».
Три речі, які можна зробити відразу
Прочитавши цю книгу, я маю три дії, які можу відразу застосувати:
По-перше, додайте до вашого поточного агента критика. Незалежно від того, чи використовуєте ви Claude Code, CrewAI чи власну рамку, додайте на кінець вашого поточного робочого процесу ще один крок: нехай інший агент (з іншим system prompt) перевірить вихід попереднього кроку. Генерація коду + перевірка коду, написання статей + перевірка фактів, розробка планів + оцінка доцільності. Ще один виклик LLM, але якість часто подвоюється. Модель Producer-Critic з книги — це «вставив і працює».
Друге, почніть з Context Engineering, а не лише Prompt Engineering. Поверніться до файлу інструкцій, які ви надали агенту. Якщо там лише правила виду «Як тобі діяти», але немає контексту «Яку ситуацію ти зараз маєш», додайте його. Повідомте агенту, в якому проекті він зараз перебуває, які рішення приймав раніше та які переваги має користувач. Розділ про Context Engineering у книзі та ваш
AGENTS.md— це два вирази однієї й тієї ж справи.Третє: не поспішайте переходити до Multi-Agent. Спочатку доведіть свій одиночний Agent до рівня 2: з інструментами, Reflection та Memory. У книзі неодноразово підкреслюється, що одиночний Agent рівня 2 разом із Producer-Critic та Context Engineering може охопити більшість реальних сценаріїв. Рівень 3 призначений для справжніх завдань, що вимагають міжгалузевої роботи, багатоетапності та паралельного розподілу обов’язків. Проблема більшості людей не в тому, що Agent’ів замало, а в тому, що навіть один Agent ще не налаштовано правильно.
Ця книга має 453 сторінки, видано Springer у 2025 році. Приклади коду охоплюють LangChain/LangGraph, Google ADK, CrewAI, OpenAI API. Передмову написав віце-президент Google Cloud AI, а також є рекомендаційний передмову від CIO Goldman Sachs — несподівано цікаво.
Але причина, чому я рекомендую його, — не «всебічність». Після прочитання ви зрозумієте одну річ: усі проблеми, з якими ви стикалися за останні шість місяців у Agent, хтось вже систематизував у вигляді шаблонів. Вам не потрібно виновувати Reflection, не потрібно вгадувати, як розподілити Memory, і не потрібно експериментувати зі схемами комунікації Multi-Agent.
Хтось намалював для тебе карту, тепер залишилося просто йти.
Ви розробляєте за допомогою AI Agent? На якому рівні зараз ваш Agent?