Skip to main content
يُعد AI Chat v2 API (/aichat2/conversations) واجهة المحادثة من الجيل الجديد، وهو إصدار مطوّر بشكل شامل من AI Chat API. يستند إلى بساطة v1 وإدارة المحادثات متعددة الجولات، ويوسّعها عبر:
  • إدخال مستخدم متعدد الوسائط: أرسل النص + الصور + كتل الملفات مباشرةً عبر حقل message المنظّم، دون الحاجة إلى إرفاقها بشكل غير مباشر باستخدام references أولًا.
  • استدعاء أدوات بأسلوب Agent: يتضمن مجموعة أدوات مدمجة للبحث عبر الإنترنت وجلب صفحات الويب وقراءة الملفات وغيرها، كما يمكن إرفاق خوادم MCP المصرّح بها من المستخدم (Google Drive وNotion وSlack وGitHub وغيرها)، بحيث يستطيع النموذج استدعاء الأدوات ذاتيًا عدة مرات ضمن طلب واحد لإكمال المهام المعقدة.
  • أحداث تدفق منظّمة: عبر accept: text/event-stream أو application/x-ndjson، يمكنك الحصول على أحداث مثل text_delta وtool_use وtool_result وthinking وcitation وcard وartifact لكل token، مما يسهّل عرض كل نوع على حدة في الواجهة الأمامية.
  • قابل للمقاطعة / الاستئناف: عندما يحتاج النموذج إلى معلومات إضافية من المستخدم، سيصدر حدث ask_user_question ويتوقف مؤقتًا؛ وفي الاستدعاء التالي، يكفي إعادة ملء الإجابة عبر tool_results للمتابعة.
  • إجراءات CRUD جديدة: أكمل retrieve / retrieve_batch / update / delete عبر حقل action على نفس endpoint، دون الحاجة إلى API إضافية لإدارة المحادثات.
  • قائمة نماذج يتم تحديثها باستمرار: يتصل افتراضيًا بنماذج معاصرة مثل GPT-5.4 وClaude Opus 4.8 وClaude Sonnet 4.6 وGemini 3.1 Pro وGLM 5.1 وDeepSeek V4 وKimi K3 وغيرها.
وفي الوقت نفسه، فهو متوافق بالكامل مع v1 من ناحية جسم الطلب: يكفي تمرير model + question (+ اختياريًا stateful / id / references / preset) للحصول على استجابة JSON من {answer, id} مكافئة لـ v1، لذا لا تحتاج إلى إعادة كتابة العميل عند الترحيل من /aichat/conversations، بل يكفي تغيير المسار إلى /aichat2/conversations.
إذا كنت تستخدم حاليًا /aichat/conversations، فستستمر الواجهة القديمة في تقديم الخدمة، ويمكنك الترحيل بالوتيرة التي تناسبك.

عملية التقديم

لاستخدام AI Chat v2 API، انتقل أولًا إلى لوحة تحكم Ace Data Cloud للحصول على API Token الخاص بك، واحتفظ به للاستخدام لاحقًا. إذا لم تكن قد سجلت الدخول أو أنشأت حسابًا بعد، فسيتم تحويلك تلقائيًا إلى صفحة تسجيل الدخول لدعوتك إلى التسجيل وتسجيل الدخول، وبعد الإكمال ستعود تلقائيًا إلى الصفحة الحالية. يمكن لـ API Token واحد استدعاء جميع خدمات المنصة، ولا حاجة للتقديم بشكل منفصل لكل خدمة. ستحصل عند التقديم لأول مرة على رصيد مجاني لتجربة الخدمة مجانًا؛ وعند عدم كفاية الرصيد، يمكنك شحن الرصيد العام من لوحة التحكم.
📘 الوثائق الكاملة: AI Chat v2 API →

الاستخدام الأساسي

أبسط استخدام مطابق تمامًا لـ v1: مرّر model + question، واحصل على {answer, id}. مثال CURL:
النتيجة المُعادة:
مثال Python:
يمكن الاطلاع مباشرةً على قيم model المتاحة من القائمة المنسدلة في لوحة Try على اليمين، وتشمل الفئات الشائعة:
  • 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 وغيرها
  • 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 وغيرها
  • 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 وغيرها
  • xAI: grok-4 وغيرها
  • DeepSeek: deepseek-v4-pro وdeepseek-v4.1-flash وdeepseek-v4-flash وdeepseek-v3.2-exp وdeepseek-r1-0528 وغيرها
  • Moonshot: kimi-k3 وkimi-k2.6 وkimi-k2.5 وغيرها
  • Zhipu: glm-5.3 وglm-5.2 وglm-5.1 وglm-5 وglm-5-turbo وglm-4.7 وglm-4.5v وغيرها
للاطلاع على قواعد التسعير المحددة، راجع بطاقة Pricing في صفحة الخدمة.

محادثة متعددة الجولات

كما في v1، مرّر stateful: true لتفعيل حفظ المحادثة، وستُرجع API قيمة id؛ وفي الطلبات اللاحقة، يكفي إعادة إرسال id لمتابعة المحادثة، دون الحاجة إلى إدارة سجل messages بنفسك. الطلب الأول:
الإرجاع:
الطلب الثاني، مع تضمين id نفسه:
القيمة الافتراضية لـ stateful هي true، وحذفها يعادل تمرير true بشكل صريح. إذا كنت لا ترغب في أن يحفظ الخادم هذه الجولة من المحادثة، يمكنك تعيين stateful: false بشكل صريح.

الاستجابة المتدفقة

يدعم الإصدار v2 تنسيقين للتدفق، ويتم الاختيار وفقًا لترويسة accept:

مثال NDJSON

كل سطر في NDJSON هو حدث منظّم، وأكثرها شيوعًا هو text_delta:

مثال SSE

لا يدعم استخدام EventSource في المتصفح نص طلب مخصصًا، ويُوصى باستخدام fetch + التحليل اليدوي بالتقسيم وفقًا لـ \n\n:

أنواع الأحداث المتدفقة

بالنسبة إلى العملاء الذين يهتمون فقط بالإجابة النهائية، فإن تجميع content لكل text_delta يعادل answer في وضع application/json.

إدخال متعدد الوسائط

إذا كان إدخال المستخدم يتضمن صورة أو ملفًا، فمرّر message (مصفوفة) بدلًا من question. كل عنصر في المصفوفة هو كتلة محتوى:
أنواع الكتل المدعومة:
  • text — نص عادي، وحقل text مطلوب.
  • image_url — صورة، وحقل image_url.url مطلوب.
  • file_url — ملف (PDF أو CSV أو TXT وغيرها)، وحقل file_url.url مطلوب.

العلاقة مع references في v1

للتوافق مع العملاء القدامى، لا يزال v2 يتعرّف على الحقل references: ["https://...", ...]:
  • إذا كانت لاحقة URL هي jpg / jpeg / png / gif / bmp / webp / svg / heic / heif، فسيتم تحويلها تلقائيًا إلى كتلة image_url؛
  • يتم تحويل الامتدادات الأخرى إلى كتلة file_url؛
  • إذا تم توفير question أيضًا في الوقت نفسه، فسيتم وضعه في المقدمة ككتلة text.
لذلك، إذا كنت تريد فقط الترحيل من v1 ولا تريد تعديل جسم الطلب، فكل ما عليك هو تغيير المسار إلى /aichat2/conversations، وسيستمر استخدام references الأصلي في العمل كالمعتاد. إذا كنت تحتاج إلى تحكم أكثر دقة (مثل وضع عدة صور بين النصوص، أو عندما يكون الترتيب مهمًا جدًا)، فاستخدم مصفوفة message مباشرةً.

استدعاءات الأدوات و MCP

التحسين الأساسي في v2 هو أن النموذج يمكنه استدعاء الأدوات بشكل مستقل لإكمال المهام متعددة الخطوات، وهذا مفعّل افتراضيًا، ولا يحتاج العميل إلى إجراء أي إعدادات إضافية في الطلب. السيناريوهات الشائعة:
  • يسأل المستخدم: «ساعدني في البحث عن المعارض الجديدة في شنغهاي مؤخرًا» → يستدعي النموذج بحث الويب المدمج → ينظم النتائج في إجابة.
  • يسأل المستخدم: «اقرأ ملف PDF هذا ثم اكتب ملخصًا» → يستدعي النموذج file_read → يكتب ملخصًا.
  • يكون المستخدم قد فوّض Google Drive / GitHub / Notion وغيرها في Connections → يمكن للنموذج استدعاء أدوات MCP المقابلة لقراءة بياناتها وكتابتها.
في تدفقات NDJSON / SSE، يتم عرض استدعاءات الأدوات من خلال نوعي الأحداث tool_use و tool_result، على سبيل المثال:
إذا كنت لا تريد عرض تفاصيل استدعاءات الأدوات في الواجهة الأمامية، فما عليك سوى تجاهل أنواع الأحداث tool_use / tool_result / card / citation، إذ سيستمر تدفق الإخراج النهائي للنموذج عبر text_delta. يمكن لـ max_turns تقييد الحد الأقصى لعدد جولات استدعاء النموذج الذاتي للأدوات في هذا الطلب، ويتراوح من 1 إلى 500، والقيمة الافتراضية هي 500 عند حذفه. يمكن أن يؤدي تعيينه إلى قيمة صغيرة (مثل max_turns: 1) إلى فرض إجابة واحدة، وعدم السماح بأي استدعاء للأدوات.

التنفيذ غير المتزامن والتفويض غير المراقب

إذا كان استدعاؤك يأتي من Webhook للتنبيهات، أو CI/CD، أو نظام مراقبة، أو مهام خلفية أخرى، يمكنك تعيين async: true لجعل الواجهة تُرجع معرّف المهمة فورًا وتستمر في التنفيذ في الخلفية:
مثال على الاستجابة:
بعد ذلك، يمكنك استخدام action: retrieve + id للاستعلام عن نتيجة المحادثة؛ كما يمكنك أيضًا تقديم callback_url، وبعد اكتمال المهمة ستقوم المنصة بإرسال { status, answer, usage, error } عبر POST إلى عنوان رد الاتصال الخاص بك. يجب أن يستخدم callback_url بروتوكول http / https، ولا يمكن ملء localhost أو عنوان IP خاص حرفيًا مباشرةً. عادةً لا يوجد شخص يمكنه النقر للتأكيد في المهام الخلفية. إذا كنت تريد أن تقوم بعض Skill أو MCP Server بتنفيذ إجراءات مثل الإرسال، أو النشر، أو الكتابة في الوضع غير المراقب، فالرجاء تمرير قائمة تفويض مسبق صراحةً في جسم الطلب:
القيم في allowed_skills هي slug للـ Skill المتصلة؛ والقيم في allowed_mcp_servers هي slug للـ MCP Server المتصلة. لا يزال بإمكان Skill / MCP Server غير المدرجة في التفويض المسبق في الوضع غير المراقب المعاينة فقط، أو dry-run، أو رفض تنفيذ عمليات الكتابة. إذا كنت تحتاج إلى تحكم أكثر دقة، يمكنك أيضًا استخدام كائن unattended_policy المكافئ:
التفويض المسبق هو هاتان القائمتان نفسهما: تعني القائمة الفارغة عدم تفويض أي قدرة، ولا حاجة إلى حقل مفتاح إضافي. ملاحظة: يمثل التفويض المسبق فقط أن «هذا الطلب يسمح لهذه القدرات بتجاوز التأكيد اليدوي في الوضع غير المراقب». يجب أن تدعم Skill المحددة أيضًا --unattended-confirm أو آلية الأمان المقابلة؛ وإلا فستستمر في dry-run، ولن تنفذ عمليات الكتابة مباشرةً.

استئناف المحادثات المتوقفة

بعض الأدوات تجعل النموذج «يسأل المستخدم سؤالًا»، وعندها يصدر النموذج حدث ask_user_question، وتتجمد المحادثة في حالة awaiting_user_input:
اعرض هذا الحدث كبطاقة في الواجهة الأمامية ليختار المستخدم الإجابة، ثم ابدأ الطلب التالي باستخدام id نفسه، وأعد تعبئة الإجابة عبر tool_results:
يجب أن يكون tool_use_id في جسم الطلب مطابقًا تمامًا لـ tool_id عند التوقف؛ وسيتم إرجاع 400 إذا لم يكن متطابقًا. عند وجود tool_results في الطلب في الوقت نفسه، سيتم تجاهل كل من question / message / references. إذا قرر المستخدم التخلي عن هذا السؤال، فما عليه سوى تمرير question / message جديد، وستقوم المنصة تلقائيًا بوضع علامة «تخطاه المستخدم» على استدعاء الأداة المتوقف.

إدارة المحادثات (CRUD)

يوفر v2 إدارة خفيفة للمحادثات عبر حقل action على نفس endpoint، دون الحاجة إلى فتح API إضافي.

action: retrieve —— جلب محادثة

يعيد مستند المحادثة الكامل (بما في ذلك سجل messages، وmodel، وtitle، وtools_used، وغير ذلك).

action: retrieve_batch —— إدراج ملخصات المحادثات

يعيد { items: [...], total }. لا يحتوي الملخص على messages، وهو مناسب لقائمة الشريط الجانبي؛ إذا فتح المستخدم محادثة معيّنة، فاستخدم بعد ذلك action: retrieve لجلب رسائلها الكاملة بشكل منفصل. معلمات التصفية الاختيارية: user_id، وapplication_id، وmodel_group، وmodel.

action: update —— تغيير العنوان أو إعادة كتابة السجل

يمكن أيضًا تمرير messages، لكن الخادم سيجري تحققًا صارمًا من schema (ويجب أن تكون بصيغة ToolUseContent المطوية)، وسيعيد 400 إذا لم تتوافق. عمومًا، يُنصح باستخدامه فقط لتغيير title.

action: delete —— حذف محادثة

يعيد { id, success: true }. لا يمكن الاستعادة بعد الحذف، يُرجى التأكيد قبل الاستدعاء.

الترحيل السلس من v1

إذا كنت تستخدم بالفعل /aichat/conversations، فإن الترحيل إلى v2 لا يتطلب تقريبًا أي تعديل في الكود:
  1. غيّر URL من https://api.acedata.cloud/aichat/conversations إلى https://api.acedata.cloud/aichat2/conversations.
  2. إذا كنت تمرر سابقًا اسم نموذج v1 (مثل gpt-3.5، وgpt-4-browsing، وغير ذلك)، فيُنصح عند التبديل إلى v2 بالترقية إلى نماذج حديثة (مثل gpt-5.4، وclaude-opus-4-8، وgemini-3.1-pro-preview، وغير ذلك).
  3. تبقى حقول تدفق NDJSON متوافقة مع الإصدارات السابقة: لا يزال كل حدث text_delta يحمل delta_answer وid، لذلك لا يحتاج العميل الذي كان يحلل delta_answer سطرًا بسطر إلى أي تعديل.
بعد الترحيل، يمكن تمكين قدرات v2 الجديدة حسب الحاجة (مثل message متعدد الوسائط، وSSE، واستدعاء الأدوات، وCRUD عبر action) والتقدم بالوتيرة المناسبة.

معالجة الأخطاء

استجابة الخطأ موحدة كالتالي:
الأخطاء الشائعة:
  • 400 bad_request: حقول إلزامية مفقودة، أو عدم تطابق tool_use_id، أو schema غير صالح لـ messages، وغير ذلك.
  • 401 invalid_token: رأس authorization غير صحيح.
  • 404 not_found: لا توجد المحادثة المطابقة لـ id عند action: retrieve / update / delete.
  • 429 too_many_requests: تم تفعيل حد المعدل.
  • 500 chat_error: خطأ من LLM العلوي أو completion_tokens=0 في هذه الجولة (يُعامل على أنه غير مستهلك، ولن يتم فرض رسوم).
في الاستجابة المتدفقة، يُصدر الخطأ كحدث {"type":"error","message":"..."}، ثم ينتهي التدفق مباشرةً.

الخلاصة

يرتقي AI Chat v2 API بالمحادثات، مع الحفاظ على التوافق مع v1، من «أسئلة وأجوبة لجولة واحدة / جولات متعددة» إلى «محادثات قابلة للرصد وموجهة بالـ Agent»: إدخال متعدد الوسائط، واستدعاء الأدوات، وإمكانية الإيقاف / الاستئناف، وأحداث منظمة متدفقة، وCRUD مدمج. يُنصح بالاستفادة من v2 مباشرةً عند التكامل الجديد؛ أما تكاملات v1 الحالية فيمكنها الترحيل بسلاسة على مراحل. إذا كانت لديكم أي أسئلة، يُرجى التواصل مع فريق الدعم الفني لدينا في أي وقت.