استدعاء الأدوات البرمجي في GPT-5.6: النموذج يكتب كود التنسيق تلقائيًا

الاستدعاء التقليدي للدوال هو نمط مألوف لمن يبني الوكلاء: يطلب النموذج أداة واحدة، ينفّذها تطبيقك، تُلحق النتيجة بالسياق، ثم تطلب من النموذج الاستدعاء التالي. أربع أدوات تعني أربع رحلات ذهاب وإياب، وأربعون أداة تعني أربعين رحلة. كل دورة تضيف زمن انتقال للشبكة وسياقًا يُعاد احتسابه. عند إطلاق OpenAI GPT-5.6 للتوفر العام في 9 يوليو 2026، قدمت واجهة Responses مخرجًا من هذه الحلقة: استدعاء الأدوات البرمجي.

جرّب Apidog اليوم

الفكرة بسيطة: بدلًا من إرجاع استدعاءات الأدوات واحدًا تلو الآخر كي ينفذها كودك، يكتب النموذج JavaScript لتنسيق عدة استدعاءات أدوات. يعمل الكود داخل بيئة V8 معزولة بلا وصول إلى الشبكة. تظل أدواتك هي الوسيلة الوحيدة التي يصل عبرها الكود إلى العالم الخارجي، لذلك تبقى الحدود الأمنية نفسها التي تستخدمها مع استدعاء دوال OpenAI. الفرق هو مكان التحكم في التدفق: الحلقات والشروط والتجميع التي كانت في تطبيقك تنتقل إلى النموذج.

كل أداة تعرضها تصبح الآن عقد API قد يستدعيه النموذج على دفعات بدل استدعاء منفرد في كل دور. لهذا تصبح دقة المخطط، وبنية الأخطاء، وحدود المعدل، وزمن الاستجابة عناصر أساسية. يشرح هذا المقال ما الذي تغيّر، وكيف تجهز أدواتك للاستخدام البرمجي، وكيف تختبر نقاط النهاية قبل منح النموذج صلاحية تنسيقها.

باختصار

• أُطلق GPT-5.6 للتوفر العام في 9 يوليو 2026، واكتسبت واجهة Responses ميزة استدعاء الأدوات البرمجي.
• بدل استدعاء أداة واحدة لكل رحلة ذهاب وإياب، يكتب النموذج JavaScript لتنفيذ الحلقات والشروط وتجميع النتائج.
• يعمل الكود المُولّد في بيئة V8 معزولة بلا شبكة؛ أدواتك المعلنة تظل المسار الوحيد للأنظمة الخارجية.
• لا يعود زمن الانتقال وتكلفة الرموز يتراكمان بالطريقة نفسها مع كل استدعاء أداة.
• راجع مرجع OpenAI لمعلمات الطلب والحدود الدقيقة قبل بناء التكامل.
• اختبر وحاكي كل نقطة نهاية أداة؛ لأن غموض المخطط قد يتحول إلى خطأ متكرر داخل حلقة.

ما تم إصداره في 9 يوليو

وصل GPT-5.6 كعائلة ثلاثية المستويات:

• gpt-5.6-sol للاستدلال الأعمق.
• gpt-5.6-terra للعمل المتوازن.
• gpt-5.6-luna للمهام الأسرع والأقل تكلفة.

يوجه الاسم المستعار gpt-5.6 إلى Sol. النماذج الثلاثة متاحة للخدمة الذاتية عبر API دون تحديد خطة، بعد معاينة محدودة لمدة أسبوعين انتهت عند رفع قيود الوصول في 8 يوليو.

بحسب تغطية إطلاق MarkTechPost ووثائق OpenAI، أضافت واجهة Responses عند الإطلاق العام:

1. استدعاء الأدوات البرمجي.
2. تجربة متعددة الوكلاء.
3. استدلالًا مستمرًا عبر الأدوار.
4. إعدادات تفاصيل للرؤية تحافظ على أبعاد الصورة الأصلية.

الميزة الأهم لمن يبني وكلاء هي استدعاء الأدوات البرمجي: يكتب النموذج JavaScript لتنسيق أدواتك، ويُنفذ هذا الكود في بيئة V8 معزولة بلا وصول للشبكة.

الحلقة التي يحل محلها استدعاء الأدوات البرمجي

في النمط التقليدي، تبدأ بطلب Responses عادي مع تعريف أدواتك:

import OpenAI from "openai";

const client = new OpenAI();

const tools = [
  {
    type: "function",
    name: "get_flight_status",
    description: "Return live status for a flight by IATA flight number.",
    parameters: {
      type: "object",
      properties: {
        flight_number: {
          type: "string",
          description: "IATA flight number, for example SQ317"
        }
      },
      required: ["flight_number"]
    }
  }
];

let response = await client.responses.create({
  model: "gpt-5.6",
  input: "Which of these 12 flights are delayed: SQ317, BA15, UA857...",
  tools
});

إذا احتاج النموذج بيانات الرحلات، يصدر استدعاء دالة. بعد ذلك، ينفذ تطبيقك الأداة ويرسل الناتج في طلب جديد إلى واجهة Responses:

// رحلة ذهاب وعودة واحدة لكل استدعاء أداة.
while (hasFunctionCalls(response)) {
  const outputs = await executeToolCalls(response);

  response = await client.responses.create({
    model: "gpt-5.6",
    previous_response_id: response.id,
    input: outputs,
    tools
  });
}

بالنسبة إلى 12 رحلة، قد تعمل هذه الحلقة 12 مرة. كل تكرار يدفع تكلفة في جانبين:

1. زمن الاستجابة: رحلة شبكة إلى OpenAI، ثم وقت معالجة النموذج، ثم الاستدعاء التالي.
2. الرموز المميزة: تتراكم نتائج الأدوات في السياق، فتُعاد معالجة مخرجات الاستدعاءات السابقة في التكرارات اللاحقة.

إذا كانت لديك سلسلة وكلاء، يتضاعف الأثر. وكيل من خمس خطوات، وكل خطوة تحتوي حلقة من عشرة استدعاءات أدوات، يمكن أن ينفذ خمسين استدعاءً يحسبها النموذج.

هذه الحلقة ليست منطق العمل الفعلي؛ إنها طبقة تنسيق. واستدعاء الأدوات البرمجي يسمح للنموذج بكتابتها.

كيف يغير الوضع البرمجي الشكل

مع استدعاء الأدوات البرمجي، يمكن للنموذج كتابة برنامج JavaScript قصير يقوم بالتالي:

1. يكرر على أرقام الرحلات الاثني عشر.
2. يستدعي get_flight_status لكل رقم.
3. يفلتر الرحلات المتأخرة.
4. يرتب النتائج بحسب مدة التأخير.
5. يعيد ملخصًا نهائيًا.

تبقى أدواتك مسؤولة عن الوصول إلى البيانات الحقيقية. ما ينتقل إلى النموذج هو التحكم في التدفق حول هذه الأدوات.

هناك ثلاث خصائص مهمة:

• بيئة معزولة: يُشغّل JavaScript في بيئة V8 معزولة من دون شبكة. لا يمكنه جلب عنوان URL أو فتح مقبس شبكة مباشرة.
• الأدوات هي المنفذ الوحيد: لا يمكن للكود المُولّد تنفيذ تأثير خارجي إلا عبر الأدوات التي أعلنت عنها.
• تحكم تدفق أكثر تعبيرًا: تصبح الحلقات والشروط والمخارج المبكرة وتجميع النتائج ممكنة داخل دورة الاستجابة نفسها.

العنصر	استدعاء الدالة الكلاسيكي	استدعاء الأداة البرمجي
من يكتب التحكم في التدفق	تطبيقك	النموذج، بصيغة JavaScript
رحلات الذهاب والإياب لـ N أدوات	N رحلات متسلسلة	دورة استجابة واحدة
مكان تشغيل التنسيق	بنيتك التحتية	بيئة V8 معزولة بلا شبكة
تنفيذ الأدوات	كودك يستدعيها	عبر سطح الأدوات المعلن نفسه
الحدود الأمنية	تعريفات الأدوات	تعريفات الأدوات، دون تغيير

ما الذي يبقى كما هو

ما زلت تعرّف الأدوات بأسماء وأوصاف ومعلمات JSON Schema. لا يستطيع النموذج تأليف استدعاءات إلا للأدوات التي تعرضها له.

لذلك يظل السؤال الأمني كما هو:

ما الذي يمكن لهذا الوكيل فعله داخل أنظمتي؟

والإجابة هي: ما تسمح به واجهة أدواتك فقط.

لكن جودة المخطط أصبحت أكثر أهمية. في الحلقة التقليدية، قد ينتج عن وصف غامض استدعاء سيئ واحد تستطيع مراجعته قبل الاستدعاء التالي. أما في الوضع البرمجي، فيمكن أن يتكرر الغموض داخل حلقة قبل أن ترى النتيجة.

طبّق الممارسات نفسها المستخدمة مع المخرجات المنظمة:

• استخدم أنواعًا صارمة.
• استخدم enum للقيم المغلقة.
• وضح الوحدات والتنسيقات في الوصف.
• اجعل الحقول المطلوبة مطلوبة فعلًا.
• حدد النطاقات والقيود عندما تكون معروفة.

مثال أفضل لوصف معلمة تاريخ:

{
  "date": {
    "type": "string",
    "format": "date",
    "description": "تاريخ الرحلة بصيغة ISO 8601: YYYY-MM-DD."
  }
}

بدل وصف عام مثل: "تاريخ الرحلة".

القيود والأسئلة المفتوحة

الميزة حديثة، لذا تعامل معها كتجربة مدروسة قبل إعادة تصميم بنية وكيلك بالكامل.

• راجع مرجع API ودليل نموذج OpenAI لمعلمات الطلب وحدود التنفيذ وسلوك المهلات. قد تتغير أسماء المعلمات خلال مرحلة التحسين بعد الإطلاق العام.
• أنشئ سجلات واضحة لتسلسل استدعاءات الأدوات. عندما كان التنسيق في مستودعك، كنت تستطيع وضع نقطة توقف. الآن يُولّد جزء من التحكم في التدفق لكل طلب.
• راقب الاختبارات المستقلة. تقدم ملاحظات سيمون ويلسون في اليوم الأول حول GPT-5.6 سجلًا مفيدًا لما يظهر في الاستخدام العملي.
• ابدأ بأدوات القراءة فقط، ثم راقب التنسيق الذي يولده النموذج، وقارن استهلاك الرموز بحلقتك القديمة، وبعد ذلك فقط فكّر في أدوات ذات آثار جانبية.

أصبحت أدواتك API يستدعيها كود شخص آخر

في الاستدعاء التقليدي، كان تطبيقك يحدد ترتيب ووتيرة استدعاءات الأدوات. مع الاستدعاء البرمجي، قد يستدعي الكود المُولّد أدواتك عدة مرات، ويتفرع بحسب استجاباتها، ويجمع النتائج.

تعامل مع كل أداة كأنها API يستهلكها عميل آلي لا تراجعه يدويًا قبل التنفيذ.

ركز على أربعة جوانب:

1. دقة المخطط

حدد الوحدات والتنسيقات والنطاقات في وصف كل معلمة. تنسيق تاريخ غامض أو رقم بلا وحدة قد يتحول إلى سلسلة من الطلبات غير الصالحة.

2. بنية الأخطاء

يحتاج الكود المُولّد إلى التفرع عند الفشل. لا تُرجع 200 OK مع رسالة خطأ مدفونة داخل نص حر.

استخدم رموز حالة صادقة وبنية خطأ ثابتة:

{
  "error": {
    "code": "FLIGHT_NOT_FOUND",
    "message": "لم يتم العثور على الرحلة المطلوبة.",
    "details": {
      "flight_number": "SQ999"
    }
  }
}

3. الثباتية وحدود المعدل

اثنا عشر طلبًا كانت تصل خلال دقيقة قد تصل الآن في دفعة واحدة. اختبر سلوك نقطة النهاية مع التزامن، وعرّف بوضوح ما يحدث عند تجاوز الحد.

4. زمن الاستجابة

أداة تستغرق ثماني ثوانٍ قد تكون مقبولة إذا استُدعيت مرة واحدة. لكنها تصبح عنق زجاجة إذا استُدعيت داخل حلقة من 12 تكرارًا.

قبل عرض الأدوات للنموذج:

1. استورد أو عرّف مواصفات كل نقطة نهاية.
2. أرسل طلبات اختبار تغطي النجاح والفشل والمدخلات غير الصالحة.
3. تحقق أن مخطط الاستجابة يطابق ما تعد به تعريفات الأدوات.
4. حاكي API ببيانات ثابتة وقابلة للتوقع.
5. اختبر التنسيق قبل لمس بيانات الإنتاج.

يمكنك تنزيل Apidog لاختبار العقد ومحاكاة الاستجابات ذات الشكل المطابق للمخطط لكل نقطة نهاية قبل استخدامها مع النموذج.

الميزات الأخرى المتاحة للجمهور باختصار

لم يُطلق استدعاء الأدوات البرمجي وحده. هناك إضافتان في واجهة Responses تستحقان المتابعة:

• متعدد الوكلاء، في مرحلة beta: تنفيذ متوازٍ لوكلاء فرعيين تديره API. ما زال مبكرًا، لذا راقبه قبل الاعتماد عليه في مسار إنتاجي حرج.
• الاستدلال المستمر: يمكن إعادة استخدام سياق الاستدلال عبر الأدوار من خلال reasoning.context، ما يقلل إعادة اشتقاق النتائج نفسها في الجلسات الطويلة.

يمكن أن تتكامل هذه القدرات مع استدعاء الأدوات البرمجي: وكيل يحتفظ بسياق استدلاله ويكتب تنسيق أدواته يقلل العمل المتكرر لكل مهمة.

استدعاء الأدوات البرمجي مقابل وضع Ultra

أتى الإطلاق أيضًا بوضع Ultra، وقد يختلط الأمر لأن كليهما ينفذ المزيد في كل طلب، لكنهما يحلان مشكلتين مختلفتين.

Ultra إعداد متعدد الوكلاء يشغّل أربعة وكلاء بالتوازي افتراضيًا، ويستهلك رموزًا أكثر عمدًا لتقليل الزمن الفعلي. وفقًا لـ OpenAI، يرفع أداء Terminal-Bench 2.1 من 88.8% إلى 91.9%. وهو متاح في ChatGPT Work على خطط Pro وEnterprise، وفي Codex من Plus فما فوق.

أما استدعاء الأدوات البرمجي فهو قدرة في API تمكّن وكيلًا واحدًا من تنسيق أدواته بالكود.

• إذا كان عنق الزجاجة هو زمن انتقال استدعاءات الأدوات، فاستخدم استدعاء الأدوات البرمجي.
• إذا كان عنق الزجاجة هو وقت التفكير في مسائل صعبة، فقد يناسبك Ultra.

للتفاصيل، راجع مقال وضع Ultra في GPT-5.6.

الأسئلة الشائعة

هل أحتاج إلى إعادة كتابة تعريفات أدواتي الحالية؟

لا. تحتفظ الأدوات بشكل JSON Schema نفسه المستخدم في الاستدعاء التقليدي للدوال. لكن من المفيد تشديد التعريفات بإضافة التعدادات والتنسيقات والأوصاف الدقيقة.

هل يمكن لجافاسكريبت المُولّدة الوصول إلى الإنترنت؟

لا. يعمل الكود في بيئة V8 معزولة بلا وصول للشبكة. أدواتك المعلنة هي الوسيلة الوحيدة للتأثير على أي شيء خارج البيئة المعزولة.

لهذا راجع الأدوات المعروضة بالصرامة نفسها التي تطبقها على API عامة.

ما هي نماذج GPT-5.6 التي تدعم استدعاء الأدوات البرمجي؟

توثق OpenAI الميزة ضمن واجهة Responses لعائلة GPT-5.6. المستويات الثلاثة هي:

• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.6-luna

راجع مرجع API لتفاصيل كل مستوى قبل الالتزام بنموذج محدد. وللإعداد الأولي، راجع كيفية استخدام واجهة برمجة تطبيقات GPT-5.6.

كيف يختلف هذا عن مترجم الكود؟

مترجم الكود يشغّل الكود كناتج للمهمة، مثل التحليل والرسوم البيانية وتحويل الملفات. أما استدعاء الأدوات البرمجي فيولّد كودًا مهمته تنسيق أدواتك المعلنة فقط؛ والناتج النهائي هو نتائج الأدوات المجمعة، لا الكود نفسه.

إلى أين يقودك هذا

كانت حلقة الذهاب والإياب الجزء الأقل إثارة في معظم الوكلاء، وجعلها GPT-5.6 اختيارية. انتقل التنسيق إلى النموذج، لكن مسؤولية تقديم أدوات دقيقة وآمنة وسريعة أصبحت أكبر.

ابدأ بخطوة عملية:

1. اختر سير عمل يعتمد على أدوات قراءة فقط.
2. شدد مخططات الأدوات الخاصة به.
3. اختبر حالات النجاح والفشل وحدود المعدل.
4. حاكي الاستجابات المتوقعة.
5. راقب تسلسل الاستدعاءات واستهلاك الرموز.
6. أضف الأدوات ذات الآثار الجانبية فقط بعد التحقق من السلوك.

استخدم عميل وخادم محاكاة Apidog API للتحقق من أن عقد الأدوات يظل ثابتًا مع الطلبات المتدفقة والمدخلات غير الصالحة. عندما يبدأ النموذج بكتابة كود ضد أدواتك، يجب أن يكون هذا الكود مبنيًا على سطح API اختبرته بالفعل.