Автор: Яньхуа
Антонио Гулли — директор по инженерии в Google. Он написал книгу объемом 453 страницы, в которой разбил разработку AI-агентов на 21 паттерн проектирования.
Но это не рецензия на книгу. Моя мотивация читать эту книгу была очень конкретной: я писал о Harness Engineering, о опыте ошибок с Clawdbot, о статье «AI-агенты — это не магия», где описывал семь переломных моментов от сжигания токенов до по-настоящему полезного результата. После каждого завершения у меня оставался неразрешенный вопрос: существует ли за всем этим единая переиспользуемая базовая логика?
Эта книга дала мне ответы, и они оказались глубже, чем я ожидал.
Возможно, то, что ты написал, вообще не агент
Самый жесткий вывод в книге спрятан в прологе.
Большинство людей используют то, что называют «ИИ», но это всего лишь Level 0: чистая LLM, без инструментов, без памяти, не способная действовать. Вы спрашиваете её, какой фильм получит «Оскар» в 2025 году — она угадывает. В книге это сказано прямо: то, что относится к Level 0, не является Agent.
Идти вверх — это настоящий агент:
Уровень 1: Пользователь инструментов
Агент начинает использовать инструменты: поиск, API, базы данных. Но он не просто «может вызывать интерфейсы» — он должен сам решать, когда вызывать, что вызывать и как использовать результаты. В книге приводится конкретный пример: пользователь спрашивает «Что нового вышло в сериалах?» Агент самостоятельно понимает, что эта информация отсутствует в обучающих данных, и активно запускает инструмент поиска, чтобы найти её, а затем составляет ответ. Ключевой момент — «самостоятельное понимание». Это не человек говорит ему «проверь это», а он сам решает, что нужно искать. Эта способность к принятию решения — порог Level 1.
Уровень 2: Стратегический мыслитель
Добавились две вещи: планирование и Context Engineering. В книге определен Context Engineering: не накапливать информацию, а тщательно отбирать, обрезать и упаковывать контекст. Пример очень удачный: пользователь ищет кофейню между двумя местами. Агент сначала вызывает инструмент карты, чтобы получить множество данных, затем самостоятельно определяет, что «следующим шагом нужны только названия улиц», обрезает вывод карты до короткого списка и передает его инструменту локального поиска. Каждый шаг направлен на снижение шума информации.
В книге есть фраза, которую я перечитывал несколько раз: «Чтобы ИИ достиг максимальной точности, ему необходимо предоставить краткий, сфокусированный и мощный контекст». Context Engineering — это именно то, чему посвящена эта задача.
На этом уровне агент может самостоятельно рефлексировать. После выполнения задачи он сам проверяет себя и исправляет обнаруженные ошибки. Я подробно расскажу об этом позже.
Уровень 3: Взаимодействие нескольких агентов
Позиция книги ясна: не пытайтесь создать универсального супер-агента. Настоящий надежный подход — это собрать команду, как в реальной жизни: агент-менеджер проекта + агент-исследователь + агент-дизайнер + агент-копирайтер. Пример из книги — запуск нового продукта: «агент-менеджер проекта» координирует все процессы и распределяет задачи между «агентом рыночных исследований», «агентом проектирования продукта» и «агентом маркетинга». Ключевой момент — коммуникация: как агенты обмениваются данными, синхронизируют состояние и разрешают конфликты. В этой главе представлены шесть типов коммуникационных топологий — от простейшей одиночной агентной системы до наиболее гибкой пользовательской гибридной, с пояснениями, для каких сценариев подходит каждый тип.
После изучения этих четырех уровней я внезапно понял, почему многие говорят: «Мой агент не работает». Модель в порядке, проблема в том, что вы используете ее как чат-бот — она, возможно, даже не достигла уровня 1.
Контекстное инжиниринг: Самая недооцененная концепция в книге
Я писал о Harness Engineering, где говорится, что дизайн трассы важнее мощности двигателя. Прочитав эту книгу, я понял, что Context Engineering — это проекция Harness Engineering на уровне промптов.
Традиционное Prompt Engineering занимается только тем, «как вы задаете вопрос». Context Engineering из книги занимается тем, «что стоит перед агентом до вопроса». Он включает четыре уровня информации:
Первый уровень, системный промпт. Определяет, кто такой агент, какой тон и какие границы. Большинство людей пишут только этот уровень.
Второй уровень, внешние данные. Документы, извлеченные с помощью RAG, результаты вызовов инструментов, данные реального времени от API. Это место, где застревают большинство: они знают, что нужно подавать данные, но не знают, как это сделать, чтобы не затопить модель.
Третий уровень — неявные данные. Идентичность пользователя, история взаимодействий, состояние среды. То, что вы не говорите прямо, но агент должен знать. Например, если вы говорите агенту: «Помоги мне отправить письмо Джону, чтобы подтвердить встречу завтра», он должен знать, какая встреча запланирована у вас в календаре завтра и каковы ваши отношения с Джоном.
Четвертый уровень, обратная связь. После каждого вывода агента автоматически оценивается качество и корректируется стратегия контекста для следующего запроса. В книге это называется «автоматизированной оптимизацией контекста»; инженерная реализация этой идеи — Google Vertex AI Prompt Optimizer.
Когда я читал это, я вспомнил свою статью «AI-агенты — это не магия», в которой один из выводов звучал так: «Вашему агенту нужны правила, и их должно быть много». Теперь, оглядываясь назад, я понимаю, что эти правила были в сущности ручной версией Context Engineering, которую в этой книге систематизировали.
Reflection: Два агента действительно лучше, чем один
Это самый практичный паттерн в книге, который мне оказался полезен.
Суть Reflection проста: агент после выполнения задачи самостоятельно проверяет свою работу и исправляет обнаруженные ошибки. Однако способ реализации имеет значение. В книге четко указано: Producer и Critic должны быть двумя разными агентами с разными system prompt. Один и тот же персонаж не может объективно оценить свою собственную работу — всегда будут слепые зоны. Если вы попросите один и тот же LLM сначала написать код, а затем проверить его, он, скорее всего, скажет: «Все в порядке».
The book provides a complete code example.
Промпт производителя: «Вы — разработчик на 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 предназначен для сценариев, где одиночный агент действительно не справляется.
Memory трехуровневая модель, я раньше смутно ощущал её, но не называл
Наиболее сильно созвучна мне глава Memory, поскольку, пиша статьи об Obsidian + Claude, я постоянно размышлял над вопросом: как следует иерархизировать память агента?
В книге есть ответ:
Сессия (уровень сессии): контекстное окно текущего диалога — это кратчайшая память, которая исчезает по завершении диалога. Модели с длинным контекстом просто расширяют это окно, но по сути оно остается временным, и при каждом выводе необходимо обрабатывать всё окно, что дорого и медленно.
State (уровень состояния): временные данные, создаваемые в процессе выполнения текущей задачи. Например, «какая задача выполняется сейчас», «на каком этапе завершено», «какие промежуточные данные были сгенерированы». Длится дольше, чем сессия, но очищается по завершении задачи; в книге приведён полный пример с использованием механизма State из Google ADK.
Память (постоянное хранилище): долгосрочная память, сохраняющаяся между сессиями и задачами. Предпочтения пользователя, полученный опыт, важные исторические решения хранятся в базе данных или векторном хранилище с семантическим поиском. В книге подчеркивается важный момент: память — это не просто сохранение, а разработка целой стратегии «что сохранять, когда сохранять и как искать». Слишком много данных — много шума, слишком мало — недостаточно для использования.
В статье о Clawdbot, которую я писал ранее, я упоминал «файл состояния» и «документы рабочей области» — по сути, я вручную реализовывал слои State и Memory, и в книге этот процесс был структурирован.
Пять предположений, пятое — самое абсурдное
В конце книги приводятся пять гипотез о будущем агентов: первые четыре остаются в рамках разумных прогнозов — универсальные агенты переходят от написания кода к управлению проектами, глубоко персонализированные агенты активно выявляют ваши потребности, встраиваемый интеллект выходит за пределы экрана в физический мир, агенты становятся независимыми экономическими субъектами.
Пятый меня поразил: деформированный Multi-Agent.
Вы просто указываете цель, например: «Создать интернет-магазин精品кофе». Система автоматически определяет: сначала создать «Агента по исследованию рынка» и «Агента по бренду». После прохождения одного цикла данных система самостоятельно решает, что Агент по бренду больше не нужен, и разбивает его на три новых: «Агент по дизайну логотипа», «Агент по созданию сайта», «Агент по цепочке поставок». Если Агент по созданию сайта становится узким местом, система автоматически копирует три параллельных Агента, которые одновременно работают над разными страницами. В течение всего процесса система непрерывно автоматически оптимизирует промпты каждого Агента и постоянно перестраивает архитектуру команды.
Книга называет это «целенаправленной, самоадаптирующейся многоагентной системой». Она не выполняет ваш план, а генерирует его самостоятельно, корректирует и переформировывает команду исполнителей.
Это напоминает мне AutoResearch от Karpathy: напишите program.md, определите цели, метрики и границы, затем запустите. Человек находится вне цикла. Но эта книга заходит дальше: даже то, как формировать и реорганизовывать команду агентов, решает сама система. Человек лишь объявляет, «что нужно».
Три дела, которые можно сделать сразу
Прочитав эту книгу, я выделил три действия, которые могу немедленно применить:
Во-первых, добавьте к вашему текущему агенту критика. Независимо от того, используете ли вы Claude Code, CrewAI или собственную рамку, добавьте на завершающем этапе вашего текущего рабочего процесса шаг: пусть другой агент (с другим системным промптом) проверит вывод предыдущего шага. Генерация кода — с проверкой кода, написание статей — с проверкой фактов, составление планов — с оценкой осуществимости. Один дополнительный вызов LLM, но качество часто удваивается. Модель Producer-Critic из книги — просто подключи и используй.
Во-вторых, начните заниматься контекстным инжинирингом, а не только инжинирингом запросов. Пересмотрите файл с инструкциями, которые вы дали агенту. Если в нём только правила вроде «как тебе поступить», но нет контекста «в какой среде ты сейчас находишься», дополните его. Сообщите агенту, в каком проекте он сейчас находится, какие решения принимал ранее и какие у пользователя предпочтения. Глава о контекстном инжиниринге в книге и ваш
AGENTS.md— это два выражения одного и того же.В-третьих, не спешите переходить к Multi-Agent. Сначала доведите свой одиночный Agent до уровня 2: с инструментами, Reflection и Memory. В книге неоднократно подчеркивается, что одиночный Agent уровня 2 в сочетании с Producer-Critic и Context Engineering покрывает большинство реальных сценариев. Уровень 3 предназначен для действительно междисциплинарных, многоэтапных задач, требующих параллельного распределения обязанностей. Проблема большинства людей не в недостатке агентов, а в том, что даже один агент не настроен должным образом.
Книга содержит 453 страницы, издана Springer в 2025 году. Примеры кода охватывают LangChain/LangGraph, Google ADK, CrewAI, OpenAI API. Предисловие написано вице-президентом по ИИ Google Cloud, а рекомендательное письмо — от CIO Goldman Sachs, и оно неожиданно интересное.
Но причина, по которой я рекомендую его, — не «всеобъемлющость». Вы поймете одну вещь, прочитав его: все ошибки, которые вы допускали на Agent за последние полгода, уже были систематизированы в виде шаблонов. Вам не нужно заново изобретать Reflection, не нужно гадать, как правильно организовать Memory, и не нужно экспериментировать с тем, какую топологию связи использовать в Multi-Agent.
Кто-то нарисовал для тебя карту, осталось только идти.
Вы используете AI Agent для разработки? На каком уровне находится ваш текущий Agent?