إنتقل إلى المحتوى الرئيسي

واجهات الوكلاء المتعددين الأصلية: بيتا الوكلاء المتعددين في Responses من OpenAI مقابل البناء بنفسك

متقدّم

طوال ثمانية عشر شهرًا كان «الوكلاء المتعددون» يعني أن أنت من يكتب التوزيع (fan-out). كنت تكتب أمر المنسّق، وتُطلق N استدعاءً بالتوازي، وتدمج مخرجاتها بصيغة JSON، وتتولى إعادة المحاولات. وفي 9 يوليو 2026 اختزلت OpenAI كل ذلك في معامل طلب واحد: multi_agent.enabled: true في Responses API، مغلّفًا بميزة للمستهلكين اسمها Sol Ultra Mode. النموذج نفسه يقرر عدد الوكلاء الفرعيين الذين سيُنشئهم، ويشغّلهم بالتوازي، ويدمج النتيجة — كل ذلك داخل استدعاء HTTP واحد. لم يُطلق أي مزوّد رائد آخر بدائية مماثلة. تستعرض هذه الصفحة ما صدر فعلًا، والأرقام خلفه، وما تقدّمه Anthropic بدلًا منه، و— وهو الأهم — أحمال العمل الثلاثة التي تستحق فيها البدائية الأصلية كلفتها، والاثنين اللذين لا يزال فيهما التوزيع الذي تبنيه بنفسك هو الأفضل.

What you'll learn
  • قراءة جسم طلب الوكلاء المتعددين في Responses API بدقة ومعرفة ما الذي يحدّه max_concurrent_subagents فعلًا
  • حساب التكلفة: ماذا يعني فعليًا أن «النموذج يُنشئ 4 وكلاء فرعيين» بأسعار Sol
  • رسم الخريطة نفسها من جهة Anthropic — Cowork وManaged Agents ووكلاء Claude Code الفرعيون — ورؤية فجوة البدائيات
  • اختيار البدائية المناسبة لكل حمل عمل: وكلاء متعددون أصليون، أو توزيع بنفسك، أو A2A، أو دور طويل واحد
  • تجنّب أنماط الفشل الأربعة التي تحوّل استدعاء Ultra بأربعة وكلاء إلى فاتورة 4 أضعاف بلا مكسب في الدقة

النسخة في جملة واحدة​

Ultra Mode هو غلاف للمستهلكين فوق multi_agent.enabled: true في Responses API — بدائية أصلية تتيح للنموذج إنشاء وكلاء فرعيين بالتوازي داخل طلب واحد، ودمج مخرجاتهم، وإرجاع استجابة واحدة. وهي تمنحك مكسبًا صغيرًا لكنه حقيقي في الدقة على المهام القابلة للتوازي (Terminal-Bench 2.1: 88.8% ← 91.9%)، مقابل فاتورة رموز (tokens) تتناسب تقريبًا خطيًّا مع عدد الوكلاء الفرعيين الذين يختار النموذج إنشاءهم.

ما الذي صدر فعلًا في 9 يوليو 2026​

وصل أمران في الإطلاق نفسه، ويستحق الأمر الفصل بينهما:

  • Ultra Mode — مفتاح منتج داخل ChatGPT وCodex. متاح في الفئة الرائدة (Sol). عند تفعيله تُفكَّك المهام الصعبة إلى تشغيلات متوازية لوكلاء فرعيين قبل الدمج. يُسوَّق على أنه «يُنشئ 4+ وكلاء»؛ وتُظهر بعض مخططات المعايير الخاصة بـ OpenAI عند الإتاحة العامة (GA) إعدادات من 16 وكيلًا على BrowseComp وSEC-Bench Pro، لكن الافتراضي العملي هو أربعة.
  • بيتا الوكلاء المتعددين في Responses API — بدائية للمطوّرين. القدرة الأساسية نفسها، مكشوفة على هيئة multi_agent.enabled: true في client.beta.responses.create(). هذا ما ستستخدمه لبناء تجربة شبيهة بـ Ultra خاصة بك.

الالتباس الذي خلّفه التسويق حقيقي: لا يزال المطوّرون يسألون «كيف أستدعي Ultra Mode من الـ API؟». والجواب أنك لا تفعل — بل تفعّل بيتا الوكلاء المتعددين، وهي البدائية التي تقف تحت ميزة المنتج.

طلب الوكلاء المتعددين في Responses API​

عمليًّا، هذا هو الشكل (Python SDK):

استدعاء أدنى لـ Responses API بالوكلاء المتعددين

from openai import OpenAI

client = OpenAI()

resp = client.beta.responses.create(
  model="gpt-5.6-sol",
  input="Audit this repo for auth-bypass patterns and write a report.",
  multi_agent={
      "enabled": True,
      "max_concurrent_subagents": 3,
  },
  tools=[...],  # your MCP tools, function tools, etc.
  extra_headers={"OpenAI-Beta": "responses_multi_agent=v1"},
)

أربعة أمور في هذا الشكل ليست بديهية:

  • max_concurrent_subagents ليس ميزانية إجمالية. إنه يحدّ أدوار الوكلاء الفرعيين النشطة عبر الشجرة كلها في أي لحظة — الجذر مع كل أحفاده. يمكن للنموذج إنشاء عدد إجمالي أكبر بكثير من الوكلاء الفرعيين طوال عمر الطلب؛ كل ما في الأمر أنه لا يستطيع تشغيل أكثر من N في آن واحد.
  • العمق غير محدود. يمكن للوكيل الفرعي أن يُنشئ بدوره وكلاء فرعيين. لا يوجد سقف ثابت لعمق الشجرة ولا للعدد الإجمالي للوكلاء الفرعيين في كل تشغيل. سطح كلفتك ليس «N استدعاءً» — بل شجرة يشكّلها النموذج وقت التنفيذ.
  • الجذر هو من يدمج. الوكيل الجذر مسؤول عن دمج استجابات الوكلاء الفرعيين في الإجابة النهائية. لا تحصل على كائن منظَّم {subagents: [...]}؛ بل على استجابة واحدة، وتظل أدوار الوكلاء الوسيطة معتمة لشيفرتك.
  • بعض المعاملات تُعطَّل بصمت. reasoning.summary وmax_tool_calls غير مدعومين عند تفعيل الوكلاء المتعددين، ونقطة نهاية الضغط (compaction) غير مدعومة لاستجابات الوكلاء المتعددين. وإن كنت تعتمد على ملخصات الاستدلال في المراقبة، فإنك تفقدها بمجرد تفعيل هذا.

حساب التكلفة الذي لا يطبعه أحد في صفحة التسويق​

بسعر Sol عند الإتاحة العامة، وهو 5 دولارات للمدخلات / 30 دولارًا للمخرجات لكل مليون رمز، تكون الحسبة قاسية. من كتابات المطوّرين الذين فككوا تشغيلات Ultra حقيقية:

  • مهمة يفكّكها Ultra إلى وكيلين فرعيين ≈ ضعف تكلفة رموز المخرجات لاستدعاء Sol واحد — لأن كلا الوكيلين يولّد مخرجات، ثم يولّد الجذر الدمج فوق ذلك.
  • مهمة ينشئ لها Ultra خمسة وكلاء فرعيين ≈ 5 أضعاف — للسبب نفسه، إضافة إلى إعادة تشغيل رموز المدخلات بنسبة أكبر عبر الشجرة.
  • مخططات BrowseComp / SEC-Bench التي تعرض إعدادات 16 وكيلًا ليست غداءً مجانيًا: إنها عرض بحثي، وليست افتراضًا. مع 16 وكيلًا فرعيًا متزامنًا على Sol، تنظر إلى رقم بالدولار في منتصف خانتين لكل استعلام صعب من رموز المخرجات وحدها.

طريقة التفكير: أنت تدفع ثمن محاكاة مونت كارلو من استدعاءات Sol زائد مرور دمج واحد فوقها. أحيانًا يشتري لك ذلك دقة كافية لتُحدث فرقًا. وأحيانًا يكون مجرد فاتورة 4 أضعاف لمهمة كان استدعاء واحد سيحلّها.

ماذا تشتري الدقة فعلًا​

المكاسب المنشورة على التقييمات القابلة للتوازي — أحمال العمل التي صُمّم Ultra Mode لها — حقيقية لكنها متواضعة:

المعيارSol (منفرد)Sol Ultraالفرقما الذي يقيسه التقييم
Terminal-Bench 2.188.8%91.9%+3.1تخطيط متعدد الخطوات لسطر الأوامر وتنسيق الأدوات
BrowseComp87.5%92.2%+4.7بحث ودمج متعدد المصادر على الويب
SEC-Bench Pro—74.3%(رقم الوضع المنفرد غير منشور)استدلال على الوثائق التنظيمية عبر مجموعات نصوص ضخمة

ثلاث نقاط حول هذا الجدول:

  • نطاق +3–5 نقاط يتسق مع ما اشترته أخذ العيّنات المتوازي تاريخيًا على حدود أخرى (best-of-N، self-consistency). البدائية مفيدة حقًّا؛ والفرق ليس نقلة نوعية.
  • هذه هي أفضل الحالات — تقييمات اختيرت لإبراز الوضع. أما في المهام المتسلسلة (تعديل شيفرة خطي، إعادة كتابة ملف واحد، محادثة قصيرة) فيضيف Ultra زمن دمج وتكلفة دون تحريك الدقة.
  • في مخطط Terminal-Bench 2.1 نفسه، سجّل Opus 4.8 من Anthropic نسبة 78.9% — أي أن تقدّم Sol Ultra يأتي من النموذج الأساسي الأفضل ودفعة الوكلاء المتعددين المتراكمة فوقه معًا. فإن انتقلت من Opus إلى Sol Ultra، فلا تنسب الفجوة كلها إلى بدائية الوكلاء المتعددين.

ما تفعله Anthropic بدلًا من ذلك​

لم تُطلق Anthropic بدائية API مماثلة. أقرب النظائر يحلّ كلٌّ منها شريحة مختلفة من المشكلة نفسها:

  • Cowork — سطح منتج. مساحة عمل مكتبية وكيلية يقوم فيها وكيل بعمل متواصل متعدد الخطوات إلى جانب المستخدم. قابل للمقارنة مع Ultra Mode بوصفه ميزة، لا بوصفه بدائية API.
  • Managed Agents وmanaged-agents memory stores — حلقة وكيل مستضافة بحالة دائمة وجدولة. تملأ خانة «الوكيل الخلفي طويل التشغيل»، لا خانة «أنشئ 4 بالتوازي وادمجها».
  • وكلاء Claude Code الفرعيون وحدود أسطول الوكلاء الفرعيين — بدائية وكلاء فرعيين من الدرجة الأولى، لكنها محصورة في واجهة Claude Code CLI. موثّقة، وقابلة للإنشاء بالتوازي، وهي أقرب نظير لـ multi_agent.enabled — مع فرق مهم هو أنك تكتب أمر المنسّق بنفسك.
  • بناء الوكلاء على Messages API — المسار بنفسك. توزّع N استدعاء messages.create بالتوازي، وتكتب أمر الدمج، وتتولى إعادة المحاولات. النتيجة نفسها، وشيفرة أكثر.

الفجوة: لا يوجد حاليًا أي سطح في Anthropic API يتيح لك قلب قيمة منطقية واحدة ليقرر النموذج بنفسه عدد الوكلاء الفرعيين الذين سيُنشئهم ويدمج أعمالهم. وإن أردت هذا السلوك مع Claude فعليك بناؤه — انظر Cowork وAgent Teams لقصة جانب المنتج، وManaged Agents لبدائية الحلقة المستضافة.

اختيار البدائية المناسبة لكل حمل عمل​

Guided walkthrough1 of 5
  1. إن كانت المهام الفرعية تعمل دون انتظار نتائج بعضها — تدقيق مستودع، أو بحث في موضوع عبر مصادر كثيرة، أو إعادة هيكلة N ملفًا باستقلال — فإن شكل التوزيع يستحق كلفته. وإن كانت المهمة متسلسلة (عدّل A، ثم اقرأ نتيجة A، ثم عدّل B) فإن أي بدائية متعددة الوكلاء تضيف عبء الدمج بلا مكسب.

أربعة أنماط فشل تحوّل Ultra إلى فاتورة 4 أضعاف بلا مقابل​

  • تفعيله للمهام المتسلسلة. يظل النموذج يفكّك ويدمج حتى عندما لا تتوازى المهمة. تدفع عبء التنسيق على عمل لم يحتجه قط. قاعدة عملية: إن لم تستطع أن تصف ماذا سيفعل الوكيل الفرعي الثاني بينما يعمل الأول، فلا تفعّل الوكلاء المتعددين.
  • ترك مراقبة ملخص الاستدلال على لوحتك. reasoning.summary غير مدعوم بصمت مع الوكلاء المتعددين. إن كانت مراقبتك تعتمد عليه فستحصل على حقول فارغة وتظنّ أن النموذج لا يفكّر. انشر تغيير المخطط (schema) قبل أن تقلب العلم.
  • استخدام max_tool_calls حدًّا للأمان. وهو أيضًا معطَّل بصمت مع الوكلاء المتعددين. الضمان الذي ظننت أنك تملكه — «20 استدعاء أداة كحد أقصى لكل طلب» — يختفي. افرض سقوف استدعاء الأدوات في طبقة محوّل الأدوات، لا عبر معامل الطلب.
  • افتراض أن max_concurrent_subagents سقف للتكلفة. إنه يحدّ الوكلاء الفرعيين النشطين في لحظة، لا إجمالي ما أُنشئ على امتداد الطلب. يمكن لاستدعاء Ultra واحد أن ينشئ عشرات الوكلاء الفرعيين تباعًا ويظل محترمًا حدّ max_concurrent_subagents: 3. وإن كانت التكلفة هي سقفك، فأضف max_output_tokens على مستوى الطلب.

ما ليس «الوكلاء المتعددين الأصليين»​

بدائيتان مجاورتان كثيرًا ما تُخلطان به:

  • ليس أخذ عيّنات بـ n > 1. معامل n الأقدم في OpenAI يأخذ عيّنات من عدة إكمالات ويعيدها كلها؛ وأنت تختار واحدًا. أما الوكلاء المتعددون فيشغّلون وكلاء فرعيين مختلفين يؤدون أعمالًا مختلفة ويدمجون مخرجاتهم. الأول أخذ عيّنات بدرجة الحرارة؛ والثاني تفكيك للمهام.
  • ليس استدلالًا دفعيًّا. واجهة الدفعات تعالج كثيرًا من الطلبات المستقلة في الخلفية. الوكلاء المتعددون هم وكلاء فرعيون كثيرون منسَّقون داخل طلب تفاعلي واحد. الدفعات موجهة نحو الإنتاجية، والوكلاء المتعددون موجهون نحو النتيجة.

إلى أين يتجه هذا​

بروتوكول A2A (انظر A2A: بروتوكول وكيل إلى وكيل) يغطي الوكلاء المتعددين بين المزوّدين. وmulti_agent.enabled: true يغطي الوكلاء المتعددين داخل النموذج. أما الخانة الشاغرة فهي بدائية عابرة للمزوّدين — نموذج المزوّد A ينشئ وكيلًا فرعيًا لدى المزوّد B ويدمج النتيجة — ولا توجد لها مواصفات عامة بعد. وحين تصل فستصل على هيئة A2A + فعل تسليم أصلي، لا واجهة جديدة عند أي من الطرفين. راقب هذا المجال.

Check yourself

0/4
  1. ما الذي يحدّه max_concurrent_subagents في بيتا الوكلاء المتعددين في Responses؟
  2. فعّلت الوكلاء المتعددين وفجأة تُظهر لوحة المراقبة حقول ملخص الاستدلال فارغة. ما الذي حدث؟
  3. تحتاج إلى وكلاء فرعيين متوازين يعملون في حسابات عملاء مختلفة عبر مزوّدين اثنين. أي بدائية هي الصحيحة؟
  4. أي مما يلي مرشح سيئ لـ Ultra Mode / multi_agent.enabled؟
لا توجد بطاقات بعد — أضف بعضها لبدء المذاكرة. 🃏

المصادر وقراءات إضافية​

التالي​