Как устроены ИИ-агенты:
инструменты, память и участие человека

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

Сквозной пример

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

1. Workflow, агент и граф: кто выбирает следующий шаг

Главное различие — кто определяет порядок действий. В workflow путь задан заранее в коде: получить список поставщиков, собрать прайсы, посчитать, оформить таблицу. В агенте модель на каждом шаге сама выбирает следующее действие с учётом уже полученных результатов (LangGraph: workflows и агенты).

Граф — не третий конкурирующий продукт, а способ описать процесс как набор шагов (узлов) и переходов между ними, в том числе условных. В одном графе могут соседствовать жёстко заданные участки и участок, где действует агент. Название LLMChain из старых учебных материалов относится к ранним интерфейсам LangChain; это не обязательная технология для современного workflow.

В нашем примере сбор прайсов с известных и однотипных сайтов можно сделать обычным workflow. Агент нужен там, где путь заранее неясен: у одного поставщика цена в PDF-файле, у другого только в форме запроса, у третьего страница явно устарела.

2. ReAct: действие, наблюдение, следующий шаг

ReAct — метод, в котором модель чередует рассуждение о задаче и действия во внешней среде, а результат каждого действия (наблюдение) учитывается на следующем шаге (Yao и др., ReAct). Например: «нужна цена поставщика Б» → поиск по его сайту → найдена страница, где цена указана без НДС → прежде чем сравнивать, нужно привести её к общей базе.

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

Современный агент в LangChain устроен как цикл «модель — инструменты» с обвязкой: инструкциями, набором инструментов и промежуточными обработчиками (middleware). Модель лишь запрашивает вызов инструмента — выполняет его приложение (LangChain: агенты). Это значит, что надёжность определяется не только моделью, но и тем, что приложение разрешает и как обрабатывает ошибки.

3. Память: разговор, долгосрочные сведения и RAG

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

Полезно различать три вещи:

• Краткосрочная память — состояние текущего разговора или задачи: сообщения, промежуточные результаты, вызовы инструментов.
• Долгосрочная память — сведения, которые приложение решило сохранить между разными разговорами, например что компания всегда сравнивает цены с НДС. В LangGraph состояние отдельного потока работы хранит checkpointer, а сведения, общие для разных потоков, — отдельное хранилище (store), содержимое которого определяет само приложение (LangGraph: persistence).
• RAG — поиск по источникам (документам, базам) и передача найденных фрагментов модели. Это извлечение знаний, а не память о диалоге; подробнее — в статье о RAG для базы знаний компании.

Инструкция в промпте «помни всё» хранилища не создаёт.

4. Инструменты, API и проверка формата данных

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

Модель формирует параметры вызова и может ошибиться: пропустить обязательное поле или передать значение не того типа. Здесь помогает описание данных по схеме, например с помощью библиотеки Pydantic для Python. Условно (это псевдокод, а не готовая интеграция):

ЗапросЦены:
  поставщик  — текст, обязательно
  артикул    — текст, обязательно
  количество — целое число больше нуля
  валюта     — одно из: RUB, USD, CNY

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

5. Уточнение, декомпозиция и независимая проверка

Уточнение. Запрос «сравни поставщиков» неполон: входит ли доставка в цену, какая партия, с НДС или без? Хорошая система спрашивает только о том, что действительно меняет результат, а очевидное определяет сама.

Декомпозиция. Большая задача делится на проверяемые шаги: список поставщиков → сбор условий со ссылками → приведение к общей базе (единица, валюта, налог) → расчёт → таблица → черновик письма. Каждый шаг можно проверить отдельно и увидеть, где именно возникла ошибка.

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

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

6. Состояние, контрольные точки и повторное выполнение

Состояние (state) — общее рабочее пространство процесса: какие поставщики уже обработаны, какие цены найдены, какие ссылки сохранены. Checkpointer записывает это состояние по ходу выполнения, привязывая его к идентификатору потока работы. После сбоя или паузы процесс можно продолжить с сохранённого места, а не начинать заново (LangGraph: persistence).

Две детали часто упускают. Сохранение в оперативной памяти (in-memory saver) годится для экспериментов, но не переживает остановку процесса: для настоящего восстановления нужны постоянное хранилище и стабильный идентификатор потока. И контрольная точка сама по себе не гарантирует, что действие выполнится ровно один раз. Если шаг успел отправить письмо, а сбой произошёл до сохранения состояния, при повторе письмо может уйти снова.

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

7. Человек в процессе: где нужна остановка

Human-in-the-loop — возможность приостановить процесс и запросить у человека данные или решение. В LangGraph для этого есть interrupt: граф останавливается, а после ответа продолжается командой возобновления с тем же потоком и тем же checkpointer (LangGraph: interrupts). Важная техническая деталь: при возобновлении узел, в котором стояла остановка, запускается с начала, поэтому код перед точкой остановки может выполниться повторно. Размещать там отправку письма без защиты от повтора нельзя.

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

8. Промпт и контекст

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

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

Как это работает вместе

Условная последовательность для нашего примера:

1. Менеджер ставит задачу; система уточняет только существенное — партию, учёт НДС и доставки.
2. Граф запускает сбор условий; на участках с непредсказуемыми источниками действует агент в цикле «действие — наблюдение».
3. Параметры каждого вызова проходят проверку формата, а найденные цифры сохраняются в состоянии вместе со ссылками.
4. Полную стоимость считает код, а не текстовый ответ модели; результаты сверяются с источниками.
5. Пробелы помечаются как «нет данных»; число доработок ограничено.
6. Граф останавливается: менеджер видит таблицу, источники и черновик письма.
7. Только после одобрения письмо отправляется — с защитой от повторной отправки.

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