Что такое агент

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

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

Пример. Допустим, нам необходимо получать информацию из базы данных через простые словесные запросы: есть таблица клиентов, и нужно узнать, сколько среди них человек с балансом выше 1000. Попробуем обойтись одним вызовом модели — то есть, по сути, чат-ботом.

from langchain.chat_models import init_chat_model

# Имя модели меняется от провайдера к провайдеру — берите актуальное из его документации.
MODEL = "openai:gpt-5.6-sol"

llm = init_chat_model(MODEL)

response = llm.invoke("Сколько клиентов с балансом выше 1000?")
print(response.text)

Ответ будет примерно таким:

Числа мы не получили — модель просит прислать данные. И дело не в том, что она недостаточно умна: у неё просто нет доступа к базе. Всё, что она умеет, — превращать текст на входе в текст на выходе. Чтобы получить число, кто-то должен сходить в базу.

Инструмент — это функция, о которой модель знает

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

import sqlite3
from contextlib import closing

from langchain.tools import tool

@tool
def run_sql(query: str) -> str:
    """Выполнить SELECT в базе клиентов clients(name, balance) и вернуть строки результата."""
    with closing(sqlite3.connect("clients.db")) as conn:
        rows = conn.execute(query).fetchall()
    return str(rows)

Про closing стоит сказать отдельно, потому что на этом спотыкаются регулярно: with sqlite3.connect(...) сам по себе соединение не закрывает — он только фиксирует или откатывает транзакцию. Инструмент агент дёргает в цикле, и без явного закрытия каждый вызов оставляет за собой открытое соединение.

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

llm_with_tools = llm.bind_tools([run_sql])
response = llm_with_tools.invoke("Сколько клиентов с балансом выше 1000?")

print(response.text)
print(response.tool_calls)

Вот что печатает этот код:

Первая строка пустая — обычного ответа модель не дала. Вместо него во второй строке лежит заявка: имя инструмента, аргументы и идентификатор вызова.

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

Один вызов задачу не закрывает

Результат run_sql нужно вернуть модели: сама она не знает, что вернула база. Значит, модель придётся вызвать ещё раз — уже с результатом инструмента в диалоге. На втором вызове она может ответить пользователю, а может запросить следующий инструмент: например, увидев пустой результат, попросить список таблиц и переписать запрос.

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

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

Остановка

Цикл нужно чем-то завершать, и здесь два разных механизма.

Первый — естественная остановка: модель возвращает обычное сообщение без заявок на вызов. Это значит, что она считает задачу решённой.

Второй — жёсткий лимит. Модель может зациклиться: снова и снова дёргать тот же инструмент, получать ту же ошибку и пробовать ещё раз. Без ограничения такой цикл крутится, пока не кончатся деньги на счёте. Поэтому число шагов ограничивают снаружи, и это не перестраховка, а обязательная часть конструкции.

Собираем всё вместе

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

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

Писать этот цикл руками не нужно, его даёт фреймворк:

from langchain.agents import create_agent

agent = create_agent(
    model=MODEL,
    tools=[run_sql],
    system_prompt=(
        "Ты аналитик. Отвечай на вопросы о клиентах, "
        "получая данные через инструмент run_sql."
    ),
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "Сколько клиентов с балансом выше 1000?"}]},
    {"recursion_limit": 12},
)

print(result["messages"][-1].text)

create_agent принимает модель, список инструментов и системный промпт, а возвращает готовый цикл. recursion_limit — тот самый жёсткий лимит: сколько внутренних шагов разрешено сделать, прежде чем выполнение прервётся с GraphRecursionError.

Считаются здесь шаги графа, а не обращения к инструментам: вызов модели — один шаг, исполнение её заявок — второй. То есть один полный ход «модель решила — код сходил» стоит примерно две единицы, и 12 в примере означает около шести ходов.

Значение по умолчанию — 10007, то есть защиты по факту нет: агент успеет сжечь бюджет задолго до срабатывания. Поэтому лимит выставляют вручную и под конкретную задачу — как здесь.

Схема получившейся конструкции:

ReAct: как выглядит один прогон агента

У цикла, который мы собрали, есть имя — ReAct, от reasoning and acting: модель чередует рассуждение и действие. Она смотрит на то, что уже произошло, решает, что делать дальше, делает один шаг и снова смотрит на результат. Никакого плана целиком наперёд у неё нет: решение принимается заново на каждой итерации, с учётом всего, что накопилось.

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

import sqlite3
import smtplib
from contextlib import closing
from email.message import EmailMessage

from langchain.tools import tool
from langchain.agents import create_agent

@tool
def run_sql(query: str) -> str:
    """Выполнить SQL-запрос к базе клиентов и вернуть результат или текст ошибки."""
    try:
        with closing(sqlite3.connect("clients.db")) as conn:
            return str(conn.execute(query).fetchall())
    except sqlite3.Error as exc:
        return f"SQLError: {exc}"

@tool
def send_email(to: str, subject: str, body: str) -> str:
    """Отправить письмо на указанный адрес."""
    message = EmailMessage()
    message["To"], message["Subject"] = to, subject
    message.set_content(body)
    with smtplib.SMTP("localhost") as server:
        server.send_message(message)
    return "sent"

agent = create_agent(
    model=MODEL,
    tools=[run_sql, send_email],
    system_prompt="Ты аналитик. Структуру базы выясняй запросами, не угадывай.",
)

task = "Посчитай клиентов с балансом выше 1000 и отправь число на ivan@example.com"

result = agent.invoke(
    {"messages": [{"role": "user", "content": task}]},
    {"recursion_limit": 12},
)

for message in result["messages"]:
    message.pretty_print()

Обратите внимание на run_sql: ошибка базы не поднимается наверх, а возвращается строкой. Это сделано намеренно — сейчас станет видно, зачем.

Трасса

Вот что напечатал последний цикл — полный список сообщений, накопленный за прогон:

Разберём по шагам, что здесь произошло.

Первая итерация. Модель видит только задачу и описания двух инструментов. Названия колонок она не знает, поэтому берёт самое правдоподобное — balance. База отвечает ошибкой, и эта ошибка возвращается модели как обычный результат инструмента.

Вторая итерация. Теперь в диалоге лежит текст ошибки. Модель читает его и меняет решение: вместо повторной попытки угадать запрашивает структуру таблицы. Вот ради чего нужен цикл — не ради красоты, а ради возможности исправиться, увидев результат.

Третья итерация. Имя колонки известно, запрос переписан, получено число.

Четвёртая итерация. Данные есть, остаётся вторая половина задачи — письмо. Модель сама решает, что теперь очередь send_email, и подставляет в аргументы результат прошлого шага.

Пятая итерация. Модель возвращает обычное сообщение без заявок на вызов — цикл завершается сам. Лимит в 12 шагов не понадобился.

Что уходит в модель на каждой итерации

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

Из этого следуют два практических вывода.

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

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

Где смотреть трассу

Печать сообщений в консоль годится, чтобы разобраться на своей машине. В работающем сервисе так отладить агента нельзя: прогоны идут параллельно, шагов десятки, а вопрос обычно один — на каком шаге всё свернуло не туда. Для этого прогон пишут не строками в лог, а деревом вложенных отрезков: вызов модели, вызов инструмента, шаг агента, с длительностью и потраченными токенами у каждого. Такой разбор ждёт нас в части курса про эксплуатацию.

Что стоит унести отсюда прямо сейчас: разбор поведения агента всегда начинается с трассы. Пока вы не видите последовательность «что модель решила — что вернул инструмент», любые рассуждения о том, почему агент ответил ерунду, остаются гаданием.

Агент, чат-бот и промпт-цепочка

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

Чат-бот

Чат-бот — диалоговый интерфейс к модели. Пользователь пишет сообщение, бот отвечает текстом. Внутри может быть что угодно: правила, поиск по базе знаний, вызов модели с историей переписки. Но результат работы — всегда сообщение в диалоге.

Задачу «посчитай и отправь на почту» чат-бот не решает не потому, что модель слабая, а потому, что в этой конструкции никто не выполняет действий: последовательность шагов задаёт человек, отправляя следующее сообщение.

Промпт-цепочка

Промпт-цепочка — фиксированная последовательность шагов, которую вы написали сами. Модель встроена в неё как один из шагов.

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_template(
    "Преобразуй вопрос в SQL-запрос к таблице clients(name, account_balance). "
    "Верни только SQL, без пояснений и без markdown-разметки.\nВопрос: {question}"
)

chain = prompt | llm

sql = chain.invoke({"question": "Сколько клиентов с балансом выше 1000?"}).text
print(sql)
rows = conn.execute(sql).fetchall()
print(rows)

Задача решена, данные из базы получены. И это по-прежнему не агент: шаги здесь заданы жёстко — сгенерировать SQL, выполнить, напечатать. Если модель ошибётся в имени колонки, цепочка упадёт с исключением и на этом закончится. Исправиться она не может: второго прохода не предусмотрено.

Такая конструкция часто оказывается правильным выбором. Она дешевле — один вызов модели вместо пяти, — предсказуема и отлаживается как обычный код.

Про запись через |: это LCEL, способ сборки цепочек из ранних версий LangChain. Он рабочий и никуда не делся, но набор готовых цепочек вынесен в отдельный пакет langchain-classic, а основным строительным блоком в документации стал агент. Так что не удивляйтесь, если в свежих руководствах цепочек почти не встретите — сам приём от этого хуже не стал.

Агент

Агент отличается от цепочки одним: последовательность шагов выбирает модель во время выполнения. Автор кода задаёт, что доступно (инструменты) и когда остановиться, но не задаёт порядок. Именно поэтому в разобранной ранее трассе агент смог после ошибки сходить за структурой таблицы — этот шаг не был предусмотрен заранее.

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

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

Сводная таблица

	Чат-бот	Промпт-цепочка	Агент
Кто определяет следующий шаг	Пользователь в диалоге	Автор кода, до запуска	Модель, во время выполнения
Действия во внешних системах	Нет	Есть, в заданном порядке	Есть, порядок и набор выбирает модель
Вызовов модели на задачу	Один на сообщение	Фиксированное число	Заранее неизвестно, нужен лимит
Реакция на ошибку шага	Отвечает текстом	Падает или идёт по заранее описанной ветке	Видит ошибку и может выбрать другой шаг
Повторяемость	Разный текст ответа	Одинаковый путь, разный текст на шагах с моделью	Путь может отличаться от запуска к запуску

Про память и «обучение на опыте»

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

Отсюда практическое следствие: «агент запомнил» означает «кто-то сохранил это и подставил обратно». Если такого механизма в коде нет, следующий запуск начнётся с чистого листа.

Как выбирать

Рабочий вопрос ровно один: можете ли вы заранее нарисовать последовательность шагов?

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

Когда агент не нужен

Свобода выбирать шаги — не бесплатная опция, а обмен. Разберём, чем именно вы платите, и в каких задачах цена оказывается выше пользы.

Цена

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

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

Непредсказуемость пути

Модель выбирает шаги заново на каждом запуске. Тот же запрос завтра может пойти другим маршрутом: другой запрос к базе, другое число обращений, другой итоговый текст.

Для отладки это означает, что воспроизвести падение по описанию «агент ответил неправильно» не выйдет — нужна трасса конкретного прогона. Для тестов — что проверять придётся не совпадение с эталонным ответом, а свойства результата: сходил ли агент в нужный инструмент, уложился ли в лимит шагов, есть ли в ответе требуемые поля.

Каждый инструмент — это выданное разрешение

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

Поэтому необратимые действия либо не отдают агенту вовсе, либо ставят перед ними подтверждение человеком: агент готовит вызов, человек утверждает. Такая схема называется human-in-the-loop и решает большинство страхов вокруг автономности, не отменяя пользы от агента.

Автономность не означает «работает сам»

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

Автономность здесь означает только одно: между шагами не нужен человек. Сопровождения агент требует не меньше обычного сервиса, а обычно больше.

Где агент не нужен

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

Второе: короткий диалог без действий. Ответить на «как сбросить пароль» — работа чат-бота с поиском по базе знаний. Цикл с инструментами тут просто добавит задержку и стоимость.

Третье: заранее известная последовательность шагов. Если процесс описан как «сделать А, потом Б, потом В», агент лишний: он будет каждый раз заново решать то, что уже решено, и иногда ошибаться в этом.

Четвёртое: среда, где действия запрещены или требуют строгого разграничения прав. Если агенту нельзя дать ни одного инструмента, остаётся модель, отвечающая текстом, — то есть не агент.

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

Правило на каждый день

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