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

Источник: https://www.youtube.com/watch?v=AZDSpS5v57w
Канал: freeCodeCamp.org
Опубликовано: 07.07.2026

---

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

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

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

### Архитектура Transformer и искусство внимания
[[JUMP:04:36]]

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

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

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

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

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

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

Процесс настройки этих параметров можно сравнить с обучением броску баскетбольного мяча [11:21]. Игрок не высчитывает угол и силу броска сознательно; после тысяч попыток его тело «запоминает» нужные настройки мышц [12:23]. Аналогично, LLM миллиарды раз сравнивает свои предсказания с реальным текстом, и алгоритм слегка корректирует каждый параметр, пока модель не начнет имитировать человеческую речь с высокой точностью [17:15]. Несмотря на огромную мощь, у «голых» LLM есть слепые зоны: они плохо справляются с математическими вычислениями и не знают событий, произошедших после даты их обучения [14:11]. Чтобы преодолеть эти ограничения и превратить модель в полноценного агента, разработчики используют API [15:31] и предоставляют моделям инструменты для действий в реальном мире [15:16].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.  **System (Системная роль):** Это невидимая для конечного пользователя инструкция от разработчика [32:34]. Здесь задаются правила поведения, личность (persona) и ограничения модели [32:49]. Например, роль «Ты — суровый сеньор-разработчик» заставит модель отвечать лаконично и критично, в то время как «Ты — дружелюбный репетитор» изменит и тон, и объем пояснений [35:45].
2.  **User (Пользователь):** Непосредственный вопрос или задача [32:55].
3.  **Assistant (Ассистент):** Предыдущие ответы самой модели, которые подаются обратно для поддержания контекста беседы [32:22].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.  **Предсказуемость:** Если шаги всегда одинаковы (например, извлечение данных или перевод по шаблону), используйте жестко заданный код (workflow) [1:05:26].
2.  **Гибкость:** Если путь решения зависит от того, что модель обнаружит в процессе (например, поиск рейса, когда нужная дата занята), системе требуется гибкость агента [1:10:54].
3.  **Стоимость и контроль:** Обычный код дешевле и работает быстрее. За каждый вызов LLM вы платите токенами и временем ожидания генерации [1:07:52].

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

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

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

1.  **Можно ли заранее определить все пути решения?** Если да — выбирайте workflow на чистом коде [1:06:44].
2.  **Нужно ли модели принимать самостоятельные решения о следующем шаге?** Если да — это задача для агента [1:06:58].
3.  **Является ли задача повторяемой и четко определенной?** Для таких задач лучше подходит структурированный код [1:06:58].
4.  **Насколько важен строгий контроль затрат?** Если бюджет ограничен, стоит минимизировать количество вызовов LLM и использовать их только там, где код бессилен [1:07:12].

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

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

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

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

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

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

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

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

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

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

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

1.  **Простота оркестрации:** Весь процесс часто управляется обычным циклом `while True` [1:17:53]. Код лишь отправляет историю диалога модели и, если та решает вызвать инструмент, выполняет его и возвращает результат обратно в чат [1:17:53].
2.  **Источник интеллекта:** Вся адаптивность и сложность поведения исходят из рассуждений LLM, а не из нагромождения условий `if-else` в коде [1:18:06]. 
3.  **Динамический путь:** Модель сама решает, какой инструмент использовать следующим, основываясь на текущем состоянии контекста [1:16:12]. Если один инструмент не дал результата, агент может попробовать другой или изменить запрос [1:18:06].
4.  **Устойчивость к изменениям:** Агентная архитектура менее хрупкая; она способна восстанавливаться после ошибок и адаптироваться к новым вводным в реальном времени, что сложно реализовать в жестком Workflow [1:25:13].

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

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

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

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

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

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

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

[[JUMP:1:40:43]]

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

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

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

1.  **Модель (Model):** Это «мозг» системы [1:53:18]. Она отвечает за интерпретацию запросов, принятие решений и генерацию текста. Как отмечают авторы, можно использовать разные модели (Claude, GPT, Gemini), переключаясь между ними в случае сбоев [1:51:10].
2.  **Инструменты (Tools):** Это «руки» агента. С их помощью он выходит за пределы текстового окна [1:41:49]. Инструменты позволяют выполнять Python-скрипты, запрашивать базы данных или обращаться к внешним API [1:42:01]. Важно, что в производственных системах чаще используется «вызов функций» (Function calling), когда модель лишь сообщает, какой инструмент ей нужен, а само выполнение ложится на приложение [1:53:30].
3.  **Память (Memory):** Способность хранить контекст между взаимодействиями [1:53:18]. Это позволяет агенту помнить предпочтения пользователя или результаты предыдущих шагов, что ранее в курсе обсуждалось как краткосрочное хранилище.
4.  **Оркестратор (Orchestrator):** Это «клей», который соединяет модель, инструменты и память [1:54:40]. Google определяет это как явный слой оркестрации, который управляет циклом: принимает ввод, решает, вызвать ли инструмент, обрабатывает результат и формирует финальный ответ [1:54:26].
5.  **Системный промпт (System Prompt):** Инструкция, задающая персону и правила поведения [2:05:28]. Именно системное сообщение определяет, будет ли агент действовать как строгий аналитик данных или как дружелюбный ассистент, прежде чем пользователь введет первое слово [2:05:40].

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

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

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

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

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

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

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

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

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

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

Краткосрочная память агента реализуется через накопление списка сообщений (`messages list`), который передается API при каждом новом вызове [2:05:54]. Это позволяет модели видеть всю историю текущей сессии, не требуя от пользователя повторения контекста [2:06:07]. Однако такая память ограничена контекстным окном модели. Если история становится слишком длинной, OpenClaw применяет механизм «сжатия контекста» (context compaction) [2:26:23]. Вместо того чтобы просто удалять старые сообщения, система суммирует их и сокращает избыточные выводы инструментов, заменяя оригиналы сжатыми версиями, что освобождает токены для новых рассуждений [2:26:36].

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

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

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

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

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

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

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

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

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

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

1.  **Настройка (Setup):** Загрузка истории сессии из JSONL-файла и сборка системного промпта на основе текущих навыков агента [2:23:56]. Ранее в курсе обсуждались основы промптов, но здесь они собираются динамически из 19 различных секций [2:19:29].
2.  **Валидация окна контекста:** Проверка доступного места. Если лимит близок, запускается упомянутое выше сжатие [2:24:10].
3.  **Цикл попыток (Attempt Loop):** Ядро работы, где модель выдает команды на вызов инструментов, а агент исполняет их в песочнице и возвращает результат [2:24:37].
4.  **Обработка ошибок:** Если один провайдер (например, Claude) недоступен, система автоматически переключается на Gemini или локальную модель [2:13:34]. Ошибки API приводят к ротации ключей, а не к падению программы [2:25:16].
5.  **Персистентность (Persistence):** Финальный этап, где агент блокирует файл сессии (write lock), чтобы предотвратить повреждение данных при одновременных запросах, и сохраняет обновленную историю [2:25:58].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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