Documentação

Design do SDK TypeScript

laya-client é um cliente HTTP sem dependências para um servidor laya-serve auto-hospedado. Ele usa o endpoint POST /v1/systemone e não adiciona nenhum código Python de produção nem dependências de servidor. O pacote npm começa na versão 0.1.0, independentemente das versões do Python.

Fronteiras

Componente Responsabilidade
sdk/typescript Tipos de pergunta/resposta, presets, validação, fetch nativo, erros e cancelamento
laya/serve.py Endpoint HTTP existente, autenticação Bearer, health e limites de solicitação
laya/router.py Seleção de checkpoint, carga e roteamento de inferência
laya/agent.py Tokenização, inferência em PyTorch e formatação de resposta calibrada
laya/presets.py Fonte dos cinco presets de pergunta TypeScript gerados
flowchart LR
    A[JavaScript or TypeScript application] --> B[laya-client]
    B -->|POST /v1/systemone| C[Existing Laya server]
    C --> E[Router and local checkpoint]

O SDK exporta predict e uma sonda health exclusiva do Laya. Ele distribui ESM, CommonJS e declarações, preservando ids de pergunta e rótulos de escolha inferidos. Use laya-client quando uma aplicação JavaScript ou TypeScript conversa por HTTP com um laya-serve Python auto-hospedado. Use laya-ts quando a inferência precisa rodar diretamente dentro do JavaScript, através do seu runtime ONNX local, sem um servidor Python.

Contrato compartilhado

As solicitações contêm state e questions. A menos que configurado ou fornecido para uma predição, laya-client omite model, deixando o laya-serve selecionar um checkpoint local automaticamente. Um model para o cliente inteiro ou por chamada pode selecionar um checkpoint local, assim como os demais controles por solicitação da tabela abaixo. Arrays de rótulos de escolha são normalizados para mapas com descrições nulas antes do transporte.

As respostas preservam model, answers e o usage de tokens. Os campos routing do Laya e action da resposta são extensões opcionais; a confiança de Noul também é opcional. A confiança de Choice e Score, as distribuições e as legendas de Score continuam obrigatórias. Toda resposta carrega answer_confidence, a massa max(p) sobre a resposta reportada, que é a mesma quantidade nos três tipos de pergunta. Uma chamada à qual foi passado min_confidence reporta abstention e abstention_threshold em cada uma de suas respostas e low_confidence: true nas que ficam abaixo do limiar; sem limiar definido, nenhuma dessas três chaves é enviada, e essa ausência é o relatório. Extensões opcionais são validadas quando presentes.

O /v1/systemone é o único endpoint que o cliente chama, e ele não tem um método de roteamento autônomo: laya-client expõe predict e health e nada mais, e o teste de integração ao vivo afirma que o servidor responde 404 para /v1/route. Os controles que o endpoint de fato respeita são por solicitação, e cada um é enviado só quando o chamador forneceu a opção – uma opção ausente deixa as próprias configurações de Router(...) da implantação no comando, em vez de sobrescrevê-las com um padrão do lado do cliente:

opção campo da solicitação
model model
task task
lang lang
langGuess lang_guess
maxLen max_len
headMaxLen head_max_len
minConfidence min_confidence

Uma opção que não pode significar nada é recusada localmente, antes de a solicitação sair: um task em branco, um orçamento que não é um inteiro positivo, um limiar fora de [0, 1], ou um mapa de limiares vazio ou com um valor fora de [0, 1]. Nada é ignorado em silêncio. O /health público do Laya retorna status, loaded e device. A predição nunca sonda o health primeiro.

As strings de detalhe e os arrays de validação do FastAPI são preservados como mensagens/detalhes de LayaAPIError. Envelopes de erro estruturados de backends compatíveis também são aceitos. As solicitações têm prazos configuráveis e cancelamento pelo chamador, e nunca são repetidas automaticamente.

Verificação e lançamento

Os testes unitários cobrem a construção de solicitações, todos os formatos de resposta, extensões do Laya, erros do FastAPI, validação de JSON, prazos e cancelamento, e prendem a tabela de controles desta página aos campos que o cliente realmente coloca no fio. As checagens de tipo cobrem metadados opcionais, tipos de resposta inferidos e consumidores ESM/CommonJS. O teste de integração ao vivo inicia a aplicação laya.serve sem alterações com um checkpoint offline minúsculo, compara as predições do SDK com a inferência direta em Python, e exercita roteamento, presets, autenticação e limites de solicitação. A CI roda as checagens do SDK em Node.js 22 e 24.

Pesos aleatórios minúsculos verificam o transporte e a paridade numérica, não a qualidade ou o desempenho pré-treinados.

Veja o guia do SDK para configuração, exemplos e publicação no npm. O pacote será publicado sob o nome laya-client. Os fluxos de lançamento do Python não mudam.