От чат-бота к агенту: инженерный подход к LLM

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

Фундамент AI-агентов: от архитектуры трансформеров до цифровых токенов 0:00

Путь к созданию по-настоящему автономных AI-агентов начинается с понимания их «двигателя» — больших языковых моделей (LLM). Самый известный пример такой технологии — ChatGPT, однако для разработчика важно разделять эти понятия. Название ChatGPT состоит из двух частей: «Chat» — это лишь интерфейс, внешняя оболочка для взаимодействия , в то время как «GPT» (Generative Pre-trained Transformer) представляет собой «мозг» системы, определяющий её интеллектуальные возможности .

Архитектура Transformer и искусство внимания 4:36

До 2017 года искусственный интеллект уже окружал нас в виде спам-фильтров и автозамен, но он редко казался по-настоящему разумным . Всё изменилось с публикацией исследователями Google статьи «Attention is All You Need», которая представила архитектуру трансформера (Transformer) . В отличие от предыдущих систем, трансформеры обладают способностью «внимания» (attention): они могут анализировать все слова в предложении одновременно, понимая сложные связи между ними . Например, в предложении «Собака гналась за своим хвостом, потому что он был длинным», модель мгновенно понимает, что «он» относится к хвосту, а не к собаке, благодаря параллельной обработке контекста .

Принцип работы любой LLM, несмотря на сложность, сводится к одной задаче — предсказанию следующего слова (или его части) . В процессе обучения модель анализирует миллиарды страниц текста: от Википедии до репозиториев кода . Важно понимать: GPT учит не факты или мнения, а паттерны (закономерности) . Она «знает», что после фразы «Париж — столица...» с огромной вероятностью должно следовать слово «Франции» . Именно ориентация на паттерны, а не на базу данных фактов, объясняет феномен галлюцинаций: модель просто генерирует текст, который звучит правдоподобно согласно усвоенным структурам языка .

Семейство моделей GPT постоянно эволюционировало:

GPT-1 (2018): доказательство жизнеспособности концепции .
GPT-3 (2020): настоящий прорыв, научившийся писать эссе и код .
GPT-4 (2023): мультимодальная модель, способная понимать изображения .
GPT-4o (2024): высокая скорость и продвинутые возможности зрения и голоса .

Параметры: масштаб «больших» моделей 10:10

Буква «L» в аббревиатуре LLM означает «Large» (большая), что относится как к объему обучающих данных, так и к количеству параметров . Параметры — это внутренние настройки, которые модель корректирует в процессе обучения, чтобы точнее предсказывать следующее слово . Если GPT-2 имела 1,5 миллиарда параметров, то GPT-3 совершила скачок до 175 миллиардов .

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

Токены и контекстное окно: валюта и память AI 17:54

Модели не читают текст буквами или словами, как люди. Они оперируют токенами — смысловыми фрагментами текста . Токеном может быть целое слово, часть слова или даже один символ . Процесс разбиения текста называется токенизацией . Например, часто встречающиеся слова (как «computer») становятся одним токеном, а редкие или сложные (как «anthropomorphisation») разбиваются на несколько частей .

Для разработчика AI-агентов токены важны по трем причинам:

Стоимость: Провайдеры (OpenAI, Anthropic) берут плату за каждый токен. При этом генерация (output) обычно стоит в несколько раз дороже, чем обработка входящего текста (input), так как модель создает каждый выходной токен последовательно, что требует больших вычислительных мощностей .
Скорость: Чем больше токенов в ответе, тем дольше пользователь будет ждать результат .
Контекстное окно: Это «рабочая память» модели, ограничивающая объем текста, который она может держать в голове одновременно .

Размер контекстного окна стремительно растет: если у GPT-3.5 оно составляло около 4 000 токенов, то современные модели, такие как Claude или Gemini, поддерживают от 128 000 до 1 миллиона токенов и более . Это позволяет загружать в модель целые книги или огромные базы кода. Однако контекстное окно — это жесткий лимит: если сумма входных и выходных данных его превысит, модель просто не сможет обработать запрос .

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

🧠 Управляемый хаос: температура и архитектура эффективного промпта 25:20

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

Температура: баланс между точностью и креативностью 25:20

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

Существуют проверенные практикой стандарты настройки:

0 (Детерминизм): Модель всегда выбирает наиболее вероятный токен. Идеально для извлечения данных, классификации и задач, где важна повторяемость .
0.1 – 0.2 (Кодинг): Код должен быть корректным, а не креативным . Минимальная температура помогает избежать синтаксических ошибок, сохраняя при этом небольшую гибкость.
0.5 – 0.7 (Общение): Оптимально для чат-ботов общего назначения. Речь звучит естественно, но остается в рамках здравого смысла .
0.8 – 1.2+ (Творчество): Используется для написания текстов, где нужны неожиданные повороты и разнообразие .

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

Психология промпта: активация паттернов вместо простых команд 31:13

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

Ключевым инструментом управления поведением модели является использование ролей в структуре сообщений (Messages Array):

System (Системная роль): Это невидимая для конечного пользователя инструкция от разработчика . Здесь задаются правила поведения, личность (persona) и ограничения модели . Например, роль «Ты — суровый сеньор-разработчик» заставит модель отвечать лаконично и критично, в то время как «Ты — дружелюбный репетитор» изменит и тон, и объем пояснений .
User (Пользователь): Непосредственный вопрос или задача .
Assistant (Ассистент): Предыдущие ответы самой модели, которые подаются обратно для поддержания контекста беседы .

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

Продвинутые техники: Few-Shot и Chain of Thought 34:09

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

Few-Shot Prompting (Промптинг с примерами) — это включение в запрос одного или нескольких примеров «входные данные — идеальный ответ» . Если просто попросить модель классифицировать отзыв (Zero-Shot), она может написать целое эссе с объяснениями, хотя вам нужно одно слово . Добавление пары строк с примерами (например, «Еда была вкусной — Позитивный») мгновенно обучает модель нужному формату и стилю ответа без дообучения самой нейросети .

Chain of Thought (Цепочка рассуждений, CoT) — техника, заставляющая модель рассуждать вслух перед выдачей финального ответа . Вместо того чтобы сразу просить «Спланируй поездку», лучше разбить задачу на шаги: «Шаг 1 — проверь календарь, Шаг 2 — найди билеты в рамках бюджета...» . Каждый написанный моделью шаг становится частью контекста для следующего шага, что значительно снижает вероятность логических ошибок . Это особенно важно для агентов, где один неверный шаг в рассуждениях может привести к выполнению деструктивного действия через внешний инструмент.

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

🛠 От кода к интеллекту: первый API-вызов и стратегия выбора инструмента 50:16

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

Программное взаимодействие: ваш первый API-вызов на Python 56:02

Переход к разработке на базе LLM начинается с настройки окружения и выполнения первого вызова через SDK. В примере используется Python 3.11 и библиотека OpenAI . Процесс инициализации ассистента в коде требует создания клиента с использованием API-ключа и базового URL, которые рекомендуется хранить в переменных окружения для безопасности .

Ключевое отличие программного взаимодействия от обычного чата — полный контроль над историей сообщений. Модели по своей природе «беспамятны» (stateless) . Чтобы бот помнил, что вы обсуждали Париж в предыдущей реплике, разработчик должен каждый раз отправлять в API полный список сообщений . В этом списке выделяются три основные роли:

System (Системная роль): устанавливает правила поведения и контекст для модели .
User (Пользователь): передаёт текущий запрос или вводные данные .
Assistant (Ассистент): хранит предыдущие ответы модели, позволяя ей поддерживать нить диалога .

В коде это выглядит как список словарей, который пополняется с каждым новым ходом диалога . В лабораторной работе agent_loop.py демонстрируется простейший цикл: программа отправляет запрос через client.chat.completions.create, извлекает ответ и параметр finish_reason, который сообщает, завершила ли модель свою мысль или ей требуется выполнить дополнительное действие . Если finish_reason равен stop, программа выводит ответ и завершает цикл . Это фундамент любого AI-приложения — от простого чат-бота до сложного агента.

Код vs LLM: когда стоит усложнять систему 1:04:22

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

Детерминированный код (обычное программирование) идеально подходит для задач с предсказуемым результатом. Если вы можете нарисовать блок-схему всех возможных путей выполнения задачи — вам не нужен агент, вам нужен обычный программный сценарий или workflow .

LLM же вступают в игру там, где требуется «суждение» (judgment) и понимание естественного языка . Основные критерии выбора между кодом и LLM:

Предсказуемость: Если шаги всегда одинаковы (например, извлечение данных или перевод по шаблону), используйте жестко заданный код (workflow) .
Гибкость: Если путь решения зависит от того, что модель обнаружит в процессе (например, поиск рейса, когда нужная дата занята), системе требуется гибкость агента .
Стоимость и контроль: Обычный код дешевле и работает быстрее. За каждый вызов LLM вы платите токенами и временем ожидания генерации .

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

Стратегия выбора: чек-лист разработчика 1:06:44

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

Можно ли заранее определить все пути решения? Если да — выбирайте workflow на чистом коде .
Нужно ли модели принимать самостоятельные решения о следующем шаге? Если да — это задача для агента .
Является ли задача повторяемой и четко определенной? Для таких задач лучше подходит структурированный код .
Насколько важен строгий контроль затрат? Если бюджет ограничен, стоит минимизировать количество вызовов LLM и использовать их только там, где код бессилен .

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

🛠️ Глава 4. Инструменты и архитектурная свобода: от простых чат-ботов к автономным агентам 1:15:33

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

Роль инструментов: «руки» ИИ-агента 1:16:38

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

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

Если дать Zippy доступ к календарю и почте, он станет персональным ассистентом .
Добавление инструментов поиска авиабилетов и бронирования отелей превращает его в тревел-агента .
В продвинутых кейсах, таких как OpenClaw, агенту доступны выполнение bash-скриптов, полноценный веб-браузинг и взаимодействие с мессенджерами .

Важно различать определение инструмента (то, что читает модель, чтобы понять, зачем нужна эта функция) и обработчик (handler) — реальный Python-код, который выполняется на стороне сервера . Чтобы агент работал эффективно, в системном промпте ему дают четкую инструкцию: «Используй инструменты, когда тебе нужны реальные данные», что заставляет модель не гадать, а обращаться к проверенным источникам . Ранее в курсе уже упоминалось, что выбор между написанием чистого кода и использованием LLM зависит от сложности задачи, и инструменты — это как раз тот мостик, который позволяет объединить детерминированную логику кода с гибкостью нейросети.

Workflows vs Agents: архитектурный выбор 1:17:28

Одним из самых удивительных открытий для начинающих разработчиков становится то, насколько прост код оркестрации агента . В отличие от жестко заданных рабочих процессов (Workflows), где каждый шаг прописан программистом заранее, агентная архитектура строится на динамическом цикле «восприятие — рассуждение — действие» (perceive, reason, act) .

Ключевые отличия агентного подхода от классического Workflow:

Простота оркестрации: Весь процесс часто управляется обычным циклом while True . Код лишь отправляет историю диалога модели и, если та решает вызвать инструмент, выполняет его и возвращает результат обратно в чат .
Источник интеллекта: Вся адаптивность и сложность поведения исходят из рассуждений LLM, а не из нагромождения условий if-else в коде .
Динамический путь: Модель сама решает, какой инструмент использовать следующим, основываясь на текущем состоянии контекста . Если один инструмент не дал результата, агент может попробовать другой или изменить запрос .
Устойчивость к изменениям: Агентная архитектура менее хрупкая; она способна восстанавливаться после ошибок и адаптироваться к новым вводным в реальном времени, что сложно реализовать в жестком Workflow .

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

Практическая реализация: связка компонентов в коде 1:19:11

Для создания работающего агента необходимо объединить пять базовых элементов (модель, инструменты, память, промпт и цикл оркестрации), о которых подробнее будет рассказано в следующей главе . На практике это реализуется через Python-скрипт и SDK (например, OpenAI) .

Процесс взаимодействия выглядит следующим образом:

Инициализация: Создается список сообщений, начинающийся с системного промпта, задающего личность агента .
Определение инструментов: Создается список tools, где описываются функции, их параметры и назначение (например, check_cal для проверки встреч) .
Цикл обработки: В бесконечном цикле приложение вызывает API модели . Если модель возвращает finish_reason: stop, цикл прерывается и пользователю выдается ответ .
Вызов функций: Если модель возвращает finish_reason: tool_calls, код извлекает имя функции и аргументы, запускает локальный обработчик и добавляет результат в историю в виде специального сообщения tool_message .

Такая структура позволяет агенту отвечать на сложные вопросы, требующие данных, которых нет в его обучающей выборке, например: «Что у меня в календаре на сегодня?» . Модель понимает, что не знает ответа, вызывает check_cal, получает данные о стендапе в 10:00 и приеме у стоматолога в 14:00, и только после этого формулирует финальный ответ . Этот простой пример иллюстрирует фундаментальный сдвиг в разработке: мы больше не программируем каждый шаг, мы создаем среду, в которой ИИ может действовать самостоятельно.

🧩 Анатомия агента: пять базовых компонентов и логика ReAct 1:40:43

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

Пять столпов архитектуры агента 1:48:07

Любой агент — это, по сути, «дополненная LLM» (Augmented LLM) . Эта концепция подразумевает, что базовая модель получает три ключевые «суперсилы»: извлечение информации (Retrieval), инструменты (Tools) и память (Memory) . Однако для полноценной работы к этому списку добавляются ещё два критических элемента: оркестратор и системный промпт.

Модель (Model): Это «мозг» системы . Она отвечает за интерпретацию запросов, принятие решений и генерацию текста. Как отмечают авторы, можно использовать разные модели (Claude, GPT, Gemini), переключаясь между ними в случае сбоев .
Инструменты (Tools): Это «руки» агента. С их помощью он выходит за пределы текстового окна . Инструменты позволяют выполнять Python-скрипты, запрашивать базы данных или обращаться к внешним API . Важно, что в производственных системах чаще используется «вызов функций» (Function calling), когда модель лишь сообщает, какой инструмент ей нужен, а само выполнение ложится на приложение .
Память (Memory): Способность хранить контекст между взаимодействиями . Это позволяет агенту помнить предпочтения пользователя или результаты предыдущих шагов, что ранее в курсе обсуждалось как краткосрочное хранилище.
Оркестратор (Orchestrator): Это «клей», который соединяет модель, инструменты и память . Google определяет это как явный слой оркестрации, который управляет циклом: принимает ввод, решает, вызвать ли инструмент, обрабатывает результат и формирует финальный ответ .
Системный промпт (System Prompt): Инструкция, задающая персону и правила поведения . Именно системное сообщение определяет, будет ли агент действовать как строгий аналитик данных или как дружелюбный ассистент, прежде чем пользователь введет первое слово .

Планирование и паттерн ReAct: от мыслей к действиям 1:40:43

Разница между простым чат-ботом и агентом заключается в способности последнего к планированию. Основной паттерн, обеспечивающий это, называется ReAct (Reason + Act). В видео упоминается, что даже сложные агенты, такие как Cody, используют «базовый цикл ReAct» (core ReAct loop) практически без изменений .

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

Рассуждение (Reason): Модель анализирует задачу и пишет «план» своих действий.
Действие (Act): На основе плана модель выбирает нужный инструмент и выполняет шаг .

Этот подход критически важен при переходе от «мира текста» к «миру действий» . Если обычные текстовые агенты просто отвечают на вопросы, то такие специалисты, как Cody, используют инструменты с «побочными эффектами», например, запись файла на диск или изменение данных в БД . Ошибка в планировании здесь может привести к удалению нужных данных или бесконечным циклам .

Паттерн ReAct позволяет минимизировать галлюцинации за счёт «заземления» (grounding) — подключения ответов агента к проверяемым источникам данных . Прежде чем ответить, агент планирует поиск в базе данных или вебе, основывая свои выводы на фактах, а не только на весах модели . Оркестратор следит за тем, чтобы этот цикл планирования и действия не стал бесконечным: для этого устанавливаются жесткие лимиты на количество итераций (Max Iterations), чтобы агент не тратил бюджет впустую, пытаясь выполнить невыполнимое .

Ранее в разговоре они касались того, как инструменты расширяют возможности LLM, но именно связка «компоненты + ReAct» превращает набор функций в автономную систему, способную решать многошаговые задачи без вмешательства человека .

🧠 Архитектура памяти и магия мультиагентной оркестрации 2:05:40

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

Краткосрочная vs Долгосрочная память: от списков сообщений к базам данных 2:05:54

Краткосрочная память агента реализуется через накопление списка сообщений (messages list), который передается API при каждом новом вызове . Это позволяет модели видеть всю историю текущей сессии, не требуя от пользователя повторения контекста . Однако такая память ограничена контекстным окном модели. Если история становится слишком длинной, OpenClaw применяет механизм «сжатия контекста» (context compaction) . Вместо того чтобы просто удалять старые сообщения, система суммирует их и сокращает избыточные выводы инструментов, заменяя оригиналы сжатыми версиями, что освобождает токены для новых рассуждений .

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

В реальных системах, таких как OpenClaw, работа с памятью организована следующим образом:

Менеджер памяти: Центральный файл manager.ts отвечает за чтение, запись и поиск информации .
Векторный поиск: Система использует Search manager.ts для поиска воспоминаний по смыслу, а не по точному совпадению текста .
Хранилище: В то время как в учебных примерах данные сохраняются в JSON-файлы , продакшн-решения используют SQLite и векторные эмбеддинги для эффективного извлечения данных .
Инъекция в промпт: При запуске агента сохраненные предпочтения (например, «я вегетарианец») загружаются из базы и автоматически добавляются в системный промпт . Таким образом, модель «узнаёт» пользователя с первых секунд диалога .

Мультиагентные системы: оркестраторы, специалисты и разделение слоёв 2:16:52

Сложные агенты редко представляют собой один монолитный кусок кода. OpenClaw построен на базе четырех пакетов, созданных Марио Зехнером, которые формируют иерархию ответственности . На нижнем уровне находится пакет Pi AI, который занимается «черновой» работой: выполняет HTTP-запросы к LLM и стримит токены . Он не знает о целях пользователя, его задача — обеспечить связь с моделью .

Над ним стоит PI agent core, который определяет «общий язык» системы — типы данных и интерфейсы . Более 50 инструментов OpenClaw (поиск в вебе, bash, Slack) реализуют один и тот же интерфейс agent_tool, что позволяет агенту работать с ними единообразно .

Ключевую роль в оркестрации играет PI coding agent. Он управляет сессией, циклом вызова инструментов и сохранением истории . Это «двигатель» агента, который крутит цикл «восприятие — рассуждение — действие» до тех пор, пока задача не будет решена . Сама оболочка OpenClaw находится на вершине этой пирамиды, добавляя каналы связи (WhatsApp, Telegram) и специфическую логику безопасности .

Интересной особенностью является возможность «мультиагентного спавнинга» (multi-agent spawning) для специализированных задач . Когда агент сталкивается со сложной проблемой, он может инициировать отдельную под-сессию с узкоспециализированным набором инструментов, работая в режиме менеджера, который делегирует выполнение задачи эксперту .

Пять фаз агентного цикла и роль персистентности 2:23:28

Жизненный цикл каждого запроса в OpenClaw проходит через пять строго определенных фаз, что гарантирует надежность системы :

Настройка (Setup): Загрузка истории сессии из JSONL-файла и сборка системного промпта на основе текущих навыков агента . Ранее в курсе обсуждались основы промптов, но здесь они собираются динамически из 19 различных секций .
Валидация окна контекста: Проверка доступного места. Если лимит близок, запускается упомянутое выше сжатие .
Цикл попыток (Attempt Loop): Ядро работы, где модель выдает команды на вызов инструментов, а агент исполняет их в песочнице и возвращает результат .
Обработка ошибок: Если один провайдер (например, Claude) недоступен, система автоматически переключается на Gemini или локальную модель . Ошибки API приводят к ротации ключей, а не к падению программы .
Персистентность (Persistence): Финальный этап, где агент блокирует файл сессии (write lock), чтобы предотвратить повреждение данных при одновременных запросах, и сохраняет обновленную историю .

Использование формата JSONL (одна строка — один объект) позволяет разработчикам легко отлаживать агента, просто читая файл истории в текстовом редакторе без специальных инструментов . Это превращает «черный ящик» ИИ в прозрачную последовательность логов, где виден каждый шаг рассуждения и каждый вызов функции .

🤖 Надежность и безопасность: подготовка агента к продакшену 2:30:57

Стратегии тестирования и обработки ошибок 2:31:10

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

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

Для комплексной проверки агента рекомендуется использовать трехуровневую пирамиду тестов:

Unit-тесты инструментов: проверка функций инструментов в изоляции без участия LLM, что позволяет отловить баги интеграции мгновенно и бесплатно .
Mocks (заглушки): замена реальных API-вызовов заранее подготовленными данными. Это позволяет протестировать логику рассуждений агента, не тратя токены и не страдая от задержек сети .
Evaluation-тесты (Evals): использование более мощной модели (например, GPT-4) в качестве судьи, который оценивает качество ответа агента по шкале от 1 до 5 .

Обсервабильность: отладка и мониторинг в реальном времени 2:39:44

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

Для поддержания производительности в продакшене необходимо отслеживать шесть ключевых метрик :

Токены на запрос: сигнал о стоимости и эффективности .
Количество вызовов инструментов: если агент делает 6 вызовов там, где достаточно одного, система неэффективна .
Latency (задержка): разделение времени на работу LLM и выполнение инструментов помогает найти узкие места .
Процент ошибок: допустимый уровень отказов API обычно не превышает 1% .
Количество итераций цикла: если агент проходит более 5-6 циклов, он, скорее всего, «зациклился» и не может достичь прогресса .
Использование контекстного окна: при достижении 80% лимита необходимо применять сжатие или суммаризацию прошлых ходов .

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

Безопасность: Guardrails и Human-in-the-Loop 2:51:44

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

Первый эшелон защиты — это изоляция. Инструменты выполнения кода должны работать в песочнице (sandbox) с ограниченным доступом к файловой системе и без прямого доступа к сети хоста . Принцип наименьших привилегий (Least Privilege) диктует, что агенту нужно давать только те инструменты, которые необходимы для конкретной задачи . Важно проводить валидацию аргументов инструментов не на уровне промпта (который можно обойти инъекцией), а на уровне жесткого программного кода .

Для управления критическими рисками используется паттерн Human-in-the-Loop (человек в цикле). Для таких действий, как удаление данных, проведение финансовых транзакций или отправка электронных писем, агент может составить план, но выполнение произойдет только после явного подтверждения человеком . Дополнительно внедряется фильтрация вывода (Output Filtering), которая проверяет ответы агента на наличие паттернов, похожих на API-ключи, пароли или персональные данные, прежде чем они попадут к пользователю . Эти многослойные меры защиты позволяют создавать агентов, которые приносят пользу, оставаясь в рамках заданных границ безопасности .

🛠️ Архитектура OpenClaw и научный подход к промпт-инжинирингу 2:55:57

Безопасность и архитектура: модель OpenClaw 2:55:57

При проектировании надежного агента, такого как OpenClaw, ключевым принципом становится «эшелонированная оборона» (defense in depth) . Каждый уровень системы безопасности предназначен для перехвата определенного типа сбоев, гарантируя, что если один уровень не сработает, следующий подстрахует систему . В архитектуру OpenClaw встроены несколько критических модулей: исполнение кода в изолированной «песочнице» (sandbox), строгие политики использования инструментов и система разрешений для выполнения чувствительных операций .

Важной частью архитектуры является управление профилями и изоляция сессий. Чтобы избежать перекрестного загрязнения данных (cross-contamination), OpenClaw использует ротацию ключей и строгую изоляцию контекста между различными каналами общения . Основной принцип прост: система никогда не доверяет входящим данным, будь то ввод от пользователя, ответы инструментов или внешние источники данных . Любой ввод рассматривается как потенциально враждебный, валидируется на каждой границе системы и выполняется в максимально ограниченной среде, которая всё же позволяет агенту выполнять его работу . Ранее в разговоре упоминались базовые компоненты агента, но именно такая «параноидальная» архитектура превращает экспериментальный скрипт в промышленное решение.

Промпт-инжиниринг как программная инженерия 2:56:50

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

Одной из самых глубоких техник является назначение персоны (Persona Assignment). Это не просто тон общения. Исследование 2025 года с использованием метода «патчинга активаций» (activation patching) подтвердило, что эффект персоны концентрируется в ранних (1–3) и средних слоях внимания (9–11) модели . Ученые смогли извлечь вектор роли из внутренних слоев модели и внедрить его напрямую во время инференса без текстового описания персоны, получив тот же результат . Однако стоит быть осторожным: исследование 12 наборов данных для рассуждений в 2024 году показало, что назначение персоны («Ты — математик») может ухудшить точность в арифметических задачах, так как модель начинает подмешивать статистические паттерны поведения людей-математиков вместо выполнения прямых вычислений . OpenClaw использует многослойные персоны: базовая роль ассистента дополняется специализированными навыками, а расширение Open Pros VM даже переопределяет идентичность модели на низком уровне для максимизации эффекта .

Механика внимания и структурные паттерны 3:00:26

Позиция информации в промпте не нейтральна. Исследователи из Стэнфорда в 2024 году задокументировали U-образный паттерн внимания (Lost in the Middle): точность модели падает с 75% до 45%, если релевантная информация находится в середине длинного контекста . Поэтому практическое правило OpenClaw гласит: критические инструкции — в начало, конкретный вопрос — в самый конец, а документы и контекст — в середину . Системный промпт OpenClaw представляет собой последовательность из 19 условных секций, где runtime-информация всегда идет последней .

Другие важные техники, интегрированные в архитектуру OpenClaw:

Позитивные инструкции вместо негативных: Исследования ACL 2023 года показали, что модели сложнее подавлять концепт (например, «не используй буллиты»), чем следовать прямому указанию («пиши только параграфами») . Подавление — это вторичная, менее подкрепленная операция в весах модели .
Цепочка рассуждений через структуру (CoT by Structure): Вместо простой просьбы «думай пошагово», OpenClaw принудительно использует теги <think> и <final> . Это заставляет модель генерировать токены рассуждения до того, как будет дан финальный ответ, что критически важно для предотвращения рационализации ошибок постфактум .
Эмоциональное обрамление: Исследование Microsoft Research 2023 года показало, что фразы вроде «Это очень важно для моей карьеры» или «Я дам тебе чаевые в $200» улучшают производительность в среднем на 8%, а в сложных задачах генерации — до 115% . Модели усвоили из обучающих данных паттерн: когда ставки высоки, люди пишут более тщательно, и LLM зеркалит это поведение .

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