ملاحظة المؤلف: انطلاقًا من اختبارات عملية علنية لثلاثة وكلاء شخصيين، نفكّك مشكلات طبقة الواجهات الكامنة وراء قصور القدرة التنفيذية لدى الوكلاء، ونقدّم قائمة إصلاحات تشمل استدعاء الأدوات، وإعادة المحاولة عند الأخطاء، والتوافق مع التنسيقات، والتحكم في التكلفة.
نشرت 36Kr في 4 نوفمبر 2026 مقال «الوكلاء الشخصيون على الطاولة: من كشف ضعفه أولاً؟»، ووضعت ثلاثة وكلاء شخصيين على الطاولة نفسها وأجرت اختبارًا عمليًا. الاستنتاج الذي تخلص إليه هذه التقييمات المقارنة عادةً متطابق: الوكيل لا يفتقر إلى «القدرة على الكلام»، بل يفتقر إلى «إنجاز المهمة حتى النهاية». المسألة الأساسية التي يركز عليها هذا المقال هي قصور القدرة التنفيذية لدى الوكيل ينبع في الغالب من طبقة الواجهات البرمجية، وليس من النموذج نفسه فحسب.
هذا ليس مقالًا آخر لترتيب الوكلاء بحسب «أيها أذكى». لن نعيد سرد درجات التقييم التفصيلية الواردة في المقال الأصلي، بل سنصنّف حالات فشل التنفيذ الشائعة في هذه الاختبارات إلى 5 فئات، ثم نربط كل فئة بما يمكن تعديله في تصميم واجهات الوكيل.
القيمة الأساسية: بعد قراءة هذا المقال، ستعرف معاملات الواجهة التي ينبغي فحصها أولًا عند بناء وكيل، وكيف تتعامل مع الإخفاقات، وكيف تنتقل بسلاسة بين صيغتي واجهة OpenAI وAnthropic.
نقاط القصور الأساسية في القدرة التنفيذية لواجهة الوكيل
هدف الوكيل الشخصي هو إنجاز المهمة كاملة نيابة عن المستخدم، مثل حجز التذاكر أو ترتيب البريد أو تجميع المواد أو التعامل مع صفحات الويب. وبمجرد أن تفشل خطوة واحدة في المنتصف، سيشعر المستخدم بأنه «لم يُنجز المهمة». وإذا تتبعنا أسباب ظواهر الفشل الشائعة في الاختبارات العملية، فسنصل في الغالب إلى الفئات الخمس التالية من مشكلات الواجهة.
| قصور القدرة التنفيذية | المظهر النموذجي | السبب الجذري في طبقة الواجهة | اتجاه الإصلاح |
|---|---|---|---|
| عدم استقرار استدعاء الأدوات | اختيار أداة خاطئة، أو نقص حقول في المعاملات، أو تنسيق غير صالح | وصف الأداة غامض، والمخطط (schema) لا يفرض قيودًا | تبسيط مجموعة الأدوات، وكتابة مخطط معاملات صارم |
| انقطاع سلسلة المهام متعددة الخطوات | يصل إلى الخطوة الثالثة أو الرابعة ثم ينسى الهدف | إدارة السياق بشكل فضفاض، وعدم إعادة نتائج الأدوات بالشكل الصحيح | توحيد سجل الرسائل، وضغط النتائج الوسيطة |
| غياب شبكة أمان عند الفشل الخارجي | يستسلم عند الحد من المعدل أو انتهاء المهلة، أو يزعم الإنجاز كذبًا | لا يميّز بين أنواع الأخطاء، ولا توجد استراتيجية لإعادة المحاولة | إعادة المحاولة المتدرجة حسب رمز الحالة، مع المهلات والتدرج الاحتياطي |
| نتائج غير قابلة للتحقق | يرد «تم»، لكنه لم يفعل شيئًا فعليًا | غياب إيصال التنفيذ والتحقق من الحالة | طلب إيصال منظم في كل خطوة |
| تكلفة وزمن استجابة خارج السيطرة | استدعاءات متكررة، ومهمة واحدة تستهلك كمية كبيرة من الرموز (tokens) | لا يوجد حد أقصى لعدد الخطوات، ولا استخدام للتخزين المؤقت | تحديد أقصى عدد جولات، واستخدام النماذج على طبقات، والاستفادة من التخزين المؤقت |
شرح مفصل لأهم نقاط القصور في واجهات الوكيل
قد تبدو الفئتان الأوليان من القصور وكأنهما مشكلة في قدرات النموذج، لكن الأساليب الهندسية قادرة على حل معظمهما. أما أكثر أسباب عدم استقرار استدعاء الأدوات شيوعًا فهو إعطاء النموذج عشرات الأدوات دفعة واحدة، مع أوصاف متداخلة، فيختار الخطأ بطبيعة الحال. قلّص الأدوات إلى ما تحتاجه المهمة الحالية فعلاً، واكتب لكل معامل نوعه وقيم التعداد وما إذا كان مطلوبًا، وستنخفض نسبة الأخطاء عادةً بشكل واضح. أما انقطاع سلسلة المهام متعددة الخطوات فيحدث غالبًا عند إعادة نتائج الأدوات: إذا لم تُربط النتيجة بمعرّف الاستدعاء المقابل وفق البروتوكول، فلن يستطيع النموذج التأكد مما إذا كانت الخطوة السابقة قد نجحت فعلاً.
أما الفئات الثلاث الأخيرة فهي مشكلات هندسية بحتة. يجب أن يعرف الوكيل المؤهل بوضوح «ماذا يفعل عند الفشل» و«كيف يثبت أنه أنجز المهمة». في الاختبارات العملية، أكثر ما يُخيّب المستخدم ليس الفشل نفسه، بل التظاهر بالنجاح بعد الفشل. لذلك فإن آلية الإيصالات وتصنيف الأخطاء في طبقة الواجهة أكثر فائدة من استبدال النموذج بآخر أكبر.
البدء السريع مع واجهة Agent: قائمة فحص من 5 خطوات
لا تعتمد الخطوات التالية على أي إطار عمل بعينه؛ فهي تصلح سواء كتبت حلقة Agent يدويًا أو استخدمت إطار Agent جاهزًا. ووفقًا لمتطلبات هذا المقال، لن نضع شيفرة برمجية هنا، بل سنشرح جميع الإعدادات الأساسية في جدول.
الخطوة 1: توحيد نقطة دخول واجهة Agent
يحتاج Agent عادةً إلى مزيج من “نموذج قوي للتخطيط ونموذج سريع للتنفيذ”. وإذا كان كل نموذج يتصل بمزود مختلف على حدة، فستختلف طريقة المصادقة وتنسيقات الأخطاء ومعايير الفوترة، ما يرفع كلفة استكشاف الأخطاء. الطريقة الأقل عناءً هي استخدام نقطة دخول موحدة متوافقة مع تنسيقي واجهات OpenAI وAnthropic، بحيث يكفي تغيير base_url وapi_key وmodel لتبديل النموذج.
| بند الإعداد | الغرض | القيمة المقترحة |
|---|---|---|
base_url |
عنوان الواجهة | وفق وثائق مزود الخدمة، مثل العنوان الوارد في وثائق APIYI على docs.apiyi.com |
api_key |
بيانات اعتماد المصادقة | ضعه في متغير بيئة، ولا تكتبه في الموجه أو السجلات |
model |
اسم النموذج | اضبط التخطيط والتنفيذ بشكل منفصل لتسهيل استبدال كل منهما على حدة |
timeout |
مهلة الطلب الواحد | اضبطها حسب نوع المهمة، ووسّعها قليلًا للمهام ذات المخرجات الطويلة |
max_retries |
عدد محاولات إعادة المحاولة التلقائية في SDK | أبقِ القيمة صغيرة، ودع طبقة منطق الأعمال تتولى إعادة المحاولة المتدرجة |
🚀 بدء سريع: يوفر APIYI استدعاءات API لنماذج اللغة الكبيرة السائدة الواردة في هذا المقال، وهو متوافق مع تنسيقي واجهات OpenAI وAnthropic معًا؛ ويكفي تعديل
base_urlفي SDK الحالي للاتصال. راجع تعليمات الاتصال في مركز توثيق APIYI: docs.apiyi.com.
الخطوة 2: اجعل معاملات استدعاء أدوات الوكيل صارمة
استدعاء الأدوات هو البوابة الأولى لقدرة الوكيل على التنفيذ. وكلما كانت المعاملات أكثر صرامة، قلّت مساحة «الارتجال» لدى النموذج، وانخفض معدل الأخطاء.
| المعامل | المعنى | توصية عملية |
|---|---|---|
tools |
قائمة الأدوات القابلة للاستدعاء | لا تعرض في الجولة الواحدة إلا الأدوات التي تحتاجها المرحلة الحالية، واكتب في الوصف «متى تُستخدم ومتى لا تُستخدم» |
tool_choice |
استراتيجية اختيار الأداة | حدّد الأداة عند الحاجة إلى فرض إجراء معيّن، واضبطها على الوضع التلقائي في الأسئلة المفتوحة |
| مخطط معاملات الأداة | بنية مدخلات الأداة | أدرج الحقول الإلزامية ضمن required، واستخدم التعدادات بدل النص الحر حيثما أمكن |
response_format |
مخرجات منظّمة | اطلب أن يكون الإيصال النهائي بصيغة JSON لتسهيل التحقق البرمجي |
max_tokens |
الحد الأقصى للمخرجات | إلزامي في صيغة Anthropic، ويجب تقديره حسب المهمة |
temperature |
العشوائية | اخفضه في خطوات التنفيذ للحدّ من اختلاف الإجراءات عند المدخل نفسه |
الخطوة 3: التعامل مع فروق الصيغ بين OpenAI وAnthropic
كثيرًا ما يبدو الوكيل «أغبى فجأة» بعد تبديل النموذج، والسبب ليس النموذج نفسه، بل اختلاف بروتوكول الأدوات بين الصيغتين، مما يؤدي إلى إعادة إرسال النتائج في غير موضعها. يوضح الجدول التالي أكثر الفروق التي يسهل الوقوع في مشكلاتها.
| وجه المقارنة | صيغة OpenAI Chat Completions | صيغة Anthropic Messages |
|---|---|---|
| موضع موجه النظام | يوضع داخل messages بدور system | يُستخدم المعامل العلوي system |
| تعريف الأدوات | type: function مع كائن function |
name وdescription وinput_schema |
| بدء النموذج للاستدعاء | tool_calls داخل رسالة المساعد |
كتلة محتوى من النوع tool_use |
| إعادة نتائج الأداة | رسالة بدور tool مع tool_call_id |
كتلة محتوى tool_result داخل رسالة user، مرتبطة بـ tool_use_id |
| الحد الأقصى للمخرجات | max_tokens اختياري |
max_tokens إلزامي |
لا تفضيل بين الصيغتين، والمهم هو أن تحتفظ داخل الوكيل بتمثيل وسيط واحد فقط، ثم تحوّله إلى الصيغة المطلوبة عند إرسال الطلب. وإذا كنت تستخدم نقطة دخول تدعم الصيغتين معًا، مثل APIYI، فيمكنك ترك نماذج Claude تستخدم صيغة Anthropic الأصلية، وترك النماذج الأخرى تستخدم صيغة OpenAI، مع الحفاظ على أكمل قدرات استدعاء الأدوات لدى كل منها.
الخطوة 4: تصميم خطة احتياطية عند فشل واجهة Agent
إنّ أسلوبي “الفشل يعني الاستسلام فورًا” و”الفشل مع التظاهر بالنجاح” هما أكثر سلوكين يُفسدان تجربة المستخدم في الاختبار الفعلي. الطريقة الصحيحة هي تصنيف الأخطاء حسب نوعها أولاً، ثم تحديد ما إذا كان يجب إعادة المحاولة، أو الانتقال إلى خطة بديلة، أو إخبار المستخدم بالحقيقة.
| نوع الخطأ | الأسباب الشائعة | استراتيجية تعامل Agent |
|---|---|---|
| 400 خطأ في المعاملات | معاملات الأداة غير صالحة، أو تنسيق الرسائل غير متوافق | لا تُعِد المحاولة بشكل أعمى، بل أعد رسالة الخطأ إلى النموذج ليصححها مرة واحدة |
| 401 / 403 خطأ في المصادقة | انتهاء صلاحية مفتاح API أو نقص الصلاحيات | أوقف التنفيذ فورًا واطلب من المستخدم التحقق من الإعدادات |
| 429 تجاوز حد المعدل | ارتفاع التزامن أو عدم كفاية الحصة | أعد المحاولة بتراجع أُسّي، وبدّل إلى نموذج احتياطي عند الحاجة |
| 5xx خطأ من جهة الخادم | تقلبات في خدمة المنبع | عدد محدود من المحاولات، وعند تجاوز الحد الأقصى انتقل إلى خطة بديلة |
| انتهاء المهلة | مخرجات طويلة أو تقلبات في الشبكة | حوّل إلى الإخراج المتدفق، أو قسّم المهمة إلى أجزاء أصغر ثم أعد المحاولة |
وهناك تفصيل يسهل تجاهله: الأدوات ذات الآثار الجانبية يجب أن تكون متسقة التكرار (idempotent). في عمليات مثل إرسال البريد الإلكتروني أو تنفيذ طلب شراء أو الكتابة في قاعدة البيانات، يجب التأكد قبل إعادة المحاولة من أن المحاولة السابقة قد نُفِّذت فعلاً، وإلا فسيقوم Agent بتنفيذ الأمر نفسه مرتين.
الخطوة 5: إضافة إيصالات استلام وبوابات تكلفة إلى الوكيل
يجب أن يعيد كل أداة بعد تنفيذها إيصالًا منظمًا يحتوي على الأقل على ثلاثة حقول: «هل نجح التنفيذ؟»، و«ما الذي تم فعله؟»، و«معرّف النتيجة الرئيسية». وقبل أن يعلن الوكيل اكتمال المهمة، يجب أن يتحقق البرنامج — وليس النموذج — من الإيصال؛ وبذلك نمنع آليًا «الادعاء الكاذب بإتمام المهمة».
أما من ناحية التكلفة، فمن المستحسن إضافة ثلاث بوابات: الحد الأقصى لعدد دورات التكرار، وميزانية token للمهمة الواحدة، وكشف الاستدعاءات المتكررة. يمكن توزيع أعمال التخطيط والتنفيذ والتصنيف على نماذج من مستويات مختلفة، ويُفضّل إبقاء موجهات النظام الطويلة وتعريفات الأدوات مستقرة قدر الإمكان للاستفادة من التخزين المؤقت للموجهات. أما أسعار الإدخال والإخراج والتخزين المؤقت الفعلية، وقواعد الفوترة، فاعتمد فيها على البيانات الفعلية في صفحة أسعار APIYI https://docs.apiyi.com/models؛ ولا يقدّم هذا المقال أي أرقام أسعار غير متحقق منها.
💡 اقتراح: في مرحلة البناء، شغّل الدورة الكاملة أولًا بحمل صغير، ثم أضف الأدوات تدريجيًا. عبر APIYI apiyi.com يمكنك، باستخدام مفتاح API واحد، مقارنة استقرار النماذج المختلفة في استدعاء الأدوات بسرعة؛ ولا يلزم للتبديل سوى تغيير حقل
model.
مرجع لاختيار واجهات API حسب الطبقات في الوكيل
نادرًا ما يستخدم الوكيل القوي في التنفيذ نموذجًا واحدًا فقط. وتقسيم الطبقات حسب المسؤولية يزيد الاستقرار ويسهّل التحكم في التكلفة.
| طبقة المسؤولية | متطلبات القدرات | منهجية الاختيار | المنصات المتاحة | مرجع السعر |
|---|---|---|---|---|
| طبقة التخطيط | سياق طويل، واستدلال معقد، وتفكيك المهام | اختر نموذجًا رائدًا بقدرات استدلال قوية | APIYI apiyi.com، وواجهة API الرسمية | وفقًا لصفحة أسعار APIYI |
| طبقة التنفيذ | استدعاء أدوات مستقر واستجابة سريعة | اختر نموذجًا متوسط المستوى يتميز باستدعاء أدوات مستقر | APIYI apiyi.com، وواجهة API الرسمية | وفقًا لصفحة أسعار APIYI |
| الطبقة خفيفة الوزن | تصنيف النوايا، والتحقق من التنسيق، وضغط الملخصات | اختر نموذجًا صغيرًا منخفض التأخير والتكلفة | APIYI apiyi.com، وواجهة API الرسمية | وفقًا لصفحة أسعار APIYI |
لمعرفة النماذج المتاحة تحديدًا وأحدث أسماء النماذج، راجع وثائق APIYI على docs.apiyi.com. ننصح بتشغيل مجموعة من العينات على مهامك الحقيقية لكل نموذج، وإحصاء معدل نجاح استدعاء الأدوات ومتوسط عدد الجولات واستهلاك المهمة الواحدة، ثم تقرر أي نموذج تستخدم في كل طبقة، بدلًا من الاعتماد على التصنيفات العامة فقط.
الأسئلة الشائعة
س1: ما المقصود بـ«حاجز الواجهة» في الوكيل (Agent)؟
هو الطبقة الهندسية التي تفصل بين «أن يفكّر» الوكيل و«أن يُنجز» فعليًا، وتشمل تعريف الأدوات، وبروتوكول الاستدعاء، ومعالجة الأخطاء، وإيصالات النتائج، وضبط التكلفة. النموذج مسؤول عن اتخاذ القرار، وطبقة الواجهة مسؤولة عن تنفيذ هذا القرار بشكل موثوق. وإن لم يُجتَز هذا الحاجز، فسيظهر النموذج — مهما بلغت قوته — بمظهر ضعيف القدرة على التنفيذ.
س2: هل ضعف القدرة على التنفيذ مشكلة في النموذج أم في الواجهة؟
في كليهما، لكن مشكلات الواجهة أسهل في التغاضي عنها. فاختيار أداة خاطئة، أو تنسيق معاملات غير صحيح، أو انقطاع في سلسلة الاستدعاء، أو ادّعاء إتمام المهمة بعد الفشل — جانب كبير من ذلك يمكن تخفيفه عبر إحكام الـ schema، وتقنين طريقة إرجاع النتائج، وإضافة تحقّق من الإيصالات. والاقتراح أن تُتقن طبقة الواجهة أولًا، ثم يُحكم بعد ذلك على ما إذا كان تغيير النموذج ضرورة حقيقية.
س3: ماذا تكشف الاختبارات العملية لثلاثة وكلاء شخصيين من اتجاهات؟
تقرير الاختبار العملي الذي نشرته 36Kr في نوفمبر 2026 يُظهر أن الوكلاء الشخصيين دخلوا مرحلة «مَن يستطيع فعلًا إنهاء العمل»، وأن محور المنافسة انتقل من جودة المحادثة إلى اكتمال دورة التنفيذ. أما تفاصيل أداء كل منتج فيُرجى الرجوع فيها إلى النص الأصلي، فمقالنا هذا يقتصر على استخلاص الدروس الهندسية العامة.
س4: أيّهما أختار: صيغة OpenAI أم صيغة Anthropic؟
الاختيار يتبع النموذج. فسلسلة Claude تستخدم صيغة Anthropic الأصلية، ما يتيح الاستفادة الكاملة من ميزات مثل استدعاء الأدوات والتخزين المؤقت، بينما معظم النماذج الأخرى تكون صيغة OpenAI أعمّ معها. وAPIYI يدعم الصيغتين معًا، فيمكنك الاحتفاظ داخل الوكيل بتمثيل وسيط موحّد، ثم التحويل حسب النموذج عند إرسال الطلب.
س5: كيف أربط عدة نماذج بوكيلي بسرعة؟
1. سجّل في APIYI على apiyi.com واحصل على مفتاح API؛
2. اضبط `base_url` وفق توثيق docs.apiyi.com؛
3. املأ `model` في طبقة التخطيط وطبقة التنفيذ كلٍّ على حدة، ثم اختبر المقارنة باستخدام المجموعة نفسها من المهام.
العملية كلها لا تتطلب تعديل الـ SDK، بل ضبط عناصر التهيئة فقط.
س6: كيف أقدّر تكلفة الوكيل، وأين أطّلع على الأسعار؟
أولًا احسب متوسط عدد الجولات لكل مهمة، وعدد رموز الإدخال ورموز الإخراج، ثم اضربها في سعر الوحدة للنموذج المعني. أما أسعار الإدخال والإخراج والتخزين المؤقت وأساس حساب الفاتورة، فالمرجع الموحّد هو البيانات الفعلية في صفحة أسعار APIYI: https://docs.apiyi.com/models — والفروق بين النماذج كبيرة، لذا احسب على أساس الصفحة الفعلية دون سواها.
س7: كلما زادت الأدوات أصبح الوكيل أقل استقرارًا، فما الحل؟
اعرض الأدوات ديناميكيًا حسب مرحلة المهمة، وأعطِ النموذج في الجولة الواحدة عددًا قليلًا من الأدوات ذات الصلة فقط. ويمكنك أيضًا استخدام نموذج خفيف للتصنيف والتوجيه أولًا، ثم تسليم المجموعة الفرعية المناسبة من الأدوات إلى نموذج التنفيذ. وتوضيح حدود الاستخدام في وصف الأداة أنفع من تكديس أمثلة إضافية.
س8: ما القيود المتبقية بعد إتقان طبقة الواجهة؟
يمكن لطبقة الواجهة أن ترفع الاستقرار بشكل ملموس، لكنها لا تحلّ السقف الذي يفرضه استدلال النموذج نفسه، ولا تعالج التغيّرات التي تطرأ على مواقع الطرف الثالث أو الخدمات الخارجية. وفي المهام ذات السلسلة الطويلة، يُستحسن الإبقاء على نقاط تأكيد بشرية، خصوصًا في العمليات غير القابلة للتراجع مثل الدفع أو الحذف أو الإرسال إلى جهات خارجية.
خلاصات رئيسية حول قدرة الوكيل على تنفيذ الواجهات
- قصور التنفيذ يقع غالبًا في طبقة الواجهة: اختيار الأداة الخطأ، وانقطاع السلسلة، والادّعاء الكاذب بإتمام المهمة، لمعظمها حلول هندسية
- مجموعة الأدوات: القليل أفضل من الكثير: اعرض الأدوات على مراحل، وكلما كان مخطط معاملات الأداة (schema) أكثر صرامة زاد الاستقرار
- اعزل فروق الصيغ: وحّد التمثيل داخليًا، ثم حوّله إلى صيغة OpenAI أو Anthropic عند إرسال الطلب
- صنّف الأخطاء إلزاميًا: خطأ 400 يعني تصحيح الطلب، و429 تراجعًا مع الانتظار، و5xx تخفيضًا للخدمة، والعمليات ذات الآثار الجانبية يجب أن تكون متكررة بأمان (idempotent)
- الإتمام يحكم عليه البرنامج: إشعار استلام مُهيكل مع التحقق من الحالة، لمنع “الإتمام الوهمي”
- ضع بوابات للتكلفة: حد أقصى لعدد الجولات، وميزانية tokens، واستخدام النماذج على طبقات، والأسعار تُعتمد من صفحة أسعار APIYI
- مسار البدء: اتصل بنماذج متعددة عبر مدخل APIYI الموحّد، ويكفي تغيير
base_urlوmodelللمقارنة
الملخص
الاختبار العملي لثلاثة وكلاء ذكاء اصطناعي شخصيين وجّه رسالة تنبيه للمطورين: محور المنافسة بين الوكلاء ينتقل من “القدرة على المحادثة” إلى “القدرة على الإنجاز”. ولتعويض القدرة التنفيذية، فإن الاستثمار الأكثر جدوى هو إتقان طبقة الواجهات أولاً:
- استدعاء الأدوات: تبسيط الأدوات، وتضييق schema، وتوحيد إعادة النتائج؛
- التسامح مع الأخطاء وشبكة الأمان: تصنيف الأخطاء، وإعادة محاولة محدودة، وحماية التكرارية (idempotency)؛
- القابلية للتحقق والتحكم: إيصالات منظمة، وتحقق برمجي، وبوابات التكلفة.
نوصي بالبدء بمهمة حقيقية واحدة وإتمام الحلقة الكاملة لها، ثم توسيع القدرات تدريجيًا. ونقترح الاتصال عبر APIYI من خلال apiyi.com، فهو متوافق مع تنسيقي واجهات OpenAI وAnthropic، ما يسهّل مقارنة استقرار التنفيذ بين النماذج المختلفة. الوثائق متاحة على docs.apiyi.com، والأسعار وفقًا لما ورد في https://docs.apiyi.com/models.
📚 المراجع
- 36Kr: وكلاء الذكاء الاصطناعي الشخصيون يدخلون الساحة، فمن أظهر ضعفه أولاً؟: تقرير اختبار عملي لثلاثة وكلاء شخصيين
- الرابط:
36kr.com/p/4055385191224452 -
الوصف: مصدر موضوع هذا المقال، يُرجى الرجوع إلى النص الأصلي لمعرفة المنتجات المحددة ونتائج الاختبار
-
مركز وثائق APIYI: إعدادات الاتصال ووصف النماذج المتاحة
- الرابط:
docs.apiyi.com -
الوصف: إعداد
base_url، وطرق الاتصال بتنسيقي OpenAI وAnthropic -
صفحة أسعار نماذج APIYI: سعر الوحدة ومعايير الفوترة
- الرابط:
docs.apiyi.com/models - الوصف: جميع المحتويات المتعلقة بالأسعار في هذا المقال تعتمد على البيانات الفعلية في هذه الصفحة
المؤلف: فريق تقنية APIYI
التواصل التقني: يسعدنا تواصلكم معنا عبر الموقع الرسمي لـ APIYI على apiyi.com، ولمزيد من مواد الاتصال يمكنكم زيارة مركز وثائق docs.apiyi.com
