Паттерны агентного проектирования: книга, заставившая меня переосмыслить, что именно представляет собой «агент»

Автор: Yanhua

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

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

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

Возможно, вы вообще не создаете агента

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

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

Настоящие агенты начинаются выше:

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

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

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

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

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

  На этом уровне агент также может заниматься саморефлексией. Завершив задачу, он проверяет свою работу, выявляет проблемы и вносит исправления самостоятельно. Я подробно остановлюсь на этом позже.

• Уровень 3: Коллаборация мультиагентов

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

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

Инженерия контекста: самая недооцененная концепция в книге

Я написал статью о Harness Engineering, обсуждая, почему проектирование «упряжки» важнее мощности двигателя. Прочитав эту книгу, я понял, что инженерия контекста — это отображение Harness Engineering на уровне промптов.

Традиционная промпт-инженерия заботится только о том, «как вы спрашиваете». Инженерия контекста в книге касается того, «какой контекст находится перед агентом до того, как он получит вопрос». Она включает четыре уровня информации:

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

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

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

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

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

Рефлексия: два агента действительно лучше, чем один

Для меня это самый практически ценный паттерн во всей книге.

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

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

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

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

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

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

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

Мультиагентная система не становится лучше от усложнения

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

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

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

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

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

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

Трехуровневая модель памяти: я чувствовал это, но не мог назвать

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

Книга дает ответ:

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

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

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

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

Пять предположений, пятое — самое абсурдное

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

Пятое предположение меня шокировало: Трансформирующиеся мультиагенты.

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

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

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

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

Закончив эту книгу, я выделил три действия, которые могу внедрить немедленно:

• Во-первых, добавьте критика (Critic) к вашему текущему агенту. Используете ли вы Claude Code, CrewAI или фреймворк, который вы создали сами, добавьте шаг в конце существующего рабочего процесса: пусть другой агент (с другим системным промптом) проверит вывод предыдущего шага. Генерация кода плюс проверка кода, написание статьи плюс проверка фактов, планирование плюс оценка осуществимости. Это добавляет еще один вызов LLM, но повышение качества часто удваивается. Модель Producer-Critic из книги работает по принципу plug-and-play.

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

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

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

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

Кто-то уже нарисовал для вас карту; осталось только пройти по ней.

Используете ли вы ИИ-агентов для разработки? На каком уровне находится ваш текущий агент?