OpenAI Agents SDK позволяет собрать маршрут поддержки, где агент читает обращение, вызывает разрешённые инструменты, передаёт сложный вопрос специалисту и готовит запись в CRM к подтверждению человеком. SDK ведёт цикл вызовов и переходов между агентами, а сервер компании отвечает за права, факты клиента и окончательную запись. Такой контур подходит для обращений с разными правилами обработки, когда итоговое действие должно оставаться проверяемым.
Маршрут обращения
Официальная документация OpenAI Agents SDK описывает агентный цикл, инструменты, handoff, guardrails и tracing. Для поддержки разделите ответ клиенту, передачу вопроса специалисту и запись в CRM на разные решения.
На входе есть текст обращения, идентификатор диалога и доступный сотруднику контекст. Агент маршрутизации определяет намерение и запрашивает данные только через функции, которые разрешены для текущего сценария. Ответ о статусе заказа опирается на запись учётной системы, а спор о возврате может потребовать передачи человеку. Подготовленный текст сохраняет ссылку на источник факта, чтобы оператор мог сверить его перед отправкой.
Статья про Responses API рассматривает отдельный вызов и ручное управление состоянием приложения. В SDK Runner ведёт цикл работы агента, включая вызовы инструментов и handoff; это подтверждает руководство OpenAI по Agents SDK. Разница важна при нескольких ответственных: маршрут поддержки должен помнить, какой агент владеет текущим ходом, какое действие запрошено и где требуется человеческое решение.
- Триаж различает справочный вопрос, запрос по заказу и обращение с риском ошибки или жалобой.
- Специалист по заказам получает лишь нужные инструменты чтения и ограниченный контекст обращения.
- Человек подтверждает содержание ответа и предложение изменить CRM при спорных данных.
- Сервер сохраняет результат маршрута, статус подтверждения и связь с исходным обращением.
Для общего устройства агентных процессов есть разбор вызова инструментов агентом. Здесь разобран конкретный маршрут поддержки: связь нескольких ролей и защита записи в CRM на последнем шаге.
Инструменты по ролям
Инструмент в SDK представляет функцию приложения, доступную агенту через описанную схему аргументов. Для поддержки начните с чтения базы знаний, поиска заказа и создания черновика изменения CRM. Разделите инструменты чтения и записи: такой состав даёт ясную границу между получением факта и изменением клиентской карточки. Названия функций должны описывать бизнес-действие. Типы входных полей проверяет сервер.
| Действие | Что возвращает функция | Кто принимает решение |
|---|---|---|
| Поиск правила | Выдержку из действующей базы знаний и ссылку | Оператор сверяет применимость правила |
| Статус заказа | Поля из записи с идентификатором источника | Оператор сверяет соответствие обращению |
| Черновик CRM | Предложенные поля и причину изменения | Сотрудник проверяет факты и текст |
| Запись CRM | Результат серверной операции с идентификатором | Сервер проверяет роль и подтверждение |
В документации инструментов SDK функция приложения описана как function tool, вызываемый во время агентного цикла. Реализацию поиска и записи делает ваш сервер. Для функции записи задайте допустимые поля, запретите произвольную смену владельца карточки и передавайте точный идентификатор записи. Проверки прав и подтверждения выполняются в серверном обработчике, даже если агент получил текстовую инструкцию действовать осторожно.
Если обращение содержит большие выгрузки, парсер или скрипт извлекает нужные строки и сверяет идентификаторы. Языковая модель объясняет найденные различия и предлагает гипотезы; сотрудник сопоставляет вывод с первичными записями. Так агент получает короткий проверенный факт для ответа, а полная выгрузка остаётся в управляемом контуре.
Передача и проверки
Handoff передаёт управление другому агенту, например специалисту по сложным заказам. В официальном описании handoff этот переход оформлен как доступный агенту инструмент. Передачу полезно сопровождать краткой причиной, ссылкой на проверенные факты и указанием на ожидаемое следующее действие. Получатель должен видеть достаточный контекст, а приложение сохраняет владельца текущего шага.
- Проверьте входное обращение на допустимый тип задачи и наличие идентификатора диалога.
- Разрешите агенту чтение только нужных источников и соберите ответ с привязкой к фактам.
- При спорном запросе выполните handoff назначенному специалисту вместе с причиной и подтверждённым контекстом.
- Перед каждым вызовом функции записи проверьте аргументы, роль пользователя и текущее состояние CRM на сервере.
Документация guardrails различает проверку первого входа, конечного ответа и отдельных вызовов function tools. В цепочке с handoff входная проверка первого агента действует только на исходное обращение. Для каждого защищаемого вызова function tool настройте tool guardrail перед выполнением. Серверная авторизация всё равно остаётся обязательной, поскольку право менять CRM зависит от текущего пользователя и самой записи.
Для передачи с аргументами отдельная проверка полномочий выполняется до побочного действия в обработчике handoff. Это позволяет остановить переход по неверным данным. В материале о безопасности ИИ-агентов подробнее разобраны права и проверка инструментов; здесь они привязаны к конкретному маршруту поддержки.
Подтверждение CRM
Запись в CRM вынесите за отдельную границу. Агент готовит черновик изменения: целевую карточку, исходное значение, предлагаемое значение и основание. Оператор сверяет каждое поле с обращением и записью учётной системы, затем подтверждает конкретное действие. Изменение выполняет сервер после повторной проверки роли, состояния карточки и действительности подтверждения.
Документация SDK о человеческом подтверждении описывает паузу вызова инструмента, для которого задано подтверждение, и продолжение запуска после решения человека. Этот механизм подходит для функции записи, но пользовательский интерфейс и серверная проверка должны связывать подтверждение с точными аргументами операции. При изменении номера заказа или суммы между просмотром и записью сервер возвращает действие на сверку.
- Черновик содержит сравнение старых и новых полей и ссылку на источник каждого изменения.
- Оператор видит именно ту операцию, которую собирается подтвердить, включая целевую карточку.
- Сервер проверяет права и версию записи при фактическом выполнении операции.
- Результат записи получает идентификатор; отказ и ошибка остаются различными состояниями.
Такой экран подтверждения полезен и для пилота: команда увидит, какие предложения агента требуют исправления человеком. По этим замечаниям можно уточнять инструменты и инструкции, сохраняя контроль над записью.
Хотите проверить запись в CRM под ваши роли?
Условный пример: клиент спрашивает о доставке и просит сменить адрес. Агент читает статус заказа, предлагает ответ и черновик изменения адреса. Сотрудник сверяет запрос и полномочия, а сервер применяет подтверждённое изменение к актуальной карточке. При расхождении данных запрос возвращается на ручной разбор.
Trace и пилот
Для разбора маршрута используйте trace запуска. Официальная документация tracing перечисляет события генерации, вызовы инструментов, handoff и guardrails. Свяжите trace с внутренним идентификатором обращения, чтобы найти причину неверного ответа или остановки перед CRM. При этом входы и выходы инструментов способны содержать чувствительные данные; настройте их захват с учётом правил компании.
Предложите пилот на ограниченном наборе типов обращений. Подготовьте обезличенные сценарии: справочный вопрос, неоднозначный статус заказа, ошибочная карточка, отказ оператора и повторное подтверждение старого черновика. Для каждого запишите ожидаемый маршрут, допустимые инструменты и результат серверной проверки. Сравнивайте число обращений с подтверждённым источником факта, число ручных исправлений и число остановленных попыток записи.
Возьмите обращение, где требуется изменить поле CRM, и нарисуйте путь от факта до подтверждения. Отметьте место handoff, инструмент чтения, экран оператора и серверное условие записи. Такой маршрут даст конкретные проверки для первого пилота.
При разборе ошибок trace показывает ход агента, но итоговую корректность оценивает сотрудник по исходной записи. Скрипт или парсер считает показатели по полной выгрузке обращений с явными правилами. Языковая модель может объяснить группы ошибок и предложить гипотезы для улучшения маршрута; человек сверяет выборку, расчёт и причины остановок.
Стоимость внедрения зависит от качества базы знаний, числа функций CRM, состава ролей и требований к журналу решений. Расходы на вызовы моделей проверяйте по действующим тарифам; в смете отдельно учитывайте работу над интеграциями и проверками. Обсудить состав проекта и смету под ваш процесс можно на странице ИИ-агентов для бизнес-процессов.