AI-агент в существующем продукте: как встроить без переписывания

Добавить чат-бота в продукт умели давно. Добавить агента — систему, которая сама планирует шаги, вызывает ваши функции и доводит задачу до результата — стало массово доступно только за последние полтора года, когда OpenAI, Anthropic и Google открыли function calling и протоколы вроде MCP. Разница принципиальная: бот отвечает текстом, агент нажимает кнопки внутри вашего приложения. Ниже — как встроить его в готовый продукт, не переписывая его с нуля, и чем платят за каждый из подходов.

Что вы на самом деле встраиваете

Агент — это не одна модель, а связка из четырёх частей. Модель (LLM), которая рассуждает. Набор инструментов¹ — функции вашего продукта, которые модель может вызывать. Оркестратор — код, который крутит цикл «модель предложила действие → вы его выполнили → результат вернули модели». И память или контекст: то, что агент помнит между шагами и сессиями.

Главная ошибка на старте — думать, что интеграция сводится к вызову API модели. Вызов модели — это 20% работы. Остальные 80% — описание ваших инструментов, обработка ошибок, лимиты и то, что произойдёт, когда агент захочет сделать что-то, чего вы не разрешали.

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

Три пути интеграции

1. Прямой function calling

Вы описываете свои функции в формате, который понимает модель, и сами крутите цикл вызовов. Это делают через API OpenAI (tools), Anthropic (tool use) или Google Gemini. Максимум контроля, минимум зависимостей — но весь оркестратор, повторные попытки и логику остановки пишете сами.

2. Фреймворк-оркестратор

LangChain / LangGraph, LlamaIndex, Microsoft Semantic Kernel, CrewAI берут на себя цикл, память и цепочки шагов. Быстрее стартовать, но вы наследуете абстракции фреймворка и его версионный хаос: API этих библиотек меняются часто, и обновление может сломать рабочий пайплайн.

3. Готовый агент-сервис

OpenAI Assistants API (и более новый Agents SDK), а также платформенные конструкторы держат состояние и инструменты на своей стороне. Меньше кода — но вы отдаёте данные и логику во внешний сервис и платите за это как за premium-модель.

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

Порядок внедрения по шагам

1. Выберите один узкий сценарий. Не «умный ассистент по всему продукту», а «агент оформляет возврат заказа» или «собирает отчёт из трёх ваших таблиц». Узкая задача даёт измеримый результат за недели, а не месяцы.
2. Опишите инструменты как публичный API. Каждая функция — с чётким именем, описанием и типами параметров. Модель читает именно эти описания, а не ваш код.
3. Ограничьте права. Разделите инструменты на читающие и изменяющие. На всё, что меняет данные или деньги, поставьте подтверждение человеком.
4. Добавьте RAG², если агенту нужны ваши данные. Документация, база знаний, история заказов подаются в контекст через поиск, а не зашиваются в промпт.
5. Логируйте каждый шаг. Что модель предложила, что вы выполнили, что вернули. Без этого отладка агента превращается в гадание.
6. Поставьте лимиты. Максимум шагов на задачу, потолок токенов, тайм-аут. Агент в цикле без ограничителя способен за минуты сжечь заметный бюджет на API.

Где чаще всего ломается

Три типовые проблемы, которые всплывают уже в продакшене:

• Галлюцинации вызовов. Модель придумывает несуществующий инструмент или подставляет неверные параметры. Лечится валидацией на вашей стороне и возвратом внятной ошибки, чтобы агент повторил попытку корректно.
• Разрастание контекста. Длинная сессия переполняет контекстное окно³, растут задержка и цена. Нужна стратегия сжатия: суммаризация истории, обрезка старых шагов.
• Тихий рост счёта. Каждый шаг агента — отдельный запрос к модели. Задача из десяти шагов стоит в разы дороже одного ответа чат-бота. Считайте стоимость на сценарий, а не на запрос.

Кому это пригодится, а кому нет

Пригодится, если у продукта есть повторяющиеся многошаговые операции, которые сейчас делает человек через несколько экранов:

• поддержка, где агент сам находит заказ, проверяет статус и оформляет возврат;
• внутренние инструменты аналитики: «собери сводку по этим метрикам за квартал»;
• онбординг и настройка, где агент заполняет конфигурацию за пользователя.

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

• операции с деньгами и необратимыми последствиями без обязательного подтверждения человеком;
• задачи, где достаточно одного детерминированного запроса — тогда обычная функция дешевле и надёжнее агента;
• продукты с жёсткими требованиями к предсказуемости ответа: агент по природе недетерминирован.

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

² RAG (Retrieval-Augmented Generation) — подход, при котором перед ответом система ищет релевантные документы в вашей базе и подаёт их модели в контекст, чтобы она опиралась на факты, а не на память из обучения.

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