ملاحظة من الكاتب: إذا كان الـ Agent لديك ما زال يستخدم client.chat.completions.create مع tools، فستواجه عند الانتقال إلى GPT-6.1 نقطة تفرّع محددة: النص يعمل كما هو، أما استدعاء الأدوات فيحتاج إلى نقطة نهاية (endpoint) مختلفة.
لماذا تعلق استدعاءات الأدوات عند نقطة النهاية بعد الترقية إلى GPT-6.1
الخلاصة أولًا: النماذج الثلاثة GPT-6 Astra وGPT-6.1 Sol وGPT-6.1 Terra تدعم Chat Completions، لكن استدعاء الأدوات يجب أن يمر عبر Responses API. أي أنك في الشيفرة نفسها تستطيع إبقاء المحادثة النصية البحتة على Chat، لكن بمجرد أن تريد ربط دوال، أو قراءة مخرجات الأدوات، أو تنفيذ حلقة أدوات متعددة الجولات، يجب أن يُرسل الطلب إلى نقطة نهاية Responses.
وهذه ليست مشكلة توافق يمكن تجاوزها بتعديل المعاملات. تغيير صيغة tools لن يفيد، وإضافة tool_choice لن تفيد أيضًا، فمسار Chat Completions لا يوفّر قدرة استدعاء الأدوات لهذه النماذج الثلاثة أصلًا. ما يجب تغييره فعلًا هو نقطة النهاية نفسها، ومعها بنية الطلب والاستجابة المحيطة بها. وإذا أردت تجربة نقطتي النهاية جنبًا إلى جنب بمفتاحك الخاص، فيمكنك استخدام المدخل الموحد في APIYI على apiyi.com، بتوجيه base_url إلى https://api.apiyi.com/v1، ثم تبديل معرّف النموذج للتنقل بينها.
وهناك فخ جانبي آخر يخص GPT-6 Sol وGPT-6 Luna. هذان النموذجان يدعمان استدعاء الدوال في Chat Completions، بشرط أن تكون قيمة reasoning_effort هي none. بعبارة أخرى، يمكنهما استدعاء الأدوات عبر Chat، لكن مقابل تعطيل قوة الاستدلال. وإن كنت تحتاج إلى الاحتفاظ بالاستدلال، فعليك العودة إلى Responses أيضًا. كثيرًا ما يُغفل هذا التفصيل، فتكون النتيجة شيفرة تعمل بلا أخطاء لكن بجودة مخرجات غير مرضية.
القيمة الأساسية: بعد قراءة هذا المقال، ستعرف إلى أي فئة تنتمي سلسلة استدعاء الأدوات لديك، وكيف تنقل الطلبات من نقطة نهاية Chat إلى نقطة نهاية Responses دون إعادة بناء بنية تطبيقك بالكامل.
أهم نقاط استدعاء الأدوات في GPT-6.1
يوضّح الجدول التالي أي نقطة نهاية يستخدمها كل نموذج من النماذج الثلاثة والنموذجين الأقدم. الأفضل أن تحدد موقع نموذجك فيه أولًا ثم تنتقل إلى خطوات الترحيل.
| النموذج | Chat Completions للنصوص فقط | Chat Completions لاستدعاء الأدوات | نقطة النهاية المطلوبة لاستدعاء الأدوات |
|---|---|---|---|
| gpt-6.1-sol | مدعوم | غير مدعوم | Responses |
| gpt-6.1-terra | مدعوم | غير مدعوم | Responses |
| gpt-6-astra | مدعوم | غير مدعوم | Responses |
| gpt-6-sol | مدعوم | مدعوم فقط عندما تكون قيمة reasoning_effort هي none |
Responses (عند الحاجة إلى الاحتفاظ بالاستدلال) |
| gpt-6-luna | مدعوم | مدعوم فقط عندما تكون قيمة reasoning_effort هي none |
Responses (عند الحاجة إلى الاحتفاظ بالاستدلال) |
تقسيم المهام بين نقطتي النهاية: Chat للنصوص وResponses للأدوات
خلاصة الجدول في جملة واحدة: في سلسلة GPT-6 أصبحت Chat Completions قناة نصوص فقط، وانتقل استدعاء الأدوات إلى Responses. وتأثير هذا الفصل على المشاريع القديمة متدرّج. الخدمات التي تقتصر على الأسئلة والأجوبة والتلخيص والتصنيف لا تحتاج تقريبًا إلى أي تعديل. أما الخدمات التي تبني وكلاء (Agents) أو تستخدم استدعاء الدوال أو تنسّق أدوات متعددة على عدة خطوات، فلا بد لها من الترحيل.
إذا كان فريقك قد غلّف الاستدعاءات بطبقة SDK، فنطاق الترحيل أصغر مما تتوقع. معرّف النموذج لم يتغير، وطريقة المصادقة لم تتغير، وbase_url نفسه كما هو. التغيير يتركز في بنية جسم الطلب وفي طريقة إعادة نتائج الأدوات إلى النموذج. فالعمل الحقيقي ليس «تبديل النموذج»، بل «تغيير طريقة الاستدعاء».
منطق اختيار النماذج الرئيسية الثلاثة
GPT-6.1 Sol وGPT-6.1 Terra هما النموذجان الرئيسيان في هذا الجيل، والفرق بينهما في الموقع والتكلفة بالدرجة الأولى. أما GPT-6 Astra فهو النموذج الرائد في الجيل السابق، ولا يزال يدعم النصوص فقط عبر Chat واستدعاء الأدوات عبر Responses، ويناسب المشاريع التي استقرت ولا تريد تعديلات كبيرة. عند الاختيار، انظر أولًا إلى عدد مرات استدعاء الأدوات، ثم إلى طول السياق في الطلب الواحد، ثم إلى السعر في النهاية. استدعاء الأدوات يتضمن عادةً جولات متعددة من الذهاب والإياب، فيتضاعف استهلاك التوكنات.
يمكنك مراجعة الأسعار التفصيلية في جدول الأسعار لاحقًا، أو التحقق من آلية التسعير المعمول بها حاليًا في وثائق APIYI على apiyi.com، حتى لا تعتمد في ميزانيتك على أسعار قديمة.
ما المواضع الخمسة التي يجب تعديلها في استدعاء الأدوات مع GPT-6.1
هذا القسم هو الأكثر عمليةً في المقال كله. إذا عدّلت المواضع الخمسة التالية، يمكنك نقل حلقة استدعاء الأدوات النموذجية من نقطة نهاية Chat إلى نقطة نهاية Responses.
| الرقم | موضع التعديل | صيغة Chat Completions | صيغة Responses |
|---|---|---|---|
| 1 | طريقة الاستدعاء | client.chat.completions.create |
client.responses.create |
| 2 | حامل المدخلات | مصفوفة messages |
المعامل input |
| 3 | تعريف الأدوات | tools (تبقى كما هي) |
tools (البنية متطابقة تقريبًا) |
| 4 | إعادة نتيجة الأداة | رسالة بـ role: "tool" |
عنصر من نوع function_call_output |
| 5 | السياق متعدد الجولات | تجميع messages كاملةً يدويًا |
يمكن الربط عبر previous_response_id |
الموضعان الأول والثاني هما الأكثر عرضةً للنسيان. كثيرون يعدّلون بنية tools ويظنون أن الترحيل انتهى، ثم يكتشفون أن طريقة SDK لم تتغير أصلًا، وأن الطلبات ما زالت تذهب إلى chat.completions. نقطة النهاية تتحدد بالطريقة المستخدمة، فإن لم تغيّر الطريقة لن تتغير نقطة النهاية.
الموضع الرابع هو الأكثر تعطيلًا في عملية الترحيل. في Chat تُعاد نتيجة تنفيذ الأداة إلى messages على شكل رسالة بـ role: "tool". أما في Responses فتُعيد عنصر الاستدعاء الذي أرجعه النموذج كما هو، ثم تضيف بعده عنصر function_call_output. وإذا نقص عنصر واحد أو اختل الترتيب بمقدار موضع واحد، فقد يعيد النموذج إصدار الاستدعاء نفسه.
أما الموضع الخامس فهو من نوع «لا يلزم تعديله، لكن يُنصح به». يدعم Responses استكمال الجولة السابقة عبر previous_response_id، فتتخلص من تكلفة إعادة إرسال كل الرسائل السابقة في كل مرة. وفي وكلاء الذكاء الاصطناعي (Agents) ذوي الجولات الكثيرة من استدعاء الأدوات، يكون أثر هذا التعديل في التكلفة أوضح من أثر تغيير النموذج نفسه.
🎯 نصيحة تقنية: أيسر طريقة للتحقق أثناء الترحيل هي تشغيل المسارين القديم والجديد بالتوازي على الدفعة نفسها من الطلبات، ثم مقارنة معدل إصابة الأدوات وبنية النتائج المُعادة. وعبر الواجهة الموحدة في APIYI (apiyi.com) تستغني عن عناء إدارة مفاتيح منصات متعددة، فإعداد واحد يكفي لمقارنة الفروق الفعلية بين مخرجات Responses وChat.
البدء السريع مع استدعاء الأدوات في GPT-6.1
أبسط مثال على استدعاء أداة
لنفترض أن لديك دالة أداة لاستعلام حالة الطلب اسمها get_order_status، وهي تستقبل رقم الطلب كمدخل. لا يلزمك تعديل سوى موضعين: طريقة الاستدعاء، وإعادة نتيجة الأداة إلى النموذج.
- أبقِ تهيئة العميل كما هي: استخدم مفتاحك الخاص في
api_key، واضبطbase_urlعلىhttps://api.apiyi.com/v1، وبذلك تستطيع استدعاء أي نموذج يدعم واجهة OpenAI المتوافقة مباشرةً. - اكتب معرّف النموذج
gpt-6.1-sol(أوgpt-6.1-terraأوgpt-6-astra)، وجميع هذه النماذج الثلاثة تعتمد على Responses في استدعاء الأدوات. - استبدل
client.chat.completions.create(...)القديم بـclient.responses.create(...)، واستبدل المعاملmessagesبالمعاملinput. - مرّر
toolsكما هي، فلا حاجة إلى إعادة كتابة وصف الأداة ولا مخطط (schema) المعاملات. - ابحث في
outputالمُعاد عن العنصر الذي نوعهfunction_call، واستخرج منه اسم الأداة ومعاملاتها، ثم نفّذ دالة الاستعلام محليًا. - أضِف نتيجة التنفيذ مرة أخرى بوصفها
function_call_output، ثم أرسل طلبًا ثانيًا للحصول على الإجابة النهائية.
من بين هذه الخطوات الست، الخطوتان اللتان يجب تعديلهما فعلًا هما الثالثة والسادسة. أما الأولى والثانية فمجرد إعدادات، والرابعة والخامسة تعني ببساطة قراءة ما اعتدتَ عليه في Chat من موضع جديد.
🚀 بداية سريعة: إن لم ترغب في تجهيز بيئة اختبار بنفسك، يمكنك الحصول على رصيد تجريبي مجاني من APIYI عبر apiyi.com وتشغيل مثال الاستعلام أعلاه مرة واحدة، ثم العودة لتحويل شفرة الإنتاج. بهذه الطريقة تكون المخاطرة أقل ما يمكن.
والأسهل من ذلك أن تفصل طبقة الأدوات عن طبقة النموذج أولًا: اجمع تعريفات الأدوات في مكان واحد، وضع نقطة الاستدعاء داخل دالة واحدة تقرر في داخلها: “النص العادي يذهب إلى Chat، وما يحمل tools يذهب إلى Responses”. هكذا يقتصر الترحيل على طبقة التغليف، ولا تحتاج إلى تعديل سطر واحد في شفرة منطق العمل.
أسعار GPT-6.1 واختيار النموذج المناسب (2026-11-12)
يعرض الجدول التالي الأسعار السارية اعتبارًا من 2026-11-12، وجميعها بالدولار الأمريكي لكل مليون رمز (1M tokens).
| النموذج | الإدخال | الإخراج | قراءة الكاش | نقطة النهاية الموصى بها |
|---|---|---|---|---|
| gpt-6.1-sol | $2 | $10 | $0.1 | responses |
| gpt-6.1-terra | $1 | $5 | $0.05 | responses |
| gpt-6-luna | $0.1 | $0.5 | $0.01 | chat (مع ضبط reasoning_effort على none) أو responses |
يمكن أن نخرج من هذا الجدول باستنتاج عملي: سعر الإدخال والإخراج في GPT-6.1 Terra يساوي نصف سعر Sol تمامًا. لذلك يكون Terra في الغالب الخيار الافتراضي الأنسب للسيناريوهات التي تكثر فيها جولات استدعاء الأدوات وتتكرر فيها أجزاء السياق كثيرًا. أما GPT-6 Luna فسعره أقل بمقدار رتبة أُسّية كاملة، ما يجعله مناسبًا للمهام الخفيفة مثل التصنيف والاستخراج، وتُترك Sol أو Terra لمرحلة تنسيق الأدوات التي تحتاج فعلًا إلى الاستدلال.
يستحق عمود سعر قراءة الكاش وقفة خاصة. فاستدعاء الأدوات يولّد بطبيعته الكثير من البادئات المتكررة، مثل موجه النظام وتعريفات الأدوات وسجل المحادثة. وعند إصابة الكاش (cache hit) يصبح سعر هذا الجزء نحو جزء من عشرين من سعر الإدخال. لذا فإن استخدام previous_response_id في Responses لتمرير السياق لا يوفّر في حجم البيانات المنقولة فحسب، بل يوفّر مالًا حقيقيًا أيضًا.
💰 نصيحة لتوفير التكلفة: إذا احتجت إلى تقسيم الميزانية حسب المشروع، فاستخدام مفتاح API موحّد عبر APIYI (apiyi.com) يتيح لك تجميع استهلاك عدة نماذج في مكان واحد. ومع الفوترة حسب الاستخدام يصبح احتساب التكلفة الفعلية لاستدعاءات الأدوات أسهل.
الأسئلة الشائعة حول استدعاء الأدوات في GPT-6.1
س1: ما هو GPT-6.1، وما علاقته بـ GPT-6؟
GPT-6.1 هو إصدار محدَّث من سلسلة GPT-6، ويضم حاليًا نموذجين: GPT-6.1 Sol وGPT-6.1 Terra. أما سلسلة GPT-6 فتضم GPT-6 Astra وGPT-6 Sol وGPT-6 Luna. تشترك جميعها في قناة استدعاء الأدوات نفسها عبر Responses، ويقتصر الفرق بينها أساسًا على موقع كل نموذج من حيث القدرات وعلى السعر.
س2: لماذا لا أستطيع استدعاء الأدوات عبر Chat Completions؟ هل أخطأت في كتابة المعاملات؟
المشكلة ليست في المعاملات. يوفّر كل من GPT-6 Astra وGPT-6.1 Sol وGPT-6.1 Terra على Chat Completions قدرات النص فقط، أما استدعاء الأدوات فمقصور على Responses API. تعديل `tools` أو `tool_choice` لن يغيّر شيئًا، والحل أن تستبدل دالة SDK من `chat.completions.create` إلى `responses.create`.
س3: هل يمكن لـ GPT-6 Sol وGPT-6 Luna تنفيذ استدعاء الدوال داخل Chat؟
نعم، لكن فقط عندما تضبط `reasoning_effort` على `none`. وإذا كنت تريد الاحتفاظ بمستوى الاستدلال، فعليك استخدام Responses مع هذين النموذجين أيضًا. وهذا القيد من أسهل ما يُغفل أثناء الانتقال، لأنه لا يُظهر أي خطأ، بل تأتي النتائج مختلفة عن المتوقع فحسب.
س4: هل أحتاج إلى تغيير معرّف النموذج عند الانتقال إلى Responses؟
لا. يكفي أن تُبقي معرّفات النماذج كما هي: `gpt-6.1-sol` و`gpt-6.1-terra` و`gpt-6-astra`، ويبقى `base_url` وأسلوب المصادقة دون تغيير. الذي يتغير فعلًا هو دالة الاستدعاء، وحامل المدخلات، وبنية إعادة نتيجة الأداة إلى النموذج.
س5: كيف أتحقق بسرعة من أن استدعاء الأدوات يعمل بشكل سليم بعد الانتقال؟
أنصحك بإجراء اختبار دخان (smoke test) باستخدام أداة صغيرة للاستعلام عن الطلبات. أولًا تأكد من أن الطلب وصل فعلًا إلى نقطة نهاية Responses، ثم تأكد من وجود عنصر `function_call` في `output` المُرجَع، وأخيرًا تأكد من أن النموذج قدّم إجابته النهائية بعد إعادة تمرير `function_call_output`. إذا نجحت الخطوات الثلاث فالمسار يعمل. ويمكنك إتمام هذا التحقق بالحصول على مفتاح تجريبي من APIYI على apiyi.com.
س6: هل يجب نقل خدمات النص فقط إلى Responses أيضًا؟
ليس بالضرورة. ما زالت قدرات النص فقط متاحة عبر Chat Completions في النماذج الرئيسية الثلاثة، لذا يمكن للخدمات التي تقتصر على مهام مثل الأسئلة والأجوبة والتلخيص والترجمة أن تبقى كما هي. الطلبات التي تتضمن `tools` وحدها يجب نقلها، وهذا ما يجعل أثر التغيير متدرجًا على مستويات.
س7: كيف أتحكم في تكلفة السياق عند تعدد جولات استدعاء الأدوات؟
يُفضَّل استخدام `previous_response_id` لمتابعة الجولة السابقة بدلًا من إعادة إرسال السجل الكامل في كل جولة. بهذه الطريقة يزداد احتمال أن تصيب البادئة المتكررة الذاكرة المؤقتة (الكاش)، وسعر القراءة من الكاش أقل بكثير من سعر الإدخال. خذ `gpt-6.1-sol` مثالًا: سعر الإدخال $2 وسعر القراءة من الكاش $0.1، وهو فرق واضح.
Q8: هل هناك مشكلات معروفة عند الانتقال إلى Responses؟
هناك مشكلتان شائعتان. الأولى أن يغيّر الفريق بنية `tools` فقط دون تغيير طريقة الاستدعاء، فيبقى الطلب متجهًا إلى نقطة نهاية Chat. والثانية أن يستمر استخدام الصيغة القديمة `role: “tool”` عند إعادة نتائج الأداة، فلا يصل الناتج إلى النموذج ويكرر طلب الاستدعاء. وإذا كان الفريق يخلط بين نماذج مثل GPT-6 Sol التي تشترط أن تكون قيمة `reasoning_effort` هي `none`، فالأفضل فرض قيد موحّد في طبقة التغليف، حتى لا تظهر حالة “الأداة نفسها تعمل مع بعض النماذج ولا تعمل مع غيرها”.
أهم النقاط حول استدعاء الأدوات في GPT-6.1 (Key Takeaways)
- انفصال نقاط النهاية: نصوص GPT-6.1 Sol وTerra وGPT-6 Astra تمر عبر Chat، أما الأدوات فيجب أن تمر عبر Responses.
- استثناء واحد: يمكن لـ GPT-6 Sol وGPT-6 Luna تنفيذ استدعاء الدوال عبر Chat، بشرط أن تكون قيمة
reasoning_effortهيnone. - خمسة تغييرات: طريقة الاستدعاء، وحامل
input، وتعريفtools، وإعادة النتائج عبرfunction_call_output، وربط الجولات عبرprevious_response_id. - معرّفات النماذج لا تتغير: لا حاجة لتغيير
base_urlولا المفتاح، فالانتقال يحدث في طبقة التغليف فقط. - التكلفة مرتبطة بالكاش: بادئات استدعاء الأدوات تتكرر كثيرًا، وسعر القراءة من الكاش يساوي نحو جزء من عشرين من سعر الإدخال.
- التحقق في ثلاث خطوات: تأكد من نقطة النهاية، ثم من وجود
function_callداخلoutput، ثم من الحصول على الرد النهائي بعد إعادة النتيجة. - مسار البداية: استخدم الرصيد المجاني في APIYI على apiyi.com لتشغيل أداة صغيرة للاستعلام عن الطلبات أولًا، ثم انتقل إلى تحويل مسار الإنتاج.
الخلاصة
جوهر هذا التغيير يمكن اختصاره في جملة واحدة: نقل GPT-6.1 استدعاء الأدوات من Chat Completions إلى Responses، وبقيت قدرات النص الخالص في مكانها. ومن ذلك تنبثق ثلاث نقاط تستحق التذكر:
- صنّف أولًا ثم انتقل: الخدمات التي تتعامل مع النص فقط لا تحتاج إلى أي تعديل، أما الطلبات التي تحتوي على
toolsفيجب تحويلها إلى نقطة نهاية أخرى. - غيّر الدالة لا المعاملات: الذي يبدّل نقطة النهاية فعليًا هو
client.responses.create، أما بنيةtoolsفهي مجرد تفصيل مرافق. - إعادة النتائج هي مكمن الأخطاء الأكبر: حلّ
function_call_outputمحلrole: "tool"، ويجب الحرص على سلامة الترتيب واكتمال البيانات.
إذا كان مشروعك يشغّل استدعاء الأدوات في بيئة الإنتاج، فننصحك بأن تبدأ بأداة واحدة بسيطة وتطرحها لشريحة محدودة من الحركة، وبعد التأكد من سلامة المسار انتقل إلى التحويل الكامل. وإن أردت توفير وقت إعداد المفاتيح والبيئات على منصات متعددة، يمكنك استخدام مفتاح واحد عبر APIYI على apiyi.com لمقارنة الاستجابات الفعلية بين Responses وChat، مع توجيه base_url إلى https://api.apiyi.com/v1 في كل الحالات.
المراجع
- وثائق نماذج OpenAI الرسمية: شرح قدرات نقاط النهاية لسلسلتي GPT-6 وGPT-6.1، ويتضمن القيد الذي يوجب استخدام Responses لاستدعاء الأدوات
- الرابط:
developers.openai.com/api/docs/guides/latest-model -
الوصف: المرجع الأساسي لمعرفة ما إذا كان نموذج معين يدعم استدعاء الدوال في Chat Completions
-
وثائق النماذج والأسعار في APIYI: أسعار الإدخال والإخراج وقراءة الذاكرة المؤقتة لكل نموذج، مع نقطة النهاية الموصى بها
- الرابط:
docs.apiyi.com/models - الوصف: للتحقق من آلية التسعير السارية اعتبارًا من 2026-11-12 وتوصيات نقاط النهاية
المؤلف: فريق APIYI التقني
للنقاش التقني: يسعدنا تواصلكم معنا عبر الصفحة الرئيسية لـ APIYI على apiyi.com، ولمزيد من تفاصيل الواجهات يمكنكم زيارة مركز الوثائق docs.apiyi.com
