До запуска модели
Пользователь даёт промпт и алиас вроде cheap, fast или smart. Продакшен-сервер проверяет аутентификацию, владение воркспейсом и право доступа до принятия задачи. ID моделей провайдеров и секреты остаются за этой границей — дружественный алиас — единственный словарь моделей, который клиенту когда-либо нужен, потому что соответствие реальной модели провайдера — конфигурация, а не контракт.
Устойчивая запись задачи даёт запросу идентичность до начала фонового выполнения. Эта идентичность связывает отправку, работника, записи использования и результат. Она также даёт пользователю способ восстановить работу после ухода со страницы.
Порядок важен: дорогая работа начинается только после прохождения дешёвых проверок. Проверка аутентификации, владения и права доступа до того, как что-то ставится в очередь, не даёт неаутентифицированным или неоплаченным запросам когда-либо достичь провайдера — и делает отказ объяснимым для пользователя. Руководство по модулю AI документирует, где живут эти проверки; пост о границах воркспейса объясняет, почему владение выводится на сервере, а не доверяется от клиента.
Решите, чьи ключи и чьи лимиты
AI-функция — это решение о расходах. supastack позволяет воркспейсам приносить собственные ключи провайдеров — хранящиеся зашифрованными и никогда не открываемые клиентам — или работать на платформенных ключах и обеспечивает бюджеты на воркспейс по каталогу цен моделей. Какой бы ни была ваша реализация, вопросы одни и те же: кто платит и где обеспечивается лимит?
Обеспечение принадлежит серверному процессу, а не браузерной оценке. Бюджет, проверенный после генерации, лишь фиксирует перерасход; проверенный до отправки — предотвращает его. Настройка ключей провайдеров покрывает сторону конфигурации.
Делайте выполнение явным
Trigger.dev запускает workflow ai.generate. Маршрутизатор с учётом возможностей выбирает модель по настроенной политике и требованиям запроса. Относитесь к этой политике как к операционному входу: недоступный алиас не должен появляться в интерфейсе как рабочий выбор.
Сетевая ошибка во время отправки может оставить клиента в неуверенности, была ли работа поставлена в очередь. Продакшен-путь использует ключ идемпотентности в области задачи и сохранённую отправку, чтобы восстановление могло переиспользовать исходный запрос. Отправка новой задачи после каждого таймаута рисковала бы дублировать работу и стоимость.
Устойчивость — это также то, что держит интерфейс простым: экран читает статус задачи и отображает его вместо оркестровки повторов. Когда генерация охватывает вызовы модели, шаги инструментов или расписания, явный контракт workflow — enqueue, status, cancel — это то, что держит «в процессе» честным.
Назовите режимы сбоев
Между запросом и результатом есть конкретный, конечный набор вещей, которые идут не так. Проектируйте каждую по имени, а не «ошибки» вообще — каждая задача должна заканчиваться объяснимым состоянием: в очереди, выполняется, упала с причиной или завершена с результатом. Восстановление задач — справочник кита по стороне восстановления.
Требование интерфейса под этим — ни одно состояние не может лгать. Спиннер, переживший работу, или сообщение об успехе для задачи, которая так и не выполнялась, — это тикет в поддержку и биллинговый спор, ожидающие своего часа.
- Отправка по таймауту — восстанавливайте через сохранённую отправку и ключ идемпотентности в области задачи вместо повторной постановки в очередь.
- Провайдер упал посреди задачи — пометьте задачу упавшей с причиной, которую интерфейс сможет показать.
- Бюджет исчерпан — отклоняйте до отправки, а не после траты.
- Пользователь ушёл со страницы — устойчивая запись и URL восстановления возвращают статус и результат.
Отслеживайте произошедшее
Генерация производит больше, чем текст. Приложение записывает использование и результат задачи, а интерфейс читает статус через аутентифицированный API. Запись использования — то, что делает бюджет обеспечиваемым, — она пишется до возврата результата, а не оценивается после.
Письмо о завершении — отдельный шаг с отдельными записями доставки. Успешный ответ модели не устанавливает, что письмо доставлено. Разделение этих исходов упрощает объяснение сбоев и повтор без лишнего перезапуска модели.
Результату также нужен дом, к которому пользователь сможет вернуться: страница задачи, список истории, URL восстановления, доставленный в том письме о завершении. Генерация, существующая только во временном уведомлении, — работа, которую вас попросят произвести дважды.
Проверяйте каждую границу
Используйте детерминированные fake-адаптеры, чтобы сначала проверить решения приложения: отказанный доступ, отключённые алиасы, дублирующие отправки, восстановление результата и общие ошибки. Эти тесты должны работать без креденшел провайдеров.
Затем используйте явно подключаемый процесс smoke провайдеров для реальных интеграций. Он требует задокументированной конфигурации sandbox и одобрения для внешних вызовов. Различие сохраняет обычную разработку быстрой, делая продакшен-доказательства конкретными и подотчётными.
Держите это разделение стабильным по мере изменения продукта: детерминированное покрытие рядом с каждым решением границы, чтобы замена провайдера, смена политики маршрутизатора или новый алиас роняли тест, а не клиента.
Частые вопросы об AI-функциях в SaaS
Несколько вопросов поднимаются в каждом разговоре о том, как поставить AI за пейволл.
- Где должна происходить авторизация AI-функций? — До того, как что-то ставится в очередь: аутентифицировать, разрешить воркспейс, проверить право доступа, затем создать задачу. Проверки после генерации лишь документируют злоупотребление.
- Нужна ли мне поддержка «принеси свой ключ»? — Если у ваших клиентов собственные отношения с провайдерами, да: это решает, кто платит и кто владеет лимитами частоты. Храните ключи зашифрованными и держите их подальше от клиентов — руководство по конфигурации AI покрывает модель.
- Как не дать повторам взимать плату дважды? — Ограничьте ключ идемпотентности областью задачи и переиспользуйте сохранённую отправку при восстановлении, чтобы таймаут не мог создать второй оплачиваемый прогон.
- Какие данные об использовании записывать? — На задачу: модель, потреблённые единицы, стоимость по каталогу цен и воркспейс — достаточно, чтобы обеспечивать бюджеты и отвечать на вопросы о расходах без повторного прогона задач.
- Когда генерация принадлежит фоновой задаче? — Всякий раз, когда она может пережить запрос. Задержка модели, повторы и многошаговая работа говорят за устойчивое выполнение; только мгновенные, дешёвые вызовы остаются в строке.