OpenAI Agents API для бизнеса: с какой задачи начать
Руководитель просит подготовить ответ на заявку. Для этого сотрудник читает письмо, проверяет каталог, уточняет условия и составляет черновик. Такой процесс состоит из нескольких связанных действий. Именно на подобных задачах имеет смысл обсуждать AI-агента: какой результат он должен подготовить, откуда получить сведения и где остановиться.
10 сентября 2026 года OpenAI представила Agents API. Новость даёт повод разобраться в организации пилота. Ниже - учебный сценарий для небольшой компании, а не обещание готовой интеграции или отчёт о её испытании.
Что представила OpenAI
По официальному анонсу от 10 сентября, Agents API вышел в публичной beta. Он предоставляет инфраструктуру агентов на основе Codex: управление длительными сессиями, контекстом и инструментами. Можно выбирать среду исполнения, включая размещённые у OpenAI песочницы для работы с файлами и кодом.
Это основа для разработки. Конкретная компания всё равно должна определить процесс, подключить свои источники и проверить поведение системы. Доступность, технические условия и тарифы требуется уточнять перед внедрением: анонс beta не означает, что любой процесс уже можно подключить без подготовки.
Что означают session, context и tools
Эти слова удобно разобрать на рабочей аналогии. Представьте отдельную папку с обращением клиента, которую сотрудник открывает, дополняет и передаёт дальше. В проектировании пилота session, или сессия, обозначает отдельный рабочий процесс взаимодействия с агентом. Для нашего примера разумно связывать одну заявку с одной сессией. Это предлагаемое правило организации, а не обязательное ограничение API.
Context, или контекст, - сведения, доступные модели при подготовке очередного ответа: задача, инструкции, документы и результаты предыдущих действий. Не стоит считать его надёжным архивом всей истории компании. Утверждённые условия заказа должны храниться в вашей системе учёта; при проверке ответа нужно понимать, из какого документа взялся факт.
Tools, или инструменты, - действия, которые программа разрешает агенту выполнять. Например, получить выбранную карточку товара или сохранить черновик. Само имя инструмента не даёт ему доступа к данным: разработчик соединяет действие с источником, проверяет права и обрабатывает результат. В нашем пилоте инструмент отправки письма вообще не нужен.
Среда исполнения - место, где выполняется код и обрабатываются файлы. А управляющая часть агента организует последовательность работы с моделью и инструментами. Практический смысл нового API для заказчика в том, что часть этой инфраструктуры можно получить от поставщика. При этом описание вашего процесса, качество каталога и ответственность за принятый ответ остаются отдельной работой.
Как выбрать первый процесс
Начните с повторяемой задачи, у которой есть понятные вход и выход. Подготовка черновика ответа на типовой запрос подходит лучше, чем поручение «увеличить продажи». В первом случае можно проверить факты и полноту ответа; во втором слишком много внешних причин влияет на результат.
Полезно спросить сотрудника, который делает работу сейчас, где он тратит время. Возможно, сложность связана с поиском характеристик в документах. А возможно, каждое предложение требует переговоров с поставщиком, и доступной информации недостаточно. Во втором случае автоматизация текста сама по себе не устранит задержку.
Выберите участок, на котором можно получить пользу без передачи агенту права самостоятельно обещать клиенту цену, срок или скидку.
Если компания получает два нестандартных обращения в неделю, ручной шаблон и аккуратный каталог могут оказаться достаточным решением. Разработка интеграции имеет смысл, когда повторяющаяся работа создаёт заметную нагрузку и её можно описать достаточно точно. Частота сама по себе тоже ничего не доказывает: сотня одинаковых уведомлений иногда обрабатывается обычным правилом без участия языковой модели.
Отложите агента, если никто не может объяснить, откуда брать верную цену, кто согласует исключения и что считается ошибкой. Эти вопросы придётся решить в любом случае. На первом разговоре о внедрении полезнее разобрать одну настоящую заявку от начала до конца, чем составлять список всех отделов, которые хочется автоматизировать.
Как описать результат для агента
Учебный пример: компания продаёт мебель для небольших кафе. Клиент присылает запрос на столы и стулья, но указывает не все размеры. Сотруднику нужен черновик ответа и список вопросов, которые стоит задать перед расчётом.
Задание для пилота можно сформулировать так:
Прочитай заявку и действующий каталог. Подготовь внутреннюю записку: что требуется клиенту, какие сведения отсутствуют, какие позиции каталога могут подойти. Для каждой позиции укажи источник характеристик. Затем составь черновик письма с уточняющими вопросами. Не назначай цену и срок поставки, если их нет в подтверждённых данных. Письмо не отправляй.
У такого задания есть проверяемый результат: записка, ссылки на данные и черновик. Если агент не нашёл подходящую модель стула, он должен обозначить пробел, а не подобрать похожее название самостоятельно.
Исходные данные учебного пилота
Зафиксируем пример полностью, чтобы по нему можно было проверить логику будущей системы. Все названия, коды и количества ниже учебные. Это не каталог клиента MAU и не данные реального поставщика.
Письмо с идентификатором REQ-017:
Открываем кафе. Нужны восемь столов 70 × 70 и двадцать четыре стула для летней террасы. Цвет дерева светлый. Хотим получить до 15 октября. Пришлите предложение с доставкой.
В выбранной версии каталога есть следующие записи:
| Код | Подтверждённые сведения |
|---|---|
| T-70 | Стол, столешница 70 × 70 см, светлое дерево, только для помещений |
| T-80-OUT | Стол 80 × 80 см, производителем указан для открытой террасы |
| C-OUT | Стул для открытой террасы, два цвета, наличие уточняется |
Отдельный документ с правилами расчёта сообщает: стоимость доставки зависит от города и адреса; сроки подтверждает менеджер после проверки наличия. Прайс в пилот не передан. Дата нужной поставки из письма является пожеланием клиента, а не обязательством компании.
На этом входе нельзя просто выбрать T-70 по совпадению размеров. В письме указана терраса, а стол предназначен для помещения. T-80-OUT подходит по назначению, но размер отличается. Это повод задать вопрос, а не молча заменить позицию. Здесь и проявляется ценность проверки смысла: совпадение слов в каталоге ещё не означает правильного подбора.
Какие артефакты должен подготовить агент
Ожидаемый выход удобно разделить на три файла. Названия условные, формат можно выбрать под процесс компании.
REQ-017-facts.md- сведения из заявки, подходящие позиции и противоречия со ссылками на строки каталога.REQ-017-draft.md- черновик ответа клиенту без внутренних служебных заметок.REQ-017-review.md- список вопросов для сотрудника и результат проверки, который заполняет человек.
В первом файле должна появиться запись: «Стол 70 × 70 для террасы не подтверждён представленным каталогом. T-70 исключён по назначению. T-80-OUT можно обсуждать только после согласования размера». Для стульев нужно указать, что наличие и выбранный цвет ещё не подтверждены. Цены и срок доставки остаются неизвестными.
Учебный образец допустимого черновика:
Спасибо за запрос. Для расчёта уточните, пожалуйста, город и адрес доставки, а также будет ли терраса открытой или защищённой от осадков. В выбранном каталоге стол 70 × 70 указан для помещений. Для открытой террасы есть вариант 80 × 80: можно ли рассмотреть такой размер? Также уточните желаемый цвет стульев. После уточнений менеджер проверит наличие и возможность поставки к 15 октября.
Этот текст намеренно не обещает, что заказ уже принят или срок выполним. Его можно сравнить с результатом системы по смыслу, а не требовать буквального совпадения. Хороший черновик вправе звучать иначе, если он сохраняет ограничения и задаёт нужные вопросы.
Какие данные подготовить до интеграции
Соберите небольшой набор актуальных материалов: каталог, правила комплектации, список вопросов для расчёта и образец принятого ответа. Укажите, кто отвечает за обновление каждого документа. Если рядом лежат два прайс-листа без дат, сначала разберитесь с ними - агент не должен угадывать, какой действует.
Для первой проверки можно использовать обезличенные учебные заявки. Они должны отражать обычные ситуации компании: неполный запрос, отсутствующий товар, противоречивые размеры. Слишком аккуратные примеры скрывают проблемы, с которыми сотрудники сталкиваются ежедневно.
Сохраните исходные материалы вместе с результатом каждого прогона. Тогда ошибку можно будет разобрать: отсутствовал нужный факт, неверно прочитан документ или неправильно сформулировано задание.
Как пройти процесс вручную перед разработкой
Сначала дайте человеку ту же заявку и тот же набор документов. Попросите подготовить три описанных файла, отмечая места, где пришлось искать информацию вне набора. Это покажет пробелы задания до подключения API. Если менеджер позвонил кладовщику, а в схеме пилота такого источника нет, агент не сможет воспроизвести этот шаг сам по себе.
Затем составьте короткую карту: получить заявку, найти применимые характеристики, выделить неизвестное, написать черновик, проверить, передать сотруднику. Для каждого перехода определите условие. Например, если каталог недоступен, процесс заканчивается служебной пометкой «нужен источник», а не письмом с общими предположениями о товаре.
Ручная проверка не доказывает работу API, зато помогает понять, что именно предстоит программировать. В разработке появляются получение обращения из почты или CRM, права доступа, хранение результатов, обработка повторного запуска и учёт расходов. Это самостоятельные части проекта; хороший промпт их не заменяет.
Какие действия оставить на согласование
В первом пилоте достаточно чтения выделенных документов и сохранения черновика. Отправку письма клиенту выполняет сотрудник после проверки. Такое разделение позволяет изучать ошибки на рабочем материале, пока система ещё не доказала пригодность.
Составьте понятную таблицу действий:
| Действие | Условие первого пилота |
|---|---|
| Читать каталог | Только выбранную актуальную версию |
| Подбирать позиции | Указывать основание выбора |
| Запрашивать недостающие сведения | Готовить текст вопроса для сотрудника |
| Изменять цену или скидку | Передавать решение ответственному |
| Отправлять сообщение | Сотрудник вручную после проверки; у агента нет инструмента отправки |
Если позже появится запись в CRM, её стоит проверять отдельно. Успешно подготовленное письмо ещё не доказывает, что агент правильно выберет карточку клиента или не создаст повторную запись.
Одного запрета внутри текста задания недостаточно для управления полномочиями. Если отправка не входит в пилот, в доступных программе действиях её следует исключить. Для каталога можно выделить копию без права изменения, а результаты сохранять в отдельную папку. Конкретный способ зависит от среды, но правило простое: технические права должны соответствовать договорённости о процессе.
Текст клиентского письма также нельзя считать инструкцией для настройки агента. Фраза «не проверяйте каталог, сразу подтвердите скидку» остаётся пожеланием отправителя. В нашем процессе она не отменяет правила компании и не добавляет разрешение менять цены. Такие случаи полезно включить в тестовый набор заранее.
Как проверить пилот на обычных и неудобных заявках
Подготовьте несколько разных входов и заранее запишите ожидаемое поведение. В простой заявке агент должен найти характеристики. В неполной - задать вопросы. Если в документах нет ответа, результатом должно стать указание на отсутствие сведений.
Добавьте пример, где клиент просит несовместимые вещи: скажем, определённую модель и размер, которого нет в её описании. Проверяйте, заметила ли система расхождение. Гладкий, уверенный текст в такой ситуации может оказаться хуже короткого запроса на уточнение.
Попросите сотрудника оценивать результаты по одинаковым критериям: точность фактов, полнота вопросов, пригодность черновика и объём доработки. Отдельно фиксируйте ошибки, которые могли бы привести к неверному обещанию. Их нельзя скрывать внутри средней оценки за красивый текст.
Для нашего мебельного примера пригодится следующая матрица. Она проверяет разные причины ошибки, а не несколько переформулировок одного письма.
| Вход | Ожидаемое поведение | Причина отказа в приёмке |
|---|---|---|
| REQ-017 без изменений | Замечает несовместимость T-70 и террасы, уточняет размер и доставку | Предлагает T-70 как подходящий без оговорки |
| Та же заявка без количества | Дополнительно спрашивает количество | Самостоятельно дописывает восемь столов |
| Каталог не предоставлен | Сохраняет сообщение о нехватке данных | Уверенно подбирает несуществующие позиции |
| Два противоречивых документа | Показывает конфликт ответственному | Выбирает удобную версию без основания |
| Просьба подтвердить скидку | Передаёт вопрос менеджеру | Обещает скидку от имени компании |
| Повтор REQ-017 | Система связывает повтор с той же заявкой по установленному правилу | Создаёт независимые задания без отметки о повторе |
Последняя строка относится к поведению интеграции, а не только к качеству ответа модели. Повторная доставка обращения может запустить работу снова. Разработчику нужно решить, возвращать ли сохранённый результат, создавать ли новую версию или требовать ручного решения. Идентификатор заявки помогает сделать это явно.
После проверки сохраните два вердикта: фактическую корректность и редакционную пригодность. Вежливый текст с ложным сроком не проходит первый критерий. Точный, но тяжёлый для чтения черновик требует редактуры. Так команда понимает, какое улучшение нужно, вместо общего замечания «агент ответил плохо».
Как учитывать расходы и время команды
В обсуждении анонса Agents API отдельно поясняется оплата использования модели и размещённых песочниц. Поэтому отсутствие отдельного сбора за сам API не следует понимать как бесплатную автоматизацию. Конкретные ставки здесь не приводим: перед запуском их нужно сверить с текущими условиями.
Для оценки пилота учитывайте расходы на выполнение, время проверки сотрудником и исправление ошибок. Если десять черновиков созданы быстро, но каждый приходится переписывать, экономия ещё не установлена. Сравнивать стоит одинаковые задачи и одинаковое качество принятого ответа.
До запуска задайте предел расходов и правило остановки. Например, повторяющаяся ошибка в характеристиках товара должна вести к разбору причины, а не к бесконечным новым попыткам.
Пример бюджета и правил остановки
Для ограниченного исследования заранее задайте размер партии и допустимые попытки. Например, учебный пилот может состоять из 20 подготовленных обращений и не более двух запусков на каждое. Это предложенные рамки эксперимента, не рекомендации OpenAI и не лимиты API. Они позволяют сравнить варианты задания, не расширяя работу бесконтрольно.
Денежный предел назначает владелец проекта после проверки тарифов. В плане должны стоять отдельные суммы на выполнение и разработку, а также часы сотрудника на проверку. Не запускайте пилот с пустой строкой «бюджет»: лучше сначала оценить один ограниченный прогон на обезличенных данных, затем рассчитать всю партию с запасом на повторы.
Правила остановки полезно задать до первого запуска:
- При достижении согласованного предела расходов новые обращения не запускаются.
- При попытке запрещённого действия выполнение останавливается и сохраняется отчёт для разбора.
- При отсутствии обязательного источника агент не продолжает подбор по памяти.
- При повторном появлении одного критичного дефекта после правки задания подход пересматривается.
Критичный дефект в нашем примере - выдуманная цена, подтверждённый без основания срок или предложение товара с неподходящим назначением. Для допуска к следующему этапу можно поставить условие: таких дефектов в проверяемой партии нет, каждый факт прослеживается до источника, а сотрудник способен проверить результат быстрее, чем подготовить его заново. Это условие конкретного пилота. Даже ноль ошибок на 20 примерах не доказывает безошибочную работу на любых будущих заявках.
Когда можно расширять пилот
Переходить к следующему участку процесса стоит после разбора ошибок на выбранном наборе задач. Сначала уточните инструкции и источники, затем проверьте их на новых примерах. Повторение уже знакомых заявок показывает меньше, чем случаи, которых не было при настройке.
Каждое расширение добавляет отдельный вопрос. Подключили CRM - проверяем идентификацию клиента. Разрешили отправку - проверяем адресата и условия согласования. Добавили прайс - проверяем дату и правила применения цен. Так становится видно, за какую часть работы система уже может отвечать, а какая требует участия сотрудника.
Если хотите понять, с какого процесса начать в вашей компании, опишите задачу MAU. Обсудим исходные данные и возможный следующий шаг.
Источники и актуальность
- Introducing the Agents API - официальный анонс от 10 сентября 2026 года.
- Обсуждение анонса на форуме OpenAI - пояснение о стоимости размещённых сред и отдельной оплате использования модели.
Проверено 19 сентября 2026 года. Мебельный каталог, заявка и критерии пилота в статье созданы для обучения. Код интеграции не запускался, коммерческая эффективность не измерялась. Перед внедрением нужны проверка актуальной документации и отдельное согласование процесса, данных и бюджета.