Анатомия AI-агента для сеньоров — pipeline, цикл, tools, ловушки

50 долларов столько стоил один EA-агент на этапе прототипа. А потом его вывели в продакшн и получили счет 2,5 миллиона долларов в месяц. Это описано в отраслевом анализе масштабирования агента. Команда, имя которой не раскрыто, обнаружила это при переходе девелопмента на продакшн-нагрузку. Каждую неделю выходит новый фреймворк для EA-агента. LongChain, CREI, AutoGen, OpenEAgent SDK, Google ADK и многие другие. И каждый обещает одно и то же. Построй агента за 5 минут. Знаете что? Они не врут. Построить действительно можно за 5 минут. Три строчки на Cue.ai и агент отвечает, вызывает инструменты, выглядит умным. А потом ты выводишь его в продакшн и начинается. Компания Атакана. На девелопменте красота, магия, продакшн. Агент игнорирует команды на остановку, дает одни и те же ответы 58 раз подряд. Не 2, не 5, 58. Или вот свежая, март 25 года. Основатель Datatalk Club, платформа, на которой учатся более 100 тысяч студентов, попросил CloudCode навести порядок в Terraform ресурсах. Агент распаковал старый архив с production конфигами и выполнил Terraform Destroy. Одна команда и вся production инфраструктура, база данных, VPC, ECS-кластер, балансировщики, все исчезло. Почти 2 миллиона строк студенческих работ за 2,5 года. Все восстановили через сутки, нашли скрытый снапшот. Но основатель сам написал в PostMortem'е «Я чрезмерно полагался на я агента для выполнения Terraform Command». И это не единичная история. Гартнер в июле 2025 предсказал, более 40% агентских проектов будут закрыты к 2027 году. Неконтролируемые расходы, непонятная бизнес-ценность, недостаточный контроль и риск. Но послушайте, модели-то прекрасные. GPT, Cloud, Gemini, они все работают отлично. Проблема не в моделях, проблема в инженерии. Anthropic еще в 2024 году написали ключевую вещь. Самые успешные реализации не использовали сложные фреймворки или специализированные библиотеки. Вместо этого они строились на простых компонуемых паттернах. Простые компонуемые паттерны. Не выбери правильный фреймворк, а пойми из чего агент состоит. К этому же выводу пришел Dex из HumanWare. Поговорил с сотней фаундеров и создал методологию 12 факторов агентов. Большинство успешных AI-продуктов production. Это не магические автономные циклы, а хорошо написанный софт, в который LLM вызовы встроены точно. Именно этим мы сегодня и займемся. Эта серия видео не про фреймворки, она про то, что внутри любого фреймворка. Когда вы поймете анатомию, вам будет неважно, лангчейн это, или это просто Python или Go. Вы будете видеть компоненты. И у нас будет три части. Сегодня мы разберем анатомию. Скроем агента и посмотрим, из каких деталей он может быть собран. Во второй части мы разберем интеллект. Какие типы памяти бывают, как что где хранить и как что когда нам надо вызывать. И в третьей части мы разберем продакшн. Здесь же все то что нам надо для того чтобы построить настоящего продакшн агента. И чтобы было конкретно о несферическом вакууме у нас будет сквозной пример. Агент Борис. Это будет проактивный и я и консьерж нашей команды. Он читает календарь, чувствует настроение по свеку, помнит предпочтение через рак. и учитывают погоду. Звучит как игрушка, но замените кофе на диплоймент, получите девопс-агент. На саппорт тикет и это будет кастомер саппорт агент. На код ревью и это будет кодинг ассистем. Архитектура та же, компоненты те же, подводные камни те же. К концу серии у нас будет полная ментальная модель. Не для одного агента, а для любого. Поехали! Прежде чем рисовать квадратики и стрелочки, давайте ответим на вопрос, который многие пропускают. А вам вообще нужен агент? Ну я серьезно. Вот приходит менеджер и говорит. Нам нужен ИИ агент! И ты спрашиваешь, для чего он? Ну, для автоматизации. Ты, автоматизации чего? Он? Ну, процессов. Может быть, кому-то эта картина знакома? Anthropic, OpenAI, Google, все три независимо друг от друга в своих гайдах проводят одну и ту же фундаментальную линию. Два типа систем. Workflow. LLM работает через заранее определенные пути в коде. Вы разработчик, и вы решаете. Шаг 1, потом шаг 2, потом шаг 3. LLM выполняет каждый шаг, но не выбирает, какой следующий. Вы — это рельсы, а LLM — это поезд. Agent — это LLM сам решает, что делать дальше. Сам выбирает инструменты, сам определяет последовательность. Вы задаете ему только начальный пункт и какую цель ему надо достичь. Он уже сам строит маршрут. Чувствуете разницу? Так вот, Workflow — это больше контроля. Агенты — это больше автономии. И между ними — спектр. И Anthropic прямо рекомендует. Найдите самое простое решение, увеличивайте сложность, только когда это необходимо. По моим наблюдениям и по мнению многих практик в индустрии, подавляющее большинство реальных задач решаются через workflow-паттерны. Не агентами, а в workflow. Почему? Потому что каждый шаг от workflow к агенту — это несколько вещей. Больше денег, больше ошибок и больше непредсказуемости. И каждый шаг автономии — это решение о доверии. Вы буквально доверяете языковой модели принимать решение. А она не всегда принимает правильные решения, как мы знаем из примеров из начала ролика. Давайте пройдем по этой лестнице сверху вниз, и я покажу не просто, что бывает, а почему вы переходите на следующую ступень. Какое ограничение предыдущей вас туда толкает? Ступень первая. Самая простая. Один вызов LLM. Пользователь спрашивает, модель отвечает. С подключенным рак, с инструментами, но один вызов. Какие встречи у команды сегодня? И наш барист дергает календарь API, получает список и отвечает. Готово. Один вход, один выход. И для огромного количества задач этого достаточно. И вот ключевое. Если вам хватает одного вызова, остановитесь здесь, не усложняйте. Но что, если этого вызова нам не хватает? Допустим, наш барист должен не просто показать встречи, а собрать контекст, определить потребности команды, сформировать заказ и подтвердить его у человека. Это получается уже 4 шага, и каждый из этих шагов зависит от предыдущего. Один вызов здесь никак не справится, и нам нужна с вами цепочка. Вторая ступень промчения, последовательность шагов, где выход предыдущего шага становится ходом следующего. Это как конвейер на заводе, деталь проходит от станка к станку и движется по циклу своего производства. И каждый станок делает свою операцию. На примере нашего бариста шаг номер один. Он должен собрать контекст из календаря. и возможно из слэка. И на основе полученных данных в шаге 1 мы переходим к шагу 2 и пытаемся там определить, что команде нужно. После того, как мы определились, что сейчас нужно для нашей команды, нам надо сформировать заказ. Ну и последний шаг. После того, как все это готово, мы должны получить подтверждение у человека. То есть на этом шаге мы встраиваем у человека цикл принятия решения. И он подтверждает, да, работаем или нет. И можно услышать такой термин, как Human in the Loop. это значит человек здесь принимает решение также есть другой термин human on the loop это когда человек наблюдает за тем что делает агент чаще всего вы именно так и вайп кодите когда смотрите какие у вас открываются функции что где меняется и последний это human out of the loop это значит что уже система будет полностью автономной так вот здесь мы решили что мы встроим human in the loop человек будет принимать решение о том что делаем заказ или не делаем так вот у нас есть с вами четыре шага и каждый определен вами в коде он выполняет каждый шаг но не решает какой следующий это решаете вы вот почему это workflow а не агент customer support будет практически та же схема сначала мы с вами будем классифицировать запрос потом мы будем искать по базе знаний потом мы напишем черновик ответ проверим качество ответ и уже только после этого дадим этот ответ Но это работает только когда цепочка полностью предсказуемая и предопределена. Мы можем использовать такой подход. Но вот проблема. А что если на вход приходит принципиально разный запрос? Хочу вата или у меня аллергия на орехи? Это разные задачи. И гнать через один конвейер неэффективно. И здесь к нам приходит следующий подход. И здесь нам с вами поможет роутинг. Это классификатор на входе, который направляет запрос по нужному пути. Это может быть маленькая, очень быстрая модель. который за миллисекунды определит тип запроса и маршрутизует его к нужной цепочке. На примере нашего бариста «Хочу ватта» и цепочка у нас пойдет через оформление заката. А если мы скажем «У меня аллергия на орехи», то мы будем должны обновить информацию об этом пользователе и потом запустить цепочку, возможно, с какими-то диетическими ограничениями. И это будут две разные цепочки, но маршрутизатор будет один. Или, как пример, чат-бот банка. хочу закрыть счет. И это не просто информационный запрос, это у нас уже будет серьезная операция. И наша маленькая модель может решить, куда его отправить. А уже большая потом, что именно с ним делать. И здесь принцип очень простой. Маленькая модель классифицирует, а уже специализированные цепочки обрабатывает. Итак, теперь у нас маршрутизация решает проблему разных типов запросов. Но что если внутри одного запроса есть несколько независимых подзадач? Это как наш барист, который должен одновременно проверить календарь, прочитать слэк, запросить рак и посмотреть погоду. Зачем ему делать это последовательно, если задачи не зависят друг от друга? И здесь нам помогает параллелизейшн. Или мы будем выполнять все независимо друг от друга. Идея запустить независимые задачи одновременно, наш барист, это как раз таки календарь, слэк, рак, погода, это 4 API параллельно. Зачем нам ждать несколько секунд последовательно, если можно сделать все это за одну? Или, допустим, у нас будет какой-то HR-агент, и при онбординге он параллельно проверяет доступы, генерирует welcome письмо, бронирует рабочее место и заказывает оборудование. Четыре задачи, ни одна не зависит от другой, запускаем их одновременно. И это будет все еще наш workflow, потому что мы решили, какие задачи в караллеле. LLM не принимает это решение. Но давайте будем осложнять. А что, если эту задачу нельзя разбить заранее? И клиент нам пишет. Меня затопили соседи. И здесь нам уже надо будет динамически определять, какие подзадачи нам будут нужны для решения этой проблемы. И это будет подход с оркестратором и воркером. Здесь у нас появляется LLM-оркестратор, который сам декомпозирует задачу. Клиент пишет в поддержку страховой «Меня затопили соседи». И оркестратор разбивает их на подзадачи и передает уже воркерам. Воркер проверяет полис, другой находит ближайшего оценщика, третий генерирует черновик заявления, собирает результат и клиент получает готовый план действий. а не три отдельных ответа. Предположим, что наш бариста при заказе на большую команду. У нас один воркер собирает предпочти, другой проверяет бюджет, третий ищет ближайшую доставку, а оркестратор сводит это все в единый заказ. Но смотрите, здесь мы уже на границе. Лэм уже принимает решение о декомпозиции, но набор наших воркеров, он все еще предоставлен нами. И это будет гибрид. Давайте усвоить дальше. Что если задача настолько открытая, что вы не можете предопределить? Ни шаги, ни воркеров, никакой workflow здесь будет. И здесь к нам приходит на помощь React. И вот здесь в React Agency будет начинаться настоящая автономия. Наш бариста получает сообщение. Организуй кофе-брейк для ретро. Но у Марины сегодня день рождения. И агент сам решает. Проверить предпочтение Марине. Узнать, нет ли торта в меню. Посмотреть бюджет. И если этот торт не влезает в бюджет, предложить альтернативу. Никто не прописывал эту цепочку заранее. Это примерно как когда ты говоришь своему кодинг-агенту «Исправь баг!» И дальше агент сам читает код, ищет причину, вправит, тестирует. Принцип один. Вы задаете цель, агент строит план. И вот здесь вот у нас с вами появляется высокая стоимость, непредсказуемость и риски ошибок резко возрастают. Потому что каждое решение принимает LLM, а не ваш код. Ну и давайте еще немного усложним. А что будет, когда нашего одного агента не хватит? Нам с вами помогут мультиэйджент-системы. И здесь у нас с вами несколько агентов работают параллельно. Один рефакторит, другой пишет тесты, третий обновляет документацию. Звучит это все очень мощно. И мы с вами понимаем, что это намного больше вызовов модели. Это намного больше токенов, выше стоимость и latency тоже растет. А практика показывает интересную вещь. Один агент с простыми инструментами часто эффективнее сложной мультиагентской системы. Посмотрите на кодкод. Греб, баш, туду файлы в Markdown. Никаких векторных баз. И это прекрасно работает, но есть один нюанс, потому что это в домине программирования, где все инструменты дают довольно-таки точный результат. И для кода это очень хорошо работает, потому что в этом домине у нас все инструменты дают точные результаты. Для задач, где нужна координация между несколькими неопределенными источниками, тогда мультиагентский подход может быть необходим. Но по умолчанию начните с одного агента. А еще лучше стартануть с самого простого и дальше двигаться по усложнению. И поэтому, посмотрев на нашу иерархию, мы можем увидеть, что каждая ступень — это ответ на ограничение предыдущей. И каждая следующая ступень становится дороже с точки зрения разработки, сопровождения и стоимости вызова LLM. Поэтому мы с вами можем использовать одно простое правило. Начнем с самого простого паттерна и будем усложнять по мере того, как мы решаем нашу задачу. И когда именно данные, а не интуиция нам доказали, что простого нам не хватает, тогда мы переходим к более сложным системам. Ладно, допустим, мы с вами выбрали, что же дальше, что внутри всего этого кроется. Давайте заглянем под капот. Неважно какой патрон. Workflow, агент, мультиагентские системы. Под капотом каждого запроса происходит обработка через последовательность этапа. Или pipeline. Это будет упорядоченная цепочка стадий. Примворки берут на себя только кусок этого, ядро. Longchain Agent Executor это Execution Loop, CRIEI это оркестрация между агентами. Но кто валидирует вход? Кто проверяет инъекции? Кто собирает контекст из пяти источников в один промпт? Кто фильтрует ответы на выходе? И это ваша ответственность. Преймворки это часто не делают. И когда что-то сломается, ведь мы знаем, оно всегда ломается, вы будете искать проблему именно здесь, в частях пайплайна, которые вы не написали. Но прежде чем мы нырнем в части нашего пайплайна, Один компонент, который часто забывают, это системный промп. И это фундамент, на котором строится весь наш пайплайн. Не строчка текста, которую вы написали за 5 минут и забыли. Это архитектурный контракт поведения агента. По моему опыту, промп, которым вы владеете, дает силу. Промп, спрятанный за абстракцией фреймворка, он ее отнимает. Если агент дал плохой ответ, вы должны уметь открыть системный промп, увидеть точные инструкции и поправить их. Не перенастроить фреймворк. а поправить текст, который вы написали и понимаете. Поэтому версионируйте, ревьюйте и тестируйте. Относитесь к промптам как к коду, потому что это и есть код вашего агента. Для нашего баристы System Prompt на экране. Обратите внимание на структуру. У нас есть 4 секции. Первая секция – роль и границы. Не просто ты ассистент, а что делаешь и что не делаешь. Без негативных границ агент начинает помогать за пределами своего домена. отвечать на вопросы про погоду, политику, смысл жизни. Вам это все не нужно. Вторая часть – правила. И они у нас с вами пронумерованы по приоритету. И это очень важно, когда правила конфликтуют, они могут конфликтовать. Агент должен знать, что безопасность важнее бюджета, а бюджет важнее удобства. И без приоритетов ЛЛМ будет выбирать сам. И выберет он, скорее всего, не то, что вы хотели. Третья часть – это формат. Здесь мы описываем формат, который мы хотим получить. Без этого мы можем получить стену Markdown с заголовками, или невалидный JSON, или еще что-то. И четвертая часть это пример. Для нашего бариста мы сюда положим один диалог. И это будет примером прямо в нашем системном промоке. И это один из надежнейших способов задать поведение. Модель видит не абстрактные правила, а конкретный образец. Такая структура, роль, приоритеты, формат, пример. Работает не только для баристы, она универсальна. Вы можете сюда много чего добавлять, но лучше стартовать как минимум с этих четырех частей. И это, это не настройка, это ближе к архитектурам. И поэтому мы должны управлять нашими архитектурами соответственно. Это может быть гид с код-ревью, или возможно у нас есть специализированные системы управления промтом, вроде LangFuse, PromptLayer или HumanLoop, где можно версионировать, измерять эффективность, строить АБ-тесты, откатываться к предыдущей версии. Главное, Prompt под контролем с историей, изменениями и метриками. И это не текстовый файл на рабочем столе. Так вот, System Prompt это первый слой нашего с вами контекстного окна. Это фундамент. Но он не единственный. Каждый наш Stage Pipeline, который мы сейчас разберем, добавляет свои-свои информации поверх этого фундамента. Так вот, к моменту, когда контекстное окно дойдет до вызова LLM, оно у нас будет выглядеть как системный Prompt. Потом у нас с вами пойдут слой за слоем, знания, память, инструменты и в самом конце запросы пользоваться. И pipeline, о котором мы будем говорить, это конвейер, который собирает это контекстное окно. И каждый стейдж отвечает за свой слой. Давайте пройдем этот конвейер целиком. Одно небольшое точнее. То, что я вам покажу дальше, это не стандарт из учебника. Это моя синтезированная модель. Я собрал ее из гайдов Anthropic, OpenAI, Google. из реальных продакшн систем, из разбора инцидентов и построения множества агентов. Мы разберем много стейджей, у вас может быть меньше, а может быть и больше, и это нормально. Большинство проектов стартуют с 4-5 и растут по мере необходимости. Но сначала критическое различие. Пайплайн работает по-разному для workflow и для агентов. Workflow pipeline в основном линейный. Запрос входит, проходит стейджи от начала до конца. Но есть важный нюанс. Отдельные стейджи могут содержать мини-циклы. Как пример, Security проверил ответ, нашел PII и вернул обратно модели на переформулировку. Или Post-Processing распарсил JSON и он оказался невалидным. Retry. И это будет все еще workflow. Вы, разработчики, определили, когда и куда возвращаться. Путь предопределен. И отличие от агента в том, что решение о возврате принимает ваш код, а не LLM. А агент pipeline содержит цикл. LLM решает, нужен ли Tool Call. Если да, то вызов инструмента результат возвращается. И часть пайплайна проходится снова. И это будет у нас Agent Loop. Мы разберем его отдельно, но структура stages общая. Логика нашего пайплайна может быть объединена одной фразой. Блокируй рано, трать поздно. Дешевые проверки первыми, а дорогой ЛВМ вызов последним. Давайте проведем один реальный запрос через весь пайплайн, чтобы вы увидели, зачем нужен каждый стейдж. Пользователь пишет, Борис, хочу кофе. Итак, с чего же нам с вами начать? И начнем мы с вами с валидации. И здесь мы с вами будем экономить деньги. Мы проверяем, входные данные корректно, не пустая ли это строка, не бинарный ли это мусор, а может быть это неподдерживаемый нами язык. Если нет, все, стоп, 0 центов потрачено. Звучит очень примитивно, но посчитайте, если ваш кастомер-саппорт-агент получает миллион запросов в месяц, 5% это будет мусор. Пустые строки, случайные нажатия, может быть бот трафик. Без валидации эти 50 тысяч запросов проходит весь пайплайн. Рак, ЛМ, постпроцессинг. По 5 центов каждый. Две с половиной тысячи долларов на мусор. Один ив с регексом. И эти две с половиной тысячи остаются у вас. Вот такой интересный рой для фазы валидации. Итак, наш запрос хочу кофе, конечно, проходит валидацию. Он абсолютно корректный. Но корректный не значит безопасный. И следующий стейдж у нас будет. безопасность это будет безопасность на входе здесь мы будем проверять нет ли в запросе prompt injection не пытается ли кто-то заставить агента выдать системные prompt или выполнить несанкционированные действия проверка стоит доли цента а если бы мы пропустили инъекцию и дошли до рак плюс ом потратили бы уже 10 центов и возможно при этом слили конфиденциальные данные или сделали какие-то действия которые наш агент точно не должен делать поэтому security до дорогих операций. Это не паранойя, это экономика. И наш запрос «Хочу кофе» успешно проходит Input Security. Но посмотрев на этот запрос подробно, мы поймем, что в нем очень мало информации. И следующая фаза – обогащение запроса контекстом. И эта фаза очень сильно зависит от нашего домена и то, как мы можем изменить этот запрос. Для нашего агента-бористы, пускай он сходит в чат и посмотрит, что же в нем находит, и видит сообщение. Через час – ретро. И если мы с вами это объединим, получится. Пользователь хочет кофе через час у команды ретро. И два слова превратились в задачу с контекстом. Без этого шага наш барист предложил бы просто черный кофе. С этим же шагом он может понять, что надо подготовить заказ для команды перед встречей. И контекст меняет все. Но для правильного заказа нам нужны знания. И здесь будет следующая фаза. Наш запрос обогащен, но нам надо понять, что мы знаем. У нас может быть здесь мемори ретриум. Что мы помним о этом пользователе? Его предпочтения. Алексей пьет капучино на овсяном, Марина латте на миндальном. Также возможна история. В прошлый раз заказывали маффины, и они понравились. Без памяти же каждый разговор начинается с нуля. С памятью агент узнает вас. И в этом стейдже часть у нас будет про нашего пользователя. И это про памяти. И наша IntelliJ Zone будет состоять из нескольких шагов. Как мы видим, первая будет про память о пользователе. Вторая же будет... предметную область и здесь мы с вами ищем нашей базе знаний меню кофейни текущие акции ограничения команды customer support этот же stage у нас будет искать подчас вызываем вопросы по документации code agents по кодовой базе для devops это ранбуки stage один и тот же но данные в нем будут абсолютно раз и тут есть момент который многие пропускают наш рак вернул документы на откуда вы знаете что они чистые и с этим нам поможет следующий стейдж контент фильтр проверка Рак результатов. Не вернулись ли битые документы? Нет ли в результатах инъекции через данные? Для большинства проектов это проверка на пустые результаты. Для тех, где очень важна безопасность окружения, это полноценная фильтрация. В третьем видео нашей серии мы подробно разберем эту часть. Но мы проверили наш рак, у нас все хорошо, мы можем двигаться дальше. Что же будет следующее? Следующая у нас будет также довольно-таки большая зона, в которой мы будем оптимизировать. Это будет Preparation Zone. И здесь на входе у нас есть с вами обогащенный запрос, память о пользователе, документы из рак. И все это нам надо собрать в один промп. Как мы помним, системный промп, фундамент, а вверх него пойдут наши рак документы, память и только потом запрос пользователя. Каждый кусок нашего промп на своем месте. Но есть еще одно измерение, это история чата. Если это не первое сообщение, а десятое, предыдущие десять тоже должны быть в контексте, иначе агент теряет нить разговора. Но мы знаем, что контекстное окно у нас ограничено, и каждый токен стоит денег. И у нас с вами должен быть бюджет для токенов. И эта задача со множеством переменных. Текущие запросы, рак документы, память, история. И это все должно влезть. А если не влезает, что же нам делать? Мы можем порезать историю на текущий запрос. И здесь есть несколько стратегий. Свайдинг-виндоу. Это мы оставляем последние N сообщения. Старые просто выбрасывают. Либо самморизейшн. Мы сжимаем старую историю. Краткое резюме или компэкшн, как это делает КодКод, где при переполнении контекста вся история автоматически уплотняется. Подробно об этом будем говорить во второй серии наших видео. Итак, контекст у нас с вами собран. Но какую модель нам надо с вами выбрать? Здесь как раз может присутствовать наш смарт-роутинг. Хочу кофе? Это простой запрос. Хватит и дешевая модель. Организуй кофе-брейк на 20 человек с учетом аллергии и бюджета. Это уже сложный и скорее всего нужна будет большая дорогая модель. И наша маленькая модель классификатор решает за миллисекунды, а экономия будет огромная. Но нам важно не просто выбрать модель. Если эта модель может быть запущена в двух режимах с резонингом и без, нам надо будет определить, нужен ли нам этот thinking mode или нам хватит простого запроса. Теперь мы с вами готовы выполнять этот запрос и мы приходим к нашей следующей большой зоне, в которой мы тратим уже наши доллары. Ну и конечно здесь будет фаза генерации. И это сам LLM вызов. И тут может происходить вот это ключевое отличие от workflow до агента. В workflow один вызов, результат идет дальше. В агент у нас фаза генерации может содержать цикл. LLM вызвал Tool, получил результат, потом снова LLM, потом снова Tool и так пока не решит ответить. И этот цикл самый опасный компонент. Мы разберем его отдельно через несколько минут. Но предположим, что LLM нам с вами ответил. И как вы думаете, все, нам надо ответить пользователю? Нет, нам надо на выходе. также проверить безопасность. Нет ли в ответе персональных данных наших клиентов? А может быть утек наш системный промпт? Или модель сгенерировала что-то за пределами допустимого? Ну и финальный стейдж, в котором мы формируем ответ для пользователя. Здесь мы форматируем наш ответ. И очень важно не забывать, когда LLM нам возвращает JSON для дальнейшей обработки, то здесь валидация обязательна. Это может быть место, где агенты ломаются тихо. LLM вернул почти правильный JSON. Парсер упал. пользователь получил ошибку поэтому всегда валидируйте JSON на выходе давайте посмотрим на принципы которые могут объединять наш pipeline и первый у нас будет fail-fast вы уже видели дешевые проверки идут первыми для того чтобы не тратить деньги на последующих фазах второй single responsibility не мешайте вашей стейджи валидация форматов и детекция инъекций это разная ответственность с разными владельцами смешали в один стейдж получили каплинг Представьте, безопасники обновляют правила работы с инъекциями, при этом задевают парсинг входных данных. Пайплайнпады хотели задеплоить одно, сломали другое, а в логах непонятно что отказало, потому что оба живут в одном компоненте. Поэтому разделяйте, деплойте, тестируйте и можно все это делать независимо. И третий это конфигурируемость. Не каждый стейдж нужен каждому запросу. Глубина фильтрации контента очень сильно зависит от домена. Reasoning Strategy. Только для моделей, у которых есть возможность ее переключать. Если есть история, то можно использовать Memory. И это конфигурация, это не хардкод. Начните с нескольких стадий. Валидация, Security, генерация и постпроцессинг. Добавляйте остальные, когда данные покажут, что нужно. И вот что главное. Этот пайплайн, он универсален. Customer Support тот же самый пайплайн. Скелет одинаковый. Меняются только данные и конфигурация. Итак, у нас один запрос прошел весь путь. Но как же наши фазы, наши стейджи общаются между собой? И ответ — это контекст нашего пайплайна. Это единый контейнер, который проходит через весь пайплайн. Каждый стейдж читает, что нужно, добавляет свои результаты. Следующий стейдж видит все, что добавили предыдущие. И здесь может быть аналогия из медицины. Кровь проходит через органы. Каждый орган берет что-то, добавляет что-то. Легкий кислород, печень, фильтрацию, сердце, давление. Контекст — это кровь вашего пайплайна. И здесь очень важный принцип — накопление. Каждый стейдж добавляет, не удаляет. К концу пайплайн контекст содержит полную историю обработки запроса. И потом наш контекст assembly берет эти накопленные данные и собирает из них контекстное окно. То, что уже реально увидит модель. Не все подряд, а отобранное, приоритизированное, уложенное в наш бюджет токенов. Это как повар, у которого на столе 20 ингредиентов, но в блюда пойдут не все и не целиком. А остальные вернутся обратно в холодильник, но никак не на тарелку. И еще важно, контекст должен быть стерилизуемым. Агент может прерваться посреди работы. Крэш, тайм-аут, обрыв соединения. И если контекст нельзя сохранить, он потерян. Пользователь начинает сначала. И строгая схема, это и защита от багов, и фундамент для нашего рекавери. И небольшой совет, который стоит всего этого блока. Сделайте так, чтобы полный контекст можно было сохранить и посмотреть на любом стейдже. Когда что-то у нас пошло не так, мы открываем наш снапшот и смотрим, что было на шаге 8. Ага, рак вернул 0 документов. Роудинг выбрал дешевую модель, вот почему ответ мусор. Без этого будете гадать часами. Теперь про контекстное окно, то что собрал наш контекст Assembly. Оно у нас уже заполнено данными для запроса. И вот тут у нас с вами начинаются деньги. Смотрите как работает агент цикла. Он вызвал тул. Тул вернул результат. И этот результат мы с вами... добавляем в наше контекстное окно. Потом агент решает вызвать еще один тул и результат его опять же добавляется в наше контекстное окно. И если у нас будет 10 итераций, то контекст мог вырасти в 10 раз. И на каждой итерации вы платите за весь контекст заново, каждый раз. Если вы помните, такая была агентская платформа Manus, которую потом купила Menta. И они замерили у типичного агента на 100 входных токенов, приходится один выходной. 100 к 1 вы платите за перечитывание огромного контекста, а получаете короткий ответ. Но есть спасение, KVCash. Идея простая. Если начало нашего контекста не изменялось между вызовами наших тулов, то провайдер не пересчитывает его заново, а берет из своего кэша. Это как HTTP Cache, только для токенов. И разница здесь не проценты, здесь у нас порядок. До 10 раз может быть дешевле. Умножьте на миллион токенов в день, И вы поймете, почему многие называют KVCache HitRate единственной, самой важной метрикой для продакшен агента. Но что же убивает этот наш с вами кэш, если он настолько важен? И здесь мне запомнился один момент как раз таки от Мануса, которые обнаружили его на своем продакшен. Разработчики вставили текущее время в начало System Prompt, чтобы агент знал, который сейчас час. это невинная строчка но system prompt это начало контекста таймстамп меняется каждую секунду первый токен другой и весь кэш невалиден и каждый вызов будет полная цена они платили в 10 раз больше за то что агент мог сказать сейчас 14 35 следующий момент это мутация середины вы решили поправить сообщение на 3 итерации все что после него пересчитывается с нуля и следующий немножко скрытый это про джейсон Ключи в объекте каждый раз в разном порядке. Для вас тот же самый объект, для кэша это будет другая строка. Кэш промахнулся, отсюда правило. Когда контекст assembly собирает окно, это сборка и вы тут хозяин. Выбираете, сжимаете, выбрасываете лишнее. Но когда окно собрано и агент крутится в цикле, добавляйте только в конец. Каждая мутация середины это потерянный кэш. Потерянный кэш это потерянные деньги. А если контекст разбухает? так, что он уже у нас не помещается, то мы не меняем его по кусочкам, мы пересобираем его целиком. Это как код-код, который делает компэкшн. При переполнении вся история уплотняется с нуля. Дорого, но один раз, а не каждый раз приитераться. И стратегии уплотнения мы разберем во второй серии наших видео. Хорошо, у нас есть пайплайн, это наш скелет. Контекст, это наша кровеносная система. А теперь рассмотрим, что же такое может быть сердцем. И это наш AgentLoo. Цикл, который делает агента агентом. Именно здесь ломаются чаще всего. Не в промте, не в рак. Именно в этом цикле. Напомню, в workflow этого цикла нет. У нас линейный пайплайн. Вход, стейджи, выход. Все предсказуемо и легко отлаживать. Если вам хватит, остановитесь здесь. Не идите в агентские системы. Но если задача требует автономии, тогда нам надо с вами брать наш Agent Loop. Наш агент вызывает LLM. LLM принимает решение вызывать Tool или нет. Если нам надо вызвать тул, он передает об этом информацию агенту. И мы совершаем вызов нашего тула. Получаем ответ. И добавляем этот ответ в наше контекстное окно и возвращаем в LLM. И так продолжается до тех пор, пока у нас LLM не решит, что больше мне не надо вызывать тулы, я готов дать ответ. Это упрощенная схема. В реальном продакшн сюда добавляются проверки лимитов, обработка ошибок, валидация вызовов, логирование. Но костяк примерно вот так вот и будет выглядеть. Так работает подавляющее большинство агентских систем. И вот здесь есть проблема. Этот цикл без защиты. Бомба с часовым механизмом. Давайте разберем, как именно она может взорваться. И первая группа проблем будет потеря контроля. Агент не останавливается, когда должен, и продолжает крутить этот цикл. Такан, агент выдал один и тот же результат 58 раз подряд. Ни два, ни пять, 58. Игнорировал команды на остановку. Задача давно уже решена, а он продолжал крутиться. То ли он не понял, что пора останавливаться, то ли решил, проверю-ка я еще раз, что все верно. А представьте это на тысячах пользователей одновременно. Следующая группа — это деньги. Каждая операция — это вызов модели, это оплата. 10 итераций по центу — 10 цент — это нормально. 100 итераций — это уже доллар. Возможно, это терпимо. Но помните кейс изначально? Прототип за 50 долларов масштабировался до 2,5 миллионов в месяц. Также и второй прототип за 500 долларов. вырос до 847 тысяч. Это в 700 раз. И помните из нашего прошлого блока? Контекст растет на каждой итерации, а вы платите за весь контекст при каждом вызове. И третья группа – корректность. LLM часто галлюцинирует. Все мы это с вами уже прекрасно на себе почувствовали. И в цикле это опаснее всего, потому что галлюцинация на шаге 3, она становится фактом для шага 4. Но на шаге 5 это уже становится основой для принятия решения. И здесь у нас может быть несколько типов таких ошибок. И первый — это неправильные параметры. Агент вызывает тул с неверными данными. Количество чашек кофе 999 вместо одной. Или как в DataTalk Club — Terraform Deploy вместо точечного удаления. И следующий — это фантомные вызовы. LM говорит, я проверил базу данных и нашел три результата. Но вызовы инструмента не был совершен. Результат выдуман целиком. И это классическая проблема галлюцинации инструментов. И вероятность нашего успеха падает с каждым шагом. И поэтому нам надо добавлять защитные ограничения на такие циклы, для того, чтобы не попасть в неприятную ситуацию. Что же это за ограничители? И первое, это лимит на количество итераций. И он нам говорит, сколько круглов может сделать наш цикл. Для CodeAgent 25 это нормально. Там задачи у нас очень длинные. Для Customer Support 5. Дальше уже давайте-ка передавать человеку, чтобы понять, что же идет не так. Для баристы тоже возможно 5. Это надо все тестировать и смотреть, за сколько итераций он достигает успеха. Следующее это бюджет токенов. Сколько можно суммарно потратить за все наши циклы? Превысил стоп и неважно на какой-то итерации. И следующее это лимит на инструменты. Сколько раз можно дернуть один и тот же тул? Как пример, наш агент бариста хочет понять, какая температура. потому что это может повлиять на типы напитка. И он вызывает ее уже четвертый раз подряд. И это странно. Поэтому мы говорим ему, стоп, хватит узнавать погоду. Она не изменилась за последние 3 секунды. Но надо иметь в виду, что для каждой задачи значение этих лимитов надо подбирать самостоятельно, итеративно, смотреть, что нам хватает, а чего не хватает. Поэтому ставьте метрики и наблюдайте за вашей системой. И главное, это жесткие ограничения в коде. Не в промте. Написали в промте, пожалуйста, остановись после 10 шагов. Это рекомендация, модель может послушать, а может и не послушать. Поэтому контролируйте это именно в коде. Не отдавайте контроль этих лимитов на уровень модели. Вы можете сюда добавить и другие лимиты. Главное относиться к ним как к бюджетному контракту, как к СЛО для сервисов. Сколько стоит один принятый результат? Агент потратил доллар и решил задать. Отлично. Потратил доллар и не решил? Значит мы с вами выбросили деньги. Четвертый ограничитель. Это подтверждение человеком. Human in the loop. Первые три срабатывают при превышении лимитов. А этот срабатывает при опасности. Возможно мы хотим совершить какие-то необратимые действия. Разместить заказ, отправить платеж, удалить данные. И это только через подтверждение человека. Следующие аномальные параметры. Допустим количество заказа превышает типичное в 5 раз. Все, пауза, передаем человеку. Или сумма заказа больше дневного бюджета. Паузы остановились. А может быть кто-то заказал у нашего албариста 500 экспресса? И это для конференции или наш агент сошел с ума? Надо проверить. И это реализуется прямо внутри цикла. Перед выполнением вызова инструмента проверяем уровень риска и параметры. Если надо, ставим цикл на паузу и запрашиваем подтверждение человека. Многие фреймворки это уже поддерживают из коробки. Но принцип не зависит от фреймворка. И теперь очень интересный момент, который часто не видим, когда вы только начинаете создавать агентские системы. Что вы говорите модели, когда ограничитель сработал или, возможно, наш тур вернул какую-то ошибку? Если вы ему просто отправите «Ошибка, лимит достигнут», модель не понимает, что случилось. Это как сказать человеку «Ошибка без объяснения». И что человек сделает? Конечно, попробует сделать это еще раз. Если же вы модели скажете «Инструмент GetWeather вызван 4 раза», Максимум при этом всего 3. У тебя достаточно данных. Дай финальный ответ прямо сейчас. Модель понимает ограничения и адаптируется. Здесь у нас присутствует конкретика, контекст, инструкция. И последнее, что делать, если агент остановился. У нас есть несколько стратегий. Первое, это частичный результат. Мы можем вернуть пользователю, допустим, как наш Бористо. Я нашел предпочтение трех человек из десяти, вот они. Остальные уточните сами. И пользователь решает, достаточно ли. Следующее, это эскалация. Задача сложнее, чем я могу решить автоматически. Передаю оператору. И это очень хорошо работает в Customer Support System. И следующее это повтор с другими параметрами. Другая модель, упрощенный запрос, урезанный контекст. Помните, что в продакшн нам надо сделать так, чтобы наш пользователь не получал пустоту. Так вот, если цикл это наше сердце, то что же будет нашими руками? И это инструмент. Агент без инструментов это чат-бот. Дорогой галлюцинирующий чат-пот. Инструменты — это руки агента. И вот что важно понять. Проектирование инструментов часто важнее, чем просто выбор модели. Можно взять лучшую модель в мире, но если инструменты спроектированы плохо, агент будет ошибаться. И Anthropic пишет об этом. Критически важно проектировать набор инструментов, их документацию ясно и продумано. А вот еще немного информации. Shopify — доклад на ICML. Их агент Sidekick. Когда инструментов было до 20, Все управляемо. От 20 до 50 границы размывались. Комбинации инструментов давали неожиданные результаты. Больше 50 они назвали это смерть от 1000 инструкций. Невозможно запихнуть описание всех инструментов в системный промпт. Модель просто тонет. Но до масштаба Shopify надо еще дорасти. А вот правильное описание инструмента нужно с первого дня. Как модель выбирает инструмент? Она читает его описание. Его имя. схему параметров и на основе этого решает, подходит он или нет. Формат описания зависит от провайдера. OpenAI, Anthropic, Google, Quen оборачивают немного по-разному. На ядро одно и то же. Давайте же разбираться, что делает описание инструмента хорошим. Имя. И здесь должно быть глагол плюс существительное. И оно должно быть понятным. Все прямо как код, который вы пишете. Если вы хотите, чтобы люди понимали, что делает эта функция, ей надо дать хорошее, понятное, читаемое название. Не надо называть ее «Doo» «Stuff» или «Helter». Имя — это первое, что видит модель. По нему она решает, этот инструмент вообще про мою задачу или нет. Невнятное имя, и модель выберет не тот инструмент или пропустит нужный. Следующее — это описание. Мы с вами привыкли писать документацию для людей, а описание инструментов у нас читает модель, не человек. Ей нужны какие вещи? Что инструмент делает, когда его вызывать? И какие условия должны быть выполнены до вызова. Вызывай после подтверждения человека. Одна строчка, которая предотвращает целый класс ошибок. И важный нюанс. Исследование показывает, что модели лучше реагируют на позитивные инструкции. Сначала проверь бюджет через GetBudget. Работает надежнее, чем не вызывай без проверки бюджета. Говорите модели, что делать, а не что не делать. Следующее это параметры. И здесь чаще всего у нас будет с вами JSON. Здесь мы с вами обозначим тип, границы, и нам, и чем строже схема, тем меньше модель будет галлюцинировать. Также часто мы можем передать значение по умолчанию для необязательных параметров. Если пользователь не сказал срочно, то приоритет автоматически поставим Normal, а не придуманный моделью. Следующая часть — это ответ. Здесь будет структурированный JSON. Чаще всего, конечно, от вашей модели будет зависеть описание тулов. И модели надо будет разобрать результат вызова и принять свое решение. Подходит это, надо дальше совершать другие вызовы или у нас уже есть все нужные нам данные. Следующая часть это ошибки. И это очень важно. Здесь будет открыться разница между хорошим и плохим инструментом. Наша любимая ошибка Something went wrong. И модель у нас будет с вами в тупике. Она не знает, что случилось и что делать. Как пример. Бюджет превышен и текущая сумма 4,5 тысячи. Лимит же у нас 4 тысячи. Предложение уменьшить заказ. Модель видит конкретику и предлагает решение пользователя. Так вот ошибка это не конец, это инструкция для следующего шага. И это очень важно понимать, потому что наши с вами бэкэнды часто дают такие ошибки, которые не просто являются не инструкциями, они и нас с вами запутывают, они всех запутывают. Так вот запутать модель это значит просто так сжечь бюджет. Да, ошибки не относятся к описанию наших тулов, они относятся непосредственно к нашим тулам. Поэтому с ними надо будет очень хорошо и качественно поработать, но об этом мы еще сегодня поговорим. Итак, мы с вами спроектировали наши инструменты. Но как их подключать? Здесь в индустрии пришла к стандарту MCP. Model, Context Protocol. Подробно разбирать протокол не будем, по нему у меня есть видео. Правда, с тех пор протокол поменялся, как и все за последний год, очень сильно. Так что сейчас это будет размытием нашего фокуса. Но один архитектурный момент разобрать мы обязаны, потому что именно он как раз таки ломает всю работу. Сейчас появилось множество инструментов, которые автоматически оборачивают наши с вами бэкэнды, базы данных, API в MCP серверы, которые очень легко подключать к нашим агентам. Звучит это все очень красиво, подключил и поехал. Многие именно так и делают, фигак-фигак в продакшн. А потом бэкэнд, что делает? Возвращает нашу с вами любимую ошибку, которую мы с вами. Только что обсуждали. Something went wrong. Или тайм-аут. Или невалидный ответ. А может быть вообще стек-трейс на три экрана? И что же нашей модели совсем с этим делать? Она либо остановится, либо начнет галлюцинировать. Поэтому автоматическая обертка, она оборачивает хэппи-пат. А продакшн, это ни в коем случае не про хэппи-пат. Это тайм-ауты, пустые ответы, невалидные данные, частичные результаты. И если вы не продумали каждый из этих сценариев, Значит вы не подключили инструмент к вашему агенту. Правило простое. Прежде чем обернуть сервис в МСП, пройдите по всем ошибкам, которые он может вернуть. Для каждой сделайте ответ, который модель поймет. С конкретикой, что случилось, можно ли повторить, что делать вместо этого. Все те же самые правила, которые мы разбирали для наших инструментов. Следующий компонент это наблюдаемость. Не логирование, а именно наблюдаемость. Логирование это что произошло? Наблюдаемость. Почему запрос стоил 12 центов вместо 2 и занял 8 секунд вместо 1? Как вы это реализуете? Observer Pattern, Middleware, декораторы, хуки, зависит от вашего стека. Принцип 1. Каждое значимое событие в pipeline должно быть видимым. Начало стейдж, завершение, ошибка, вызов инструментов, итерации цикла, выбор моделей. Все это нужно уметь видеть и проанализировать. Закладывайте наблюдаемость с первого дня. Не после первого инцидента, потому что после первого инцидента у вас не будет данных, чтобы понять, что произошло. Конкретные инструменты, метрики, трейсинг. И это мы с вами подробно разберем в третьей части серии наших видео. Помните начало? 50 долларов на прототипе, 2,5 миллиона в продакшн. Или 58 одинаковых ответов подряд. Или Terraform Destroy на продакшн базе. Теперь вы знаете, почему это может произойти. Не потому что модели плохие. а потому что не было хорошего пайплайна с fail-fast подходом. Не было ограничителей в цикле, не было продуманных ошибок у инструментов, не было наблюдаемости с первого дня. Так вот мы с вами вскрыли агента и нашли не магию, мы нашли инженерную систему. И когда вам в следующий раз предложат новый крутой фреймворк, спросите, а что у него внутри? Где ограничители? Где продуманные ошибки инструментов? А что у него с безопасностью? И если ответ будет, фреймворк сам разберется и все сделает, вспомните Terraform Destroy. Во второй серии наших видео мы дадим нашему агенту мозги. Нужен ли нам рак? Или хватит большого контекста, а рак уже на самом деле мертв? Четыре типа памяти и бюджетирование, чтобы наш агент не съел месячный бюджет за один день. Подписывайтесь, чтобы не пропустить. Ставьте лайк, если анатомия стала понятней. И напишите в комментариях, какого агента планируете строить. До встречи во второй серии наших видео про агентов. Пока!

Как устроен AI-агент изнутри — анатомия, которую не покажет ни один фреймворк.

В этом видео я вскрываю AI-агента по частям: от выбора между workflow и agent до конкретных stage pipeline, agent loop, проектирования инструментов и MCP. Разбираю на сквозном примере — Агент-Бариста — но архитектура та же, что у coding assistant, DevOps-агента или customer support.

Что внутри:
— Workflow vs Agent: 7 уровней от одного LLM-вызова до мультиагентной системы — и почему большинству хватит workflow
— Pipeline: 12 stages обработки запроса 
— Context как кровеносная система агента — и три ошибки, убивающие KV-cache
— Agent Loop: почему это самый опасный компонент и какие guardrails ставить в коде, а не в промпте
— Проектирование инструментов и ловушки автоматической обёртки в MCP
— System Prompt как архитектурный контракт: роль, приоритеты, формат, пример

Видео для сеньоров, тех-лидов и архитекторов, которые хотят строить AI-агентов осознанно — понимая каждый компонент, а не доверяя фреймворку. 

Первая часть серии «System Design AI-агента — изнутри наружу».


0:00 — $50 на прототипе → $2.5 млн в production
3:41 — А вам вообще нужен агент?
4:02 — Workflow vs Agent: в чём разница
5:24 — 7 уровней: от одного LLM-вызова до мультиагента
14:14 — Pipeline: что внутри каждого запроса
15:02 — System Prompt — архитектурный контракт
19:43 — Блокируй рано, трать поздно: stages pipeline
28:29 — Context — кровеносная система агента
33:12 — Agent Loop — самый опасный компонент
36:17 — Guardrails: ограничители в коде, не в промпте
38:16 — Human in the loop: когда останавливать агента
40:30 — Инструменты: руки агента
44:41 — MCP: ловушка автоматической обёртки
46:21 — Наблюдаемость с первого дня


Видео про RAG https://youtu.be/GkKSDBgz4XQ