Skip to main content
AI Chat v2 API (/aichat2/conversations) to interfejs dialogowy nowej generacji oraz kompleksowo ulepszona wersja AI Chat API. Na bazie zwięzłości v1 i hostowanej obsługi wieloturowych rozmów rozszerza on:
  • Wielomodalne dane wejściowe użytkownika: bezpośrednie przekazywanie tekstu + obrazów + bloków plików przez ustrukturyzowane pole message, bez konieczności uprzedniego pośredniego dołączania za pomocą references.
  • Wywoływanie narzędzi w stylu Agent: wbudowany zestaw narzędzi do wyszukiwania w sieci, pobierania stron internetowych, odczytu plików itp., z możliwością podłączenia autoryzowanych przez użytkownika serwerów MCP (Google Drive, Notion, Slack, GitHub itd.); model może w ramach jednego żądania autonomicznie wielokrotnie wywoływać narzędzia, aby realizować złożone zadania.
  • Ustrukturyzowane zdarzenia strumieniowe: za pomocą accept: text/event-stream lub application/x-ndjson można otrzymywać zdarzenia takie jak text_delta, tool_use, tool_result, thinking, citation, card, artifact itp. dla każdego tokenu, co ułatwia osobne renderowanie ich według odpowiednich typów w interfejsie frontendowym.
  • Możliwość przerwania / wznowienia: gdy model potrzebuje od użytkownika dodatkowych informacji, wysyła zdarzenie ask_user_question i wstrzymuje działanie; przy następnym wywołaniu wystarczy uzupełnić odpowiedź przez tool_results, aby kontynuować.
  • Nowe działania CRUD: na tym samym endpointcie można realizować retrieve / retrieve_batch / update / delete za pomocą pola action, bez potrzeby dodatkowego API do zarządzania rozmowami.
  • Stale aktualizowana lista modeli: domyślnie obsługiwane są współczesne modele, takie jak GPT-5.4, Claude Opus 4.8, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM 5.1, DeepSeek V4, Kimi K3 i inne.
Jednocześnie na poziomie body żądania jest on w pełni wstecznie kompatybilny z v1: wystarczy przekazać model + question (+ opcjonalnie stateful / id / references / preset), aby otrzymać równoważną z v1 odpowiedź JSON {answer, id}. Dlatego migracja z /aichat/conversations nie wymaga przepisywania klienta — wystarczy zmienić ścieżkę na /aichat2/conversations.
Jeśli obecnie używasz /aichat/conversations, stary interfejs nadal będzie dostępny, więc możesz migrować we własnym tempie.

Proces aplikacji

Aby korzystać z AI Chat v2 API, najpierw przejdź do konsoli Ace Data Cloud, aby uzyskać swój API Token i zachować go na później. Jeśli nie jesteś jeszcze zalogowany ani zarejestrowany, zostaniesz automatycznie przekierowany na stronę logowania, która zaprosi Cię do rejestracji i zalogowania się; po zakończeniu automatycznie wrócisz na bieżącą stronę. Jeden API Token umożliwia wywoływanie wszystkich usług platformy — nie musisz składać osobnego wniosku dla każdej usługi. Przy pierwszym wniosku otrzymasz bezpłatne środki, aby korzystać z usługi za darmo; gdy środki będą niewystarczające, możesz doładować wspólne saldo w konsoli.
📘 Pełna dokumentacja: AI Chat v2 API →

Podstawowe użycie

Najprostsze użycie jest dokładnie takie samo jak w v1: przekaż model + question i otrzymaj {answer, id}. Przykład CURL:
Wynik zwracany:
Przykład Python:
Dostępne wartości model można bezpośrednio zobaczyć na liście rozwijanej panelu Try po prawej stronie, a często używane kategorie obejmują:
  • 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 itd.
  • 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 itd.
  • 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 itd.
  • xAI: grok-4 itd.
  • DeepSeek: deepseek-v4-pro, deepseek-v4.1-flash, deepseek-v4-flash, deepseek-v3.2-exp, deepseek-r1-0528 itd.
  • Moonshot: kimi-k3, kimi-k2.6, kimi-k2.5 itd.
  • Zhipu: glm-5.3, glm-5.2, glm-5.1, glm-5, glm-5-turbo, glm-4.7, glm-4.5v itd.
Szczegółowe zasady rozliczeń znajdziesz na karcie Pricing na stronie usługi.

Wieloturowe rozmowy

Tak jak w v1, przekaż stateful: true, aby włączyć zapisywanie rozmowy; API zwróci id; w kolejnych żądaniach wystarczy przekazać z powrotem id, aby kontynuować rozmowę, bez konieczności samodzielnego utrzymywania historii messages. Pierwsze żądanie:
Zwracane:
Drugie żądanie, z tym samym id:
Domyślnie stateful ma wartość true; pominięcie go jest równoważne jawnemu przekazaniu true. Jeśli nie chcesz, aby serwer zapisywał tę turę rozmowy, możesz jawnie ustawić stateful: false.

Odpowiedź strumieniowa

v2 obsługuje dwa formaty strumieniowe, wybierane zgodnie z nagłówkiem accept:

Przykład NDJSON

Każdy wiersz NDJSON jest ustrukturyzowanym zdarzeniem, najczęściej występującym jest text_delta:

Przykład SSE

EventSource po stronie przeglądarki nie obsługuje niestandardowego ciała żądania; zaleca się użycie fetch + ręcznego parsowania przez dzielenie według \n\n:

Typy zdarzeń strumieniowych

W przypadku klientów, którym zależy wyłącznie na końcowej odpowiedzi, połączenie wszystkich wartości content ze zdarzeń text_delta jest równoważne wartości answer w trybie application/json.

Wejście multimodalne

Jeśli dane wejściowe użytkownika zawierają obrazy lub pliki, przekaż message (tablicę) zamiast question. Każdy element tablicy jest blokiem treści:
Obsługiwane typy bloków:
  • text — zwykły tekst, wymagane pole text.
  • image_url — obraz, wymagane image_url.url.
  • file_url — plik (PDF, CSV, TXT itp.), wymagane file_url.url.

Relacja z references w v1

Aby zachować zgodność ze starszymi klientami, v2 nadal rozpoznaje pole references: ["https://...", ...]:
  • Jeśli rozszerzenie URL to jpg / jpeg / png / gif / bmp / webp / svg / heic / heif, automatycznie przekształca się w blok image_url;
  • Inne rozszerzenia są przekształcane w blok file_url;
  • Jeśli jednocześnie podano question, jest ono umieszczane na początku jako blok text.
Dlatego jeśli chcesz tylko przejść z v1 i nie chcesz zmieniać treści żądania, wystarczy zmienić ścieżkę na /aichat2/conversations, a pierwotne użycie references nadal działa jak zwykle. Jeśli potrzebujesz bardziej szczegółowej kontroli (na przykład umieszczenia wielu obrazów między tekstem albo gdy kolejność jest ważna), użyj bezpośrednio tablicy message.

Wywoływanie narzędzi i MCP

Kluczowym ulepszeniem v2 jest to, że model może samodzielnie wywoływać narzędzia w celu realizacji zadań wieloetapowych, jest to domyślnie włączone i nie wymaga żadnej dodatkowej konfiguracji po stronie klienta w żądaniu. Typowe scenariusze:
  • Użytkownik pyta „Pomóż mi sprawdzić, jakie nowe wystawy są ostatnio w Szanghaju” → model wywołuje wbudowane web search → porządkuje wyniki w odpowiedź.
  • Użytkownik pyta „Przeczytaj ten PDF, a następnie napisz podsumowanie” → model wywołuje file_read → pisze podsumowanie.
  • Użytkownik autoryzował Google Drive / GitHub / Notion itd. w Connections → model może wywoływać odpowiednie narzędzia MCP, aby odczytywać i zapisywać ich dane.
W strumieniu NDJSON / SSE wywołania narzędzi są prezentowane za pomocą dwóch typów zdarzeń: tool_use i tool_result, na przykład:
Jeśli nie chcesz wyświetlać szczegółów wywołań narzędzi w frontendzie, po prostu zignoruj zdarzenia typu tool_use / tool_result / card / citation; końcowe wyjście modelu nadal będzie przesyłane strumieniowo przez text_delta. max_turns może ograniczyć maksymalną liczbę rund samowywołań narzędzi przez model w tym żądaniu, a domyślny limit jest określany przez platformę. Ustawienie małej wartości (na przykład max_turns: 1) może wymusić pojedynczą odpowiedź i nie pozwolić na żadne wywołania narzędzi.

Wykonywanie asynchroniczne i autoryzacja bez nadzoru

Jeśli Twoje wywołanie pochodzi z alertowego Webhooka, CI/CD, systemu monitorowania lub innego zadania działającego w tle, możesz ustawić async: true, aby interfejs natychmiast zwrócił ID zadania, a wykonywanie było kontynuowane w tle:
Przykład odpowiedzi:
Następnie możesz użyć action: retrieve + id, aby sprawdzić wynik konwersacji; możesz też podać callback_url, a po zakończeniu zadania platforma wyśle { status, answer, usage, error } metodą POST na Twój adres zwrotny. callback_url musi używać http / https i nie może bezpośrednio wskazywać localhost ani literałowego adresu prywatnego IP. Zwykle nie ma nikogo, kto mógłby kliknąć potwierdzenie dla zadań działających w tle. Jeśli chcesz, aby określone Skill lub MCP Server wykonywały działania takie jak wysyłanie, publikowanie lub zapisywanie w trybie bez nadzoru, jawnie przekaż listę wstępnej autoryzacji w treści żądania:
Wartości w allowed_skills są slugami połączonych Skill; wartości w allowed_mcp_servers są slugami połączonych MCP Server. Skill / MCP Server, które nie zostały uwzględnione we wstępnej autoryzacji, w trybie bez nadzoru nadal mogą jedynie wyświetlać podgląd, wykonywać dry-run lub odmówić wykonania operacji zapisu. Jeśli potrzebujesz bardziej szczegółowej kontroli, możesz także użyć równoważnego obiektu unattended_policy:
Wstępna autoryzacja to właśnie te dwie listy: pusta lista oznacza brak autoryzacji dla jakichkolwiek możliwości, bez potrzeby stosowania dodatkowego pola przełącznika. Uwaga: wstępna autoryzacja oznacza jedynie, że „to żądanie pozwala tym możliwościom pominąć ręczne potwierdzenie w trybie bez nadzoru”. Konkretny Skill nadal musi obsługiwać --unattended-confirm lub odpowiedni mechanizm bezpieczeństwa; w przeciwnym razie nadal wykona dry-run i nie przeprowadzi bezpośrednio operacji zapisu.

Wznawianie wstrzymanych konwersacji

Niektóre narzędzia powodują, że model „zadaje użytkownikowi pytanie zwrotne”; model emituje wtedy zdarzenie ask_user_question, a konwersacja zostaje zamrożona w stanie awaiting_user_input:
W frontendzie wyrenderuj to zdarzenie jako kartę, aby użytkownik mógł wybrać odpowiedź, a następnie rozpocznij kolejne żądanie z tym samym id, przekazując odpowiedź zwrotnie przez tool_results:
tool_use_id w treści żądania musi być całkowicie zgodne z tool_id z momentu wstrzymania; niezgodność zwróci 400. Gdy w żądaniu jednocześnie występuje tool_results, question / message / references zostaną wszystkie zignorowane. Jeśli użytkownik zdecyduje się porzucić to pytanie, wystarczy bezpośrednio przekazać nowe question / message, a platforma automatycznie oznaczy wstrzymane wywołanie narzędzia jako „pominięte przez użytkownika”.

Zarządzanie konwersacjami (CRUD)

v2 zapewnia lekkie zarządzanie konwersacjami przez pole action w tym samym endpointcie, bez potrzeby uruchamiania dodatkowego API.

action: retrieve —— pobieranie konwersacji

Zwraca kompletny dokument rozmowy (w tym historię messages, model, title, tools_used itd.).

action: retrieve_batch —— Wyświetlanie listy podsumowań rozmów

Zwraca { items: [...], total }. Podsumowania nie zawierają messages, więc nadają się do listy na pasku bocznym; jeśli użytkownik otworzy konkretną rozmowę, użyj następnie action: retrieve, aby osobno pobrać jej pełne wiadomości. Opcjonalne parametry filtrowania: user_id, application_id, model_group, model.

action: update —— Zmiana tytułu lub nadpisanie historii

Można również przekazać messages, ale serwer przeprowadzi rygorystyczną walidację schematu (musi mieć zwiniętą postać ToolUseContent); w przypadku niezgodności zwróci 400. Zazwyczaj zaleca się używanie tego wyłącznie do zmiany title.

action: delete —— Usuwanie rozmowy

Zwraca { id, success: true }. Po usunięciu nie można odzyskać rozmowy, dlatego przed wywołaniem upewnij się.

Płynna migracja z v1

Jeśli już używasz /aichat/conversations, migracja do v2 prawie nie wymaga zmian w kodzie:
  1. Zmień URL z https://api.acedata.cloud/aichat/conversations na https://api.acedata.cloud/aichat2/conversations.
  2. Jeśli wcześniej przekazywałeś nazwy modeli v1 (takie jak gpt-3.5, gpt-4-browsing itd.), podczas przejścia na v2 zaleca się aktualizację do współczesnych modeli (takich jak gpt-5.4, claude-opus-4-8, gemini-3.1-pro-preview itd.).
  3. Pola strumienia NDJSON pozostają wstecznie kompatybilne: każde zdarzenie text_delta nadal zawiera delta_answer oraz id, dlatego klient, który wcześniej analizował wiersz po wierszu delta_answer, nie wymaga zmian.
Po migracji możesz w razie potrzeby włączyć nowe możliwości v2 (multimodalne message, SSE, wywoływanie narzędzi, action CRUD), wdrażając je w odpowiednim tempie.

Obsługa błędów

Odpowiedzi błędów mają ujednoliconą postać:
Typowe błędy:
  • 400 bad_request: brak wymaganych pól, niezgodność tool_use_id, nieprawidłowy schemat messages itd.
  • 401 invalid_token: nagłówek authorization jest nieprawidłowy.
  • 404 not_found: rozmowa odpowiadająca id nie istnieje podczas action: retrieve / update / delete.
  • 429 too_many_requests: został uruchomiony limit szybkości.
  • 500 chat_error: błąd nadrzędnego LLM lub completion_tokens=0 w tej turze (traktowane jako niezużyte, opłata nie zostanie naliczona).
W odpowiedzi strumieniowej błędy są wysyłane jako zdarzenia {"type":"error","message":"..."}, po czym strumień natychmiast się kończy.

Wnioski

AI Chat v2 API, zachowując wsteczną kompatybilność z v1, podnosi rozmowy z poziomu „pytań i odpowiedzi jednokrotnych / wielokrotnych” do „obserwowalnych rozmów opartych na Agentach”: wejście multimodalne, wywoływanie narzędzi, możliwość wstrzymywania / wznawiania, strumieniowe ustrukturyzowane zdarzenia, wbudowane CRUD. Zaleca się, aby nowe integracje od razu korzystały z v2; istniejące integracje v1 mogą migrować płynnie etapami. W razie jakichkolwiek pytań skontaktuj się w dowolnym momencie z naszym zespołem wsparcia technicznego.