Visão geral

Um deployment é uma versão publicada de um workflow que chamadores externos podem executar. Enquanto você constrói, o workflow vive no workflow builder como um rascunho que só você pode executar. Fazer o deploy publica uma cópia fixa desse rascunho e lhe dá um endereço: um endpoint REST, uma página de chat ou um conjunto de ferramentas MCP. Cada um deles é uma superfície, um canal pelo qual chamadores alcançam o mesmo workflow publicado.

Como na publicação de um livro, construir e fazer o deploy são atos separados. Você rascunha e revisa livremente no builder. Quando você clica em Deploy, o Studio imprime uma edição fixa. Os leitores recebem essa edição, não o seu rascunho mais recente, até você publicar uma nova. E você sempre pode voltar a uma impressão anterior.

O modelo de deployment

Snapshot

Um snapshot é uma cópia imutável do seu workflow, tirada no momento em que você faz o deploy. Ele fica congelado: editar o builder depois altera o seu rascunho, não o snapshot. Toda chamada ao seu deployment roda contra o snapshot, então uma edição pela metade no builder nunca chega a um chamador em produção. Publicar de novo tira um snapshot novo do rascunho atual.

Versão

Cada snapshot é registrado como uma versão numerada (v1, v2 e assim por diante) na tabela Versions, marcada com quem fez o deploy e quando. As versões são independentes: uma fica live por vez, sinalizada com um ponto verde, e as demais continuam disponíveis para renomear, descrever, carregar de volta no builder ou promover. Você publica a v1 com Deploy, e cada Update posterior adiciona a próxima versão.

Versão live

A versão live é o único snapshot exposto no momento por todas as superfícies. A aba General a mostra como Live Workflow, um minimapa somente leitura de exatamente o que os chamadores executam. Só uma versão fica live por vez. Promover uma versão diferente, ou atualizar para uma nova, troca qual snapshot está live sem afetar os outros.

Update

Depois que você altera o builder em um workflow com deploy, um selo Update deployment aparece na barra de ferramentas para sinalizar que sua versão live está atrás do seu rascunho. Clicar em Update tira um novo snapshot, registra-o como a próxima versão e o torna live, tudo sem reabrir o modal de deploy.

Promote to live

Promote to live torna uma versão anterior a versão live de novo. É o caminho rápido para rollback: se um novo deployment se comportar mal, promova a última versão que funcionava para restaurá-la instantaneamente. Promover reaproveita um snapshot existente, então não cria uma nova versão.

As superfícies

Toda superfície roda o mesmo snapshot live. Você as gerencia pelas abas do modal de deploy.

A superfície mais comum é a API. Depois do deploy, seu workflow responde em:

POST https://agent-studio.seeyu.ai/api/workflows/{workflow-id}/execute

Envie no corpo da requisição um objeto que corresponda ao Input Format do workflow. A resposta é um objeto com as saídas dos blocos e os metadados de execução.

curl -X POST https://agent-studio.seeyu.ai/api/workflows/{workflow-id}/execute \
  -H "X-API-Key: $STUDIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "input": "Refund request from customer #4821" }'

Versionamento na prática

Trate a versão live como produção e o builder como staging. Execute o workflow no builder até ele se comportar como você quer, então use Deploy ou Update para publicar. Os chamadores continuam usando o snapshot anterior até a nova versão entrar em produção, então não existe um estado meio implantado. Se uma nova versão causar problemas, use Promote to live na anterior para reverter na hora, depois corrija o rascunho e atualize novamente quando estiver pronto. Os logs registram todas as execuções de todas as versões, então você pode confirmar qual snapshot uma determinada execução usou.

Próximos passos