Паттерны проектирования агентов: книга, которая помогла мне понять, что же такое "Агент" на самом деле

Автор: Yanhua

Антонио Гулли — директор по инженерным вопросам в Google. Он написал книгу на 453 страницы, разбив разработку AI-агентов на 21 паттерн проектирования.

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

Эта книга дала мне ответ, и он оказался глубже, чем я ожидал.

Вы, возможно, пишете совсем не агента

Самый жёсткий вывод книги спрятан в прологе.

Большинство людей используют «ИИ» лишь на Уровне 0: голый LLM, без инструментов, без памяти, без способности действовать. Вы спрашиваете, какой фильм получил «Оскар» в 2025 году, он угадывает. В книге это сказано прямо: Вещи на Уровне 0 — это не агенты.

Только продвигаясь выше, получаем настоящего агента:

• Уровень 1: Пользователь инструментов

  Агент начинает использовать инструменты: поиск, API, базы данных. Но это не просто «способность вызывать API», он должен сам решать, когда вызывать, что вызывать и как использовать результат. В книге приводится конкретный пример: пользователь спрашивает «Какие новые сериалы вышли?», агент сам понимает, что этой информации нет в обучающих данных, сам вызывает поисковый инструмент, чтобы найти её, и затем синтезирует результат. Ключевой шаг — «сам понимает». Не человек говорит ему «пойди поищи», а он сам решает, что нужно искать. Эта способность принимать решения — порог для Уровня 1.

• Уровень 2: Стратегический мыслитель

  Появляются ещё две вещи: планирование и Инженерия контекста (Context Engineering). В книге даётся определение Context Engineering: не складывание информации, а тщательный отбор, обрезка и упаковка контекста. Пример очень хорош: пользователь хочет найти кофейню между двумя точками. Агент сначала вызывает картографический инструмент, получает кучу данных, затем сам решает, что «для следующего шага нужны только названия улиц», обрезает вывод карты до короткого списка и передаёт его инструменту локального поиска. На каждом шаге происходит очистка информации от шума.

  Одна фраза из книги заставила меня перечитать её несколько раз: «Чтобы ИИ достиг максимальной точности, ему нужно предоставить короткий, сфокусированный, мощный контекст.» Context Engineering как раз этим и занимается.

  На этом уровне агент также способен к саморефлексии. Закончив работу, он сам её проверяет, находит проблемы и сам их исправляет. Об этом я расскажу подробнее позже.

• Уровень 3: Коллаборация нескольких агентов

  Позиция книги предельно ясна: не нужно пытаться создать одного супер-агента на все случаи жизни. По-настоящему надёжный подход — собрать команду, как в реальной жизни: агент-проектный менеджер + агент-исследователь + агент-дизайнер + агент-копирайтер. Пример из книги — запуск нового продукта: «Агент-проектный менеджер» осуществляет общую координацию, распределяет задачи между «Агентом по исследованию рынка», «Агентом по дизайну продукта», «Маркетинговым агентом». Ключ — в коммуникации: как агенты передают данные, синхронизируют состояние, разрешают конфликты. В этой главе нарисовано шесть топологий коммуникации, от самого простого (один агент) до самого гибкого (пользовательская гибридная), с пояснениями, какая для какого сценария подходит.

Посмотрев на эти четыре уровня, я вдруг понял, почему многие говорят «мой агент плохо работает». Модель в порядке, проблема в том, что вы используете его как чат-бота, он, возможно, даже не достиг Уровня 1.

Context Engineering: самая недооценённая концепция в книге

Я писал о Harness Engineering, о том, что дизайн трассы важнее мощности двигателя. Прочитав эту книгу, я понял, что Context Engineering — это отображение Harness Engineering на уровне промтов.

Традиционный Prompt Engineering занимается только тем, «как ты спрашиваешь». Context Engineering из книги занимается тем, «что лежит перед глазами агента перед тем, как спросить». Это включает в себя четыре слоя информации:

1. Первый слой, system prompt. Определяет, кто агент, какой у него тон, какие границы. Большинство людей пишут только этот слой.

2. Второй слой, внешние данные. Документы, найденные через RAG, возвращаемые значения вызовов инструментов, данные из API в реальном времени. Здесь большинство застревает: понимают, что нужно накормить данными, но не знают, как это сделать, чтобы не «утопить» модель.

3. Третий слой, неявные данные. Идентификация пользователя, история взаимодействия, состояние окружения. То, что вы явно не говорите, но что агенту следует знать. Например, вы говорите агенту «помоги отправить Джону письмо для подтверждения завтрашней встречи», он должен знать, какая встреча в вашем календаре завтра и как вы с Джоном связаны.

4. Четвёртый слой, обратная связь. После каждого вывода агента — автоматическая оценка качества, корректировка стратегии контекста для следующего раза. В книге это называется «автоматическая оптимизация контекста», инженерной реализацией этого подхода является Google Vertex AI Prompt Optimizer.

Читая это, я вспомнил свою статью «AI-агенты — не магия», где одним из пунктов опыта было «вашему агенту нужны правила, и их должно быть много». Теперь, оглядываясь назад, понимаю, что те правила по сути были ручной версией Context Engineering, которую в книге систематизировали.

Reflection: два агента действительно лучше, чем один

Этот паттерн оказался наиболее ценным для меня в практическом плане.

Суть Reflection (Рефлексии) проста: агент после выполнения работы сам её проверяет, находит проблемы и сам их исправляет. Но в реализации есть нюансы. В книге прямо говорится: Producer (Создатель) и Critic (Критик) должны быть двумя разными агентами с разными system prompt. Одна и та же персона, проверяющая собственную работу, неизбежно будет иметь слепые пятна. Если заставить один и тот же LLM сначала написать код, а затем проверить его, он, скорее всего, скажет «всё отлично».

В книге приведён полный пример кода.

• Prompt для Producer: «Ты — Python-разработчик, напиши функцию для вычисления факториала, обработай граничные условия и исключения».

• Prompt для Critic: «Ты — дотошный senior-инженер, проведи построчную проверку кода, найди баги, проблемы со стилем, пропущенные граничные условия, места для улучшения. Если всё идеально, выведи CODE_IS_PERFECT, иначе перечисли все проблемы».

• Затем идёт цикл for: Producer пишет код → Critic проверяет → Producer исправляет по замечаниям → Critic проверяет снова → продолжается, пока Critic не скажет CODE_IS_PERFECT или не будет достигнуто максимальное число итераций.

Всё просто. Но в книге напоминают о легко упускаемой из виду проблеме стоимости: каждый цикл рефлексии — это новый вызов LLM, чем больше итераций, тем дороже. Кроме того, по мере роста истории диалога, контекстное окно заполняется предыдущими версиями и критическими замечаниями, сокращая реальное пространство для рассуждений. Поэтому лучшая практика для Reflection: установить разумный лимит итераций (в книге используют 3), останавливаться, как только Critic доволен, не гнаться за совершенством.

Применение далеко не ограничивается написанием кода. Написание статей, составление планов, суммирование документов, решение логических задач — модель Producer-Critic подходит для всего. В книге перечислено семь сценариев применения, основная логика одинакова: создание, проверка, исправление.

Multi-Agent: чем сложнее, не значит лучше

В главе про коллаборацию нескольких агентов больше всего мне понравились шесть диаграмм топологий коммуникации. Многие сразу берутся за сложные, но в большинстве случаев достаточно трёх:

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

2. Одноранговая сеть (Peer-to-Peer): агенты общаются напрямую, без центрального узла управления. Децентрализованность, отказоустойчивость, если один агент «упадёт», это не повлияет на всю систему. Но высокие затраты на координацию, может возникнуть хаос.

3. Супервизор (централизованное планирование): агент-супервизор управляет группой агентов-исполнителей. Распределяет задачи, собирает результаты, решает конфликты. Чёткая иерархия, легко управлять. Но Супервизор — это единая точка отказа и узкое место в производительности.

Остальные три (Супервизор-как-инструмент, иерархическая, пользовательская гибридная) — это вариации и комбинации первых трёх. В книге говорят очень реалистично: Необходимая вам топология зависит от сложности задачи. Чем сильнее раздроблена задача, тем выше затраты на коммуникацию, и в определённый момент модель Супервизора может оказаться эффективнее иерархической.

Мой вывод: многие, создавая Multi-Agent систему, тратят 80% времени на протоколы связи, забывая задать более базовый вопрос: действительно ли эта задача требует нескольких агентов? В книге чётко написано, что часто достаточно одного агента Уровня 2 с Reflection. Уровень 3 предназначен для тех сценариев, где с одним агентом действительно не справиться.

Трёхуровневая модель памяти — я смутно её чувствовал, но не называл

Глава о памяти нашла у меня самый сильный отклик, потому что когда я писал статьи об Obsidian + Claude, я постоянно размышлял над вопросом: как следует разделять память агента на уровни?

В книге дан ответ:

1. Session (сессионный слой): контекстное окно текущего диалога, самая короткая память, исчезает после окончания диалога. Модели с длинным контекстом лишь расширяют это окно, но по сути оно всё равно временное, и каждый раз при рассуждении нужно обрабатывать всё окно, что дорого и медленно.

2. State (слой состояния): временные данные, создаваемые в процессе выполнения текущей задачи. Например, «какая задача сейчас выполняется», «до какого этапа уже дошло», «какие промежуточные данные были созданы». Длиннее, чем Session, но очищается после завершения задачи; в книге приведён полный пример с использованием механизма State в Google ADK.

3. Memory (постоянный слой): долгосрочная память, охватывающая сессии и задачи. Пользовательские предпочтения, полученный опыт, важные исторические решения, хранятся в базе данных или векторном хранилище с семантическим поиском. В книге подчёркивается важный момент: Memory — это не просто сохранение, но и целая стратегия «что сохранять, когда сохранять, как извлекать». Сохранить слишком много — получишь шум, сохранить слишком мало — не хватит.

В статье про Clawdbot я упоминал «файл состояния» и «рабочие документы», по сути это была ручная реализация слоёв State и Memory, которую в книге оформили в виде фреймворка.

Пять гипотез, пятая самая невероятная

В конце книги приведены пять гипотез о будущем агентов, первые четыре находятся в рамках разумного прогнозирования: универсальные агенты от написания кода до управления проектами, глубокая персонализация и активное обнаружение ваших потребностей, воплощённый интеллект, выходящий за пределы экрана в физический мир, агенты как независимые экономические субъекты.

Пятая меня потрясла: Трансформирующиеся (мутирующие) Multi-Agent системы.

Вы просто объявляете цель, например: «Создать бизнес по продаже элитного кофе в интернете». Система автоматически решает: сначала создать «Агента по исследованию рынка» и «Бренд-агента». Прогнав данные, она сама решает, что бренд-агент больше не нужен, и разделяет его на три новых: «Агент по дизайну логотипа», «Агент по созданию сайта», «Агент по управлению цепочкой поставок». Если агент по созданию сайта становится узким местом, система автоматически создаёт три параллельных агента для одновременной работы над разными страницами. На протяжении всего процесса система постоянно автоматически оптимизирует prompt каждого агента, непрерывно реорганизуя архитектуру команды.

В книге это называется «целеуправляемая, самотрансформирующаяся мульти-агентная система». Она не выполняет написанный вами план, она сама генерирует план, сама его корректирует, сама реорганизует исполнительную команду.

Это напомнило мне Karpathy AutoResearch: написать program.md, определить цели, метрики, границы, нажать «Запустить». Человек остаётся вне цикла. Но книга идёт дальше: даже то, как формируется и реорганизуется команда агентов, отдаётся на усмотрение самой системе. Человек только объявляет «чего хочет».

Три вещи, которые можно сделать прямо сейчас

После прочтения книги у меня появилось три конкретных действия для немедленного внедрения:

• Первое: добавьте Critic к вашему текущему агенту. Неважно, используете ли вы Claude Code, CrewAI или свой фреймворк, добавьте в конец вашего workflow шаг: пусть другой агент (с другим system prompt) проверяет вывод предыдущего шага. К генерации кода — проверку кода, к написанию статьи — проверку фактов, к составлению плана — проверку выполнимости. Один дополнительный вызов LLM, но качество часто улучшается вдвое. Модель Producer-Critic из книги подключается сразу.

• Второе: начните заниматься Context Engineering, а не только Prompt Engineering. Взгляните на файлы с инструкциями для вашего агента. Если там только правила «как делать», и не хватает контекста «в какой среде ты сейчас находишься» — дополните. Расскажите агенту, в каком проекте он сейчас, какие решения принимались ранее, каковы предпочтения пользователя. Глава про Context Engineering в книге и ваш AGENTS.md — два разных выражения одной и той же идеи.

• Третье: не спешите внедрять Multi-Agent. Доведите вашего одного агента до Уровня 2: с инструментами, Reflection и Памятью. В книге постоянно подчёркивается, что одного агента Уровня 2 с Producer-Critic и Context Engineering достаточно для подавляющего большинства практических сценариев. Уровень 3 предназначен для действительно междисциплинарных, многоэтапных задач, требующих параллельного разделения труда. У большинства проблема не в том, что агентов мало, а в том, что одного агента как следует не настроили.

В этой книге 453 страницы, издана Springer в 2025 году. Примеры кода охватывают LangChain/LangGraph, Google ADK, CrewAI, OpenAI API. Предисловие написано вице-президентом Google Cloud по ИИ, есть рекомендация от CIO Goldman Sachs — удивительно интересно.

Но я рекомендую её не за «полноту». После прочтения вы осознаете одну вещь: все ошибки, которые вы совершали за последние полгода в работе с агентами, уже кто-то собрал и оформил в виде паттернов. Вам не нужно заново изобретать Reflection, не нужно гадать, как разделять память на уровни, не нужно методом проб и ошибок выбирать, какую топологию коммуникации использовать для Multi-Agent.

Кто-то уже нарисовал вам карту, осталось только пройти по ней.

Вы используете AI-агентов в разработке? До какого уровня развился ваш текущий агент?