For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /pt/docs/modules/ai.md (or send Accept: text/markdown).
IA e jobs em segundo plano
De um pedido autorizado a um resultado durável.
Experimente uma IA falsa e escolha um provedor real
Para obter seu primeiro resultado, siga a tarefa /dashboard do tutorial da Web: inicie o fluxo local, coloque um prompt na fila, execute-o e visualize o resultado. AI_PROVIDER=fake retorna uma resposta de demonstração repetível sem enviar dados para um modelo externo ou usar uma chave API paga.
Para geração real, primeiro configure contas persistentes, escolha um provedor de IA e siga a configuração de IA abaixo. Adicione um modelo e seu preço ao catálogo do banco de dados, escolha os modelos permitidos para cada alias e conceda ao espaço de trabalho o acesso necessário. Um alias como fast é uma escolha amigável mostrada ao usuário; ele próprio não é um ID de modelo de provedor externo.
Um AI task em segundo plano também precisa do serviço de trabalhos configurado. Se nenhuma opção de modelo for mostrada, inspecione o catálogo e a política de alias antes de tentar novamente. Se o acesso for negado, inspecione o direito do espaço de trabalho ativo. Mantenha todas as chaves API do provedor na configuração do servidor Web, não no navegador, aplicativo móvel ou janela da área de trabalho.
Segue o ciclo de vida da tarefa
A API de tarefas de produção valida o workspace autenticado e a permissão antes de persistir uma tarefa e despachar o workflow ai.generate do Trigger.dev. O router aplica requisitos de capacidade e a política de modelo configurada.
POST /api/ai/tasks
→ authenticated workspace + entitlement
→ durable task record
→ Trigger.dev ai.generate
→ model routing + generation
→ usage record + result
→ transactional completion deliveryConfigura aliases e orçamentos
O utilizador escolhe um alias ativado: cheap, fast ou smart. O servidor controla os IDs de modelo subjacentes, as credenciais de fornecedor, a política do workspace e a aplicação de orçamentos. O suporte encriptado de chaves próprias deve preservar a mesma fronteira de servidor.
Mantém a semântica de workflow explícita
O JobRunner só promete enqueue, status e cancel. A semântica de workflow do Trigger.dev é explícita, incluindo o comportamento de execução durável. Não deduzas retries nem garantias de agendamento do contrato genérico.
O caminho de submissão de produção usa idempotência e recuperação de tarefa guardada para lidar com dispatch ambíguo. A conclusão da geração é separada da entrega do email de conclusão.
Para continuar a configuração, leia Configurar jobs em segundo plano.