Decisions API вышла из беты: как создать ИИ-агента, который сначала выбирает шаг

Заявка ещё не разобрана, а агент уже пишет клиенту длинное письмо. Нужен был другой ответ: продолжать, переспросить человека или остановиться. Мы долго просили рабочую модель решить это "заодно" и каждый раз получали абзац вместо выбора. 22 октября Decisions API вышла из беты: классификация, маршрутизация и оценка по рубрике идут отдельным вызовом GPT-6 Luna и не требуют обычного текста модели. Для создания ИИ-агента это экономит шаг - развилка больше не обязана притворяться письмом.
Что такое ИИ-агент на одном шаге
Заказчик спрашивает об этом раньше, чем приносит описание процесса. Отвечаем не определением, а одним шагом. На входе заявка, счёт или короткая переписка. На выходе одно из действий, которые назвали заранее.
Пока выбор сидит внутри длинной генерации, модель успевает сочинить черновик даже там, где верный шаг - остановиться. Черновик жалко выбрасывать, и его отправляют. Потом разбираем не ошибку маршрута, а тон письма.
Decisions API черновик не пишет. Тип ответа задаётся явно: probability, choice или score. Это вероятность, выбор из списка или балл по рубрике. На вход идёт текст, изображение или JSON. В одном запросе до 400 вопросов, в бете лимит был 200. Модель у вызова одна - gpt-6-luna.
OpenAI сравнивает его с GPT-6 Luna через Responses API и пишет, что вызов до 10 раз быстрее. Цена - $0,10 за 1 млн входных токенов и $0,01 за 1 млн кэшированных. За выходные токены платы нет: наружу уходит не сочинение, а ответ из заданного множества.
С беты появились кэш инструкции, картинка в формулировке отдельного вопроса, связка с GPT-Live и размещение вычислений в США и ЕС. Если развилка смотрит на скан или на уже собранный JSON, это как раз её место. Письмо она всё равно не напишет.
Один знакомый шаг вместо всего контура
Весь процесс на новый вызов переносить не нужно. Возьмите шаг, на котором люди уже спорят: агент должен был остановиться, а пошёл дальше. В песочнице Decisions задайте choice из трёх исходов - продолжить, переспросить человека, остановиться. Тот же вопрос задайте обычным ответом модели.
Сравнивайте не складность фразы, а паузу и то, уложился ли результат в список. Затем прогоните несколько своих примеров, включая кривые: пустое вложение, два противоречивых поля, заявка не о том. Если выбор стабильно совпадает с тем, что сделал бы старший сотрудник, развилку можно отделять от генерации. Если плавает, исходы названы слишком широко. Скорость вызова тут ни при чём.
Первый подход у нас был "всё в одном запросе": и решение, и черновик. Модель почти всегда склонялась продолжить - текст уже лежал в ответе, и его хотелось оправдать. Отдельный вызов с закрытым списком этот соблазн убирает. Создание ИИ-агента после такого разреза короче: дорогая модель включается только на ветке "продолжить".
Где вызов честно бесполезен
Открытый текст, план и черновик документа этот вызов не заменяет. Письмо клиенту, разбор условий, справка для руководителя - обычный ответ модели. Он стартует после развилки, не вместо неё.
Режим без хранения данных есть не у всех клиентов API. Для российского контура это не сноска. Заявки, счета и переписка часто попадают под 152-ФЗ, и удобная цена вызова закон не отменяет. Мы не отправляем такой пакет наружу только потому, что развилка там уже собрана.
Замеры заказчиков в анонсе - их собственные цифры, не общий бенчмарк. "До 10 раз быстрее" - сравнение вендора с Responses API, а не обещание на вашем процессе. Лимит в 400 вопросов легко забить впрок. Тогда развилка снова становится простыней, только без связного текста.
Один шаг - один понятный choice. Балл и вероятность уместны там, где цифру потом смотрит человек. Где агент действует молча, лишняя шкала только прячет решение.
Что меняется в ИИ-агентах для бизнеса
Схему стоит забрать, даже если сам Decisions API в контур не войдёт. Ломаются такие агенты чаще не на красивом тексте, а на шаге, где надо было выбрать действие и промолчать.
Список исходов пишем до инструкции. Хватает трёх или четырёх, не двадцати. Шаг выбора не пишет клиенту и не вызывает инструменты, которые меняют учёт. В журнал кладём ветку, а не пересказ модели. Полный ответ, план или правка документа стартуют, только если исход - "продолжить". "Переспросить" уходит человеку вместе с уже собранным контекстом. "Остановиться" считаем нормальным итогом и не лечим повторным запросом.
Если данные нельзя вывозить, ту же развилку собираем внутри контура: короткий вызов с жёстким форматом, российская модель или отдельный классификатор, и только потом рабочая модель. Модель на выборе и модель на тексте лучше не склеивать. Иначе снова выйдет один дорогой ответ, который "заодно решил".
Дешевизна входа здесь вторична. Лишнее письмо клиенту обходится дороже, чем $0,10 за миллион токенов на развилке. Хватает одного знакомого шага и трёх заранее названных исходов. Если закрытый список не описывает работу, отделять развилку рано: сначала договоритесь, какие действия вообще допустимы.
Какой исход на следующем шаге ваш агент имеет право взять сам, а какой обязан отдать человеку?
Похожие статьи
- GitHub Agentic Workflows в общем доступе: разработка ИИ-агентов начинается с текста, а не с YAML
- n8n 3.0 убирает старые режимы AI Agent: создание ИИ-агента придётся собрать заново
- Яндекс ИИ-агент на старом URI: Yandex AI Studio отключит модели, подмены не будет
- Agent Builder отключат 30 ноября: заберите сценарий в код, пока он ещё вызывается
