/aichat2/conversations) est une interface de conversation de nouvelle génération et une version entièrement améliorée de l’API AI Chat. En s’appuyant sur la simplicité de v1 et la gestion hébergée des conversations multi-tours, elle étend :
- Entrée utilisateur multimodale : envoyez directement des blocs de texte + image + fichier via le champ
messagestructuré, sans avoir besoin de les joindre indirectement viareferences. - Appels d’outils orientés Agent : intègre un ensemble d’outils tels que la recherche en ligne, l’extraction de pages web, la lecture de fichiers, etc., et permet de monter des serveurs MCP autorisés par l’utilisateur (Google Drive, Notion, Slack, GitHub, etc.) ; le modèle peut appeler des outils de manière autonome sur plusieurs tours dans une seule requête afin d’accomplir des tâches complexes.
- Événements de streaming structurés : via
accept: text/event-streamouapplication/x-ndjson, vous pouvez obtenir des événements tels quetext_delta,tool_use,tool_result,thinking,citation,card,artifacttoken par token, ce qui facilite leur rendu séparé selon leur type côté frontend. - Interrompable / Reprenable : lorsque le modèle a besoin que l’utilisateur complète des informations, il émet un événement
ask_user_questionet se met en pause ; lors de l’appel suivant, il suffit de renseigner la réponse viatool_resultspour continuer. - Nouvelles actions CRUD : utilisez le champ
actionsur le même endpoint pour effectuerretrieve/retrieve_batch/update/delete, sans avoir besoin d’une API supplémentaire de gestion des conversations. - Liste de modèles continuellement mise à jour : intègre par défaut des modèles contemporains tels que GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3, etc.
model + question (+ éventuellement stateful / id / references / preset) pour obtenir une réponse JSON {answer, id} équivalente à v1. Ainsi, pour migrer depuis /aichat/conversations, il n’est pas nécessaire de réécrire le client : il suffit de remplacer le chemin par /aichat2/conversations.
Si vous utilisez actuellement /aichat/conversations, l’ancienne interface restera disponible, et vous pourrez migrer à votre propre rythme.
Processus de demande
Pour utiliser l’API AI Chat v2, rendez-vous d’abord sur la console Ace Data Cloud afin d’obtenir votre API Token et le conserver pour plus tard.
Si vous n’êtes pas encore connecté ou inscrit, vous serez automatiquement redirigé vers la page de connexion afin de vous inviter à vous inscrire et à vous connecter ; une fois terminé, vous reviendrez automatiquement sur la page actuelle.
Un seul API Token permet d’appeler tous les services de la plateforme, il n’est pas nécessaire d’en demander un séparément pour chaque service. Lors de votre première demande, un quota gratuit vous sera offert afin de pouvoir l’essayer gratuitement ; lorsque le quota est insuffisant, vous pouvez recharger votre solde universel dans la console.
📘 Documentation complète : API AI Chat v2 →
Utilisation de base
L’utilisation la plus simple est exactement la même que v1 : envoyezmodel + question, et récupérez {answer, id}.
Exemple CURL :
model disponibles peuvent être visualisées directement dans la liste déroulante du panneau Try à droite ; les catégories courantes incluent :
- 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.1-pro,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.
Conversation multi-tours
Comme avec v1, envoyezstateful: true pour activer la sauvegarde de la conversation, et l’API renverra un id ; il suffit de renvoyer cet id lors des requêtes ultérieures pour continuer la conversation, sans avoir à maintenir vous-même l’historique des messages.
Première requête :
id :
statefulest défini surtruepar défaut ; l’omettre est équivalent à transmettre explicitementtrue. Si vous ne souhaitez pas que le serveur enregistre ce tour de conversation, vous pouvez définir explicitementstateful: false.
Réponse en streaming
v2 prend en charge deux formats de streaming, sélectionnés selon l’en-têteaccept :
Exemple NDJSON
text_delta :
Exemple SSE
L’utilisation deEventSource côté navigateur ne prend pas en charge les corps de requête personnalisés ; il est recommandé d’utiliser fetch + une analyse manuelle par segments \n\n :
Types d’événements de streaming
Pour les clients qui ne s’intéressent qu’à la réponse finale, concaténer le
content de tous les text_delta est équivalent à answer en mode application/json.
Entrée multimodale
Si l’entrée utilisateur contient des images ou des fichiers, transmettezmessage (un tableau) à la place de question. Chaque élément du tableau est un bloc de contenu :
text— Texte brut, champtextobligatoire.image_url— Image, champimage_url.urlobligatoire.file_url— Fichier (PDF, CSV, TXT, etc.), champfile_url.urlobligatoire.
Relation avec les references de v1
Afin d’assurer la compatibilité avec les anciens clients, v2 reconnaît toujours le champ references: ["https://...", ...] :
- Les suffixes d’URL sont
jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, automatiquement convertis en blocsimage_url; - Les autres extensions sont converties en blocs
file_url; - Si un
questionest également fourni, il est alors placé en tête en tant que bloctext.
/aichat2/conversations, et l’utilisation originale de references continue de fonctionner normalement.
Si vous avez besoin d’un contrôle plus précis (par exemple, placer plusieurs images entre des textes, ou si l’ordre est important), utilisez directement le tableau message.
Appels d’outils et MCP
L’amélioration principale de v2 est que le modèle peut appeler lui-même des outils pour accomplir des tâches en plusieurs étapes, ceci est activé par défaut, et ne nécessite aucune configuration supplémentaire dans la requête côté client. Cas courants :- L’utilisateur demande « Aidez-moi à chercher quelles sont les nouvelles expositions récentes à Shanghai » → le modèle appelle la recherche web intégrée → organise les résultats dans une réponse.
- L’utilisateur demande « Lisez ce PDF puis rédigez un résumé » → le modèle appelle file_read → rédige un résumé.
- L’utilisateur a autorisé Google Drive / GitHub / Notion, etc. dans Connections → le modèle peut appeler les outils MCP correspondants pour lire et écrire leurs données.
tool_use et tool_result, par exemple :
tool_use / tool_result / card / citation ; la sortie finale du modèle continue d’être diffusée via text_delta.
max_turns peut limiter le nombre maximal de cycles durant lesquels le modèle peut s’appeler lui-même via des outils dans cette requête ; la plage est de 1 à 500, et la valeur par défaut est 500 s’il est omis. Le définir à une valeur faible (par exemple, max_turns: 1) peut forcer une réponse unique et ne permettre aucun appel d’outil.
Exécution asynchrone et autorisation sans supervision
Si vos appels proviennent de Webhooks d’alerte, de CI/CD, de systèmes de surveillance ou d’autres tâches backend, vous pouvez définirasync: true pour que l’interface renvoie immédiatement l’ID de la tâche, tandis que l’exécution se poursuit en arrière-plan :
action: retrieve + id pour consulter le résultat de la conversation ; vous pouvez également fournir un callback_url, et une fois la tâche terminée, la plateforme enverra { status, answer, usage, error } par POST à votre adresse de rappel. callback_url doit utiliser http / https, et ne peut pas contenir directement localhost ou une adresse IP privée littérale.
Les tâches backend n’ont généralement personne pour cliquer sur une confirmation. Si vous souhaitez que certains Skill ou MCP Server exécutent des actions telles que l’envoi, la publication ou l’écriture en mode sans supervision, veuillez transmettre explicitement une liste de préautorisations dans le corps de la requête :
allowed_skills sont les slugs des Skill connectés ; les valeurs dans allowed_mcp_servers sont les slugs des MCP Server connectés. Les Skill / MCP Server non inclus dans la préautorisation ne peuvent toujours qu’être prévisualisés, exécutés en dry-run ou se voir refuser les opérations d’écriture en mode sans supervision.
Si un contrôle plus précis est nécessaire, vous pouvez également utiliser l’objet unattended_policy équivalent :
--unattended-confirm ou le mécanisme de sécurité correspondant ; sinon, il continuera en dry-run et n’exécutera pas directement les opérations d’écriture.
Reprendre une conversation en pause
Certains outils amènent le modèle à « poser une question à l’utilisateur » ; le modèle émet alors un événementask_user_question, et la conversation est figée dans l’état awaiting_user_input :
id et réinjectez la réponse via tool_results :
tool_use_id dans le corps de la requête doit être exactement identique au tool_id au moment de la pause ; sinon, une erreur 400 sera renvoyée. Lorsque tool_results est présent dans la requête, question / message / references sont tous ignorés.
Si l’utilisateur décide d’abandonner cette question, transmettez directement un nouveau question / message, et la plateforme marquera automatiquement l’appel d’outil en pause comme « ignoré par l’utilisateur ».
Gestion des conversations (CRUD)
v2 fournit une gestion légère des conversations via le champaction sur le même endpoint, sans nécessiter d’API supplémentaire.
action: retrieve —— Récupérer une conversation
messages, model, title, tools_used, etc.).
action: retrieve_batch —— Lister les résumés des conversations
{ items: [...], total }. Les résumés n’incluent pas messages, ils sont adaptés à une liste de barre latérale ; si l’utilisateur ouvre une conversation, utilisez ensuite action: retrieve pour récupérer séparément ses messages complets.
Paramètres de filtrage facultatifs : user_id, application_id, model_group, model.
action: update —— Modifier le titre ou réécrire l’historique
messages peut également être transmis, mais le serveur effectue une validation stricte du schéma (il doit être sous la forme ToolUseContent repliée), et renverra 400 en cas de non-conformité. En général, il est uniquement recommandé de l’utiliser pour modifier title.
action: delete —— Supprimer une conversation
{ id, success: true }. La suppression est irréversible, veuillez confirmer avant d’appeler cette action.
Migrer en douceur depuis v1
Si vous utilisez déjà/aichat/conversations, la migration vers v2 ne nécessite presque aucune modification de code :
- Remplacez l’URL
https://api.acedata.cloud/aichat/conversationsparhttps://api.acedata.cloud/aichat2/conversations. - Si vous transmettiez auparavant des noms de modèles v1 (tels que
gpt-3.5,gpt-4-browsing, etc.), il est recommandé de passer à des modèles contemporains lors de la migration vers v2 (tels quegpt-5.4,claude-opus-4-8,gemini-3.1-pro-preview, etc.). - Les champs du flux NDJSON restent rétrocompatibles : chaque événement
text_deltacontient toujoursdelta_answeretid, ainsi les clients qui analysent déjàdelta_answerligne par ligne n’ont pas besoin d’être modifiés.
message multimodal, SSE, appels d’outils, CRUD action) et avancer à votre rythme.
Gestion des erreurs
Les réponses d’erreur sont uniformisées comme suit :400 bad_request: champs obligatoires manquants,tool_use_idnon correspondant, schémamessagesinvalide, etc.401 invalid_token: l’en-têteauthorizationest incorrect.404 not_found: la conversation correspondant àidn’existe pas lors deaction: retrieve / update / delete.429 too_many_requests: la limite de débit a été déclenchée.500 chat_error: erreur du LLM en amont oucompletion_tokens=0pour ce tour (traité comme non consommé, aucun frais ne sera facturé).
{"type":"error","message":"..."}, puis le flux se termine immédiatement.

