ai-agent-book/book-ru/chapter1.md

Введение в ИИ-агенты

Если вы писали код в Cursor и наблюдали, как он ищет по кодовой базе, редактирует несколько файлов и гоняет тесты, пока они не пройдут; если проводили исследование темы с Deep Research и видели, как он раз за разом ищет, читает и в итоге собирает целостный отчёт; если управляли браузером через Manus, чтобы он выполнил за вас онлайн-задачу; если просили мобильного помощника Doubao купить билет или отправить сообщение на телефоне; или если поручали Pine AI позвонить оператору связи и договориться о снижении счёта — значит, вы уже пользовались ИИ-агентами.

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

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

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

Современный агент = LLM + контекст + инструменты

Суть современной агентной системы можно выразить лаконичной формулой: Агент = LLM (большая языковая модель, Large Language Model) + контекст + инструменты. Формула проста и удобна, но каждое слово в ней нужно понимать в широком смысле:

• LLM — это мозг агента: не просто набор параметров модели, а весь ядро принятия решений агента — понимание намерений, обдумывание и планирование, вынесение суждений. Как человеческий мозг — это не только совокупность нейронов, но и способ мышления, сформированный опытом, так и способности LLM складываются из двух частей: накопленных на этапе предобучения знаний о мире и языковых способностей, а также закреплённой на этапе постобучения стратегии принятия решений — конкретные технологии последней (такие как дообучение с учителем (SFT) и обучение с подкреплением) будут раскрыты в седьмой главе.
• Контекст — это глаза агента: не просто тот кусок текста, который подаётся модели на вход, а вся информация, которую агент видит в каждой точке принятия решения — сведения об окружении, память пользователя, знания предметной области, собственное состояние и ход выполнения задачи. Как человеку для принятия решения нужно ясно видеть текущую ситуацию, вспоминать релевантный опыт и заглядывать в справочные материалы, так и окно контекста агента — это всё, что он видит в данный момент.
• Инструменты — это руки и ноги агента: не просто несколько вызываемых функций API, а совокупность всего, что агент способен сделать — от вызова предопределённых инструментов до подгружаемых по требованию специализированных навыков (Skills), от динамической генерации кода для создания новых возможностей до делегирования задач дочерним агентам, от активного общения с пользователем до реакции на внешние события.

Если сказать нагляднее: Агент = мозг + глаза + руки и ноги. Мозг отвечает за размышление и принятие решений, глаза дают всю необходимую для размышления информацию, а руки и ноги превращают решения в изменения реального мира.

С классической точки зрения обучения с подкреплением и теории управления Агент и Окружение — две стороны взаимодействия с замкнутым контуром, а не части друг друга. Окружение возвращает наблюдение, Агент использует контекст для выбора следующего действия, а действие меняет состояние Окружения и порождает следующее наблюдение.

На рис. 1-1 показаны два уровня абстракции. Внешний уровень — это взаимодействие Агента и Окружения: к Окружению относятся файловая система, базы данных, веб-страницы, пользователи, другие агенты и физический или симулированный мир. Внутренний уровень — структура Модель–Harness внутри Агента: Модель принимает решения политики, а Harness — слой выполнения и управления внутри границы Агента, который строит контекст, предоставляет интерфейсы инструментов, поддерживает цикл и состояние и применяет права, проверку и исправление. Harness может создать, изолировать или проксировать окружение, но не включает его состояние и правила переходов.

Инженерную формулу можно развернуть так: LLM соответствует Модели, а Context + Tools образуют минимальный Harness; в производственной системе внутри этой границы добавляются ограничения, проверка и исправление. Дальнейшее изложение главы следует этой границе.

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

Интуитивное понимание	Компонент реализации	Академическое понятие	Значение
Мозг	LLM	Политика (Policy)	Логика принятия решений агента о том, «что делать дальше» — увидев текущую информацию, выбрать из всех возможных действий наиболее подходящее
Глаза	Построение контекста	Наблюдения и история	Организует наблюдения Окружения и имеющуюся историю в информацию, необходимую для текущего решения
Руки и ноги	Интерфейсы инструментов	Интерфейсы наблюдения и действий	Определяет, какие наблюдения агент может читать, какие действия отправлять и в каком формате

Пространства наблюдений и действий: интерфейс между моделью и миром

Пространства наблюдений и действий вместе образуют интерфейс между LLM и внешней средой. Пространство наблюдений преобразует информацию из среды в контекст, который модель способна обработать, а пространство действий превращает решения модели в операции над внешним миром. Информация, не попавшая в пространство наблюдений, для модели словно не существует. Если же операция отсутствует в пространстве действий, модель может лишь описать её словами, даже когда точно знает, что нужно сделать.

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

Manus: объединение прежде раздельных пространств. До появления Manus продакшн-агенты в основном развивались по трём отдельным направлениям: Deep Research, Coding и Computer Use. Manus стал первым широко влиятельным продакшн-агентом, объединившим все три направления в одной системе. Виртуальный браузер расширил его пространство наблюдений, а файловая система, выполнение кода и командная строка — пространство действий. Manus стал универсальным агентом не просто благодаря замене модели на более сильную: он взял объединение пространств наблюдений и действий трёх типов агентов, позволив одной системе пересечь прежние границы продуктов.

OpenClaw: расширение интерфейса на цифровую жизнь пользователя. OpenClaw раздвигает оба пространства ещё дальше. Он принимает задачи и возвращает результаты через привычные пользователю каналы — WhatsApp, Telegram, Slack, Discord, iMessage и многие другие, — поэтому к агенту можно обратиться почти откуда угодно. Локальный Gateway подключает облачные приложения вроде Google Drive и Notion, а также локальную файловую систему. Таким образом, цифровые файлы, разбросанные по аккаунтам и устройствам, с явного разрешения пользователя могут войти в пространство наблюдений одного агента и обрабатываться его инструментами. По сравнению с ранней формой Manus, сосредоточенной на изолированной облачной песочнице и обычно требовавшей загрузить файлы или отдельно настроить коннектор, локально-ориентированный OpenClaw пересекает более широкую границу данных. Позднее Manus тоже добавил коннектор Google Drive и доступ к локальным файлам с рабочего стола — что лишь подтверждает тезис: развитие продукта часто и есть расширение пространств наблюдений и действий¹ .

Понимание роли этих трёх компонентов и их взаимосвязей — основа построения эффективной агентной системы. Начнём с самого конкретного — рук и ног (инструментов), а затем постепенно углубимся к мозгу (LLM) и глазам (контексту). Сначала посмотрим, как разные типы агентов разворачиваются по этим трём измерениям:

Агентный продукт	Глаза (восприятие)	Руки и ноги (действие)	Политика
Кодинг-агенты вроде Cursor	Документ с требованиями, кодовая база, среда терминала	Открытое (внутреннее обдумывание, поиск по коду, чтение и запись файлов, выполнение команд и т. д.)	Инкрементальная разработка: понять требования → найти релевантный код → отредактировать код → проверить тестами → отладить и исправить
Поисковые агенты вроде Deep Research	Сетевые ресурсы, академические базы данных, локальные файлы	Открытое (внутреннее обдумывание, поисковые запросы, чтение веб-страниц, генерация резюме)	Итеративное углубление: корректировать направление поиска на основе имеющейся информации, постепенно синтезируя целостный отчёт
Агенты управления компьютером вроде Browser Use	Экран компьютера, страницы браузера, файловая система	Открытое (внутреннее обдумывание, клики, ввод, прокрутка, скриншоты, выполнение кода и т. д.)	Визуальное восприятие + действия: наблюдать за экраном → распознать целевой элемент → выполнить действие → проверить результат
Агенты мобильного помощника вроде Doubao	Экран телефона, установленные приложения	Открытое (внутреннее обдумывание, клики, свайпы, ввод, открытие приложений и т. д.)	Понимание намерения + управление приложениями: понять запрос пользователя → найти нужное приложение → выполнить действие → подтвердить завершение
Агенты личного помощника вроде Pine AI	Данные аккаунта пользователя, история счетов, база знаний поставщика услуг	Открытое (внутреннее обдумывание, телефонные звонки, отправка писем, заполнение форм, подтверждение с пользователем)	Выполнение многошаговой задачи: собрать информацию → выработать стратегию переговоров → связаться с поставщиком услуг → провести переговоры → отчитаться о результате

У этих агентных систем есть несколько общих черт: все они используют открытое пространство действий — они не выбирают из ограниченного набора кнопок, а способны генерировать произвольный естественный язык и код; все они умеют внутренне обдумывать — прежде чем действовать, они думают и планируют; все они способны к непрерывному взаимодействию — постоянно корректируя стратегию по обратной связи от окружения. Именно эти способности рождаются из совместной работы мозга, глаз и рук с ногами — то есть LLM, контекста и инструментов.

Инструменты: руки и ноги агента

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

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

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

Инструменты выполнения позволяют агенту менять мир: выполнение кода, операции с файлами, системные команды, вызовы внешних API — так решения превращаются в реальные действия.

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

Инструменты срабатывания события принципиально отличаются от первых трёх категорий по способу вызова — их вызывает не сам агент, они выступают как внешний вход, запускающий выполнение задачи агентом. Например, приход нового письма, наступление заранее заданного момента времени или Webhook-колбэк от другой системы — такие события активируют агента и запускают его дальнейшее обдумывание и действия. Хотя срабатывание события не инициируется самим агентом, это один из каналов его взаимодействия с внешним миром, поэтому оно относится к системе инструментов в широком смысле.

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

Полная система классификации этих пяти категорий инструментов и принципы их проектирования будут рассмотрены в четвёртой главе. Качество проектирования инструментов напрямую определяет, как далеко сможет зайти агент: если определение интерфейса нечёткое, модель будет применять инструменты как попало; если обработка ошибок недостаточна, стоит инструменту дать сбой — и он превратится во взаимоблокировку для агента; если контроль разрешений слишком широк, то стоит агенту ошибиться — и последствия будет трудно исправить. Распространение стандарта MCP (Model Context Protocol, протокол контекста модели) упрощает подключение инструментов.

Вызов инструмента (Tool Calling, также Function Calling) — одна из ключевых способностей современных LLM-агентов, которая позволяет модели структурированным образом вызывать внешние инструменты. Эта способность превращает LLM из чистого генератора текста в интеллектуальную систему, способную выполнять реальные действия. Далее в книге мы будем единообразно использовать термин «вызов инструмента».

Процесс вызова инструмента состоит из четырёх шагов: сначала в контексте модели сообщается, какие инструменты доступны (включая имя, назначение и параметры); затем модель сама решает, нужно ли вызывать инструмент, какой именно и с какими параметрами; далее, после того как инструмент отработал, его результат добавляется в контекст; и наконец, на основе этого модель решает, что делать дальше. Этот цикл и есть основа ReAct, о котором пойдёт речь ниже.

На примере сценария с запросом погоды упрощённое представление четырёх шагов на уровне API выглядит так:

Шаг 1: объявление инструментов        Шаг 2: модель решает вызвать
tools: [{                          assistant: {
  name: "get_weather",               tool_calls: [{
  parameters: {                        function: "get_weather",
    city: "string"                     arguments: {city: "Пекин"}
  }                                  }]
}]                                 }

Шаг 3: результат добавлен в контекст   Шаг 4: модель отвечает по результату
tool: {                            assistant: {
  tool_call_id: "call_1",            content: "В Пекине сегодня 28°C, ясно."
  content: '{"temp":28,"sky":"ясно"}'  }
}

Разработчику нужно лишь определить инструменты и выполнить вызов инструмента, а решение «вызывать ли, какой именно и с какими параметрами» модель принимает самостоятельно. Во второй главе эта структура API будет разобрана подробно.

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

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

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

LLM: мозг агента

Большая языковая модель (Large Language Model, LLM) — это ядро принятия решений агента. Получив запрос пользователя, она должна сперва разобрать его истинное намерение (то, что говорит пользователь, часто не совпадает с тем, что он на самом деле хочет), а затем разложить размытую или сложную задачу на выполнимые шаги. По ходу выполнения ей приходится постоянно принимать решения: что делать дальше, вызывать ли инструмент, какой именно инструмент и с какими параметрами. Эта способность «понять — спланировать — выполнить» вырастает из знаний, накопленных на этапе предобучения, и служит фундаментом как для рабочих процессов, так и для автономных агентов.

Одна из уникальных способностей LLM-агента — это внутреннее размышление: прежде чем предпринять реальное действие, агент может сначала спланировать и мысленно проиграть ситуацию. Этот процесс не меняет внешнюю среду, но заметно повышает качество последующих действий. LLM способна на эффективное внутреннее проигрывание благодаря умениям, приобретённым на этапе предобучения (Pre-training — начальное обучение на огромном массиве интернет-текстов, в ходе которого модель усваивает закономерности языка и знания о мире): при проигрывании модель опирается на логические правила, уже отложившиеся в человеческом знании, — математические законы, причинно-следственные связи, стратегии декомпозиции задач и так далее. Поэтому, в отличие от традиционных агентов обучения с подкреплением, современные LLM-агенты не ведут слепой случайный поиск, а рассуждают внутри структурированной системы знаний.

Модель как агент: когда сама модель становится продуктом

Новая парадигма «модель как агент» (Model as Agent) представляет собой самое свежее направление развития ИИ-агентов. Передовые модели через постобучение (особенно через обучение с подкреплением) превращают способность к вызову инструментов во врождённую: когда вызвать инструмент, какой именно и с какими параметрами — всё это модель решает сама, без ручной оркестровки. Но это не значит, что слой фреймворка стал неважным. Наоборот, чем мощнее модель, тем важнее Harness, выстроенный вокруг неё. Слово Harness исходно означает конскую упряжь — поводья и сбрую, надеваемые на лошадь: они нужны не для того, чтобы ограничить её способность бежать, а чтобы направить эту силу в правильную сторону. В контексте агента модель — это та самая мощная, но непредсказуемая лошадь, а Harness — инженерная оболочка, направляющая её способности в надёжное выполнение задач. В агенте Harness включает управление контекстом, интерфейсы инструментов, ограничения безопасности, проверку и исправление и другую инфраструктуру (подробнее — в последнем разделе этой главы).

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

Но здесь возникает более глубокий вопрос: если модель продолжит усиливаться, не будут ли сегодняшние Harness в итоге «поглощены» моделью? Рич Саттон в «Горьком уроке» (The Bitter Lesson) вспоминает картину, вновь и вновь повторявшуюся за семьдесят лет исследований ИИ² : исследователи раз за разом кодировали своё понимание предметной области в систему, что давало краткосрочный эффект, но в долгосрочной перспективе неизменно проигрывало универсальным методам, способным масштабироваться вместе с вычислительными ресурсами и объёмом данных, — поиску и обучению. Если судить по этой мерке, какая часть ограничений, проверки и исправления внутри Harness относится к «человеческим априорным знаниям» и обречена быть усвоенной моделью? Позиция этой книги такова: согласны с направлением, прагматичны в темпе. Что касается направления, книга не сомневается, что модель будет и дальше поглощать Harness: и вызов инструментов, и долгосрочное планирование когда-то опирались на внешнюю оркестрацию, а теперь стали нативными способностями модели. Однако по темпу это «поглощение» происходит куда медленнее, чем подсказывает интуиция: обучение измеряется месяцами, и модель не способна разом усвоить все ограничения и предпочтения реального бизнеса; текущая граница возможностей модели и составляет текущую ценность Harness. Поэтому Harness-инженерия — не сопротивление горькому уроку, а практическое воплощение этого урока в масштабе инженерного времени: то, что модель пока выполняет нестабильно, сначала компенсирует Harness; усваивая очередной слой, модель позволяет Harness снять его и переключиться на страхование нового рубежа возможностей.

Механизмы обучения агента: от контекстной адаптации до персистентных обновлений

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

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

Чтобы изменения сохранялись между задачами, можно обновлять внешние артефакты: оформлять факты и опыт в виде документов знаний, записывать выразимые на естественном языке стратегии в Prompt или Skill, а детерминированные процессы и ограничения — в программы и Harness. Такие артефакты поддаются аудиту и исправлению, однако при выполнении агент по-прежнему должен обращаться к ним через контекст или интерфейсы инструментов. Главы с третьей по пятую закладывают основу для знаний и программ, а восьмая глава рассматривает, как генерировать подобные обновления из уже оценённых траекторий выполнения.

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

Контекст: глаза агента

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

• Системный промпт (System Prompt): в отличие от промпта, который пользователь вводит каждый раз, системный промпт пишет разработчик, и он остаётся неизменным на протяжении всего диалога — это своего рода «должностная инструкция» агента, определяющая его личность, полномочия и правила поведения. Тщательно проектируя системный промпт с помощью инженерии промптов (Prompt Engineering), мы можем формировать способ работы агента. Системный промпт также включает сохраняемую между сессиями память пользователя (персонализированная информация: предпочтения пользователя, история поведения, фоновые настройки и т. д., подробнее — в третьей главе) и динамически внедряемое состояние среды.
• Определения инструментов (Tool Definitions): объявляют имена доступных агенту инструментов, описания их функций и формат параметров. Без определений инструментов агент не сможет распознать и вызвать ни один инструмент — это подтвердит абляционное исследование (эксперимент 1-1). Определения инструментов вместе с системным промптом образуют статический префикс, неизменный на протяжении диалога (это базовый режим; с 2026 года в производственных фреймворках полная schema инструментов также может по мере необходимости динамически подгружаться в конец контекста, не нарушая префикс, подробнее — в разделе об определениях инструментов второй главы и в четвёртой главе).
• Сообщения пользователя (User Messages): ввод от пользователя. В сообщениях пользователя также могут содержаться внешние знания, динамически извлечённые через RAG (генерация с дополнением поиском, Retrieval-Augmented Generation, подробнее — в третьей главе) — информация, появившаяся после отсечки обучающих данных, или знания из закрытых предметных областей.
• Ответы модели (Assistant Messages): ранее сгенерированные моделью ответы, включающие максимум три части — процесс размышления (reasoning, то есть цепочка рассуждений, обеспечивающая связность мышления и объяснимость решений), текстовое содержимое (content, то есть ответ пользователю) и запрос на вызов инструмента (tool_calls, то есть способ, которым агент совершает действие). В конкретном ответе эти три части не обязательно присутствуют одновременно: например, когда агент решает вызвать инструмент, обычно есть только reasoning + tool_calls, а когда он даёт итоговый ответ — обычно только reasoning + content.
• Результаты выполнения инструментов (Tool Results): результат, возвращаемый фреймворком агента после выполнения инструмента. Эти результаты служат прямым основанием для следующего шага размышления агента, а также позволяют ему учиться на результатах выполнения и не повторять ошибок.

Первые два элемента (системный промпт + определения инструментов) — это статический префикс, а последние три (сообщения пользователя + ответы модели + результаты выполнения инструментов) — это динамическая история сообщений, непрерывно растущая по мере взаимодействия. Эти пять частей вместе образуют контекст LLM при каждом акте вывода.

Чтобы убедиться, что каждый компонент незаменим, самый прямой способ — это абляционное исследование (Ablation Study): подобно тому как врач при диагностике по очереди исключает причины болезни — сначала убираем компонент A и смотрим, работает ли система по-прежнему нормально, затем убираем компонент B, и так далее, чтобы оценить вклад каждого компонента. Эксперимент 1-1 как раз в этой логике систематически протестировал пять описанных выше компонентов, и результаты показывают следующее: без определений инструментов агент полностью теряет способность действовать; при отсутствии результатов выполнения инструментов агент, не видя обратной связи от предыдущего шага, снова и снова вызывает один и тот же инструмент и попадает в бесконечный цикл; стоит лишить ответ модели процесса размышления, как последовательные решения начинают противоречить друг другу; что до истории сообщений — без неё агент словно теряет память, а потому запускает весь процесс задачи с самого начала, повторно выполняя уже завершённые шаги.

Эксперимент 1-1 ★★: ключевая роль контекста

С помощью систематического абляционного исследования (Ablation Study) мы изучили влияние разных компонентов контекста на поведение агента. Для тестирования из пяти описанных выше частей были выбраны четыре компонента — системный промпт как базовое определение личности агента в абляции не участвует, поскольку без системного промпта у агента нет даже базового осознания своей роли, и тестировать его бессмысленно. Как показано на рис. 1-3, пять сравнительных групп эксперимента включают: одну полную базовую группу со всеми компонентами и ещё четыре группы, в каждой из которых отсутствует один компонент, — чтобы пронаблюдать влияние каждого компонента на производительность агента.

Результаты эксперимента раскрывают незаменимую роль каждого компонента контекста. Определения инструментов (Tool Definitions, часть статического префикса) — основа способности агента действовать; без них агент не может распознать и вызвать ни один инструмент. Результаты выполнения инструментов (Tool Results) — ключ к замкнутому контуру управления; их отсутствие приводит к тому, что агент действует «вслепую» и попадает в бесконечный цикл. Процесс размышления (часть reasoning в ответах модели) сохраняет причины прежних решений агента, делает поток мышления более связным и предотвращает взаимно противоречивые решения. История сообщений (сообщения пользователя, ответы модели и результаты выполнения инструментов из предыдущих раундов) предотвращает избыточные операции, поддерживает связность выполнения задачи и помогает не повторять одни и те же ошибки.

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

Цикл ReAct

Разобравшись с тремя основными компонентами агента, естественно задаться вопросом: как они работают вместе? Цикл ReAct — это и есть ключевой механизм, связывающий LLM, контекст и инструменты в единое целое. Давайте посмотрим, как агент шаг за шагом рассуждает и действует.

Основной режим работы агента при выполнении задач называется ReAct (Reasoning + Acting). Хотя в названии отражены только два слова — рассуждение (Reasoning) и действие (Acting), — на деле цикл включает три этапа: модель сначала рассуждает, что нужно сделать сейчас, затем вызывает инструмент и действует, после чего наблюдает возвращённый инструментом результат и продолжает рассуждать о следующем шаге. Этот цикл «подумать → сделать → посмотреть → подумать → сделать → посмотреть» повторяется снова и снова, пока задача не будет выполнена.

Давайте разберём траекторию (trajectory) агента на конкретном примере — сведении доходов в нескольких валютах. Траектория — это история сообщений, которая непрерывно накапливается по ходу выполнения задачи агентом: сообщения пользователя, ответы модели (включая процесс рассуждения и вызовы инструментов), результаты выполнения инструментов. При каждом вызове LLM полный контекст, который она получает, состоит из двух частей: статического префикса (системный промпт + определения инструментов) и траектории (динамической истории сообщений) (рис. 1-4). Отсюда следует ключевой факт: контекст агента = статический префикс + траектория. Конкретно: статический префикс соответствует первым двум из пяти упомянутых ранее компонентов (системный промпт + определения инструментов), а траектория — оставшимся трём (сообщения пользователя + ответы модели + результаты выполнения инструментов, растущие по мере взаимодействия). На основе этого полного контекста LLM генерирует ответ для следующего шага, а затем этот ответ снова добавляется в траекторию для использования при следующем вызове.

Следующий скетч в стиле Python — поясняющий псевдокод, а не запускаемый код SDK; маркер python используется только для подсветки синтаксиса.

Цикл управления ReAct:

trajectory = [user_request]

repeat:
    context = stable_prefix + trajectory
    decision = Model(context)
    trajectory.append(decision)

    if decision has no tool call:
        return decision.answer

    for call in decision.tool_calls:       # independent calls may run in parallel
        validated_call = Harness.validate(call)
        observation = Environment.execute(validated_call)
        trajectory.append(observation)

Давайте разберём структуру траектории агента на псевдокоде:

траектория = [
  {role: "user" , content: "По квартальным доходам компании: Q1 2.5M долларов, Q2 2.1M евро, Q3 1.8M фунтов, Q4 380M иен, рассчитай годовой суммарный доход компании и средний квартальный доход" },
  
  # Первая итерация — LLM видит указанную выше траекторию и генерирует ответ
  {role: "assistant" ,
   reasoning: "Нужно перевести все валюты в USD..." ,
   content: "" ,  # Нет прямого ответа пользователю
   tool_calls: [
     {name: "convert_currency" , args: {amount: 2100000, from: "EUR" , to: "USD" }},
     {name: "convert_currency" , args: {amount: 1800000, from: "GBP" , to: "USD" }},
     {name: "convert_currency" , args: {amount: 380000000, from: "JPY" , to: "USD" }}
   ]},
  
  # Фреймворк агента выполняет инструменты и добавляет результаты в траекторию
  {role: "tool" , content: "EUR->USD: 2282608.7" },
  {role: "tool" , content: "GBP->USD: 2278481.01" },
  {role: "tool" , content: "JPY->USD: 2541806.02" },
  
  # Вторая итерация — LLM видит полную траекторию, включая результаты инструментов
  {role: "assistant" ,
   reasoning: "Результаты конвертации получены, теперь нужно свести и рассчитать..." ,
   content: "" ,
   tool_calls: [
     {name: "code_interpreter" , args: {code: "total = 2500000 + 2282608.7 + ..." }}
   ]},
  
  {role: "tool" , content: "Total: $9,602,895.73, Average: $2,400,723.93..." },
  
  # Третья итерация — LLM видит полную траекторию и генерирует итоговый ответ
  {role: "assistant" ,
   reasoning: "Все расчёты завершены, подводим итог..." ,
   content: "FINAL ANSWER: Суммарный доход $9,602,895.73..." }
]

Обратите внимание: в траектории не показаны системный промпт и определения инструментов — они выступают статическим префиксом и при каждом вызове LLM автоматически подставляются перед траекторией.

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

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

Траектория — это не просто запись выполнения, а отражение возможностей агента. Анализируя большое количество траекторий, мы можем выявлять поведенческие паттерны агента, оптимизировать пути принятия решений и улучшать дизайн инструментов. Данные траекторий можно даже сводить в базу знаний или использовать для обучения с подкреплением, чтобы тренировать более совершенные модели агентов, замыкая цикл оптимизации на обучении из опыта.

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

Эксперимент 1-2 ★: врождённые агентные способности Kimi K3

Этот эксперимент демонстрирует врождённые агентные способности Kimi K3 и воплощает новую парадигму «модель как агент». Kimi K3 — это модель на смеси экспертов (MoE, Mixture of Experts) с примерно 2,8 триллиона параметров. MoE можно представить как команду экспертов: сталкиваясь с задачами разного типа, система автоматически выбирает несколько наиболее подходящих экспертов для ответа, вместо того чтобы задействовать всех сразу, что одновременно обеспечивает высокую способность и повышает эффективность. Она обладает контекстным окном в 1 миллион токенов, врождённой способностью к пониманию изображений и всегда включённым «режимом размышления» (thinking mode); модель обучена с помощью обучения с подкреплением, благодаря чему стратегия принятия решений о вызове инструментов стала её врождённой способностью — когда вызывать инструмент, какой именно и с какими параметрами, модель решает самостоятельно, что позволяет ей автономно выполнять такие задачи, как веб-поиск. Следует пояснить: врождённым стало именно решение «когда и как вызывать», тогда как сами инструменты вроде web_search, code_runner по-прежнему выполняются как встроенные инструменты на уровне API на стороне сервера (Kimi запускает эти официальные инструменты через серверный движок скриптов под названием Formula).

Ключевые наблюдения таковы: модель сама решает, когда искать и что искать, проявляя настоящую автономность; она может динамически корректировать стратегию по результатам поиска, самостоятельно оценивая, достаточно ли информации. Здесь нужно развеять распространённое заблуждение, и ключ в том, чтобы разделить принадлежность двух вещей. Обучение с подкреплением наделяет модель способностью принимать решения — когда следует вызвать инструмент, какой именно, какие параметры передать, продолжать ли после получения результата, как связать десятки и сотни вызовов в связное рассуждение; эти суждения «использовать или нет, как использовать» вписаны в параметры модели. А сами инструменты и их выполнение обеспечиваются фреймворком агента (или встроенными инструментами API) — реальная реализация web_search, code_runner, песочница для кода, инициирование вызова и возврат результата выполняются в инфраструктуре за пределами модели. RL оптимизирует стратегию принятия решений, а не «зашивает» поисковую систему или песочницу для кода в веса модели. Поэтому цикл оркестрации никуда не исчез — он переместился с клиента на сервер, а право принятия решений было передано модели³ .

Одно из ярких преимуществ Kimi K3 в агентных задачах — устойчивость при длинных цепочках вызовов инструментов: она способна подряд выполнить 200–300 вызовов инструментов, сохраняя согласованность рассуждения, что заметно превосходит поведение большинства моделей, у которых деградация начинается уже после нескольких десятков вызовов. K3 оптимизирована под долгосрочные задачи программирования и агентные рабочие нагрузки; на момент выпуска предлагаются две конфигурации — K3 Max (для диалогов и агентных задач) и K3 Swarm Max (для масштабной параллельной обработки). Будучи моделью с открытым исходным кодом, она показала в бенчмарках по программной инженерии и агентным задачам производительность, сопоставимую с топовыми закрытыми системами, что доказывает эффективность подхода, при котором врождённые агентные способности наделяются модели через обучение с подкреплением.

Эксперимент 1-3 ★: врождённые способности Deep Research у GPT-5.6

Второй эксперимент использует OpenAI GPT-5.6 и демонстрирует, как продвинутая модель с помощью встроенных инструментов API замыкает цикл оркестрации «поиск — чтение — анализ» Deep Research на стороне сервера. Одна из удобных особенностей GPT-5.6 — свободный формат вызова инструмента (Freeform Tool Calling). В традиционном подходе, вызывая инструмент, модель должна упаковать все параметры в строгий формат JSON (структурированный формат данных), что, как заполнение анкеты, накладывает много ограничений на формат. Свободный формат вызова инструмента (в API объявляется через тип инструмента type: "custom") позволяет модели отправлять инструменту прямо необработанный текст (например, фрагмент кода на Python или SQL-запрос), избавляя от возни с экранированием JSON. Следует пояснить: это эволюция формата параметров API, а не революция в архитектуре модели — логика клиентского цикла вызова инструментов (обнаружить tool_calls → выполнить → вернуть результат) остаётся прежней, меняется лишь то, что параметры превращаются из JSON-строки в необработанный текст.

GPT-5.6 в связке с Responses API использует встроенные инструменты веб-поиска и интерпретатора кода — в этом и суть Deep Research: модель может автономно искать в интернете актуальную информацию и писать код для глубокого анализа, реализуя итеративный исследовательский процесс «поиск -> чтение -> анализ -> снова поиск». Например, столкнувшись с вопросом вроде «Между столицами 10 стран АСЕАН — какова расстояние между ближайшей парой столиц?», GPT-5.6 автоматически ищет географические координаты столиц каждой страны, затем пишет код на Python для вычисления расстояний по большому кругу между всеми парами столиц и в итоге находит ближайшую пару. Или в задаче «Найди динамику биткоина за последний месяц и сделай технический анализ» она может получить актуальные данные о ценах из нескольких финансовых источников, применить профессиональные библиотеки технического анализа для расчёта скользящих средних, RSI, MACD и других технических индикаторов, построить визуализированные графики и дать торговые рекомендации.

Что ещё важнее, GPT-5.6 сделала врождённой на уровне модели концепцию продукта OpenAI Deep Research, введя процесс уточнения намерения. Когда пользователь выдвигает исследовательский запрос, GPT-5.6 не бросается сразу его выполнять, а сначала серией вопросов проясняет истинное намерение пользователя. На примере «Найди динамику биткоина за последний месяц и сделай технический анализ» она сначала спросит: «Какой источник данных вы предпочитаете? Какие технические индикаторы нужно проанализировать?» Благодаря такому интерактивному уточнению намерения GPT-5.6 способна сформировать более точный отчёт, лучше отвечающий потребностям пользователя.

GPT-5.6 — зрелый образец концепции «модель как агент»: веб-поиск, интерпретатор кода и прочие инструменты выполняются замкнутым циклом на стороне сервера как встроенные инструменты Responses API, цикл оркестрации переместился с клиента на серверную часть API, что упрощает клиентскую реализацию; модель по-прежнему выдаёт стандартные вызовы инструментов, просто клиенту больше не нужно самому строить фреймворк оркестрации «поиск — чтение — анализ». Наибольшего внимания заслуживает механизм уточнения намерения: модель не начинает выполнение сразу по получении задачи, а сначала через вопросы подтверждает истинную потребность пользователя, а затем вырабатывает исследовательскую стратегию. Это позволяет ликвидировать разрыв между тем, «что сказал пользователь», и тем, «что пользователь действительно хочет», ещё до начала выполнения задачи.

Важно отметить, что этот эксперимент не привязан к одному поставщику. Читатели без кредитов OpenAI могут воспроизвести его у поставщика с равноценными управляемыми инструментами. Например, Responses API модели qwen3.7-plus от Alibaba Cloud Bailian также включает встроенные web_search и code_interpreter; управляемый поиск Formula и code_runner в Kimi K3 предоставляют возможности того же класса.

Рис. 1-5 показывает полную архитектуру врождённого вызова инструментов в парадигме «модель как агент», а также процесс исполнения ReAct у Kimi K3 / GPT-5.6 в реальных задачах.

Harness-инженерия: конкурентоспособность за пределами модели

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

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

Развернём полный состав в продакшн-форме в виде уравнения:

Агент = Model + Harness

Harness = управление контекстом + интерфейсы инструментов + ограничения + проверка + исправление

Агент ↔ Окружение

Минимальной демонстрации достаточно Model и Harness, который формирует контекст и предоставляет инструменты; в промышленной системе внутри той же границы нужны также ограничения, проверка и исправление. Например, агент возврата средств может поместить правила в контекст, ограничить вызовы требованиями к полномочиям и сумме, сверить результат с состоянием базы данных, а при тайм-ауте повторить попытку или перейти на запасной путь. Harness engineering изучает именно этот код исполнения и управления — «вне модели, но внутри среды».

Точнее говоря, Harness — это не всё за пределами модели, а слой выполнения и управления внутри границы Агента и за пределами Модели. Он опосредует взаимодействие Модели и Окружения, но не включает само Окружение. Определения инструментов, адаптеры вызовов, разрешения песочницы и механизмы сброса относятся к Harness; файлы и процессы, изменяющиеся внутри песочницы, внешние базы данных, веб-страницы, пользователи и физический мир относятся к Окружению. Место развёртывания не меняет эту концептуальную границу. Ядро Harness — это управление контекстом и интерфейсы инструментов, вокруг которых построены три категории инженерных защитных механизмов:

Функция	Задача одной фразой / Основной принцип	Практический пример	Подробнее
Context (контекст)	Предоставляет модели воспринимаемую информацию; Достаточность информации: агент в каждой точке принятия решения опирается на достаточную информацию для суждения	Системный промпт, база знаний, строка состояния агента, побочные запросы через Sidecar	Главы 2 и 3
Tools (инструменты)	Предоставляет модели средства действия; Ясность интерфейса: интуитивные имена инструментов, примеры параметров, описание границ	Инструменты MCP, интерпретатор кода, инструмент поиска	Глава 4
Constrain (ограничения)	Задаёт границы поведения — что можно делать, что нельзя; Значения по умолчанию с обеспечением безопасности при сбое: все возможности по умолчанию отключены и должны открываться явно (подобно управлению разрешениями приложений на телефоне)	В Claude Code каждый инструмент по умолчанию требует авторизации пользователя для выполнения	Глава 4
Verify (проверка)	Автоматически определяет правильность результата операции; Изоляция входных данных: проверка безопасности смотрит только на структурированные данные (например, JSON-поля, возвращаемые инструментом), а не на текст, свободно сгенерированный моделью (потому что атакующий может через инъекцию промпта манипулировать выводом модели)	Проверка линтером, система типов, валидация результатов вызова инструментов	Главы 5 и 6
Correct (исправление)	При обнаружении проблемы автоматически исправляет или откатывает; Не показывать промежуточное состояние, пока не подтверждена невозможность восстановления (например, при сбое вызова инструмента сначала молча повторять попытку, не демонстрируя пользователю полуготовый результат)	Молчаливый повтор, продолжение генерации, откат к человеческому суждению при последовательных сбоях (механизм предохранителя)	Главы 2 и 5

Базовый ход цикла управления моделью показан в следующем псевдокоде:

observation = Environment.observe()
trajectory = [observation]
while true:
	actions = Model(Harness.build_context(trajectory))
	if len(actions) == 0:
		break
	allowed_actions = Harness.constrain(actions)
	observation = Environment.apply(allowed_actions)
	if not Harness.verify(Environment):
		observation = Harness.correct(Environment)
	trajectory.append(allowed_actions, observation)

Этот каркас намеренно опускает детали реализации. Полный цикл сообщений API приведён в главе 2; инструменты и автоматическая проверка рассматриваются соответственно в главах 4 и 5.

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

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

Возьмём для примера Claude Code: подавляющая часть кода его Harness — это ограничения, проверка и исправление, а не контекст и инструменты. Сами инструменты (чтение и запись файлов, выполнение команд, поиск) — лишь малая часть, а настоящее ядро — защитные механизмы, построенные вокруг этих инструментов. К ним относятся:

• Управление состоянием процесса: отслеживание того, на каком шаге сейчас находится агент
• Многоуровневое сжатие контекста: автоматическое упрощение, когда информации становится слишком много
• Классификация разрешений: контроль того, какие операции требуют подтверждения пользователя
• Предохранитель (Circuit Breaker): автоматическое «отключение питания» и остановка повторных попыток при последовательных ошибках — как дома при коротком замыкании срабатывает предохранитель, предотвращая крах всей системы
• Механизм восстановления после ошибок: перехват исключений, откат к последнему стабильному состоянию, повтор или передача человеку

Отрасль переходит от «уметь делать дела» к «делать дела надёжно», и потому Harness-инженерия становится ключевой конкурентоспособностью агентных систем.

От инженерии промптов к Loop-инженерии: эволюция инженерных парадигм

Оглядываясь на развитие инженерии ИИ-приложений, можно увидеть чёткую эволюционную дугу:

Инженерия промптов (Prompt Engineering) — первая волна инноваций: повышение качества вывода за счёт оптимизации подаваемых модели инструкций на естественном языке.

Инженерия контекста (Context Engineering) — вторая волна: люди осознали, что одной лишь оптимизации промптов недостаточно, нужно системно управлять всей информацией, которую видит модель: системными инструкциями, определениями инструментов, историей диалога и внешними знаниями.

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

Затем появилась Loop-инженерия (Loop Engineering), расширив взгляд с одиночного запуска до непрерывной автономной работы через множество итераций: кто обнаруживает следующее нужное дело, когда проверять, когда считать задачу действительно завершённой (об этом пойдёт речь в главе 10 в связи с мультиагентными системами совместной работы).

В июле 2026 года в отрасли стали использовать термин Graph-инженерия (Graph Engineering) для обозначения более высокого уровня оркестрации: агентные циклы, детерминированные программы и человеческие согласования организуются в явный граф выполнения, где узлы предоставляют конкретные возможности, рёбра задают маршрутизацию и зависимости, а структурированное состояние передаётся по рёбрам и сохраняется на ключевых границах⁴ .

Эти пять этапов не заменяют друг друга, а вложены слой за слоем: инженерия промптов — подмножество инженерии контекста, инженерия контекста — подмножество Harness-инженерии, Harness-инженерия — подмножество Loop-инженерии. Каждый слой расширяет круг внимания и влияния инженера, опираясь на предыдущий. Когда способности разных моделей становятся всё ближе друг к другу и перестают быть решающим фактором различия, конкурентное преимущество смещается к инженерным практикам за пределами модели.

Этот вывод подтверждается недавней инженерной практикой. Практика LangChain на Terminal Bench 2.0, бенчмарке способности агента выполнять сложные задачи в терминальной среде, служит убедительным примером: их кодинг-агент вырос с 52,8% до 66,5% и поднялся с места за пределами топ-30 в топ-5. Изменилась не модель, а Harness: агент стал автоматически проверять собственные результаты выполнения, определять, не застрял ли он в повторяющемся цикле, и оптимизировать стратегию размышления.

Основные принципы построения эффективного агента

По опыту Anthropic, успешные агентные системы следуют трём основным принципам.

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

Сохраняй прозрачность. Явно показывай шаги планирования агента, журналы выполнения и траекторию принятия решений — это нужно не только для удобства отладки, но и как предпосылка для построения доверия пользователя. Потому что если ошибка произошла в чёрном ящике, внешний наблюдатель не сможет ни локализовать её, ни исправить.

Хорошо проектируй интерфейс инструментов (ACI, Agent-Computer Interface). ACI подчёркивает проектирование интерфейса с точки зрения агента (чтобы агенту было легко его понимать и использовать), а не с точки зрения программиста, как в традиционных API. Имена и параметры инструментов должны быть интуитивно понятны, а места, где легко ошибиться, должны быть спроектированы так, чтобы ошибка была невозможна в принципе — например, скошенный угол SIM-карты позволяет вставить её в лоток только одной стороной, а микроволновая печь не начинает нагрев, пока дверца не закрыта, исключая опасную работу с открытой дверцей. У такого подхода «устранять ошибки за счёт проектирования» в производственной сфере есть специальный термин — Poka-yoke, происходящий из производственной системы Toyota. Плохо спроектированный инструмент заставит даже самую сильную модель постоянно ошибаться — потому что единственный канал общения между моделью и инструментом — это сам интерфейс, и размытый интерфейс модель раздует до системных ошибок.

Следующие три раздела раскрывают три независимые, но важные темы Harness-инженерии: выбор модели, паттерны оркестрации, защитные ограждения и безопасность. Ни одна из них не входит в сами пять элементов Harness, но все они — неизбежные решения в инженерной практике.

Как выбрать модель

Прежде чем обсуждать паттерны оркестрации, ответим на практический вопрос: какую модель выбрать для управления агентом?

Модель — это интеллектуальная основа агента, и правильный выбор модели зачастую эффективнее оптимизации промптов. Поскольку модели обновляются крайне быстро, в этом разделе мы не рекомендуем конкретные версии, а даём общие ориентиры для выбора.

Закрытые модели. Сейчас два наиболее часто используемых в разработке агентов поставщика закрытых моделей — OpenAI (серии GPT/o) и Anthropic (серия Claude). Закрытые модели обычно опережают по способностям, но дороже и ограничены API-политикой поставщика. Выбирая модель, не ориентируйся только на рейтинги — проводи оценку на своей собственной задаче (см. главу 7).

Открытые модели. На момент написания книги отставание открытых моделей от закрытых составляет менее шести месяцев, а стоимость значительно ниже. Если твой бизнес-сценарий не требует максимальных возможностей модели, открытая модель — прагматичный выбор. Такие модели дешевле, допускают частное развёртывание и дообучение, поэтому подходят для сценариев, чувствительных к стоимости или требующих соответствия требованиям к данным. DeepSeek, Kimi и GLM относятся к сильным китайским моделям по агентным способностям. Возможности вызова инструментов сильно различаются, поэтому перед выбором обязательно протестируй модель в конкретном сценарии.

Помимо возможностей, учитывай границы политик модели. Техническая способность модели выполнить задачу ещё не означает, что продукт, в котором она работает, разрешит пользователю задействовать эту способность. Разные поставщики проводят разные границы в отношении кибербезопасности, дистилляции и извлечения моделей, приватных данных и высокорисковых операций; одна и та же задача может также дать разные результаты в чат-продукте, Coding Agent и API. Поэтому при выборе модели нельзя сравнивать только точность, цену и скорость. На реальных задачах нужно проверить, согласится ли модель их выполнять, предоставляет ли интерфейс необходимые возможности и допускают ли условия сервиса предполагаемое использование. Для критически важных бизнес-задач заранее подготовь передачу человеку или другую соответствующую требованиям модель.

Подавляющему большинству агентов нужна модель с поддержкой рассуждения (Reasoning). Агенту нужно многошаговое рассуждение, выбор инструментов и другие сложные решения, а модели без способности к рассуждению обычно показывают на таких задачах плохие результаты. Исключение — лишь очень редкие сценарии, например выполнение единичной простой задачи или простые GUI-операции в Computer Use, где нужно лишь кликнуть в фиксированное место — здесь справится и модель без рассуждения. Но как только речь заходит о многошаговом рассуждении или динамическом принятии решений, обязательно выбирай модель с поддержкой рассуждения.

Обрати внимание на скорость вывода и мультимодальные возможности. Помимо стоимости, есть ещё два легко упускаемых измерения. Первое — скорость вывода токенов: агенту часто нужно много раундов рассуждения, и на каждом раунде приходится ждать завершения вывода модели, прежде чем выполнить следующий шаг, поэтому скорость вывода напрямую определяет сквозную задержку ответа — если задача агента требует 20 раундов рассуждения, а каждый медленнее на 2 секунды, это означает лишние 40 секунд ожидания в сумме. Второе — поддержка мультимодальности: если твой агент должен понимать изображения, аудио или видео, мультимодальные возможности становятся жёстким требованием, и разные модели тут сильно различаются.

Паттерны оркестрации: рабочий процесс и автономность

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

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

Паттерн рабочего процесса: детерминированная оркестрация

Рабочий процесс (Workflow) — это система, которая оркеструет LLM и инструменты по предопределённым путям кода. Его путь исполнения детерминирован и заранее спроектирован разработчиком: что делать на каждом шаге и куда двигаться дальше — всё жёстко прописано в коде, а LLM внутри каждого узла отвечает лишь за понимание и генерацию.

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

1. Проверка личности пользователя — вызов API аутентификации, чтобы подтвердить, кто пользователь
2. Поиск доступных рейсов — запрос к базе данных рейсов по запросу пользователя
3. Завершение оплаты — вызов платёжного интерфейса для списания средств
4. Подтверждение бронирования — вызов API бронирования, чтобы зафиксировать место, и отправка пользователю подтверждения

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

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

Главное ограничение рабочего процесса — недостаток гибкости. Когда возникает ситуация, не покрытая заранее заданным процессом (например, пользователь на этапе оплаты вдруг захотел поменять рейс, или рейс внезапно отменили и нужно предложить альтернативу), фиксированный путь узлов не может гибко на это отреагировать — остаётся только пойти по заранее заданной ветке обработки исключений или вернуть управление человеку.

Автономный агент: динамическое самостоятельное принятие решений

Когда фиксированный путь рабочего процесса не может удовлетворить требования, нам нужен автономный агент (Autonomous Agent). Ключевое отличие автономного агента от рабочего процесса в том, что путь исполнения не определён заранее, а решается агентом в реальном времени на основе обратной связи от среды.

Снова возьмём бронирование билетов: автономному агенту не нужны четыре предопределённых фиксированных узла. Пользователь говорит: «Забронируй мне билет в Шанхай на следующую среду», — и агент сам решит сначала поискать рейсы, обнаружит, что нужен вход в систему, поэтому сначала проверит личность, потом вернётся к поиску, обнаружит, что самый дешёвый рейс требует пересадки, сам спросит пользователя, согласен ли тот, пользователь скажет, что без пересадок, агент скорректирует условия поиска…

Это значит, что автономный агент должен обладать способностью к самостоятельному планированию — самостоятельно решать, какие шаги предпринять, а также уметь распознавать неудачи и корректировать стратегию, а не просто останавливаться при ошибке. Но автономность не означает вседозволенности — необходимо спроектировать чёткие условия остановки (задача выполнена, достигнут максимум итераций или произошла невосстановимая ошибка), иначе агент легко впадёт в бесконечный цикл или будет выполнять лишнее.

С точки зрения реализации автономный агент по сути — это LLM, использующий инструменты в цикле и продвигающий задачу за счёт постоянного получения обратной связи от среды; это и есть описанный ранее цикл ReAct. Типичные условия выхода включают: вызов инструмента финального вывода, ответ модели без каких-либо вызовов инструментов, либо возникновение ошибки или достижение максимального числа раундов.

Автономный агент особенно подходит для открытых задач — таких, где трудно предсказать количество необходимых шагов. Типичные сценарии применения включают: кодинг-агент, решающий задачи SWE-bench (Software Engineering Benchmark — бенчмарк для оценки способности агента автоматически исправлять реальные GitHub Issue), агент «использования компьютера» (Computer Use), управляющий интерфейсом компьютера как человек, а также исследовательские задачи, требующие итеративного поиска и анализа.

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

Выбор между двумя паттернами и их сочетание

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

Краткое сравнение основных агентных фреймворков

В таблице ниже собраны текущие популярные агентные фреймворки/платформы, чтобы читатель мог быстро сориентироваться в зависимости от сценария:

Фреймворк/платформа	Основное позиционирование	Паттерн оркестрации	Способ разработки	Подходящие сценарии
OpenAI Agents SDK	Лёгкая библиотека для разработки агентов	Автономный (цикл инструментов)	Код в первую очередь	Быстрое прототипирование, одноагентные приложения
Claude Agent SDK	Продакшн-фреймворк для разработки агентов	Автономный (цикл инструментов + субагенты)	Код в первую очередь	Сложные автономные задачи, кодинг-агент
LangChain / LangGraph	Универсальный фреймворк для LLM-приложений	Рабочий процесс + автономный	Код в первую очередь	Сложные цепочки рассуждений, многошаговые рабочие процессы
n8n	Визуальная автоматизация рабочих процессов	Рабочий процесс + автономный	Low-code (визуальный перетаскиванием)	Автоматизация бизнеса, нетехнические команды
Dify	Платформа разработки LLM-приложений	Рабочий процесс + диалоговый	Low-code (визуальный + API)	Корпоративный RAG, приложения баз знаний
CrewAI	Ролевая мультиагентная оркестрация	Мультиагентное сотрудничество	Код в первую очередь	Командная декомпозиция и выполнение задач
OpenClaw	Опенсорсный универсальный персональный агент	Автономный + событийно-управляемый	Конфигурация + код (self-hosted)	Персональный ассистент, Deep Research, Computer Use, интеграция сообщений с разных платформ
DeepSeek Harness	Фреймворк самоэволюции агента	Всё является плагином	Сначала код, легко настраивать	Разработчики агентов, исследователи
Pi	Минималистичный фреймворк Coding Agent	Автономный	Сначала код, легко настраивать	Разработчики агентов

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

Обсуждённые выше паттерны оркестрации решают проблему организации контекста и инструментов внутри Harness — как связать воедино вызовы LLM, инструменты и потоки данных. Но одной лишь способности что-то делать недостаточно — нужно ещё гарантировать, что это делается правильно и безопасно. Далее обсудим самое главное практическое средство реализации механизмов ограничения, проверки и исправления, выстраиваемых вокруг контекста и инструментов, — ограждения.

Ограждения и безопасность

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

Ограждения — это ключевое средство реализации на уровне «ограничений, проверки и исправления» внутри Harness; они образуют многоуровневую линию обороны, обеспечивающую безопасное и контролируемое поведение агента. Хорошо спроектированные ограждения (Guardrails) помогают управлять рисками конфиденциальности данных (например, предотвращать утечку системного промпта) или репутационными рисками (например, обеспечивать соответствие поведения модели образу бренда). Можно сначала установить ограждения под уже выявленные риски, а затем постепенно добавлять новые по мере обнаружения новых уязвимостей.

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

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

Типы ограждений

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

Ограждения слоя контекста заведуют тем, что модели вообще позволено увидеть, и перехватывают содержимое до того, как оно попадёт в контекст. Обычно они складываются из четырёх механизмов. Классификатор релевантности отмечает запросы не по теме — например, когда помощнику по программированию задают вопрос «какой высоты Эмпайр-стейт-билдинг?». Классификатор безопасности выявляет джейлбрейк (Jailbreak — побуждение модели обойти собственные ограничения) и внедрение в промпт (Prompt Injection — встраивание вредоносных инструкций во входные данные); принципиальная разница в том, что джейлбрейк устраивает сам пользователь, а внедрение в промпт — это злоумышленник, косвенно управляющий поведением модели через внешние данные вроде веб-страниц или документов. Модерация контента отмечает вредный или неуместный ввод: насилие, дискриминацию. Защита на правилах применяет детерминированные меры — чёрные списки, ограничение длины ввода, фильтры регулярных выражений — против известных угроз наподобие SQL-инъекции. К этому же слою относятся маркировка источника и разделение «инструкций» и «данных»; глава 2 разбирает их подробно.

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

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

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

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

Вмешательство человека

Вмешательство человека (Human in the loop, также «человек в контуре») — ключевая мера защиты, которая позволяет агенту повышать фактическую производительность, не жертвуя пользовательским опытом. Это особенно важно на раннем этапе развёртывания: помогает выявлять паттерны сбоев, обнаруживать граничные случаи и выстраивать надёжный цикл оценки.

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

Обычно есть две основные ситуации, которые запускают вмешательство человека:

Превышение порога сбоев Установите верхний предел числа повторных попыток или операций агента. Если агент превышает эти лимиты, следует эскалировать к вмешательству человека.

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

Вернёмся к основной линии пяти элементов Harness и посмотрим, как она соотносится со структурой книги.

Пять элементов Harness и часть «построение»

Сначала проясним отношение двух формул, чтобы не пришлось держать в голове два скелета. Структурный скелет книги ровно один — тот, который снова и снова используют введение и послесловие: Агент = LLM + контекст + инструменты: главы со 2-й по 6-ю строят, главы с 7-й по 9-ю оценивают и развивают, глава 10 посвящена сотрудничеству. Агент = Модель + Harness — не соперничающее с ним деление, а то же самое, развёрнутое в производственную форму: «контекст» и «инструменты» разворачиваются в пять обязанностей — управление контекстом, интерфейс инструментов, ограничения, проверка, исправление. Поэтому это линза внутри части «построение», а не оглавление, покрывающее все десять глав.

В этих пределах пять элементов Harness ясно соответствуют главам со 2-й по 5-ю:

Фокус Harness	Соответствующая глава	Основное содержание	Точка внимания к безопасности
Проектирование контекста	Глава 2 (инженерия контекста)	Инженерия промптов, строка состояния агента, сжатие контекста, Agent Skills	Инъекция в промпт и утечка информации
Расширение контекста (персистентность знаний)	Глава 3 (база знаний)	Память пользователя, RAG, структурированное индексирование, агентный RAG	Раскрытие чувствительной информации, защита приватности
Проектирование инструментов и ограничения безопасности	Глава 4 (проектирование инструментов)	Классификация инструментов, контроль разрешений, стандарт MCP, асинхронная архитектура	Ошибочные действия, несанкционированный доступ, необратимые операции
Проверка и исправление инструментов	Глава 5 (генерация кода)	Harness Coding Agent, разработка через тесты, правила в виде кода	Подмена личности, распределение ответственности

Глава 6 («Взаимодействие») не относится ни к одному из пяти элементов: она расширяет саму модальность и момент пространств наблюдения и действия. Главы с 7-й по 9-ю спрашивают, как узнать, что Harness построен верно, и как заставить его продолжать улучшаться. Глава 10 заменяет Harness одного агента структурой сотрудничества нескольких. Если втиснуть и эти главы в пять клеток, клетки просто перестанут различать.

Безопасность тоже не делится по главам: это сквозная забота (cross-cutting concern — проблема, затрагивающая многие части системы), проходящая через всю книгу и организованная по трём слоям ограждений из предыдущего раздела — контекста, исполнения и данных. Столбец «фокус безопасности» в таблице показывает, куда преимущественно приземляется каждая глава среди этих трёх слоёв.

Практика Anthropic при построении долго работающих агентов показывает, как проектирование Harness решает проблемы, которые сама модель решить не в состоянии. Они разбивают сложную задачу на «инициализирующего агента» (настраивает среду, раскладывает список задач) и «исполняющего агента» (в каждой сессии инкрементально продвигается и оставляет ясные передаточные артефакты), и с помощью структурированного Harness решили проблемы «исчерпания контекста» и «преждевременного объявления о завершении» агента в долгих задачах. Последующие главы поочерёдно углубятся в компоненты Harness — глава 2 начинается с самого ядра, инженерии контекста, а глава 5 специально разворачивает полную практику Harness-инженерии в кодинг-агенте.

Шаблоны проектирования, проходящие через всю книгу

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

Предлагающий — Проверяющий (Proposer-Reviewer): производство и суждение берут на себя две роли, не разделяющие контекст, причём проверяющий видит сам артефакт — отрисованный результат, вывод тестов, структурированные аргументы вызова, — а не ход рассуждений производителя. Предпосылка в том, что самопроверка ненадёжна: модель внутри контекста не может додуматься до того, до чего не додумалась, и с трудом определяет, не внедрились ли в неё. Глава 3 применяет этот шаблон для обновления знаний; глава 4 — для предварительного одобрения и последующей проверки вызовов инструментов (Sidecar — его версия только для чтения); три эксперимента главы 5 — презентации, видео и логи — целиком на нём построены; глава 7 использует его для оценки интерфейсов, глава 9 — для проверки предложений об обновлении; глава 10 разбирает его форму в равноправном сотрудничестве и то, почему агенту нельзя проверять самого себя.

Постепенное раскрытие (Progressive Disclosure): вместо того чтобы разом положить в контекст всю информацию, сначала дают доступный для поиска каталог, а подробности подгружают по требованию. Это оптимизирует сразу две вещи — бюджет контекста и точность выбора. Agent Skills из главы 2 — самая типичная форма (метаданные постоянно в контексте, тело загружается по требованию); многоуровневый поиск главы 3, проактивное обнаружение инструментов и постраничное усечение главы 4, обнаружение агентов главы 10 — всё это его варианты.

Только добавление (Append-only): состояние развивается дописыванием, а уже записанное не переписывают. Взамен получают кэшируемость, воспроизводимость и проверяемость. Стабильность префикса KV Cache из главы 2 — производительностная форма этого шаблона: чем раньше внесено изменение, тем больше кэша обесценивается; событийная память главы 3 и привычка главы 4 дописывать схему нового инструмента в конец траектории, а не вставлять обратно в префикс, следуют той же дисциплине.

Граничный набор + удерживающий набор (Boundary Set + Retention Set): любое изменение нужно проверять одновременно на «тех примерах, которые оно должно изменить», и на «тех, которых оно не должно затронуть». Измеряя только первые, переобучение принимают за прогресс; измеряя только вторые, бесполезное изменение принимают за безопасное. Регрессионные задачи главы 7, разделение обучения и оценки в главе 8 и проверка предложений об обновлении в главе 9 держатся на этой паре наборов.

Минимальный diff + обратимость: каждое изменение по возможности небольшое, с указанием источника и с возможностью отката по отдельности, а не сплошная переписка. Именно это делает возможной атрибуцию: когда что-то ломается, можно проследить до конкретного изменения. Обновления знаний главы 3, патчи кода главы 5, обновления промптов и программ главы 9 следуют этому правилу; а три пути обновления, приведённые в начале этой главы (адаптация внутри контекста, обновление внешних артефактов, обновление параметров), как раз выстроены по убыванию обратимости.

Итоги главы

Эта глава, отталкиваясь от практики, выстроила базовую систему понимания и построения ИИ-агентов.

Агент = мозг + глаза + руки и ноги: LLM — это мозг (ядро принятия решений), контекст — глаза (определяет, что он может видеть), инструменты — руки и ноги (определяют, что он может делать). Все трое незаменимы.

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

Глаза (контекст) — решающий фактор: контекст состоит из статического префикса (системный промпт + определения инструментов) и динамической траектории (история сообщений). Абляционное исследование показывает, что удаление любого компонента приводит к заметной деградации системы. Суть цикла ReAct — заставлять модель непрерывно продвигать задачу, постоянно дописывая траекторию.

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

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

Пять шаблонов проектирования проходят через всю книгу: Предлагающий—Проверяющий, постепенное раскрытие, только добавление, граничный набор + набор сохранения и минимальный diff + обратимость.

Безопасность — вопрос архитектуры: её нужно учитывать с первой строки кода, а не латать перед запуском. По сложности обхода ограждения делятся на слои контекста, исполнения и данных; вся дальнейшая дискуссия о безопасности опирается на этот каркас.

Следующая глава углубится в самый ключевой компонент Harness — инженерию контекста. Академические истоки понятия «агент» в обучении с подкреплением, а также подробное сравнение традиционного RL и современных LLM-агентов мы систематически развернём в главе 8.

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

Вопросы для размышления

1. ★★ Если бы вы могли добавить агентной системе лишь одну способность — более сильную модель, более богатый контекст или больше инструментов, — что бы вы выбрали? При каких условиях ваш выбор изменился бы?
2. ★★★ В цикле ReAct совокупный объём чтения из кеша растёт примерно квадратично с числом раундов. Как уменьшить этот рост?
3. ★★ Парадигма «модель как агент» означает, что модель становится всё более самостоятельной в решениях о вызове инструментов. Но в этой главе доказывается, что важность Harness-инженерии, наоборот, растёт. Как сосуществуют эти две тенденции? В чём будет заключаться ключевая ценность агентных фреймворков в будущем?
4. ★★ В абляционном исследовании отсутствие «обратной связи о результатах инструментов» приводило к тому, что агент попадал в бесконечный цикл. Какие ещё ситуации в продакшене, помимо отсутствия результатов инструментов, могут привести агента к бесконечному циклу? Какой механизм обнаружения и остановки вы бы спроектировали?
5. ★ В этой главе пять агентных продуктов разбирались по трём измерениям: восприятие, действие, политика. Выберите ИИ-продукт, которым вы пользуетесь ежедневно, проанализируйте его по этим трём измерениям и подумайте, разумна ли его архитектура. Если бы вы проектировали этот ИИ-продукт, какие возможности для улучшения вы бы нашли?
6. ★★ Если бы вам нужно было спроектировать систему поддержки клиентов, специально обрабатывающую бронирование авиабилетов, вы бы выбрали режим рабочего процесса или режим автономного агента? Возможно ли смешать оба режима в одной системе?
7. ★★★ В разделе про ограждения упоминалась оценка риска инструментов. Если инструмент в большинстве случаев низкорисковый, но при определённых сочетаниях параметров становится высокорисковым (например, delete_file для удаления обычного файла против удаления системного файла), как бы вы спроектировали динамическую оценку риска?
8. ★★ В таблице агентных продуктов из этой главы пространство действий у всех агентов «открытое». В каких сценариях ограниченное пространство действий (например, выбор только из предопределённых вариантов) оказывается предпочтительнее открытого?
9. ★★ Механизм вмешательства человека требует, чтобы агент умел «изящно передавать управление». Но на практике пользователь может быть не в сети, отвечать очень медленно или давать расплывчатые указания. Что агенту делать в таком случае?
10. ★★★ Во введении отмечалось, что «хорошие принципы проектирования должны пережить циклы итераций модели», однако конкретные инженерные приёмы, реализующие эти принципы, могут устаревать по мере развития возможностей моделей. Приведите пример такого инженерного приёма для агентов и обоснуйте свою точку зрения.

---

1. В официальных материалах Manus исходный Sandbox описан как изолированная облачная виртуальная машина. Представляя Google Drive Connector, Manus прямо напомнил, что прежде пользователю приходилось вручную скачивать и загружать файлы между Drive, рабочим столом и Manus. При запуске My Computer в марте 2026 года компания назвала тот факт, что важнейшая работа находится локально, а не в облаке, фундаментальным ограничением облачной песочницы. Официальный README OpenClaw описывает его как постоянно доступного персонального помощника с локально-ориентированной архитектурой, работающего на устройствах пользователя, и перечисляет более двадцати каналов сообщений; инструменты и плагины позволяют добавлять облачные интеграции и локальные возможности. См. https://manus.im/blog/manus-sandbox, https://manus.im/blog/manus-google-drive-connector, https://manus.im/blog/manus-my-computer-desktop, https://github.com/openclaw/openclaw и https://docs.openclaw.ai/tools ↩︎

2. Sutton, Rich. "The Bitter Lesson", 2019. http://www.incompletenessideas.net/IncIdeas/BitterLesson.html ↩︎

3. Спасибо читателю asdlem, который через GitHub Issue #30 указал на это и прояснил различие: «RL делает врождённой стратегию принятия решений о вызове инструментов, а не механизм их выполнения». См. https://github.com/bojieli/ai-agent-book/issues/30 ↩︎

4. Josh C. Simmons явно использовал это название в статье We Are Entering the Graph Engineering Phase от 4 июля 2026 года, описав его через узлы, типизированные рёбра и состояние с контрольными точками. 18 июля вопрос Peter Steinberger о том, не сместилось ли обсуждение от циклов к графам, помог термину распространиться. Сами практики старше названия: официальная документация LangGraph, Microsoft Agent Framework и Google ADK называет их графовой оркестрацией или graph-based workflows. См. https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase, https://x.com/steipete/status/2078277297791189132, https://docs.langchain.com/oss/python/langgraph/overview, https://learn.microsoft.com/en-us/agent-framework/workflows/ и https://adk.dev/workflows/. ↩︎

5. Anthropic. "Next-generation Constitutional Classifiers: More efficient protection against universal jailbreaks", 2026. https://www.anthropic.com/research/next-generation-constitutional-classifiers ; статья: Cunningham et al., "Constitutional Classifiers++: Efficient Production-Grade Defenses against Universal Jailbreaks", arXiv:2601.04603 ↩︎