Skip to main content
Die AI Chat v2 API (/aichat2/conversations) ist eine Dialogschnittstelle der neuen Generation und eine umfassend aktualisierte Version der AI Chat API. Auf Grundlage der Einfachheit und des gehosteten Mehr-Runden-Dialogs von v1 erweitert sie Folgendes:
  • Multimodale Benutzereingaben: Text-, Bild- und Dateiblöcke können direkt über das strukturierte Feld message übergeben werden, ohne sie zuerst indirekt über references anzuhängen.
  • Agent-basierte Tool-Aufrufe: Eine Reihe integrierter Tools für Websuche, Webseiten-Abruf, Dateilesen usw. ist enthalten; außerdem können vom Benutzer autorisierte MCP-Server (Google Drive, Notion, Slack, GitHub usw.) eingebunden werden. Das Modell kann Tools innerhalb einer Anfrage mehrfach eigenständig aufrufen, um komplexe Aufgaben abzuschließen.
  • Strukturierte Streaming-Ereignisse: Über accept: text/event-stream oder application/x-ndjson können Token für Token Ereignisse wie text_delta, tool_use, tool_result, thinking, citation, card, artifact usw. abgerufen werden, damit sie im Frontend nach ihrem jeweiligen Typ separat gerendert werden können.
  • Unterbrechbar / fortsetzbar: Wenn das Modell zusätzliche Informationen vom Benutzer benötigt, sendet es ein ask_user_question-Ereignis und pausiert. Beim nächsten Aufruf kann die Antwort über tool_results zurückgegeben werden, um fortzufahren.
  • Neue CRUD-Aktionen: Über das Feld action können auf demselben Endpoint retrieve / retrieve_batch / update / delete ausgeführt werden, ohne eine zusätzliche API zur Sitzungsverwaltung zu benötigen.
  • Fortlaufend aktualisierte Modellliste: Standardmäßig sind aktuelle Modelle wie GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3 usw. angebunden.
Gleichzeitig ist sie auf Request-Body-Ebene vollständig abwärtskompatibel mit v1: Wenn nur model + question (+ optional stateful / id / references / preset) übergeben werden, erhalten Sie eine zu v1 gleichwertige {answer, id}-JSON-Antwort. Daher müssen Sie beim Umstieg von /aichat/conversations den Client nicht neu schreiben, sondern lediglich den Pfad zu /aichat2/conversations ändern.
Falls Sie derzeit /aichat/conversations verwenden, bleibt die alte Schnittstelle weiterhin verfügbar und Sie können in Ihrem eigenen Tempo migrieren.

Antragsprozess

Um die AI Chat v2 API zu verwenden, rufen Sie zunächst die Ace Data Cloud-Konsole auf, um Ihren API-Token zu erhalten und ihn als Reserve aufzubewahren. Falls Sie noch nicht angemeldet oder registriert sind, werden Sie automatisch zur Anmeldeseite weitergeleitet, um sich zu registrieren und anzumelden. Nach Abschluss kehren Sie automatisch zur aktuellen Seite zurück. Ein API-Token kann alle Dienste der Plattform aufrufen; es ist nicht erforderlich, für jeden Dienst einen separaten Antrag zu stellen. Beim ersten Antrag erhalten Sie ein kostenloses Guthaben, mit dem Sie den Dienst kostenlos testen können; bei unzureichendem Guthaben können Sie das allgemeine Guthaben in der Konsole aufladen.
📘 Vollständige Dokumentation: AI Chat v2 API →

Grundlegende Verwendung

Die einfachste Verwendung ist vollständig mit v1 identisch: Übergeben Sie model + question und erhalten Sie {answer, id}. CURL-Beispiel:
Rückgabewert:
Python-Beispiel:
Die verfügbaren model-Werte können direkt im Dropdown-Menü des Try-Bereichs auf der rechten Seite angezeigt werden. Häufig verwendete Kategorien umfassen:
  • 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 usw.
  • 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 usw.
  • 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 usw.
  • xAI: grok-4 usw.
  • DeepSeek: deepseek-v4-pro, deepseek-v4.1-flash, deepseek-v4-flash, deepseek-v3.2-exp, deepseek-r1-0528 usw.
  • Moonshot: kimi-k3, kimi-k2.6, kimi-k2.5 usw.
  • Zhipu: glm-5.3, glm-5.2, glm-5.1, glm-5, glm-5-turbo, glm-4.7, glm-4.5v usw.
Die konkreten Abrechnungsregeln finden Sie auf der Service-Seite in der Pricing-Karte.

Mehr-Runden-Dialog

Wie bei v1 aktiviert die Übergabe von stateful: true die Speicherung der Sitzung. Die API gibt eine id zurück; bei nachfolgenden Anfragen genügt es, die id erneut mitzusenden, um den Dialog fortzusetzen, ohne dass Sie den Nachrichtenverlauf selbst verwalten müssen. Erste Anfrage:
Rückgabe:
Zweite Anfrage, mit derselben id:
stateful ist standardmäßig true; das Weglassen ist gleichwertig mit der expliziten Übergabe von true. Wenn Sie nicht möchten, dass der Server diese Gesprächsrunde speichert, können Sie explizit stateful: false setzen.

Streaming-Antwort

v2 unterstützt zwei Streaming-Formate, die über den accept-Header ausgewählt werden:

NDJSON-Beispiel

Jede NDJSON-Zeile ist ein strukturiertes Ereignis; am häufigsten ist text_delta:

SSE-Beispiel

Die Verwendung von EventSource im Browser unterstützt keine benutzerdefinierten Request-Bodys; es wird empfohlen, fetch + manuelles Parsen durch Aufteilen bei \n\n zu verwenden:

Typen von Streaming-Ereignissen

Für Clients, die nur an der endgültigen Antwort interessiert sind, entspricht das Zusammenfügen aller content-Werte von text_delta dem answer im Modus application/json.

Multimodale Eingabe

Wenn die Benutzereingabe Bilder oder Dateien enthält, übergeben Sie message (ein Array) anstelle von question. Jedes Array-Element ist ein Inhaltsblock:
Unterstützte Blocktypen:
  • text — Normaler Text, das Feld text ist erforderlich.
  • image_url — Bild, image_url.url ist erforderlich.
  • file_url — Datei (PDF, CSV, TXT usw.), file_url.url ist erforderlich.

Beziehung zu v1 references

Zur Kompatibilität mit alten Clients erkennt v2 weiterhin das Feld references: ["https://...", ...]:
  • Wenn das URL-Suffix jpg / jpeg / png / gif / bmp / webp / svg / heic / heif ist, wird es automatisch in einen image_url-Block umgewandelt;
  • andere Erweiterungen werden in einen file_url-Block umgewandelt;
  • wenn gleichzeitig noch question bereitgestellt wird, wird es als text-Block vorangestellt.
Wenn Sie daher nur von v1 migrieren möchten und den Request-Body nicht ändern wollen, ersetzen Sie einfach den Pfad durch /aichat2/conversations; die ursprüngliche Verwendung von references funktioniert weiterhin wie gewohnt. Wenn Sie eine präzisere Steuerung benötigen (z. B. mehrere Bilder zwischen Texten platzieren möchten oder die Reihenfolge wichtig ist), verwenden Sie direkt das message-Array.

Tool-Aufrufe und MCP

Die zentrale Erweiterung von v2 besteht darin, dass das Modell Tools eigenständig aufrufen kann, um mehrstufige Aufgaben zu erledigen, dies ist standardmäßig aktiviert, ohne dass der Client zusätzliche Konfigurationen in der Anfrage vornehmen muss. Häufige Szenarien:
  • Der Nutzer fragt „Hilf mir, nachzusehen, welche neuen Ausstellungen es kürzlich in Shanghai gibt“ → Das Modell ruft die integrierte Websuche auf → Es bereitet die Ergebnisse zu einer Antwort auf.
  • Der Nutzer fragt „Lies dieses PDF und schreibe dann eine Zusammenfassung“ → Das Modell ruft file_read auf → Es schreibt eine Zusammenfassung.
  • Der Nutzer hat in Connections Google Drive / GitHub / Notion usw. autorisiert → Das Modell kann die entsprechenden MCP-Tools zum Lesen und Schreiben ihrer Daten aufrufen.
Im NDJSON-/SSE-Stream werden Tool-Aufrufe durch die beiden Ereignistypen tool_use und tool_result dargestellt, zum Beispiel:
Wenn Sie die Details von Tool-Aufrufen nicht im Frontend anzeigen möchten, ignorieren Sie einfach die Ereignistypen tool_use / tool_result / card / citation; die endgültige Ausgabe des Modells wird weiterhin über text_delta gestreamt. max_turns kann die maximale Anzahl der Runden begrenzen, in denen das Modell innerhalb dieser Anfrage selbstständig Tools aufrufen darf; das Standardlimit wird von der Plattform festgelegt. Wenn Sie es niedrig setzen (z. B. max_turns: 1), können Sie eine einmalige Antwort erzwingen und jegliche Tool-Aufrufe verhindern.

Asynchrone Ausführung und unbeaufsichtigte Autorisierung

Wenn Ihr Aufruf von einem Alarm-Webhook, CI/CD, Überwachungssystem oder einer anderen Hintergrundaufgabe stammt, können Sie async: true setzen, damit die Schnittstelle sofort eine Aufgaben-ID zurückgibt und im Hintergrund weiterarbeitet:
Rückgabebeispiel:
Danach können Sie mit action: retrieve + id das Sitzungsergebnis abfragen; Sie können auch callback_url bereitstellen, woraufhin die Plattform nach Abschluss der Aufgabe { status, answer, usage, error } per POST an Ihre Callback-Adresse sendet. callback_url muss http / https verwenden und darf weder direkt localhost noch eine private IP-Literaladresse enthalten. Bei Hintergrundaufgaben kann normalerweise niemand zur Bestätigung klicken. Wenn Sie möchten, dass bestimmte Skills oder MCP Server im unbeaufsichtigten Modus Aktionen wie Senden, Veröffentlichen oder Schreiben ausführen, übergeben Sie bitte explizit eine Vorautorisierungsliste im Request-Body:
Die Werte in allowed_skills sind die Slugs bereits verbundener Skills; die Werte in allowed_mcp_servers sind die Slugs bereits verbundener MCP Server. Skills / MCP Server, die nicht in die Vorautorisierung aufgenommen wurden, können im unbeaufsichtigten Modus weiterhin nur eine Vorschau anzeigen, dry-run ausführen oder die Ausführung von Schreibvorgängen ablehnen. Wenn eine feinere Steuerung erforderlich ist, können Sie auch das gleichwertige Objekt unattended_policy verwenden:
Die Vorautorisierung besteht aus diesen beiden Listen selbst: Eine leere Liste autorisiert keinerlei Fähigkeiten, ohne dass ein zusätzliches Schalterfeld erforderlich ist. Hinweis: Die Vorautorisierung bedeutet nur, dass „diese Fähigkeiten bei dieser Anfrage im unbeaufsichtigten Modus die manuelle Bestätigung überspringen dürfen“. Der jeweilige Skill muss weiterhin --unattended-confirm oder den entsprechenden Sicherheitsmechanismus unterstützen; andernfalls bleibt er bei dry-run und führt Schreibvorgänge nicht direkt aus.

Angehaltene Unterhaltungen fortsetzen

Einige Tools veranlassen das Modell dazu, „dem Nutzer eine Rückfrage zu stellen“. Das Modell sendet dann ein ask_user_question-Ereignis, und die Unterhaltung wird im Status awaiting_user_input eingefroren:
Rendern Sie dieses Ereignis im Frontend als Karte, damit der Nutzer eine Antwort auswählen kann, und starten Sie dann mit derselben id die nächste Anfrage, indem Sie die Antwort über tool_results zurückschreiben:
tool_use_id im Request-Body muss vollständig mit der tool_id zum Zeitpunkt der Unterbrechung übereinstimmen; bei Abweichung wird 400 zurückgegeben. Wenn in der Anfrage gleichzeitig tool_results vorhanden ist, werden question / message / references alle ignoriert. Wenn der Nutzer beschließt, diese Frage aufzugeben, übergeben Sie einfach ein neues question / message; die Plattform markiert den angehaltenen Tool-Aufruf automatisch als „vom Nutzer übersprungen“.

Sitzungsverwaltung (CRUD)

v2 bietet über das Feld action auf demselben Endpoint eine leichtgewichtige Sitzungsverwaltung, ohne dass eine zusätzliche API erforderlich ist.

action: retrieve —— Eine Sitzung abrufen

Gibt das vollständige Sitzungsdokument zurück (einschließlich messages-Verlauf, model, title, tools_used usw.).

action: retrieve_batch —— Sitzungzusammenfassungen auflisten

Gibt { items: [...], total } zurück. Zusammenfassungen enthalten keine messages und eignen sich für Seitenleistenlisten; wenn ein Benutzer eine Sitzung öffnet, rufen Sie anschließend mit action: retrieve deren vollständige Nachrichten separat ab. Optionale Filterparameter: user_id, application_id, model_group, model.

action: update —— Titel ändern oder Verlauf überschreiben

messages kann ebenfalls übergeben werden, aber der Server führt eine strenge Schema-Validierung durch (es muss die zusammengefasste ToolUseContent-Form sein); bei Abweichungen wird 400 zurückgegeben. Im Allgemeinen wird empfohlen, dies nur zum Ändern von title zu verwenden.

action: delete —— Eine Sitzung löschen

Gibt { id, success: true } zurück. Nach dem Löschen ist keine Wiederherstellung möglich; bitte bestätigen Sie dies vor dem Aufruf.

Reibungslose Migration von v1

Wenn Sie bereits /aichat/conversations verwenden, erfordert die Migration zu v2 nahezu keine Codeänderungen:
  1. Ändern Sie die URL von https://api.acedata.cloud/aichat/conversations zu https://api.acedata.cloud/aichat2/conversations.
  2. Wenn Sie zuvor v1-Modellnamen verwendet haben (wie gpt-3.5, gpt-4-browsing usw.), wird beim Wechsel zu v2 empfohlen, auf aktuelle Modelle zu aktualisieren (wie gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview usw.).
  3. Die Felder des NDJSON-Streams bleiben abwärtskompatibel: Jedes text_delta-Ereignis enthält weiterhin delta_answer und id, daher müssen Clients, die ursprünglich delta_answer zeilenweise parsen, nicht geändert werden.
Nach der Migration können Sie die neuen Fähigkeiten von v2 nach Bedarf aktivieren (multimodale message, SSE, Tool-Aufrufe, action-CRUD) und schrittweise vorgehen.

Fehlerbehandlung

Fehlerantworten haben ein einheitliches Format:
Häufige Fehler:
  • 400 bad_request: Pflichtfelder fehlen, tool_use_id stimmt nicht überein, messages-Schema ist ungültig usw.
  • 401 invalid_token: Der authorization-Header ist nicht korrekt.
  • 404 not_found: Die Sitzung, die der id bei action: retrieve / update / delete entspricht, existiert nicht.
  • 429 too_many_requests: Das Ratenlimit wurde ausgelöst.
  • 500 chat_error: Der vorgelagerte LLM hat einen Fehler gemeldet oder completion_tokens=0 in dieser Runde (wird als nicht verbraucht behandelt und nicht berechnet).
In Streaming-Antworten werden Fehler als Ereignis {"type":"error","message":"..."} ausgegeben, unmittelbar danach endet der Stream.

Fazit

Die AI Chat v2 API bleibt mit v1 abwärtskompatibel und erweitert Gespräche von „Einzelrunden- / Mehrfachrunden-Fragen und Antworten“ zu „agentenbasierten beobachtbaren Gesprächen“: multimodale Eingaben, Tool-Aufrufe, pausierbar / fortsetzbar, strukturierte Streaming-Ereignisse, integriertes CRUD. Für neue Integrationen wird empfohlen, direkt v2 zu verwenden; bestehende v1-Integrationen können schrittweise reibungslos migriert werden. Bei Fragen kontaktieren Sie jederzeit unser technisches Support-Team.