От чат-бота к агенту: как перевести LLM на действия

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

Что вообще делает бота агентом

Обычный сценарий с чат-ботом линеен: запрос пользователя → один вызов модели → ответ. Даже если вы подмешиваете документы через RAG¹, модель по-прежнему только генерирует текст, а действия совершает ваш код заранее.

Агент² устроен как петля. Модель на каждом шаге получает список доступных инструментов и сама решает: ответить пользователю или вызвать функцию. Если вызвала — ваш рантайм исполняет функцию, возвращает результат обратно в контекст, и цикл повторяется, пока модель не сочтёт задачу выполненной. Именно этот цикл — а не «умная модель» — и есть агент.

Практический механизм называется function calling (у Anthropic — tool use). Вы описываете функции в формате JSON Schema, модель возвращает не текст, а структуру с именем функции и аргументами. Форматы у OpenAI, Anthropic и Google близки, но не идентичны — переносить придётся с правкой.

Главная ошибка миграции — считать, что агент это чат-бот с плагинами. На деле вы строите распределённую систему, где недетерминированный компонент (модель) управляет исполнением. Отладка ближе к отладке многопоточного кода, чем к правке промпта.

Пять вещей, которые придётся добавить

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

Пошаговый план миграции

Не переписывайте всё сразу. Порядок, который снижает риск:

1. Выделите один сценарий, где действие реально нужно (например, «проверь статус заказа по номеру»), а не весь бот.
2. Опишите один инструмент для этого сценария и подключите function calling, оставив остальное как есть.
3. Добавьте цикл с жёстким лимитом — 5–10 итераций для старта хватит.
4. Введите режим «человек в контуре»: опасные действия только после подтверждения оператора.
5. Настройте логирование по шагам и посчитайте реальный расход токенов на типовой запрос.
6. Только убедившись, что один инструмент работает стабильно, добавляйте следующие.

Чем это отличается от готовых фреймворков

Писать цикл руками не обязательно — есть оркестраторы. Но у каждого своя цена входа и свои течи абстракций.

Общее правило: чем сложнее фреймворк, тем труднее понять, почему агент повёл себя не так — часть логики спрятана в абстракции. Для первого агента разумно взять минимальный SDK провайдера и цикл на 50 строк, а тяжёлые оркестраторы подключать, когда сценариев станет много.

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

Пригодится:

• Поддержка, где бот должен не только объяснять, но и делать: создавать тикет, менять адрес доставки, проверять статус в CRM.
• Внутренние инструменты — «сходи в три системы, собери отчёт, положи в таблицу».
• Разработка: агент, который читает репозиторий, запускает тесты и предлагает патч.

Не стоит переусложнять, если:

• Бот отвечает на вопросы по базе знаний — здесь достаточно RAG без агентности, дешевле и предсказуемее.
• Сценарий строго линеен и известен заранее — обычный код с одним-двумя вызовами модели надёжнее, чем петля, которая может уйти не туда.
• Цена ошибки высока, а подтверждения человеком нет — недетерминированный агент с правом на действие без контроля опасен.

Сколько это стоит в токенах

Главный сюрприз миграции — счёт. В чат-боте один запрос это один вызов модели. В агенте один запрос пользователя может развернуться в 5–15 вызовов, и каждый раз в контекст уходит вся предыдущая история плюс результаты инструментов. Расход токенов на диалог легко вырастает в несколько раз.

Как держать бюджет:

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

¹ RAG (retrieval-augmented generation) — подход, когда перед ответом модель получает найденные в базе документы, чтобы отвечать по вашим данным, а не только по обучающим.

² Агент — система, где языковая модель в цикле сама выбирает и вызывает инструменты (функции, API), а не только генерирует текст в ответ на один запрос.