Skip to main content
A API AI Chat v2 (/aichat2/conversations) é a interface de conversa de nova geração, uma versão totalmente atualizada da API AI Chat. Com base na simplicidade e no gerenciamento hospedado de conversas de múltiplas rodadas da v1, ela expandiu:
  • Entrada de usuário multimodal: envie diretamente blocos de texto + imagem + arquivo através do campo message estruturado, sem precisar anexá-los indiretamente primeiro usando references.
  • Chamada de ferramentas orientada a Agent: inclui um conjunto de ferramentas como pesquisa na internet, captura de páginas web e leitura de arquivos, e permite montar servidores MCP autorizados pelo usuário (Google Drive, Notion, Slack, GitHub etc.); o modelo pode chamar ferramentas autonomamente em múltiplas rodadas dentro de uma única solicitação para concluir tarefas complexas.
  • Eventos de streaming estruturados: através de accept: text/event-stream ou application/x-ndjson, é possível obter eventos como text_delta, tool_use, tool_result, thinking, citation, card, artifact etc. token por token, facilitando a renderização separada no frontend conforme o tipo correspondente.
  • Interrompível / retomável: quando o modelo precisa que o usuário complemente informações, ele emite o evento ask_user_question e pausa; na próxima chamada, basta preencher a resposta através de tool_results para continuar.
  • Novas ações CRUD: realize retrieve / retrieve_batch / update / delete através do campo action no mesmo endpoint, sem precisar de uma API adicional de gerenciamento de conversas.
  • Lista de modelos continuamente atualizada: por padrão, integra modelos contemporâneos como GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3 etc.
Ao mesmo tempo, ela é totalmente retrocompatível com a v1 no nível do corpo da solicitação: basta enviar model + question (+ opcionalmente stateful / id / references / preset) para obter uma resposta JSON {answer, id} equivalente à v1. Portanto, não é necessário reescrever o cliente ao migrar de /aichat/conversations; basta alterar o caminho para /aichat2/conversations.
Se você estiver usando atualmente /aichat/conversations, a interface antiga continuará sendo mantida, e você poderá migrar no seu próprio ritmo.

Processo de solicitação

Para usar a API AI Chat v2, primeiro obtenha seu API Token no Console Ace Data Cloud e guarde-o como reserva. Se você ainda não tiver feito login ou se registrado, será redirecionado automaticamente para a página de login, onde será convidado a se registrar e fazer login; após concluir, retornará automaticamente à página atual. Um único API Token permite chamar todos os serviços da plataforma, sem precisar solicitar um separadamente para cada serviço. A primeira solicitação concede uma cota gratuita, permitindo uma experiência sem custo; quando a cota for insuficiente, você poderá recarregar saldo universal no console.
📘 Documentação completa: API AI Chat v2 →

Uso básico

O uso mais simples é totalmente igual ao da v1: envie model + question e obtenha {answer, id}. Exemplo CURL:
Resultado retornado:
Exemplo Python:
Os valores disponíveis para model podem ser vistos diretamente no menu suspenso do painel Try à direita, e as categorias comuns incluem:
  • OpenAI: gpt-5.4-mini, gpt-5.4-nano, gpt-5.2-pro, gpt-5.1-all, gpt-5-all, gpt-4.1, gpt-4o, gpt-4o-image, o3, o4-mini etc.
  • Anthropic: claude-opus-4-8, claude-opus-4-7, claude-opus-4-6, claude-opus-4-5-20251101, claude-sonnet-4-6, claude-sonnet-4-5-20250929, claude-haiku-4-5-20251001 etc.
  • Google: gemini-3.1-pro-preview, gemini-3.1-pro-preview, gemini-3.1-flash-image, gemini-3.1-pro-preview, gemini-2.5-flash-lite etc.
  • xAI: grok-4 etc.
  • DeepSeek: deepseek-v4-pro, deepseek-v4.1-flash, deepseek-v4-flash, deepseek-v3.2-exp, deepseek-r1-0528 etc.
  • Moonshot: kimi-k3, kimi-k2.6, kimi-k2.5 etc.
  • Zhipu: glm-5.3, glm-5.2, glm-5.1, glm-5, glm-5-turbo, glm-4.7, glm-4.5v etc.
Para regras específicas de cobrança, consulte o cartão Pricing na página do serviço.

Conversas de múltiplas rodadas

Assim como na v1, envie stateful: true para ativar o salvamento da conversa; a API retornará um id; nas solicitações subsequentes, basta enviar o id de volta para continuar a conversa, sem precisar manter o histórico de messages por conta própria. Primeira solicitação:
Retorno:
Segunda solicitação, incluindo o mesmo id:
O padrão de stateful é true, omiti-lo é equivalente a passar explicitamente true. Se você não quiser que o servidor salve esta rodada de conversa, pode definir explicitamente stateful: false.

Resposta em streaming

A v2 suporta dois formatos de streaming, selecionados de acordo com o cabeçalho accept:

Exemplo de NDJSON

Cada linha do NDJSON é um evento estruturado, sendo o mais comum text_delta:

Exemplo de SSE

O uso de EventSource no navegador não oferece suporte a um corpo de solicitação personalizado; recomenda-se usar fetch + análise manual por fatias de \n\n:

Tipos de eventos de streaming

Para clientes que se preocupam apenas com a resposta final, concatenar o content de todos os text_delta é equivalente ao answer no modo application/json.

Entrada multimodal

Se a entrada do usuário contiver imagens ou arquivos, passe message (uma matriz) em vez de question. Cada elemento da matriz é um bloco de conteúdo:
Tipos de blocos suportados:
  • text — Texto comum, campo text obrigatório.
  • image_url — Imagem, image_url.url obrigatório.
  • file_url — Arquivo (PDF, CSV, TXT etc.), file_url.url obrigatório.

Relação com references da v1

Para compatibilidade com clientes antigos, a v2 ainda reconhece o campo references: ["https://...", ...]:
  • Se o sufixo da URL for jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, converta automaticamente em um bloco image_url;
  • Outros tipos de extensão são convertidos em um bloco file_url;
  • Se question também for fornecido, coloque-o antes como um bloco text.
Portanto, se você quiser apenas migrar do v1 sem alterar o corpo da solicitação, basta alterar o caminho para /aichat2/conversations, e o uso original de references continuará funcionando normalmente. Se precisar de um controle mais refinado (por exemplo, colocar várias imagens entre textos, ou quando a ordem for importante), use diretamente o array message.

Chamada de ferramentas e MCP

O principal aprimoramento do v2 é que o modelo pode chamar ferramentas de forma autônoma para concluir tarefas em várias etapas, isso vem ativado por padrão, sem necessidade de qualquer configuração adicional do cliente na solicitação. Cenários comuns:
  • O usuário pergunta: «Pesquise para mim quais exposições novas há recentemente em Xangai» → O modelo chama a busca web integrada → Organiza os resultados em uma resposta.
  • O usuário pergunta: «Leia este PDF e depois escreva um resumo» → O modelo chama file_read → Escreve o resumo.
  • O usuário já autorizou Google Drive / GitHub / Notion etc. em Connections → O modelo pode chamar as ferramentas MCP correspondentes para ler e escrever seus dados.
No fluxo NDJSON / SSE, as chamadas de ferramentas são apresentadas por meio de dois tipos de eventos, tool_use e tool_result, por exemplo:
Se não quiser exibir os detalhes da chamada de ferramentas no frontend, basta ignorar os eventos dos tipos tool_use / tool_result / card / citation; a saída final do modelo ainda será transmitida por text_delta. max_turns pode limitar o número máximo de rodadas em que o modelo pode chamar ferramentas por conta própria nesta solicitação; o limite padrão é determinado pela plataforma. Defini-lo como um valor baixo (por exemplo, max_turns: 1) pode forçar uma resposta única e não permitir nenhuma chamada de ferramenta.

Execução assíncrona e autorização não assistida

Se sua chamada vier de um Webhook de alerta, CI/CD, sistema de monitoramento ou outra tarefa de backend, você pode definir async: true para que a interface retorne imediatamente o ID da tarefa e continue executando em segundo plano:
Exemplo de retorno:
Depois, você pode usar action: retrieve + id para consultar o resultado da conversa; também pode fornecer callback_url, e após a conclusão da tarefa a plataforma fará POST de { status, answer, usage, error } para o seu endereço de callback. callback_url deve usar http / https e não pode preencher diretamente localhost ou um endereço literal de IP privado. Normalmente, não há ninguém que possa clicar para confirmar nas tarefas de backend. Se quiser que determinados Skills ou MCP Servers executem ações como enviar, publicar e gravar no modo não assistido, transmita explicitamente a lista de pré-autorização no corpo da solicitação:
Os valores em allowed_skills são os slugs dos Skills conectados; os valores em allowed_mcp_servers são os slugs dos MCP Servers conectados. Skills / MCP Servers não incluídos na pré-autorização, no modo não assistido, ainda poderão apenas visualizar, executar dry-run ou recusar a execução de operações de escrita. Se for necessário um controle mais detalhado, também é possível usar o objeto equivalente unattended_policy:
A pré-autorização são essas duas listas em si: uma lista vazia significa não autorizar nenhuma capacidade, sem a necessidade de campos de ativação adicionais. Observação: a pré-autorização representa apenas que «esta solicitação permite que essas capacidades ignorem a confirmação humana no modo não assistido». O Skill específico ainda deve suportar --unattended-confirm ou o mecanismo de segurança correspondente; caso contrário, continuará em dry-run e não executará diretamente operações de escrita.

Retomar conversas pausadas

Algumas ferramentas fazem com que o modelo «faça uma pergunta ao usuário». Nesse momento, o modelo emitirá um evento ask_user_question, e a conversa ficará congelada no estado awaiting_user_input:
No frontend, renderize esse evento como um cartão para que o usuário escolha uma resposta e, em seguida, inicie a próxima solicitação usando o mesmo id, preenchendo a resposta por meio de tool_results:
O tool_use_id no corpo da solicitação deve ser exatamente igual ao tool_id no momento da pausa; se for diferente, será retornado 400. Quando tool_results existir simultaneamente na solicitação, question / message / references serão todos ignorados. Se o usuário decidir abandonar esta pergunta, basta transmitir um novo question / message, e a plataforma marcará automaticamente a chamada de ferramenta pausada como «ignorada pelo usuário».

Gerenciamento de conversas (CRUD)

O v2 fornece gerenciamento leve de conversas por meio do campo action no mesmo endpoint, sem necessidade de criar outra API.

action: retrieve —— Buscar uma conversa

Retorna o documento completo da conversa (incluindo o histórico de messages, model, title, tools_used etc.).

action: retrieve_batch —— listar resumos de conversas

Retorna { items: [...], total }. Os resumos não incluem messages, sendo adequados para listas na barra lateral; se o usuário abrir uma conversa, use então action: retrieve para buscar separadamente suas mensagens completas. Parâmetros de filtro opcionais: user_id, application_id, model_group, model.

action: update —— alterar o título ou reescrever o histórico

messages também pode ser enviado, mas o servidor realizará uma validação rigorosa do schema (deve estar no formato ToolUseContent recolhido), e retornará 400 caso não esteja em conformidade. Em geral, recomenda-se usá-lo apenas para alterar o title.

action: delete —— excluir uma conversa

Retorna { id, success: true }. Após a exclusão, não será possível recuperar, portanto confirme antes de chamar.

Migração tranquila da v1

Se você já estiver usando /aichat/conversations, a migração para a v2 quase não exige alterações de código:
  1. Altere a URL de https://api.acedata.cloud/aichat/conversations para https://api.acedata.cloud/aichat2/conversations.
  2. Se você anteriormente utilizava nomes de modelos da v1 (como gpt-3.5, gpt-4-browsing etc.), ao mudar para a v2 é recomendável atualizar para modelos contemporâneos (como gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview etc.).
  3. Os campos do fluxo NDJSON permanecem compatíveis com versões anteriores: cada evento text_delta continua contendo delta_answer e id, portanto os clientes que originalmente analisam delta_answer por linha não precisam de alterações.
Após a migração, você pode habilitar, conforme necessário, os novos recursos da v2 (como message multimodal, SSE, chamadas de ferramentas, CRUD com action) e avançar no seu próprio ritmo.

Tratamento de erros

As respostas de erro são unificadas como:
Erros comuns:
  • 400 bad_request: campos obrigatórios ausentes, incompatibilidade de tool_use_id, schema de messages inválido etc.
  • 401 invalid_token: o cabeçalho authorization está incorreto.
  • 404 not_found: a conversa correspondente ao id não existe ao usar action: retrieve / update / delete.
  • 429 too_many_requests: o limite de taxa foi acionado.
  • 500 chat_error: erro do LLM upstream ou completion_tokens=0 nesta rodada (tratado como não consumido, sem cobrança).
Em respostas de streaming, os erros são emitidos como eventos {"type":"error","message":"..."}, e o fluxo será encerrado em seguida.

Conclusão

A API AI Chat v2, mantendo compatibilidade com versões anteriores da v1, atualiza as conversas de «perguntas e respostas de turno único / múltiplos turnos» para «conversas observáveis orientadas a agentes»: entrada multimodal, chamadas de ferramentas, pausa / retomada, eventos estruturados de streaming e CRUD integrado. Recomenda-se que novas integrações utilizem diretamente a v2; integrações existentes da v1 podem migrar gradualmente em fases. Se tiver alguma dúvida, entre em contato com nossa equipe de suporte técnico a qualquer momento.