Со стороны работа AI-агента может выглядеть почти волшебно.
Вы даёте поручение: «Найди последние новости по искусственному интеллекту, выбери три важные темы и подготовь материал для сайта».
Через некоторое время получаете результат — список публикаций, ссылки на источники и готовый черновик статьи.
Возникает ощущение, будто нейросеть самостоятельно открывала сайты, читала документы, принимала решения и писала текст.
На практике всё устроено гораздо понятнее.
За работой агента стоит программная система, объединяющая языковую модель, инструкции, инструменты и механизм управления действиями.
Разберём её устройство без сложных технических терминов.
Модель — мозг агента, но не его руки
В основе большинства современных AI-агентов находится большая языковая модель — LLM.
Например, модель семейства GPT от OpenAI.
Она получает информацию, анализирует её и определяет, каким должен быть следующий шаг.
Модель может предложить поискать дополнительный источник, подготовить текст или запросить данные из подключённого сервиса.
Но здесь есть принципиальное отличие между принятием решения и выполнением действия.
Сама языковая модель не получает автоматически доступ к вашему компьютеру, электронной почте или интернет-магазину.
Чтобы она могла взаимодействовать с внешними системами, разработчик должен предоставить соответствующие инструменты.
Например, модель может определить, что для ответа необходимо узнать остатки товара на складе.
Она формирует запрос к инструменту получения остатков. Приложение выполняет этот запрос и возвращает результат.
Получив данные, модель продолжает работу.
Именно такой механизм описан в официальной документации OpenAI по Function Calling.
Источник: OpenAI — Function Calling
Существуют и инструменты, выполнение которых обеспечивает сама AI-платформа, например встроенный веб-поиск. Но принцип сохраняется: возможности системы определяются доступными инструментами и правилами их использования.
Инструменты — руки и глаза агента
Представим сотрудника, который умеет анализировать информацию, писать тексты и принимать решения, но у него нет доступа ни к браузеру, ни к рабочим документам.
Польза от такого помощника ограничена.
То же самое происходит с AI-агентом.
Чтобы выполнять реальные задачи, ему необходимы инструменты.
Например, для редакционного помощника Ershov AI они могут выглядеть следующим образом:
| Инструмент | Для чего нужен |
|---|---|
| Веб-поиск | Находить актуальные публикации и первоисточники |
| Поиск по файлам | Работать с редакционными инструкциями и документами |
| Подключение к электронной почте | Получать сообщения и готовить ответы |
| Редакционная база данных | Сохранять темы, источники и черновики |
| Система публикации | Передавать одобренные статьи на сайт |
Это не означает, что одному агенту обязательно нужны все перечисленные возможности.
Наоборот, разумнее давать ему только те инструменты, которые требуются для конкретной задачи.
Если помощник должен собирать новости, ему не нужен доступ к платежам компании.
Если его задача — писать черновики, ему не требуется разрешение удалять опубликованные статьи.
Чем меньше лишних полномочий, тем проще контролировать последствия ошибок.
Как модель вызывает инструмент
Допустим, агенту поручили узнать, сколько определённого товара осталось на складе.
Вместо того чтобы угадывать количество, модель обращается к доступному инструменту, условно названному «Получить остатки».
В запросе она указывает нужный товар.
Приложение проверяет запрос, обращается к системе учёта и возвращает ответ: например, 125 единиц.
Теперь модель использует полученные данные при подготовке отчёта.
Если инструмент вернул ошибку, агент может попытаться повторить запрос в разрешённых пределах или сообщить пользователю, что получить сведения не удалось.
Здесь важно различать три операции:
- Модель решает, какую информацию необходимо получить.
- Программный инструмент обращается к внешней системе.
- Модель обрабатывает возвращённый результат.
Благодаря такому разделению агент может работать с актуальными данными, которых не было в информации, использованной при обучении модели.
Но получение данных из внешней системы ещё не гарантирует их достоверности. Источник может содержать ошибки, устаревшие значения или неполные сведения.
Поэтому агент должен не только собирать информацию, но и учитывать её происхождение.
Память: почему агент не обязан каждый раз начинать сначала
Теперь представим редакционного помощника, который каждый день готовит статьи.
В понедельник вы объяснили ему, что Ershov AI пишет для русскоязычной аудитории, избегает рекламных формулировок и проверяет факты по первоисточникам.
Во вторник дали новое задание.
Должны ли вы повторять все инструкции?
Необязательно. Но для этого приложение должно сохранять необходимые сведения и передавать их модели при следующих обращениях.
Здесь стоит разобраться с двумя понятиями.
Контекст — информация, которую модель получает и использует во время выполнения текущей задачи.
Например, запрос пользователя, редакционные правила, найденные документы и результаты предыдущих действий.
Память — механизм сохранения информации для последующего использования.
Она может включать историю разговоров, настройки пользователя, результаты прошлых задач или отдельные записи в базе данных.
Важно понимать: это не человеческая память.
Модель не обязательно хранит все прошлые разговоры внутри себя. Приложение может сохранять историю и снова предоставлять нужные сведения при очередном запросе.
В OpenAI Agents SDK для этого предусмотрены сессии, позволяющие сохранять историю взаимодействия между запусками агента.
Для Ershov AI полезно разделить информацию на две части.
Первая — постоянные редакционные правила: стиль, требования к источникам, целевая аудитория и структура материалов.
Вторая — история работы: какие темы уже освещены, какие черновики подготовлены и какие публикации одобрены.
Причём историю публикаций надёжнее хранить в редакционной базе данных, а не рассчитывать, что языковая модель самостоятельно вспомнит каждый ранее написанный материал.
Кто управляет последовательностью действий
Мы подошли к самому интересному.
Если агент использует несколько инструментов, кто решает, когда остановиться, когда продолжить поиск и когда подготовить итоговый ответ?
Эту работу выполняет механизм управления процессом, который в технической документации часто называют orchestration — оркестрацией.
Представим редакционную задачу.
Агент получил поручение подготовить материал об обновлении AI-сервиса.
Сначала модель определяет, что необходимо найти официальную публикацию разработчика.
Система вызывает поиск и получает результаты.
Затем модель изучает найденную информацию и обнаруживает, что некоторые характеристики продукта требуют уточнения.
Она может инициировать дополнительный поиск.
Когда информации достаточно, модель переходит к созданию черновика.
После этого приложение сохраняет результат и направляет его редактору.
Получается цикл:
Задача → выбор действия → вызов инструмента → получение результата → оценка ситуации → следующее действие.
Этот цикл может повторяться несколько раз.
В OpenAI Agents SDK предусмотрен механизм выполнения, который управляет взаимодействием модели с инструментами и продолжает процесс до получения итогового результата, остановки или другого предусмотренного условия.
При этом разработчик должен предусмотреть ограничения, например максимальное количество шагов, допустимые расходы и условия прекращения работы.
Иначе агент, столкнувшись с неудачными запросами или противоречивыми данными, может потратить слишком много ресурсов на повторные попытки.
Где в этой системе находится человек
Важный момент: агенту необязательно разрешать выполнение всех действий, которые он способен предложить.
Например, редакционный помощник подготовил статью и определил, что она готова к публикации.
Но решение модели — ещё не разрешение размещать текст на сайте.
Программная система может остановить процесс и отправить материал редактору.
Человек проверяет заголовок, факты, источники и содержание.
Если статья одобрена, выполняется следующий этап — постановка публикации в расписание.
Если редактор нашёл ошибки, материал возвращается на доработку.
Такой механизм называется human-in-the-loop — участие человека в процессе выполнения задачи.
OpenAI предусматривает специальные механизмы одобрения, при которых агентный процесс приостанавливается до разрешения или отклонения чувствительного действия.
Источник: OpenAI — Guardrails and Human Review
Для редакционного конвейера это означает, что можно автоматизировать поиск информации и подготовку текста, не передавая системе право самостоятельно решать, что должно появиться на сайте.
Разберём всю архитектуру на примере Ershov AI
Представим, что мы создаём агента для подготовки ежедневных статей.
Это пример целевой архитектуры, а не описание уже полностью работающей системы.
1. Источник информации. Система получает новую публикацию, заметку автора или транскрипт записи.
2. Инструкции редакции. Агент получает правила: писать понятно, не выдумывать факты, проверять первоисточники и указывать происхождение информации.
3. Языковая модель. Анализирует материал, выбирает тему и определяет, какие сведения необходимо уточнить.
4. Инструменты. Предоставляют доступ к поиску, документам и редакционной базе.
5. Память и состояние процесса. Сохраняют информацию о теме, найденных источниках, подготовленном черновике и его статусе.
6. Черновик. Модель формирует самостоятельный материал с заголовком, структурой и ссылками на источники.
7. Редактор. Проверяет текст и одобряет публикацию либо возвращает материал на доработку.
8. Публикация. После одобрения отдельная система размещает материал на сайте в назначенное время.
Обратите внимание: языковая модель участвует не во всех этапах.
Получение данных по расписанию, хранение статусов и размещение одобренной публикации могут выполняться обычными программными механизмами.
Это позволяет не усложнять систему без необходимости.
Можно ли собрать агента вообще без программирования?
Для простых сценариев — да.
Существуют платформы визуальной автоматизации, которые позволяют связывать источники данных, языковые модели и внешние сервисы через готовые блоки.
Но отсутствие необходимости писать код не означает, что агент не требует настройки.
Всё равно необходимо определить задачу, подключить сервисы, настроить права доступа, проверить обработку ошибок и протестировать результат.
Для более сложных сценариев может потребоваться собственное приложение или участие разработчика.
Впрочем, читателю необязательно сразу выбирать технологическую платформу.
Гораздо полезнее начать с другого вопроса:
Какую конкретную работу я хочу перестать выполнять вручную — и какой результат должен получить вместо неё?
Когда ответ понятен, подобрать инструменты становится значительно проще.
Главное об устройстве AI-агента
У AI-агента нет одного универсального устройства, обязательного для всех проектов. Но большинство практических решений можно понять через несколько основных компонентов.
Языковая модель обрабатывает информацию и помогает выбирать действия. Инструменты позволяют получать данные и взаимодействовать с внешними сервисами. Память и контекст помогают учитывать предыдущую информацию. Программный механизм управляет выполнением задачи, а ограничения и проверки определяют, какие действия разрешены.
Именно взаимодействие этих компонентов превращает обычный запрос к нейросети в многоэтапный рабочий процесс.
При этом архитектура сама по себе не обеспечивает надёжность.
Агент может получить неточные сведения, неправильно выбрать инструмент или сделать неверный вывод из вполне достоверного документа.
Следующий практический вопрос — как агент переходит от ответа к реальному действию, что происходит при ошибке и как проверить, что поручение действительно выполнено.