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 هو أن النموذج يمكنه استدعاء الأدوات ذاتيًا لإكمال المهام متعددة الخطوات، وهذا مفعّل افتراضيًا، ولا يحتاج العميل إلى إجراء أي إعدادات إضافية في الطلب. السيناريوهات الشائعة:
  • يسأل المستخدم: «ساعدني في البحث عن المعارض الجديدة في شنغهاي مؤخرًا» → يستدعي النموذج web search المدمج → يرتب النتائج في إجابة.
  • يسأل المستخدم: «اقرأ هذا الـ 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 تحديد الحد الأقصى لعدد جولات الاستدعاء الذاتي للأدوات التي يمكن للنموذج تنفيذها في هذا الطلب، ويحدد النظام الأساسي الحد الافتراضي. يمكن لتعيينه بقيمة صغيرة (مثل max_turns: 1) فرض إجابة واحدة ومنع أي استدعاءات للأدوات.

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

إذا كان استدعاؤك يأتي من Webhook للتنبيهات، أو CI/CD، أو نظام مراقبة، أو مهام خلفية أخرى، فيمكنك تعيين async: true لجعل الواجهة تعيد معرّف المهمة فورًا وتواصل التنفيذ في الخلفية:
مثال على الاستجابة:
بعد ذلك، يمكنك استخدام action: retrieve + id للاستعلام عن نتائج المحادثة؛ ويمكنك أيضًا توفير callback_url، وبعد اكتمال المهمة سترسل المنصة { status, answer, usage, error } عبر POST إلى عنوان الاستدعاء الخلفي الخاص بك. يجب أن يستخدم callback_url بروتوكول http / https، ولا يمكن إدخال localhost أو عنوان IP خاص حرفيًّا مباشرةً. لا يكون هناك عادةً شخص قادر على النقر للتأكيد في المهام الخلفية. إذا كنت تريد أن تنفذ بعض Skills أو 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 الحالية الترحيل بسلاسة على مراحل. إذا كانت لديك أي أسئلة، فيُرجى التواصل مع فريق الدعم الفني لدينا في أي وقت.