Систематический курс по агентной инженерии: структура повторяет главы открытой книги «Глубокое понимание AI Agent» (Apache-2.0, github.com/bojieli/ai-agent-book), текст уроков — авторская переработка Александра Зубика (ArtCloud) с инженерными выводами и примерами из продакшена. Контекст и KV-cache, память и RAG, инструменты и MCP, кодинг-агенты, компьютерное использование, оценка (evals), дообучение и RL, непрерывная эволюция и мультиагентные схемы — с тестами после каждой главы и итоговым тестом по книге.
Курс — о том, как проектировать AI-агентов: системы, которые сами планируют шаги, вызывают инструменты и доводят задачу до результата, а не просто отвечают на вопросы. Архитектурная основа — открытая книга [«Глубокое
С августа по октябрь 2025 года я провёл серию технических лекций в «Практическом лагере AI Agent» издательства «Тьюринг». Замысел лекций был прост: перевести проектирование ИИ-агентов из режима «на ощупь» в режим «по
Главы книги относительно независимы друг от друга — вы можете выбрать маршрут чтения, исходя из ваших
Эта книга рассчитана на читателей с определённой технической подготовкой, но не требует, чтобы вы были экспертом в какой-то конкретной области. Ниже перечислены предварительные знания по двум уровням — «обязательные» и
Благодарю редакторов издательства «Турин» — Мэн Гэ и Лю Мэйин — за кропотливую редакторскую работу, а также за усилия по организации курса «AI Agent Практикум» издательства «Турин»; благодарю преподавателя Лю Цзюньмина
Короткая проверка перед главным: три вопроса по введению. Ответы — в первых уроках курса, ничего искать не
Если вы писали код в Cursor и наблюдали, как он ищет по кодовой базе, редактирует несколько файлов и гоняет тесты, пока они не пройдут; если проводили исследование темы с Deep Research и видели, как он раз за разом
К этому моменту ты уже понимаешь основной принцип работы агента — LLM через цикл ReAct, опираясь на контекст, использует инструменты для выполнения задач. Предыдущие эксперименты доказали, что эта базовая механика
В следующих главах многократно используются одни и те же шаблоны проектирования, поэтому здесь мы один раз даём им имена и канонические
Эта глава, отталкиваясь от практики, выстроила базовую систему понимания и построения
1. ★★ Если бы вы могли добавить агентной системе лишь одну способность — более сильную модель, более богатый контекст или больше инструментов, — что бы вы выбрали? При каких условиях ваш выбор изменился
В первой главе контекст сравнивался с «глазами» агента: агент может принимать решения только на основе той информации, которую видит. Проектирование и управление контекстом называется **инженерией контекста (Context
В этом разделе на примере Chat Completions API от OpenAI (структура API у Anthropic, Google и других поставщиков в целом схожа) мы подробно разберём полную структуру каждого запроса, который агент отправляет большой
Прежде чем перейти к истории, сформируем интуицию насчёт **KV Cache**. Каждый раз, генерируя очередной токен, модель должна заново «оглядываться» на промежуточные результаты вычислений по всем предыдущим токенам. Если
Центральный объект инженерии промптов (Prompt Engineering) — это **системный промпт (System Prompt)**, то самое сообщение с ролью `role: "system"` в списке сообщений API. Это «руководство для сотрудника» агента,
![Рис. 2-11 Механизм прогрессивного раскрытия
![Рис. 2-14 Архитектура строки состояния
В предыдущих разделах обсуждалось, как добавлять содержимое в контекст — инженерия промптов определяет, что писать, Skills определяют, что загружать по требованию, строка состояния агента определяет, какую
Основная линия контекстной инженерии — явное управление информацией: структура сообщений API задаёт каркас; стабильный префикс повышает попадания в KV Cache; промпт, Skills и строка состояния несут соответственно
1. ★★★ Эксперимент 2-3 показал, что скользящее окно истории диалога приводит к тому, что агент повторно выполняет одни и те же вызовы инструментов. Но полное сохранение истории приводит к бесконтрольному разрастанию
Предыдущая глава решала задачу управления контекстом в рамках одного взаимодействия. Эта глава берётся за более сложную проблему: как сделать так, чтобы агент продолжал помнить пользователя и знания даже после
Ключевая технология построения общей базы знаний — генерация с дополнением поиском (Retrieval-Augmented Generation, RAG). Её центральная идея — объединить способность больших языковых моделей к рассуждению и генерации с
Базовые технологии RAG, описанные ранее (плотный эмбеддинг, разреженное встраивание, гибридный поиск), решают задачу «дан текстовый блок — как быстро найти несколько наиболее релевантных». Но есть более фундаментальный
В этой главе устойчивое знание разделено на два масштаба: пользовательская память, обслуживающая одного человека, и общая база знаний, обслуживающая всех. Первая живёт по циклу «прочитать релевантные воспоминания →
1. ★★ В системе памяти пользователя, когда один и тот же пользователь в разных сессиях предоставляет противоречивую информацию (например, дважды называет разные домашние адреса), как система памяти должна обрабатывать
В научно-фантастическом фильме «Она» (*Her*) ИИ-ассистент Саманта самостоятельно разбирает почту, распознаёт эмоционально сложные письма и предлагает варианты ответа, ведёт издательские дела от лица главного героя и
Ранняя форма проектирования инструментов — прямая обёртка над API: каждая конечная точка API упаковывалась в отдельный инструмент, гранулярность оказывалась слишком мелкой, и агенту приходилось согласовывать несколько
При реальном построении набора инструментов агента возникает практическая проблема: каждый фреймворк для агентов определяет инструменты по-своему — формат function calling у OpenAI, формат tool use у Anthropic,
Раздел «Форма выражения возможностей» спрашивал, какую форму придать возможности. Этот раздел спрашивает о другом: **в какой бы форме она ни была выражена, сколько их модель должна видеть за раз?** Когда доступных
Инструменты восприятия — основной канал, по которому агент получает внешнюю информацию, и при их проектировании нужно тщательно взвешивать сразу несколько измерений: гранулярность, способ организации и формат
Если инструмент восприятия — это «органы чувств» агента, то инструмент выполнения — это его «руки и ноги». Но, в отличие от инструмента восприятия, цена ошибки для инструмента выполнения может быть чрезвычайно высокой:
Когда задача выходит за пределы возможностей одного агента, инструмент сотрудничества позволяет ему делегировать подзадачу другим агентам или человеку, а затем объединить результаты всех
Проектирование инструментов определяет потолок возможностей агента. Первое решение — в какой форме выражена способность: по умолчанию склоняйтесь к универсальному краю и отступайте к специализированному инструменту лишь
1. ★★ Стандарт MCP отделил определения инструментов от фреймворка агента. Но стандартизация также означает, что сложные паттерны взаимодействия с инструментами (например, потоковый вывод, двусторонняя коммуникация,
В предыдущих главах мы подробно рассмотрели инженерию контекста (главы 2 и 3) и проектирование инструментов (глава 4). В этой главе мы соберём эти элементы вместе и ответим на ключевой вопрос: **как выглядит архитектура
Предыдущая часть показала, как построить надёжный кодинг-агент — от архитектурного проектирования до реализации инструментов и Harness-инженерии. Но ценность генерации кода далеко не исчерпывается написанием
В основе всего, что обсуждалось в этой главе, лежит одна и та же мысль: код — это не просто инструмент для написания программ, это язык, на котором агент формализует мышление и точно выражает свои
1. ★★ Генерацию кода называют «мета-способностью» агента. Но выполнение кода несёт риски безопасности — сгенерированный агентом код может содержать уязвимости, бесконечные циклы или приводить к исчерпанию ресурсов.
В главе 1 был выдвинут тезис: когда базовая модель зафиксирована, главным системно-инженерным рычагом повышения качества работы агента обычно оказывается переопределение или расширение его **пространства наблюдений** и
Инструменты восприятия, исполнения и совместной работы из главы 4 агент вызывает сам. Но как ему реагировать на внешние события, способные прийти в любой момент? Для этого нужна событийно-управляемая асинхронная
Голос — это не просто текст, превращённый в звук. Человек говорит примерно в четыре раза быстрее, чем печатает, и при этом освобождает руки и глаза. Поэтому голосовой Agent образует непрерывный цикл ввода и вывода, в
Голос опустил ось времени до миллисекунд, но его наблюдение по-прежнему остаётся одномерным потоком звука. Computer Use переносит ту же задачу на двумерный экран: наблюдением становятся непрерывно меняющиеся пиксели, а
> **Как читать этот раздел**: от начала до конца мы используем одну-единственную задачу——«поставить красную чашку на поднос, выбросить жёлтую бумажку в мусорное ведро и в конце ещё раз посмотреть, чтобы убедиться в
На двух осях—**модальности** и **момента исполнения**—**асинхронность и событийность** расширяют наблюдение от «агент сам получает» до «мир присылает», а действие от «завершить внутри хода» до «запустить сейчас и
1. ★★ В асинхронной архитектуре агента стратегия приоритетов очереди событий должна быть определена на этапе проектирования. Но если само определение приоритета требует семантического понимания (например, оценить,
Первые шесть глав раскрыли построение одиночного агента: его контекст, знания, инструменты, способность писать код, а также пространства наблюдений и действий. Но завершить построение — ещё не значит построить
Результат оценки из предыдущего раздела — четыре пройденные задачи из пяти. По одному числу 0,8 нельзя судить, пригодна ли система. Если это Agent поддержки по возвратам, то один пользователь из пяти не получит
Когда основание метрики определено, следующий вопрос — где измерять. Среда оценки — это установка, которую можно запускать повторно: при одном и том же начальном состоянии один и тот же Agent должен давать сопоставимые
Если среда оценки — сцена, то набор данных — сценарий. Те же пять составляющих при смене класса задач могут заполняться совершенно иначе: откуда берутся задачи, насколько глубоко может проверить верификатор, как не дать
У бенчмарков, разобранных в предыдущих разделах, есть общая черта: их верификаторы почти всегда детерминированы. SWE-bench запускает набор тестов, AndroidWorld проверяет конечное состояние UI, GAIA сверяет строки на
Выбор модели — это не простое «выбрать самую сильную», а компромисс, основанный на оценке, между несколькими измерениями в зависимости от сценария
Набор для оценки конечен, а выход модели случаен, поэтому разница в баллах может быть всего лишь шумом выборки. Если на $n$ случаях измерена доля успеха $p$, стандартную ошибку можно грубо оценить
Решения, основанные на оценке (будь то выбор модели или непрерывная итерация), зависят от качественных эксплуатационных данных. Сначала разберём, как систематически собирать эти данные (наблюдаемость), а затем — как
Следующий пример взят из реальной, намеренно узкой итерации AndroidWorld в сопутствующем репозитории. Она охватывает четыре задачи настройки Wi-Fi на эмуляторе API 35, с одним парным запуском на задачу. Это не полный
В предыдущих разделах обсуждалось, как оценивать систему агента извне — как построить среду оценки, спроектировать датасет, проанализировать отчёт benchmark. Но лучшие агентные продукты не только проходят внешнюю оценку
Конечная точка оценки — не выставление баллов, а улучшение. Эта глава уже показала два пути улучшения: настройка Harness (от отчёта benchmark к системному улучшению) и встраивание оценки в инженерию продукта (внутренняя
Глава отвечает на один вопрос: как понять, что агент действительно улучшился? Эта цепочка состоит из четырёх звеньев: сначала определить, что считать успехом (различие оснований Pass@k, Best@k и Pass consecutive@k),
1. ★★ LLM-as-a-Judge использует языковую модель для оценки выходных данных языковой модели. Существуют ли в такой «самооценке» системные слепые зоны — например, модель может стабильно ставить высокие баллы ответам
Ключевая формула этой книги — Агент = LLM + контекст + инструменты. Эта глава посвящена оптимизации LLM как «мозга»: с помощью постобучения мы учим модель лучше использовать контекст и инструменты, тем самым повышая
Суть **обучения с подкреплением (Reinforcement Learning, RL)** — научиться выбирать действия исходя из текущей ситуации так, чтобы получить максимальную **кумулятивную награду (Cumulative Reward)**. Представьте ИИ,
Чтобы понять, почему методы постобучения работают, нужно сначала разобраться, что закладывает предобучение. Постобучение (SFT и RL) по сути представляет собой оптимизацию внутри пространства представлений, построенного
Под **Mid-training** в этой главе понимается следующее: отталкиваясь от уже имеющейся базовой модели, провести ещё один этап обучения языковой модели на целевом распределении данных. Обычно при этом используется та же
![Рис. 8-10 Конвейер дообучения с учителем
Потолок SFT задаётся прежде всего данными. В реальных проектах редко удаётся вручную написать достаточно демонстраций по одной, поэтому обычно комбинируют **небольшой набор рукописных «семян», генерацию моделью-учителем
Раздел «От предобучения до RL: панорама четырёх этапов» разобрал механику трёх видов обучения; этот раздел даёт практическую диагностику: **сначала определите, чего не хватает — основы, протокола или стратегии, и не
«Однораундовое» означает, что задача выполняется за одно взаимодействие: модель получает вход, выдаёт выход, получает награду — без необходимости поддерживать состояние между шагами. Такая упрощённая постановка
**GRPO (Group Relative Policy Optimization)** — предложенный DeepSeek алгоритм, один из самых используемых сегодня в обучении RL. Понять его нагляднее всего на примере: пусть в SWE-bench есть задача — в некотором
Узкое место RL-обучения чаще лежит не в алгоритме, а в том, **достаточно ли среда реалистична, сбрасываема и параллелизуема**. Телефонные звонки, платежи или изменения файлов у настоящего агента бывают дорогими и
![Рисунок 8-14 Сравнение однораундового и многораундового
Разобранные выше одноходовые, многоходовые сценарии и вызов инструментов показали, *чему* учить; этот раздел отвечает на вопрос, *как среда должна сообщать модели, хорошо ли она справилась*. Проектирование награды
Предыдущие эксперименты систематически показали ключевую ценность RL в обучении агентов, но каждый из них дорого обошёлся по числу примеров. «Эффективность выборки» здесь означает вполне конкретное: **сколько полезных
Этот раздел возвращается к вопросу, оставленному главой 7: как оценочный набор данных, построенный на production-овых bad case, действительно становится входом постобучения. В конце главы 7 оценочная среда и
Эта глава прошла долгий путь от «предсказания следующего слова» в предобучении: SFT эффективно осваивает формат и протокол, а ориентированный на результат RL в контролируемых экспериментах этой главы улучшил обобщение
Mid-training, SFT и RL — не три взаимозаменяемые «степени дообучения», а работа соответственно с **основой, протоколом и стратегией**. Mid-training, кроме того, должен через программу по длине, смешанные данные и
1. ★★ Катастрофическое забывание — когда тонкая настройка под конкретную задачу разрушает исходные общие способности модели (например, общий вызов инструментов) — особенно болезненно в сценариях с агентами. По сравнению
Современные Agent сталкиваются с ярко выраженным парадоксом возможностей: они способны без примеров решать ранее не встречавшиеся сложные задачи, но даже после десяти тысяч сходных задач на следующий день могут
Обучающий сигнал указывает, что Agent должен измениться, но не определяет, где именно должно произойти изменение. Главный критерий выбора способа обновления — не давность опыта, а возможность естественно выразить
Четыре способа обновления превращаются из однократной оптимизации в непрерывную эволюцию только внутри единого автономного цикла. На рисунке 8-5 показана более надёжная двухконтурная структура производственной системы:
Непрерывная эволюция становится одной из важнейших способностей Agent, однако современные модели пока не могут самостоятельно осуществлять его надёжным образом. Контекстная адаптация во время вывода не сохраняется
1. ★★ Один документ опыта подтверждается тремя успешными и одной неуспешной траекторией. Неудача произошла на более новой версии API. Как системе определить, опровергнут ли опыт или изменились условия его
Первые девять глав были посвящены одиночному агенту: сначала мы строили его контекст, знания, инструменты и способности к взаимодействию, а затем с помощью оценки, постобучения и непрерывной эволюции делали его лучше в
Прежде чем переходить к конкретным архитектурам взаимодействия, ответим на более фундаментальный вопрос: **когда действительно нужно несколько агентов, а когда достаточно одного?** Ответ на этот вопрос станет общим
При взаимодействии с общим контекстом каждый этап является отдельным Agent со своим системным промптом и набором инструментов, но наследует полную траекторию предыдущего этапа. Главное преимущество — отсутствие потери
Отсутствие общего контекста представляет собой настоящее мультиагентное взаимодействие. В такой архитектуре каждый агент — независимая сущность со своим собственным контекстом, траекторией и состоянием. Агенты не могут
Введение способности к взаимодействию в многоагентных системах одновременно порождает новые режимы отказа, не свойственные одиночным агентам. Статья 2025 года «Why Do Multi-Agent LLM Systems Fail?» (предложившая
В трёх предыдущих разделах обсуждалось сотрудничество с чёткой целью в решении задач — будь то равноправное сотрудничество, модель оркестрации или децентрализованная модель, во всех случаях разработчик заранее определял
Ценность многоагентного взаимодействия в том, что оно вносит информацию, недоступную одному агенту. Результаты выполнения кода, визуальная обратная связь и проверка внешними инструментами способны пробить слепые зоны
1. ★★ В мультиагентном взаимодействии с общим контекстом последующий агент наследует полный контекст предшествующего. Но накопленная предыдущим агентом «инерция мышления» может влиять на суждения последующего —
В начале книги мы вывели формулу: **Агент = LLM + Контекст + Инструменты**. Все десять глав книги разворачивают эти три
Оглянитесь на всю эту многослойную подстраховочную логику внутри harness — многоуровневое сжатие контекста, повторные попытки, отключающиеся только после тысяч неудач, пессимистичные по умолчанию решения о правах
Три вопроса по послесловию: два облака агентов и совместная эволюция модели и агента. Порог проверки —
Итог курса — рабочий чек-лист из двадцати пунктов. Пройдите по своему проекту до того, как писать код: каждый пункт — класс инцидентов, которые дешевле
Войдите и запишитесь, чтобы открывать уроки и сохранять прогресс.
Запишитесь на созвон с ментором: разбор кода, проекта, карьерного плана или практики с материалами платформы. Это часть консультационной услуги, не массовый онлайн-курс.