Platform For AI:Guia de descontinuação e migração do PAI-LangStudio

1,1 O que é o Model Studio

O Alibaba Cloud Model Studio é uma plataforma completa de serviços de grandes modelos, projetada para empresas e desenvolvedores. Ele oferece serviços de modelos, criação de aplicações, bases de conhecimento, um ecossistema de ferramentas e recursos de publicação e operações. O Model Studio é ideal para assumir as cargas de trabalho de criação, depuração, implantação e observabilidade de aplicações que você executava anteriormente no LangStudio.

Para o mapeamento detalhado de recursos e a abordagem de migração, consulte 2. Migration Overview. Para mais informações, consulte Alibaba Cloud Model Studio Overview e Model Studio Application Types.

1,2 Configuração de permissões pré-migração

Antes de migrar, solicite as permissões necessárias com antecedência. Peça ao proprietário da sua conta Alibaba Cloud para conceder aos usuários RAM dos desenvolvedores do LangStudio as permissões de leitura e gravação para aplicações do Model Studio, criar workspaces e solicitar chaves de API. Para itens de permissão específicos e procedimentos de autorização, consulte Permission management e Model Studio System Permission Policy Reference.

2,1 Mapeamento de recursos

A tabela a seguir mapeia os recursos do LangStudio para seus equivalentes no Model Studio:

2,2 Mapeamento de tipos de aplicação

Priorize a migração para tipos de aplicação de workflow ou high-code e reconstrua as configurações individualmente:

O Model Studio também oferece aplicações de agente, que possuem uma configuração mais simples. Avalie se esse tipo é adequado para o seu cenário de negócios.

3,1 Contagem e cobertura de nós

Primeiro, identifique os nós que possuem diferenças significativas ou nenhum equivalente direto. Reconstrua todos os outros nós na tela do Model Studio.

Para os nós marcados como "Diferenças menores", reconstrua a configuração no lado do Model Studio de acordo com as diferenças listadas na tabela acima. Para descrições completas dos parâmetros, consulte Workflow application. As seções a seguir abordam os nós com "Diferenças significativas" e "Deve ser implementado manualmente".

3.2 Nós com diferenças significativas

As seções a seguir focam apenas nas principais diferenças que exigem redesign.

{{ variable }}

${node.variable}

@tool
def invoke(...): ...

def main(params):
    return {"output": params["input"]}

{% for doc in documents %}
{{ doc.content }}
{% endfor %}

${KnowledgeBase_1.result}

3,3 Testes de integração

Clique em Test no canto superior direito da tela para abrir o painel de teste. Ele fornece três modos: Text Conversation (múltiplas rodadas, retém o contexto; clique em um nó para visualizar sua entrada e saída), Text Generation (rodada única, suporta síncrono e assíncrono) e Audio/Video Interaction. O canto superior direito também possui uma entrada Checklist que lista os itens de configuração que devem ser concluídos antes de uma execução. Recomendamos revisá-la antes de testar.

Concentre-se em verificar quatro tipos de problemas: se as referências de variáveis são passadas corretamente (especialmente após a reescrita da sintaxe do prompt), se a lógica de ramificação condicional e terminação de loop corresponde à aplicação original, se as chamadas de serviços externos falham devido a listas de permissões não configuradas, e se a estrutura de saída do nó Script corresponde ao que os nós downstream esperam.

4,1 Mudança fundamental na abordagem de desenvolvimento

O LangStudio fornece um Web IDE baseado em nuvem. As aplicações high-code do Model Studio usam desenvolvimento local.

O processo de migração é desenvolvimento local -> empacotar como .whl -> upload -> verificação na nuvem:

Se você preferir continuar o desenvolvimento e a depuração na nuvem, pode usar o DSW (Data Science Workshop) do PAI.

4,2 Mudanças na estrutura do projeto

Estrutura típica de uma aplicação do modo de código do LangStudio (modelo LLM Basic):

project/
├── agent.py          # Entry point: FastAPI app and API endpoints
├── agent_loop.py     # Core logic: LLM calls and tool execution loop
├── agui.py           # AG-UI Protocol event stream conversion
├── skills.py         # Skill discovery, loading, and execution
├── requirements.txt
├── .env              # Environment variables
└── README.md

Cinco mudanças são necessárias para migrar para o Model Studio:

Se o arquivo de entrada não for nomeado main.py, o console exibe "Deploying" até atingir o tempo limite. O endpoint de verificação de integridade é como o Model Studio determina se a aplicação foi iniciada com sucesso. Se o endpoint estiver inacessível, a implantação é considerada falha.

@app.get("/health")
def health_check():
    return "OK"

Implemente o endpoint padrão /process de acordo com o protocolo Agent API.

O ambiente de execução requer Python >= 3.10:

pip install "agentscope-runtime[deployment]==1.0.0"

4,3 Mudanças na invocação de modelos no código

Substitua as conexões de modelos existentes por chamadas para modelos da plataforma por meio de uma chave de API do Model Studio.

Defina a variável de ambiente DASHSCOPE_API_KEY e, em seguida, chame os modelos usando o SDK do DashScope ou o protocolo compatível com OpenAI:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DASHSCOPE_API_KEY"],
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)
resp = client.chat.completions.create(
    model="qwen-plus",
    messages=[{"role": "user", "content": "Hello"}],
)

O desenvolvimento de aplicações do Model Studio atualmente suporta apenas a região China (Beijing). Para chamadas de API de modelo, use o endpoint da região China (Beijing). Para integração de modelos auto-hospedados, consulte a Seção 6,1.

4,4 Mudanças na invocação de base de conhecimento no código

Aplicações high-code podem chamar a API ou SDK Knowledge Base Retrieve diretamente para realizar a recuperação.

Ao chamar serviços MCP, componentes de aplicação ou conectores de dados, conecte-se a eles por meio de suas respectivas interfaces. Após adicionar ou remover ferramentas, você deve reimplantar. Para detalhes, consulte .

4,5 Empacotamento, implantação e outras considerações do Model Studio

Os pacotes de código suportam apenas o formato .whl e são carregados via linha de comando:

# First deployment
runtime-fc-deploy --deploy-name <application_name> --whl-path <PATH_TO_WHL> --telemetry enable

# Update deployment
runtime-fc-deploy --update <HIGH_CODE_APP_ID> --whl-path <PATH_TO_WHL> --telemetry enable

Antes de fazer o upload, configure ALIBABA_CLOUD_ACCESS_KEY_ID, ALIBABA_CLOUD_ACCESS_KEY_SECRET e variáveis opcionais do workspace. Para a primeira implantação, siga as instruções do console para autorização.

Recursos de implantação: Selecione as especificações e o número mínimo de instâncias com base na sua carga de trabalho. Para preços, consulte a página de faturamento.

A observabilidade da aplicação exige a adição de instrumentação ao seu código:

from agentscope_runtime.engine.tracing import trace, TraceType

@trace(trace_type=TraceType.LLM, trace_name="llm_call")
def call_llm(...):
    ...

Ative --telemetry enable durante a implantação para visualizar os dados de invocação em Application Observability.

Rede e publicação: Para acessar recursos da rede interna da empresa, configure a rede de acordo com os métodos atualmente suportados para aplicações high-code. Configure nomes de domínio e autenticação por meio do gateway.

5,1 Publicação e invocação

Após publicar um aplicativo de workflow ou agent, obtenha os detalhes da API no console:

curl -X POST https://dashscope.aliyuncs.com/api/v1/apps/{APP_ID}/completion \
  -H "Authorization: Bearer $DASHSCOPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input": {"prompt": "Hello"}, "parameters": {}}'

Para saída em streaming, use o header X-DashScope-SSE: enable. Para conversas de múltiplas interações, passe session_id ou messages conforme descrito na documentação da API.

Os timeouts de chamadas síncronas dependem do domínio de acesso: o domínio padrão tem um timeout de 600 segundos, enquanto um domínio específico do workspace suporta até 3.600 segundos. Para tarefas mais longas, mude para execução assíncrona ou divida a tarefa.

Os aplicativos também podem ser publicados como componentes de aplicativo ou conectados a canais de compartilhamento. O escopo específico de suporte depende do tipo de aplicativo e da documentação oficial.

5,2 Limitação de taxa e cotas

O Model Studio calcula as cotas de RPM e TPM por conta do Alibaba Cloud e por modelo. Uma resposta 429 indica que a limitação de taxa foi acionada. Os usuários do RAM, workspaces e chaves de API na mesma conta do Alibaba Cloud compartilham a cota.

Antes de migrar workloads de alta concorrência, avalie suas cotas de modelo e solicite aumentos de cota, se necessário. Para mais detalhes, consulte Rate limiting.

5,3 Gerenciamento de produção e observabilidade

O Application Observability permite que você visualize cadeias de chamadas, entradas e saídas, latência, consumo de tokens e status de execução. O escopo de suporte e o período de retenção de dados estão descritos na documentação do console.

O Model Monitoring permite visualizar métricas como volume de chamadas, taxa de falhas, limitação de taxa e latência. Você pode integrar com sistemas de logging, alertas ou monitoramento com base nos recursos atuais.

Iteração de versão: Mantenha as versões no seu repositório de código local. Os workflows podem ser importados e exportados para salvar snapshots. Os aplicativos high-code são reimplantados com um novo pacote .whl usando --update. A DSL do Model Studio não pode importar diretamente o formato flow.dag.yaml do LangStudio.

6,1 Connections (Acesso a modelos)

O Model Studio não possui um objeto "connection" equivalente. Cada tipo de recurso é gerenciado pelo seu respectivo módulo, e as chamadas de modelo usam chaves de API.

Os modelos da plataforma do Model Studio são selecionados no ModelGallery e chamados por meio de chaves de API usando o protocolo DashScope ou compatível com OpenAI.

Os modelos de propriedade do cliente podem ser tratados por meio de três caminhos:

Para mais detalhes, consulte Model import e Model deployment.

6,2 Bases de conhecimento

Pré-requisito importante: Os dados vetoriais nas bases de conhecimento não podem ser exportados ou migrados diretamente. Você deve analisar, fragmentar e vetorizar novamente a partir dos arquivos originais ou de outros dados de origem. Certifique-se de que seus dados de origem estejam completos e acessíveis.

As bases de conhecimento do Model Studio oferecem quatro tipos. O tipo não pode ser alterado após a criação:

• Dados multimodais: Selecione o método de acesso com base no tipo de dados.

  • O Q&A de imagens usa campos image_url públicos em dados estruturados. A pesquisa de áudio e vídeo importa do armazenamento local ou do OSS.

  • Para documentos com layouts ou gráficos complexos, selecione o cenário de compreensão visual na Pesquisa de Documentos.

  • Áudio e vídeo são importados do armazenamento local ou do OSS e processados por parsers de áudio/vídeo.

• Análise e fragmentação: Selecione um parser e uma estratégia de fragmentação antes da criação. Estes não podem ser modificados após a criação. Valide a precisão da recuperação com dados de amostra primeiro.

• Modelos de embedding e ranking: Selecione modelos de embedding e reranking no momento da criação. Estes não podem ser alterados após a criação. Se a dimensão do embedding mudar, revalide os resultados da recuperação.

• Edições: Para detalhes de preços, consulte a página oficial de preços.

• Limites de associação e recuperação: Estes dependem do tipo de aplicativo e do modo de invocação. Verifique os limites atuais antes da migração.

• Etapas de migração: Valide e ajuste com dados de amostra -> crie uma base de conhecimento de produção e importe todos os dados -> anexe ao seu aplicativo -> faça benchmark dos resultados. Converta os arquivos de origem primeiro se o formato não for suportado.

Para mais detalhes, consulte Knowledge base.

6,3 Ferramentas (Plugins)

O Model Studio usa plugins para substituir ferramentas: os agents podem selecionar plugins de forma autônoma, enquanto os workflows os chamam deterministicamente por meio de um nó de Plugin.

Os plugins oficiais incluem code_interpreter, calculator, text_to_image, quark_search, generate_qrcode, github_search, entre outros. Estes podem substituir algumas chamadas de terceiros.

Os plugins personalizados são configurados no console com detalhes de interface e autenticação. Após a conclusão, eles podem ser publicados como MCP services. Para descrições detalhadas dos campos, consulte o console.

Para mais detalhes, consulte Plugin overview e Custom plugins.

6,4 MCP

O Model Studio fornece o MCP como um recurso de nível de plataforma, com uma MCP Gallery, services hospedados na cloud e um nó de MCP para workflow.

Os MCP services personalizados podem ser integrados da seguinte forma:

• Implantação de script: Use type: stdio ou type: sse / streamableHttp para conectar seu service.

• Importação do AI Gateway: Encapsule APIs RESTful existentes como ferramentas MCP.

• Importação do Alibaba Cloud OpenAPI: Crie um BailianMcpRole* e conceda as permissões necessárias.

Os limites de montagem, ferramentas e configuração do MCP estão sujeitos a alterações conforme os recursos são atualizados. Verifique a documentação oficial atual antes da migração.

6,5 Outros módulos comuns

O Model Studio também fornece os seguintes recursos de plataforma que não possuem um equivalente independente no LangStudio. Introduza-os conforme necessário durante a migração:

Desses, Skills e Avaliação de aplicativos são os mais relevantes para a migração: o primeiro assume o diretório de skills de projetos do modo de codificação, e o segundo permite que você crie conjuntos de avaliação para comparar a consistência da saída antes e depois da migração.

P: Meus nós Python usam bibliotecas de terceiros como pandas. O nó Script no Model Studio não as suporta. O que devo fazer?

Três opções: reescreva com bibliotecas padrão; mova a lógica para um nó do Function Compute (que suporta um ambiente de dependências completo, com um timeout fixo de 60 segundos); ou empacote como um service independente e chame por meio de um nó de API. Para mais detalhes, consulte 3.2.2 Python Development to Script Node.

P: Meu aplicativo original é executado dentro de uma VPC corporativa e acessa services de rede interna. Como faço para lidar com isso após a migração?

Quando um nó de API de workflow precisa acessar services internos corporativos, você deve expor o service por meio de um método suportado e configure o controle de acesso. Para acesso de VPC corporativa a services publicados, siga as instruções de acesso à rede privada. Para mais detalhes, consulte 3.2.4 HTTP Request to API Node.

P: Ainda posso usar meus modelos auto-hospedados no PAI-EAS após a migração?

Sim, mas o método de integração muda. O Model Studio não suporta o registro de endpoints de modelos externos como modelos de plataforma. Em um workflow, use um nó de API para chamar o modelo via HTTP ou empacote-o como um plugin / MCP service personalizado. Se o modelo for um resultado de fine-tuning LoRA baseado no Qwen, você também pode importá-lo para o Model Studio. Se precisar de recursos de computação dedicados, reimplante no service de inferência dedicado do Model Studio. Para mais detalhes, consulte 6,1 Connections (Model Access).

P: Posso migrar diretamente os dados vetoriais da minha base de conhecimento?

Não, você não pode migrá-los diretamente. Você deve analisar e vetorizar novamente a partir dos arquivos originais ou de outros dados de origem. Se você escolher uma solução de RAG auto-hospedada e já usar Elasticsearch / Milvus, os dados vetoriais residem na sua própria instância e podem ser reutilizados diretamente.

P: O limite Top K do modo de recuperação selecionado é menor do que o meu aplicativo original usa. O que devo fazer?

Primeiro otimize a fragmentação e o reranking, depois avalie a divisão de bases de conhecimento ou a construção de um RAG service auto-hospedado. Para mais detalhes, consulte 7. Alternative: Building a Self-hosted RAG Service.

P: Como confirmo que a qualidade não degradou após a migração?

Recomendamos usar o recurso de Avaliação de Aplicativos no Model Studio para criar um conjunto de avaliação. Execute seu aplicativo migrado com amostras de solicitações reais do aplicativo original e compare a consistência da saída e a precisão da recuperação. Concentre-se nas três áreas com maior probabilidade de diferir: reescrita de sintaxe de prompt, alterações no limite de recuperação da base de conhecimento e reescrita do nó Script.

P: Se o Model Studio não atender aos nossos requisitos corporativos, existem outras opções?

Recomendamos os seguintes três products do Alibaba Cloud. Selecione com base nos seus requisitos de negócios e roteiro técnico. Se tiver mais dúvidas, consulte seu gerente de conta.

1. Function Compute AgentRun

   Uma plataforma de infraestrutura de IA Agentic completa, construída sobre uma base high-code. Com base em uma arquitetura serverless, oferece elasticidade em nível de milissegundos, sandboxes de segurança de nível corporativo, governança unificada de modelos e ferramentas, e observabilidade de ponta a ponta. Cobre todo o ciclo de vida dos aplicativos Agent corporativos, desde o desenvolvimento e implantação até as operações.

2. AgentCore - Plataforma de Criação e Governança de Agents

   Criação e governança unificadas de agents corporativos em todo o ciclo de vida do agent. Suporta múltiplos modos de criação, autenticação de identidade unificada e orquestração de colaboração em equipe. Gerencia agents desenvolvidos internamente, de harness open-source e SaaS comerciais em uma única plataforma.

3. AgentLoop - Agent Observability and Optimization

   Uma plataforma completa de autoevolução para agents corporativos. Abrange cinco recursos principais: observabilidade, avaliação, ajuste, memória e auditoria. Ajuda as empresas a construir um ciclo virtuoso de evolução de agents com foco na otimização contínua dos aplicativos de agent.