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

Разница появляется, когда всё это запускается в прод и начинает ловить реальную нагрузку.

Давайте разберём агента по слоям. Не в стиле маркетинговой презентации, а как инженер объяснил бы инженеру: что внутри, за что реально идут деньги, где оно сыпется.

Четыре кирпича любого агента

Если снять с ИИ-агента красивую обёртку, внутри окажется четыре компонента:

  1. Модель (LLM) - клод, жпт, джемини или локальный Qwen. Отвечает за рассуждение и генерацию текста.
  2. Инструменты (tools) - набор функций, которые агент умеет вызывать. Найти клиента в CRM, отправить письмо, посчитать тариф.
  3. Память - краткосрочная (контекст одного диалога), долгосрочная (что помнит между сессиями), семантическая (RAG по базе знаний).
  4. Оркестратор - код, который получает задачу и решает, когда звать модель, когда дёргать инструменты, когда лезть в память.

Всё. Любой агент - это комбинация этих четырёх штук. Разница между пилотом за 150к и промышленным решением за 2 миллиона - не в составе слоёв, а в глубине проработки каждого.

Слой 1. LLM - не самый важный, но самый обсуждаемый

На демонстрациях обычно меряются моделью. «У нас Claude 4.7 Sonnet», «а у нас GPT-5». Это удобный аргумент для слайда, но в реальности выбор модели решает 15-20% задачи.

Почему так. Модель отвечает за то, насколько умно агент интерпретирует запрос. Для простой классификации заявок хватит Haiku за ≈25 ₽ на миллион токенов. Для разбора сложного многостраничного договора нужен Sonnet или Opus. Для картинок - Gemini. Для полной изоляции данных - Qwen на своём GPU.

Что реально ломает агента - не уровень модели, а вещи вокруг неё:

  • Плохой промпт. Модель топовая, а ей дали задачу в стиле «помоги клиенту с заказом». Агент начинает шарашить лирику вместо действий.
  • Неверно настроенный function calling. Модель вызывает несуществующие функции, ответы не валидируются, всё падает при первом нестандартном запросе.
  • Контекстные лимиты. В контекст на 200к токенов пихают всю базу знаний вместо релевантных кусков. Счёт за месяц уходит в семизначную сумму, финдиректор просыпается в поту.

Выбор модели - это про «чем платим в ежемесячном счёте» и «что умеем». Разница Haiku vs Opus - 60 раз по цене. На классификации Haiku хватит за глаза. На анализе договоров - нет.

Слой 2. Инструменты - здесь начинается реальная разработка

В демо агент часто выглядит как умный чат-бот. Задают вопрос, он отвечает. Для бизнеса такой бот бесполезен: бизнесу нужен агент, который делает.

Инструмент - это функция, которую агент вызывает вместо генерации текста. Примеры из живых проектов:

  • get_order_by_id(order_id) - найти заказ в 1С
  • create_ticket(subject, priority, user_id) - завести тикет в Jira
  • send_telegram_message(chat_id, text) - написать клиенту
  • search_knowledge_base(query) - подтянуть кусок из базы знаний

Звучит просто. На практике вокруг каждой функции вырастает куча обвязки, про которую в демо не говорят:

Валидация входных данных. Модель может галлюцинировать и передать order_id = "abc-лол", а у вас в 1С только числа. Без валидации - исключение в проде, агент падает, клиент в ахере.

Авторизация. Агент работает от имени пользователя и с его правами, или от имени системы. В первом случае нужен OAuth-поток, во втором - аудит всех действий. Иначе через полгода придёт проверка и спросит, кто обнулил цены в каталоге.

Идемпотентность. Агент дёрнул функцию «создать заказ», сетевой таймаут, ретрай. Клиент получил два заказа. Менеджер по возвратам работает лишний час.

Rate limiting. Модель зациклилась и дёргает одну и ту же функцию 200 раз в секунду. Ваш API лёг, легли чужие API. У всех плохо.

Обработка ошибок. Функция вернула 500. Что делает агент - ретраит? Говорит пользователю? Эскалирует человеку? Если ответ «ну, как-то обрабатываем» - не обрабатываем никак.

Таймауты. Функция зависла на 40 секунд. Пользователь давно закрыл чат. Агент всё ещё думает и будет платить за токены.

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

Слой 3. Память - три вида, в каждом можно накосячить

Память агента - штука, о которой любят говорить на уровне «у нас есть память». На самом деле видов памяти три, и каждая требует отдельной инженерии.

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

Долгосрочная. Агент помнит клиента между сессиями. «В прошлый раз вы спрашивали про холодильник на 400 литров». Реализация - внешнее хранилище, по user_id лежит профиль и история. Подвох глубокий: что хранить. Сохранять всё подряд - чеки за токены космические, потому что это потом грузится в контекст. Сохранять мало - агент регулярно забывает что-то важное.

Семантическая (RAG). У агента есть база знаний, из которой он тянет релевантные куски под запрос. Регламенты, документация, база товаров. Реализация - векторная БД (Qdrant, Pinecone, pgvector). Подвох тут самый коварный: плохие эмбеддинги и тупой чанкинг дают ответы, которые звучат уверенно, но содержат чушь.

Если в описании проекта написано «используем RAG» и всё - уточняйте. Какие эмбеддинги. Как нарезаны чанки. Чем реранкерите. Как обновляете базу при изменениях в источниках. Без ответов на эти вопросы «используем RAG» - это буллшит-слово, а не решение.

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

Слой 4. Оркестратор - невидимый мозг

Самый недооценённый компонент. Оркестратор - это код (обычный императивный, не модель), который принимает запрос пользователя и решает, как его обрабатывать.

Варианты реализации, от простого к сложному:

Прямой вызов модели. Запрос - модель - ответ. Это не агент, это чат-бот. Подходит для FAQ, не подходит для действий.

ReAct-цикл. Модель получает запрос, думает, решает вызвать инструмент, вызывает, получает результат, снова думает. Цикл до финального ответа. Популярный вариант, нормально работает для средней сложности задач.

Граф агентов. Несколько специализированных агентов, каждый со своей ролью. Один принимает заказ, другой проверяет склад, третий оформляет доставку. Оркестратор гоняет данные между ними по DAG. Про это мы писали отдельно.

Самостоятельно планирующий агент. Агент сам разбивает задачу на шаги, выполняет, корректирует план. Звучит эффектно, в демо производит впечатление. В проде - работает плохо, слишком большой люфт непредсказуемости. Для B2B почти всегда перебор.

Главный вопрос, который нужно задать подрядчику - какой тип оркестрации выбрали и почему. Если ответа нет или ответ «модель сама разберётся» - это не агент, это надежда в коробке.

Где оно всё разваливается в проде

Паттерны провалов повторяются от проекта к проекту.

Слой инструментов. Агент правильно понял задачу, но инструменты возвращают мусор или падают. Пример из реальности: агент отправляет запрос в CRM, CRM лагает и возвращает 504. Агент интерпретирует это как «заказа нет» и сообщает клиенту, что заказ не найден. Клиент в ярости, заказ на самом деле есть.

Слой памяти. Агент теряет контекст между сессиями, потому что долгосрочная память хранит только последние 100 сообщений. Клиент возвращается после недельной паузы и получает «здравствуйте, чем могу помочь», как будто он впервые зашёл. Клиент уходит, менеджер клиента не спас.

Промпт. В промпт засунули всю политику компании, все регламенты, список из 47 правил. На пятом правиле модель теряет концентрацию, на десятом начинает конфликтовать сама с собой. Ответы становятся странными, а отследить причину сложно - логи промпта никто не смотрит.

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

Что спросить у подрядчика на первой встрече

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

  • Какая модель, почему именно эта, сколько будет стоить в месяц на вашем объёме запросов
  • Какие инструменты планируются, как работает валидация их ответов
  • Как устроена память, что физически хранится и где
  • Какой тип оркестрации выбран, почему именно он
  • Что происходит, если модель ошиблась или инструмент упал
  • Кто поддерживает промпты после запуска и как их менять без деплоя
  • Как будете мониторить качество ответов

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

Про внедрение, реальные бюджеты и сроки запуска мы уже писали пошагово. Здесь цель была показать только архитектуру изнутри.

Коротко

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

Когда выбираете подрядчика, не слушайте обещания про «умный агент, который решит все ваши проблемы». Слушайте, как человек описывает вот эти четыре слоя. Если говорит предметно - у него шанс собрать рабочий продукт. Если общими словами - вы купите красивое демо, которое не доживёт до прода.

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