Gemini 4 Argon وGPT-6 Astra وClaude Opus 5.5: ثلاثة نماذج رائدة وثلاثة فائزين مختلفين

يتضمن منشور إطلاق Gemini 4 Argon من Google جدول اختبارات أداء مؤلفاً من 19 صفاً، وبحسب إحصائنا لهذا الجدول، يتصدر Argon في 13 صفاً بشكل قاطع ويتعادل في صف واحد. أما الصفوف الخمسة التي خسرها فليست مصادفة؛ إذ يتفوق GPT-6 Astra في FrontierSWE v2 وTerminal-Bench Science وOSWorld-2.0، بينما يتفوق Claude Opus 5.5 في Terminal-bench 4.0 وPostTrainBench. وتشمل هذه الاختبارات صفي Terminal-Bench، وصفاً للبرمجة القائمة على الوكلاء (agentic coding)، وصف هندسة تعلم الآلة (ML engineering)، وواحداً من صفي استخدام الحاسوب (computer use)—وهي المهام التي يقضي فيها فريق البرمجة معظم دورات التشغيل فعلياً. ولم يعد الأمر مجرد نقاش نظري؛ فمنذ 13 أكتوبر 2026، بات Argon متاحاً بشكل عام عبر Gemini API المدفوعة باسم gemini-4-argon.

وبذلك، فإن الإجابة عن سؤال «أي النماذج هو الفائز؟» تنقسم إلى ثلاث إجابات باختلاف الصف المعني، وهذا الأمر ليس تفصيلاً هامشياً لفريق يشغّل عدة وكلاء برمجة. فإذا كان كل وكيل (Agent) في مساحة العمل يعتمد على بيئة التشغيل (Runtime) نفسها، فإن الفريق سيرث إخفاقات مختبر واحد إلى جانب إنجازاته، ومع كل إطلاق جديد سيتجدد الجدال. فأي وكيل مخصص لأي مهمة، وما الذي اكتمل، وما الذي يحتاج إلى مراجعة—كل ذلك لا ينبغي أن يتقرر بناءً على من تصدر الجدول هذا الأسبوع.

باختصار

لا ينفرد أي من مختبرات الذكاء الاصطناعي الرائدة بالصدارة في كل المجالات، حتى في الجداول التي يعدها بنفسه. لذلك، تعامل مع كل إطلاق جديد كدليل يفيد في توجيه المهام (routing)، لا كدافع للهجرة الشاملة: احتفظ بأكثر من بيئة تشغيل (Runtime) متصلة، ودوّن قاعدة التوجيه بوضوح (الخيار الافتراضي، والشروط التي تحيل المهمة إلى وكيل مختلف، ومسؤول المراجعة)، ثم اختبرها على ثلاث مهام حقيقية من قاعدة كود مشروعك. يعمل Astra عبر Codex، وOpus 5.5 عبر Claude Code، ونماذج Gemini عبر Gemini CLI باستخدام مفتاح مدفوع. ولما كانت Google لم تؤكد بعد دعم Gemini CLI لنموذج Argon، فاحرص على إجراء اختبار تحقق سريع (smoke-test) للنموذج gemini-4-argon قبل إسناد مهام فعلية إليه.

ما يظهره جدول Google حسب نوع المهمة

إليك الصفوف التي تهم وكلاء البرمجة، مصنفة وفقاً لفئات Google نفسها:

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

لكن ينبغي قراءة هذه الأرقام بشيء من التحفظ؛ فهذا جدول أعدته Google. لقد اختبرت Google نموذج Argon بنفسها في عدة صفوف، في حين أن أرقام المنافسين مستندة في معظمها إلى تقاريرهم الذاتية أو مأخوذة من لوحات الصدارة العامة، ناهيك عن اختلاف بيئات وأطر الاختبار. وتوضح منهجية التقييم مصدر البيانات لكل خلية. كما أن النتائج المستقلة الصادرة منذ الإطلاق تتباين فيما بينها أيضاً: فاختبار Humanity’s Sixth Sense من Scale AI يضع Argon في المرتبة الأولى بنسبة 55.4% مقابل 53.6% لـ GPT-6 Astra، بينما تراه Cursor متعادلاً مع Opus 5.5 في تقييم CursorBench الخاص بها، وتضع منصة Artificial Analysis نموذج Argon (High) في المرتبة الثامنة من بين 216 إصداراً مسجلاً حتى 15 أكتوبر.

ولا يحسم السعر هذه المقارنة أيضاً؛ إذ تبلغ تكلفة Argon دولارين لكل مليون رمز دخل و10 دولارات لكل مليون رمز خرج حتى 30 نوفمبر 2026، ثم ترتفع إلى 4 دولارات و20 دولاراً بدءاً من 1 ديسمبر، وهو السعر المطابق تماماً لـ Opus 5.5. أما Astra فيُطرح بسعر 10 دولارات و50 دولاراً.

لا ينفرد أي مختبر بكل المجالات، فلا تجعل أي نموذج يستحوذ على كامل العمل

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

هذا يغير طريقة تعاملنا مع أيام الإطلاق. فالخطوة المغرية دائماً هي الهجرة الكاملة: تغيير بيئة التشغيل الافتراضية، وإعادة ضبط الإعدادات، وتغيير عادات الفريق بأكمله. أما الخطوة الأقل تكلفة والأكثر حكمة، فهي معاملة النموذج الجديد كمرشح إضافي للمهام التي أثبت جدارته فيها، وترك بقية منظومة العمل دون تغيير. لقد أوضحنا سابقاً أن اختيار أفضل وكيل برمجي أقل أهمية من كيفية إدارتك للعمل نفسه؛ وهذا الجدول الذي يتقاسم فيه ثلاثة منافسين مراكز الصدارة يجسد هذه الحقيقة بالأرقام.

والقرار المنطقي ينحصر في خيارين صريحين:

• الاعتماد على بيئة تشغيل افتراضية واحدة إذا كانت معظم مهامك متشابهة ويتولى شخص واحد مراجعة كل شيء؛ فإضافة بيئة تشغيل ثانية تعني إعدادات إضافية يجب صيانتها، وفاتورة أخرى، ونمطاً جديداً من الأخطاء المحتملة.
• تشغيل بيئتين أو ثلاث بيئات إذا كانت مهامك تتوزع بين العمل الكثيف على الطرفية، والتحقق عبر واجهات المستخدم، وقراءة قواعد الكود الضخمة؛ فهذا التوزيع هو تماماً ما تعكسه تباينات نتائج الجدول.

دوّن قاعدة التوجيه بوضوح

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

Routing rule v1 (re-test after every frontier launch)

Default
  The Agent on your current default Runtime, until your own
  comparison says otherwise.

Send the Task to the Claude Code Agent (Opus 5.5 set in Claude Code) when
  - most of the work happens in a terminal: builds, CI repair, setup  [Terminal-bench 4.0]
  - it is training or evaluation plumbing for a model pipeline        [PostTrainBench]

Send the Task to the Codex Agent (GPT-6 Astra set in Codex) when
  - the change has to be verified by driving a desktop or browser UI  [OSWorld-2.0]
  - it is scientific or data work done mostly in a terminal           [Terminal-Bench Science]

Send the Task to the Gemini CLI Agent (gemini-4-argon) when
  - it needs a very large codebase or log read in one pass            [GraphWalks]
  - note: the 1M window is shared by input, thinking and output, and
    Gemini CLI support is unverified. Smoke-test before this line routes work.

Escalate
  If a run fails its acceptance checks twice, reassign the Task to the next
  Agent in this rule. The failed runs stay on the Task as evidence.

Review
  An Agent on a different Runtime from the author reads the diff and the
  evidence. A person accepts the result.

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

أما مكان توثيق هذه القاعدة فيعتمد على آلية التوجيه: فإذا كان الأشخاص هم من يحددون المكلف بالمهمة (Assignee)، فمكانها ضمن المعايير المكتوبة لمساحة العمل (Space). وإذا كان قائد الفريق (Crew leader) هو من يتولى التوجيه، فيجب إدراجها ضمن تعليمات الفريق (Crew instructions). وفي كلتا الحالتين، تُعاد النتائج إلى المهمة ذاتها، مما يحفظ سجل المقارنات في مكان واحد. ويتناول مقال أي النماذج يناسب كل مهمة برمجية هذا الموضوع بتفصيل أكبر حول مطابقة أنماط المهام مع أدوار النماذج.

اختبر القاعدة على قاعدة كودك الخاصة قبل الاعتماد عليها

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

1. مهمة تعتمد بكثافة على الطرفية، مثل إصلاح مسار تكامل مستمر (CI) معطل.
2. مهمة تتطلب التحقق من التعديلات عبر واجهة مستخدم.
3. سؤال يتطلب قراءة جزء كبير من المستودع ووضعه ضمن السياق.

زوّد كل وكيل بوصف المهمة نفسه ومعايير القبول ذاتها، مستخدماً وضع إنشاء دليل مؤقت (Create temporary directory) ليحصل كل تشغيل على شجرة عمل (worktree) خاصة به. ثم قيّم ما يُعاد إلى المهمة فعلياً، وليس ما يدعيه الوكيل: أي ملف الفروقات، والاختبارات ونتائجها، والأسئلة المطروحة، والوقت الذي استغرقه المراجع البشري لقبول النتيجة.

يمكن لـ Argon الدخول في هذه المقارنة الآن بمجرد نجاح اختبار تحقق سريع من سطر واحد باستخدام gemini-4-argon في Gemini CLI. نفّذ المهام الثلاث نفسها عليه قبل إجراء أي تغيير آخر. كما يوضح مقال مقارنة بيئة التشغيل الافتراضية بين Opus 5.5 وGPT-6 Sol جانب التكلفة لكل مهمة مكتملة في اتخاذ القرار ذاته.

بيئات تشغيل النماذج حتى 15 أكتوبر 2026

تنطوي صفوف Gemini على فخ؛ فمنذ 18 يونيو 2026، لم يعد Gemini CLI يدعم حسابات Google AI Pro أو Ultra أو حسابات Code Assist المجانية للأفراد، وفقاً لما ورد في إشعار الانتقال الصادر عن Google. ورغم أن اشتراكي Pro وUltra يتضمنان Argon في تطبيق Gemini، إلا أن الاشتراك ليس مفتاح API، كما أن Argon لا يوفر باقة API مجانية.

لا تختار Sharkly النماذج نيابة عنك؛ إذ توضح وثائق الوكلاء ذلك بصراحة: «يتبع الوكيل النموذج الافتراضي لبيئة التشغيل (Runtime). ولا يضمن أو يعرض اسم نموذج محدد». بل يمكنك تحديد النموذج عبر المعاملات المخصصة (Custom arguments) في الوكيل أو بيئة التشغيل، أو من خلال إعدادات الأداة نفسها على الحاسوب (Computer). وبالتالي، فإن عبارة «وكيل Codex» في قاعدة التوجيه تعني وكيلاً يعمل على بيئة تشغيل Codex ومُهيأً لاستخدام Astra.

يمكنك الاطلاع على خطوات الإعداد في مقالات: GPT-6 Astra في Sharkly، وClaude Opus 5.5 في Sharkly، وللاطلاع على تهيئة Gemini CLI والتحويل إلى Argon، راجع مقال Gemini 4 Argon لوكلاء البرمجة.

تتغير الجداول، لكن منظومة العمل يجب أن تبقى ثابتة

سيعيد أي إطلاق قادم رسم ملامح هذا الجدول بلا شك. وما يجب أن يظل ثابتاً هو كل ما يحيط بالنموذج: قاعدة التوجيه، والمهام، والأدلة التي يُسفر عنها كل تشغيل، والشخص المسؤول عن قبول النتائج. فالوكلاء يبحثون وينفذون ويختبرون ويقدمون التقارير، بينما يتولى البشر تحديد المسار ومنح الصلاحيات واعتماد النتائج النهائية.

وإذا كنت ترغب في مواصلة استخدام وكلاء برمجة متعددين بدلاً من حصر نفسك في نظام بيئي واحد، فهذه هي المشكلة التي صُممت Sharkly لمعالجتها تحديداً.