Представьте предпринимателя, который каждое утро начинает день одинаково.

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

На всё это уходит время. При этом значительная часть работы повторяется изо дня в день.

Предприниматель решает воспользоваться ChatGPT.

Он копирует данные о продажах, вставляет их в чат и просит:

«Проанализируй вчерашние продажи, сравни с предыдущим днём и скажи, на что обратить внимание».

Через некоторое время получает структурированный ответ: показатели, изменения, возможные проблемы и рекомендации.

Это полезно. Но на следующий день всё начинается заново.

Нужно открыть нужные сервисы, получить свежие цифры, перенести их в ChatGPT, объяснить задачу и дождаться результата.

И здесь возникает вполне логичный вопрос:

А почему искусственный интеллект не может проделать всю эту работу самостоятельно?

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

Именно для решения таких задач применяют AI-агентов.

От ответов к действиям

Привычный сценарий работы с нейросетью выглядит просто:

Человек задаёт вопрос → модель формирует ответ → человек решает, что делать дальше.

Например, пользователь спрашивает ChatGPT, как написать деловое письмо.

Нейросеть составляет текст. Пользователь копирует его, открывает почту, вставляет адрес получателя и отправляет сообщение.

Теперь представим другую ситуацию.

Система подключена к электронной почте и имеет разрешение создавать черновики. Пользователь просит:

«Найди последнее письмо поставщика, подготовь ответ с уточнением сроков доставки и покажи мне перед отправкой».

Вместо одного текстового ответа система может выполнить последовательность действий:

1. Найти письмо в подключённом почтовом ящике.
2. Прочитать содержание и связанный контекст переписки.
3. Подготовить ответ с учётом полученной информации.
4. Создать черновик письма.
5. Передать его пользователю для проверки.

Пользователю остаётся оценить результат и принять решение об отправке.

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

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

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

Почему об агентах стали говорить так много

Большие языковые модели, или LLM (Large Language Models), изначально получили широкую известность благодаря способности работать с текстом: отвечать на вопросы, переводить, писать, сокращать и объяснять информацию.

Постепенно область их применения расширилась.

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

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

Например, системе поручили подготовить обзор изменений законодательства на основе официальных публикаций.

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

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

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

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

Источник: OpenAI — A Practical Guide to Building Agents

Не нужно автоматизировать всё подряд

Здесь легко попасть в ловушку.

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

Но сложность сама по себе не делает систему полезнее.

Допустим, предпринимателю нужно ежедневно в 9:00 получать вчерашнюю выручку из одной базы данных.

Если для этого достаточно обычного запроса к базе и отправки сообщения, языковая модель вообще может не понадобиться.

Зачем подключать дополнительные инструменты, расходовать деньги на обращения к ИИ и создавать новые возможности для ошибок?

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

Разработчики Anthropic в своём инженерном руководстве Building Effective Agents рекомендуют начинать с самого простого решения, которое справляется с задачей, и увеличивать сложность только при необходимости.

Источник: Anthropic — Building Effective Agents

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

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

Первоисточник ↗

Начнём с простого определения.

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

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

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

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

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

Источник: OpenAI — Building Agents

Чат-бот, автоматизация и агент — в чём разница

Представим, что мы создаём небольшое интернет-издание об искусственном интеллекте.

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

Одну и ту же работу можно организовать тремя способами.

Вариант первый. Обычный чат-бот

Редактор находит интересную публикацию, копирует её содержание и отправляет в ChatGPT:

«Изучи этот текст и подготовь краткую статью на русском языке. Укажи главные факты и объясни их простыми словами».

Модель выполняет запрос и возвращает текст.

Редактор проверяет его, исправляет неточности и решает, публиковать ли материал.

Здесь искусственный интеллект участвует в работе, но не управляет процессом целиком.

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

Это пример использования чат-бота в качестве помощника.

Вариант второй. Обычная автоматизация с ИИ

Теперь представим, что мы настроили регулярный процесс.

Программа каждый день проверяет заданный источник. Когда там появляется новый материал, она передаёт его текст в OpenAI, получает черновик и сохраняет его в редакционной системе.

Последовательность заранее определена:

Новая публикация → передача текста в модель → подготовка черновика → сохранение результата.

Вся цепочка может выполняться без участия человека.

Но это ещё не обязательно AI-агент.

Почему?

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

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

Нейросеть отвечает только за конкретную операцию — например, за подготовку текста.

Такую систему правильнее назвать автоматизированным редакционным процессом с использованием ИИ.

И это не недостаток. Для многих задач именно такой вариант оказывается наиболее удобным.

Вариант третий. AI-агент

Теперь усложним задачу.

Редактор даёт системе инструкцию:

«Каждое утро изучай новые публикации из разрешённого списка источников. Выбирай темы, важные для предпринимателей. Проверяй ключевые утверждения по первоисточникам. Если информации недостаточно, проведи дополнительный поиск. Подготовь один черновик и передай мне на утверждение. Ничего не публикуй самостоятельно».

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

Например:

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

Это уже пример агентного подхода.

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

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

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

Сравним три подхода

Это упрощённое сравнение. Границы между подходами не всегда строгие.

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

Точно так же сложная система может сочетать заранее заданные шаги с отдельными агентными этапами.

Значит ли это, что агент работает без человека?

Нет.

Самостоятельность AI-агента не означает отсутствие контроля.

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

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

Представим агента, который помогает обрабатывать письма покупателей интернет-магазина.

Ему можно разрешить самостоятельно классифицировать обращения и готовить ответы.

Но возврат денежных средств, изменение заказа или отправку важного официального письма разумно вынести на отдельное подтверждение.

При этом одного текстового запрета вроде «не возвращай деньги самостоятельно» недостаточно для надёжной защиты. Критически важные ограничения должны обеспечиваться самой программой: проверкой разрешений и подтверждением действий на уровне инструментов.

Практический пример: редакция Ershov AI

В Ershov AI мы используем эту логику для построения редакционного процесса.

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

Базовая схема выглядит так:

Источник → OpenAI → черновик → проверка редактором → одобрение → публикация по расписанию.

В Ershov AI уже работают сбор официальных релизов, подготовка черновиков через OpenAI, редакторская проверка и публикация одобренных материалов по расписанию. При этом свободный выбор тем и самостоятельная проверка фактов агентом пока не реализованы. Подготовка новых черновиков зависит от работающего генератора на Mac владельца.

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

Однако финальное решение о публикации останется за человеком.

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

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

Именно так проще проверить пользу технологии, обнаружить ошибки и сохранить контроль над результатом.

Первоисточник ↗

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

Не «напиши мне письмо», а «изучи переписку с поставщиком, выясни, какие вопросы остались без ответа, и подготовь письмо для согласования».

Не «объясни, почему упали продажи», а «собери данные за последние семь дней, найди товары с заметным снижением продаж и подготовь отчёт с возможными причинами».

Звучит привлекательно. Но между такой постановкой задачи и её реальным выполнением есть важное условие: агент должен иметь доступ к необходимым данным и инструментам.

Без подключения к почте он не прочитает письма. Без доступа к системе продаж не получит свежие показатели. Без возможности сохранять документы не создаст отчёт в нужном сервисе.

Разберём несколько сценариев, в которых агентный подход может быть полезен.

Сценарий 1. Личный помощник для почты и повседневных задач

Начнём с самого понятного примера — электронной почты.

Предположим, каждый день вам приходят десятки писем. Среди них счета, уведомления, рабочая переписка и рекламные рассылки.

Проверять всё вручную неудобно, но полностью доверить нейросети общение от своего имени тоже не хочется.

Можно организовать промежуточный вариант.

Задача агенту:

«Каждое утро просматривай новые письма, выделяй важные, сообщай, где от меня требуется решение, и готовь черновики ответов. Ничего не отправляй без подтверждения».

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

Например, вместо просмотра двадцати писем пользователь получает короткую сводку:

• Поставщик ожидает подтверждения заказа.
• По одному из счетов приближается срок оплаты.
• Клиент запросил документы.
• На два письма подготовлены черновики ответов.

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

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

Особенно важно не позволять системе самостоятельно отправлять конфиденциальные сведения, подтверждать финансовые обязательства или переходить по подозрительным инструкциям из входящих писем.

Сценарий 2. Исследователь, который собирает информацию

Допустим, предприниматель собирается выйти на новый рынок.

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

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

А можно поручить агенту подготовительную часть исследования.

Задача агенту:

«Найди официальные требования к продаже выбранного товара в Мексике, собери ссылки на действующие документы и подготовь список вопросов, которые нужно проверить перед запуском».

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

В документации OpenAI предусмотрено использование веб-поиска для получения актуальной информации и ответов со ссылками на источники.

Источник: OpenAI — Web Search

Но здесь нужно различать поиск информации и подтверждение её достоверности.

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

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

Для юридически и финансово значимых решений его выводы необходимо проверять отдельно.

Сценарий 3. Помощник интернет-магазина

Теперь рассмотрим более сложную задачу.

Предприниматель продаёт товары на нескольких маркетплейсах. Ему необходимо следить за выручкой, остатками, рекламными расходами и состоянием карточек товаров.

Обычно эти данные находятся в разных разделах и системах.

Агенту можно поручить их первичный анализ.

Задача агенту:

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

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

Дальше работа может выглядеть следующим образом.

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

Важно: агент может обнаружить взаимосвязь, но это ещё не означает, что он установил причину.

Допустим, продажи упали одновременно с сокращением рекламных показов. Это повод проверить влияние рекламы, а не доказательство того, что снижение вызвано исключительно ею.

Что лучше оставить человеку?

Изменение цен, запуск рекламных кампаний, перераспределение существенных бюджетов и подтверждение крупных поставок.

Агент может подготовить предложения, показать расчёты и объяснить возможные последствия. Но принимать финансово значимые решения без ограничений — неоправданный риск.

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

Сценарий 4. Работа с клиентскими обращениями

Представим интернет-магазин, в который постоянно поступают похожие вопросы.

Покупатели уточняют сроки доставки, правила возврата, характеристики товаров и статус заказа.

Для простых вопросов часто достаточно обычного чат-бота с базой готовых ответов.

Но бывают ситуации сложнее.

Например, клиент сообщает, что заказ доставлен не полностью, и требует возврата денег.

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

Здесь агентный подход может оказаться полезным.

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

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

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

Источник: OpenAI — A Practical Guide to Building Agents

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

Сценарий 5. Документы, договоры и внутренняя база знаний

Ещё одна область применения — работа с большими объёмами документов.

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

Сотруднику нужно найти ответ на вопрос, который может быть описан сразу в нескольких документах.

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

Агент с поиском по файлам может находить подходящие фрагменты, сопоставлять их и готовить ответ со ссылками на документы.

Например:

«Сравни условия возврата товара в действующих правилах компании и в договоре с конкретным поставщиком. Покажи различия и укажи соответствующие пункты».

OpenAI предоставляет инструмент File Search, позволяющий модели искать информацию в предварительно загруженной базе файлов.

Источник: OpenAI — File Search

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

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

Сценарий 6. Редакция, которая готовит материалы

Вернёмся к примеру нашего медиа Ershov AI.

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

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

Часть этой работы можно организовать с помощью автоматизации, а часть — поручить AI-агенту.

Например, система получает новую публикацию разработчика AI-продукта.

Вместо немедленного пересказа агент может сначала определить, подходит ли тема аудитории издания.

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

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

На этом этапе система останавливается.

Человек проверяет текст, исправляет ошибки, определяет, соответствует ли статья редакционным стандартам, и принимает решение о публикации.

Для Ershov AI такой процесс особенно важен: мы не хотим превращать редакцию в поток автоматически переписанных чужих материалов.

Наша цель — использовать AI для обработки информации, сохраняя самостоятельность материалов, проверяемость фактов и ответственность редактора.

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

Какие задачи лучше не поручать агенту самостоятельно

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

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

Например:

Здесь важно не только написать в инструкции «спрашивай разрешение».

Если действие критично, техническая система должна действительно останавливать его выполнение до подтверждения.

Например, OpenAI Agents SDK поддерживает механизм human-in-the-loop: выполнение приостанавливается перед чувствительной операцией, после чего приложение получает решение человека — разрешить действие или отклонить его.

Источник: OpenAI — Guardrails and Human Review

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

Как понять, подходит ли ваша задача для агента

Чтобы оценить идею, полезно задать себе несколько вопросов.

Первый: задача действительно повторяется?

Если действие нужно выполнить один раз, возможно, проще сделать его непосредственно в ChatGPT. Но если одинаковая работа возникает ежедневно или еженедельно, её автоматизация уже заслуживает внимания.

Второй: требуется ли принимать решения по ситуации?

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

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

Третий: можно ли проверить результат?

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

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

Четвёртый: что произойдёт, если агент ошибётся?

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

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

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

Пятый: не будет ли автоматизация сложнее самой задачи?

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

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

Один агент или целая команда?

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

Такая архитектура возможна, но совершенно необязательно начинать именно с неё.

OpenAI рекомендует постепенно увеличивать сложность агентных систем. Для многих процессов достаточно одного агента с несколькими понятными инструментами.

Источник: OpenAI — A Practical Guide to Building Agents

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

А уже после проверки полезности добавлять новые возможности.

Главное, что стоит запомнить: хороший AI-агент — не тот, которому разрешили делать всё. Хороший агент — тот, которому поручили конкретную работу, дали необходимые инструменты и установили понятные границы.

Первоисточник ↗

Со стороны работа AI-агента может выглядеть почти волшебно.

Вы даёте поручение: «Найди последние новости по искусственному интеллекту, выбери три важные темы и подготовь материал для сайта».

Через некоторое время получаете результат — список публикаций, ссылки на источники и готовый черновик статьи.

Возникает ощущение, будто нейросеть самостоятельно открывала сайты, читала документы, принимала решения и писала текст.

На практике всё устроено гораздо понятнее.

За работой агента стоит программная система, объединяющая языковую модель, инструкции, инструменты и механизм управления действиями.

Разберём её устройство без сложных технических терминов.

Модель — мозг агента, но не его руки

В основе большинства современных AI-агентов находится большая языковая модель — LLM.

Например, модель семейства GPT от OpenAI.

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

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

Но здесь есть принципиальное отличие между принятием решения и выполнением действия.

Сама языковая модель не получает автоматически доступ к вашему компьютеру, электронной почте или интернет-магазину.

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

Например, модель может определить, что для ответа необходимо узнать остатки товара на складе.

Она формирует запрос к инструменту получения остатков. Приложение выполняет этот запрос и возвращает результат.

Получив данные, модель продолжает работу.

Именно такой механизм описан в официальной документации OpenAI по Function Calling.

Источник: OpenAI — Function Calling

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

Инструменты — руки и глаза агента

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

Польза от такого помощника ограничена.

То же самое происходит с AI-агентом.

Чтобы выполнять реальные задачи, ему необходимы инструменты.

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

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

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

Если помощник должен собирать новости, ему не нужен доступ к платежам компании.

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

Чем меньше лишних полномочий, тем проще контролировать последствия ошибок.

Как модель вызывает инструмент

Допустим, агенту поручили узнать, сколько определённого товара осталось на складе.

Вместо того чтобы угадывать количество, модель обращается к доступному инструменту, условно названному «Получить остатки».

В запросе она указывает нужный товар.

Приложение проверяет запрос, обращается к системе учёта и возвращает ответ: например, 125 единиц.

Теперь модель использует полученные данные при подготовке отчёта.

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

Здесь важно различать три операции:

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

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

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

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

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

Теперь представим редакционного помощника, который каждый день готовит статьи.

В понедельник вы объяснили ему, что Ershov AI пишет для русскоязычной аудитории, избегает рекламных формулировок и проверяет факты по первоисточникам.

Во вторник дали новое задание.

Должны ли вы повторять все инструкции?

Необязательно. Но для этого приложение должно сохранять необходимые сведения и передавать их модели при следующих обращениях.

Здесь стоит разобраться с двумя понятиями.

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

Например, запрос пользователя, редакционные правила, найденные документы и результаты предыдущих действий.

Память — механизм сохранения информации для последующего использования.

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

Важно понимать: это не человеческая память.

Модель не обязательно хранит все прошлые разговоры внутри себя. Приложение может сохранять историю и снова предоставлять нужные сведения при очередном запросе.

В OpenAI Agents SDK для этого предусмотрены сессии, позволяющие сохранять историю взаимодействия между запусками агента.

Источник: OpenAI — Sessions

Для Ershov AI полезно разделить информацию на две части.

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

Вторая — история работы: какие темы уже освещены, какие черновики подготовлены и какие публикации одобрены.

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

Кто управляет последовательностью действий

Мы подошли к самому интересному.

Если агент использует несколько инструментов, кто решает, когда остановиться, когда продолжить поиск и когда подготовить итоговый ответ?

Эту работу выполняет механизм управления процессом, который в технической документации часто называют orchestration — оркестрацией.

Представим редакционную задачу.

Агент получил поручение подготовить материал об обновлении AI-сервиса.

Сначала модель определяет, что необходимо найти официальную публикацию разработчика.

Система вызывает поиск и получает результаты.

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

Она может инициировать дополнительный поиск.

Когда информации достаточно, модель переходит к созданию черновика.

После этого приложение сохраняет результат и направляет его редактору.

Получается цикл:

Задача → выбор действия → вызов инструмента → получение результата → оценка ситуации → следующее действие.

Этот цикл может повторяться несколько раз.

В OpenAI Agents SDK предусмотрен механизм выполнения, который управляет взаимодействием модели с инструментами и продолжает процесс до получения итогового результата, остановки или другого предусмотренного условия.

Источник: 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-агента нет одного универсального устройства, обязательного для всех проектов. Но большинство практических решений можно понять через несколько основных компонентов.

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

Именно взаимодействие этих компонентов превращает обычный запрос к нейросети в многоэтапный рабочий процесс.

При этом архитектура сама по себе не обеспечивает надёжность.

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

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

Первоисточник ↗