Как настроить Programmatic Tool Calling в OpenAI API для цепочек инструментов

Programmatic Tool Calling позволяет модели написать и выполнить JavaScript, который оркестрирует обращения к инструментам. Выполнять этот код следует только в контролируемой среде; набор доступных функций задаёт приложение. Это не разрешение на произвольный доступ к сети, файловой системе или секретам.

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

Что подготовить до первого запроса

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

Подготовьте таблицу приёмки ещё до запуска. Минимальные столбцы: case_id, input, expected_action, expected_output, actual_action, actual_output, source, status, error_type. Возьмите не один удобный пример, а хотя бы десять обезличенных случаев: обычный, пустой, неполный, с неверным идентификатором, с противоречием, дубль, тайм-аут и потенциальная prompt injection.

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

Пошаговая настройка

1. Опишите три минимальные функции: get_order(order_id), get_stock(sku) и format_summary(rows). Для каждой зафиксируйте типы аргументов и ошибок; не принимайте произвольные SQL-строки или URL.
2. Передайте функции как инструменты и включите режим Programmatic Tool Calling по схеме из официального руководства. В исполнительной среде экспортируйте только эти функции, без process, fetch, eval и доступа к переменным окружения.
3. Добавьте валидатор: order_id соответствует шаблону ORD-[0-9]{6}, sku — известному формату, число вызовов не превышает 10, суммарное время — 15 секунд. Нарушение завершает запуск без частичного изменения данных.
4. Сохраните исходный запрос, сгенерированную программу, имена вызванных функций, аргументы и укороченные результаты. Секреты и персональные данные маскируйте до записи журнала.
5. Прогоните позитивный тест с тремя заказами и негативный — с идентификатором ../../secrets. Во втором случае get_order не должна вызываться.

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

Копируемый шаблон инструкции

Ты оркестратор проверки заказов. Используй только get_order, get_stock и format_summary. Сначала проверь формат каждого идентификатора. Не вызывай функции для невалидных значений. Максимум 10 вызовов. Верни JSON: {valid_orders:[], rejected_inputs:[], summary:""}. Не изменяй данные.
Общие правила:
1. Используй только переданные данные и разрешённые инструменты.
2. Не заполняй пропущенные значения догадкой.
3. Перед действием проверь идентификаторы, права и границы задачи.
4. При конфликте данных верни status=needs_review и назови конфликт.
5. Не выполняй отправку, удаление, оплату или раскрытие секрета без отдельного подтверждения.
6. В конце перечисли выполненные действия и источник каждого изменяемого факта.

Шаблон полезен именно как контракт. Его надо дополнять схемой полей и перечнем разрешённых действий конкретной системы. Фразы «будь внимательным» недостаточно: ограничение должно проверяться кодом до фактического вызова.

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

Вход: ORD-104201, ORD-104202 и ../../secrets. Для каждого корректного заказа покажи статус и наличие его SKU.

Ожидается два обращения get_order, затем только необходимые get_stock. В rejected_inputs попадает ../../secrets с причиной invalid_order_id; в итоговом JSON нет выдуманных заказов и нет изменения данных.

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

Как проверять результат по уровням

Первый уровень — транспорт. Запрос завершился, ответ читается, идентификатор сохранён. HTTP 200 сам по себе не доказывает правильность. Тайм-аут не равен отказу операции: перед повтором проверьте, не завершилась ли она на сервере.

Второй уровень — структура. Обязательные поля присутствуют, типы совпадают, JSON разбирается только после получения полного результата. Неизвестные поля либо отклоняются, либо явно сохраняются отдельно. Пустая строка не превращается в ноль или «неизвестно» без правила.

Третий уровень — смысл. Сопоставьте каждый факт с входом или результатом инструмента. Числа пересчитайте обычным кодом. Идентификаторы сравните посимвольно. Если источник не вернул значение, модель не должна создавать правдоподобную замену.

Четвёртый уровень — действие. Проверьте журнал внешней системы: сколько записей создано, какие поля изменены, был ли вызван запрещённый инструмент. Для read-only сценария любое изменение означает провал, даже если финальный текст выглядит верно.

Контроль в рабочей системе