Sonnet 5.5 أم Opus 5.5: أي وكيل ذكي هو الأنسب لإنجاز المهمة؟

أطلقت شركة Anthropic نموذج Claude Sonnet 5.5 في 28 سبتمبر، بعد ستة أيام فقط من إطلاق Opus 5.5. وبتكلفة تبلغ دولارين لكل مليون رمز دخل (input tokens) و10 دولارات لكل مليون رمز خرج (output tokens)، فإنه يأتي بنصف تكلفة Opus 5.5 البالغة 4 دولارات و20 دولارًا على التوالي. وعلاوة على ذلك، تُظهر صفحة الإطلاق أن أداءه يقع بفارق نقاط معدودة فقط عن Opus 5.5 في معظم المؤشرات، بل ويتفوق عليه في اختبار Terminal-Bench 4.0 الذي أجرته Anthropic بنفسها. بالنسبة لأي فريق يعتمد على وكلاء برمجة متعددين، تبدو الخطوة المغرية هنا هي تعيين جميع الوكلاء (Agents) على Sonnet وتوفير فارق التكلفة.

إلا أن الرسوم البيانية المعتمدة على مستوى الجهد في الصفحة نفسها تُثبت عكس ذلك. فالنتيجة البارزة لنموذج Sonnet في Terminal-Bench تحققت عند أقصى مستوى جهد للنموذج، بتكلفة بلغت 12.54 دولارًا للمحاولة الواحدة. أما عند الإعدادات العملية القابلة للتشغيل طوال اليوم، فإن الترتيب ينقلب تمامًا: يحقق Opus 5.5 عند مستوى الجهد المتوسط (medium) نسبة 57.6% بتكلفة 2.94 دولار، بينما يسجل Sonnet 5.5 عند الجهد العالي (high) نسبة 43.0% بتكلفة 1.94 دولار، ولا يتفوق Sonnet على مستوى Opus المتوسط إلا عند رفع الجهد إلى الفائق (xhigh)، حيث يحقق 61.5% ولكن بتكلفة 5.30 دولار.

خلاصة القول (TL;DR)

اعتمد Sonnet 5.5 بمستوى جهد متوسط (medium) كخيار افتراضي للمهام محددة النطاق بدقة. وأسند المهام الطويلة أو الغامضة أو ذات التأثير المتشعب عبر النظام إلى Opus 5.5 بدلًا من رفع جهد Sonnet إلى الفائق (xhigh)؛ ففي جميع الرسوم البيانية الثلاثة للبرمجة حسب الجهد التي نشرتها Anthropic، يتفوق Opus بمستوى high على Sonnet بمستوى xhigh وبتكلفة مماثلة تقريبًا أو أقل. دوّن هذه القواعد بوضوح كإعداد رسمي على الوكيل، وليس كمجرد تفضيل شخصي غير معلن: وكيل واحد لكل فئة تجمع بين النموذج ومستوى الجهد، مع شروط تصعيد محددة بالاسم، وتعريف واضح لمعايير الإنجاز (definition of done). إن منصة Sharkly لا تختار النموذج أو مستوى الجهد بنفسها، بل تحتفظ بسجل دقيق يوضح ما قام به كل وكيل داخل المهمة (Task).

ما تدعمه أرقام الإطلاق فعليًا

فيما يلي جدول الإطلاق، موضحًا مستوى الجهد المبذول وراء كل نتيجة والجهة المنفذة للاختبار:

هناك ملاحظتان مهمتان حول نتائج Terminal-Bench: توضح بطاقة النظام أن الطلبات المحظورة أو التي وُضعت عليها علامات تدقيق أثرت في 10% من تجارب Opus 5.5 مقابل 1.5% فقط لتجارب Sonnet، كما سجّل الاختبار المستقل لمنصة Artificial Analysis أداء Sonnet 5.5 بنسبة 63.6% وليس 70.6%. وفي الوقت نفسه، يُظهر معيار SWE-Bench Pro فارقًا قدره 8.6 نقطة لصالح Opus. ويتوافق هذا مع التوجه الرسمي لشركة Anthropic، حيث تقترح Sonnet 5.5 للمهام اليومية محددة النطاق وإصلاح الأخطاء، في حين يظل Opus 5.5 «أقوى بوضوح في المهام المعقدة والمفتوحة».

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

يُعد Sonnet 5.5 الخيار الأقل تكلفة للمحاولة عند مستويي medium وhigh، ولكنه يسجل في الوقت ذاته أدنى الدرجات. ولكن بمجرد تجاوز مستوى high تتقاطع الخطوط: إذ تصبح تكلفة تشغيل Sonnet عند مستوى xhigh أعلى من تكلفة Opus عند مستوى medium عبر المعايير الثلاثة بأكملها، كما يخسر أمام Opus بمستوى high في المعايير الثلاثة جميعها رغم تقارب التكلفة أو كون Opus أقل تكلفة. باختصار، يفقد النموذج الاقتصادي ميزته السعرية بمجرد أن تطلب منه العمل كنموذج باهظ التكلفة. تجدر الإشارة إلى أن تكاليف CursorBench لنموذج Sonnet هي مجرد تقديرات من Anthropic، كما أن أيًا من هذه الاختبارات لم يُجرَ على مستودع الشيفرة الخاص بك؛ لذا تعامل مع نقطة التقاطع هذه كفرضية بحاجة إلى التحقق العملي.

صياغة قاعدة التوجيه وتوثيقها

دعت مقالاتنا السابقة إلى مواءمة النماذج مع أدوار الوكلاء، وإلى تحديد الوكيل المناسب للمهمة استنادًا إلى طبيعتها، وكذلك إلى توثيق فئات التشغيل في صورة قواعد واضحة. ويضيف Sonnet 5.5 بعدًا إضافيًا لهذه المعادلة؛ ففي معيار Terminal-Bench، تتسع الفجوة في التكلفة للنموذج نفسه بنحو 15 ضعفًا بين مستويي medium وmax (0.83 دولار مقابل 12.54 دولار للمحاولة الواحدة). بناءً على ذلك، لا يمكن اعتبار عبارة «وجّه هذا العمل إلى Sonnet» قاعدة مكتملة ما لم تحدد بدقة مستوى الجهد المطلوب.

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

• فشل الفحص نفسه مرتين: يقوم مراجع بشري بنقل المهمة إلى وكيل Opus مع إرفاق سجل التشغيل، مع تجنب تكرار المحاولات تلقائيًا وبصمت على فئة أعلى.
• حاجة التعديل إلى ملفات أكثر مما يُسمح به لوكيل التنفيذ (ثمانية ملفات مثلًا)، أو تعديل مسار لم يُذكر في تفاصيل المهمة.
• طرح الوكيل سؤالًا يتعلق بالتصميم المعماري، وليس مجرد استفسار عن صياغة المهمة.
• نجاح فئة معينة من المهام فقط عندما يعمل Sonnet بمستوى أعلى من high: يتم نقل هذه الفئة بالكامل إلى وكيل Opus في دورة العمل التالية (Sprint).

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

أثر كل نموذج على قائمة انتظار المراجعة

إن القاعدة التي تكتفي بتحديد النموذج ومستوى الجهد هي نصف قاعدة فقط؛ فنصفها الآخر يكمن في تحديد معايير «اكتمال العمل»، لأن كل فئة تشغيل تُسلّم للمراجع مخرجات مختلفة تمامًا، وكانت المراجعة تشكّل عنق الزجاجة بالفعل قبل إطلاق أيٍّ من النموذجين. فـ التشغيل الأقل تكلفة يضيف المزيد من الفروقات البرمجية المطلوب فحصها، ولكنه لا يضيف ساعات إضافية لعمل المراجعين.

يوضح دليل هندسة الأوامر لنموذج Sonnet 5.5 من Anthropic بصراحة ما سيواجهه المراجع:

• عند مستويي low وmedium، يطلب الاستيضاح مبكرًا في المهام البرمجية المستقلة الطويلة: فتجد على لوحة المهام مهمة متوقفة في انتظار رد بشري في الثانية صباحًا. وقد عزا أحد المعلقين على Hacker News تسجيل نسبة 7.4% فقط في اختبار قياسي مخصص (بينما حقق Sonnet 5 نسبة 17.8%) إلى هذا السلوك تحديدًا.
• عند مستوى low، قد يتخطى مرحلة التحقق ويعلن اكتمال الشيفرة دون تشغيل الاختبارات. لذا، فإن إعلان وكيل الفرز عن «اكتمال» المهمة لا قيمة له دون إرفاق مخرجات الفحص.
• في جميع مستويات الجهد، يُضيف اختبارات ومستندات وملفات صغيرة لم يطلبها أحد. ورغم أن بعضها قد يكون مفيدًا، إلا أنها تشكّل كلها حجمًا إضافيًا من الفروقات البرمجية التي يجب قراءتها.
• عند مستويي xhigh وmax، يُضيف جولات مراجعة أو وكلاء فرعيين للمراجعة. وتشير صفحة الإطلاق إلى أن هذا كان سبب تسجيل Sonnet 5.5 نتيجة أقل في FrontierCode عند مستوى max مقارنة بمستوى xhigh؛ إذ قام مرارًا بتشغيل مهارة مراجعة الشيفرة في Claude Code، والتي تفرّع العمل إلى العديد من الوكلاء الفرعيين، وهو ما تسبب في حالتين درستهما Cognition في انتهاء المهلة الزمنية أو إجراء تعديلات خارج نطاق المهمة. وتُعد هذه التعديلات الخارجة عن النطاق العبء الأثقل على المراجع، إذ تضطره للبحث عنها سطرًا بسطر.

في المقابل، يُلقي Opus 5.5 عبئًا من نوع آخر على قائمة المراجعة؛ فوفقًا لـ Anthropic، يستطيع النموذج مواصلة العمل على المهمة لمدة 18 ساعة أو أكثر مع مخرجات تصل إلى 128 ألف رمز (tokens). بالتالي، لا تكمن مشكلته في الضوضاء غير الضرورية بل في الحجم الضخم للمخرجات، وتنطبق عليه أيضًا حزمة التسليم التي يحتاجها المراجع للتحقق من المخرجات.

لهذا السبب، يجب أن يكون تعريف «اكتمال العمل» جزءًا أساسيًا من تعليمات الوكيل المنفذ، وهي التعليمات التي تُضمّنها Sharkly في كل تشغيل:

Agent: sonnet-worker  (Claude Code, claude-sonnet-5-5, effort medium)

Done means:
- The checks named in the Task ran. Paste each command and its exit
  code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
  created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.

Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.

Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.

تشغيل الفئتين معًا في Sharkly

لا تختار Sharkly النموذج ولا تحدد مستوى الجهد؛ إذ تنص وثائق الوكلاء صراحةً على ما يلي: «يتبع الوكيل النموذج الافتراضي لبيئة التشغيل. ولا يتعهد بنموذج محدد أو يعرض اسمه. يتم تغيير النماذج من خلال إعدادات بيئة التشغيل أو أداة Computer، وليس على مستوى الوكيل». كما لا يتوفر أي خيار للتحكم في عمق التفكير على مستوى الوكيل نفسه. فالفئة التشغيلية ما هي إلا إعداد لـ Claude Code على جهاز Computer محدد، بينما يمثل الوكيل أسلوب الفريق في إسناد المهام إليه.

إذن، القاعدة هي: وكيل واحد لكل فئة. يعمل sonnet-worker على Computer تم ضبط Claude Code فيه على claude-sonnet-5-5، بينما يعمل opus-lead على جهاز مهيأ لاستخدام claude-opus-5-5. ويمكن أن يكون Computer مجرد حاوية برمجية، وبالتالي فإن إضافة فئة ثانية لا تعني توفير جهاز حاسوب إضافي. وثمة ثلاثة تفاصيل أساسية من وثائق إعداد النماذج في Claude Code تحدد ما إذا كانت الفئة مطابقة بالفعل لاسمها:

• تثبيت المعرّف الكامل: الاسم المستعار sonnet لا يشير إلى Sonnet 5.5 إلا عبر واجهة برمجة تطبيقات Anthropic فقط (بينما لا يزال يشير في منصتي Bedrock وGoogle Cloud إلى Sonnet 4.5)، كما يتطلب تشغيل Sonnet 5.5 إصدار Claude Code v2.1.284 أو أحدث.
• النموذج الافتراضي default في Claude Code هو Opus 5.5 في اشتراكات Pro وMax وTeam وEnterprise وعبر واجهة التطبيقات البرمجية، لذا فإن أي Computer لم يتم تخصيص إعداداته يُعتبر تلقائيًا ضمن فئة Opus.
• مستوى الجهد الافتراضي لنموذج Sonnet 5.5 في Claude Code هو medium، وهو ما يمثل فئة الوكيل المنفذ الموضحة أعلاه. ويتم تغيير هذا الإعداد من خلال Computer، وليس على مستوى الوكيل.

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

بالنسبة للأعمال التي تتطلب استخدام الفئتين معًا في مهمة واحدة، استخدم فرق العمل (Crew). تمثل Crew مجموعة قابلة لإعادة الاستخدام تضم أفرادًا ووكلاء يديرهم وكيل قائد واحد. وعند تعيين opus-lead قائدًا ووكلاء Sonnet أعضاءً، يقرأ القائد المهمة ويتولى تنفيذها أو يوجّه إشارة إلى أحد الأعضاء لإنجاز جزء منها، ليقوم الأعضاء بدورهم بإضافة نتائجهم إلى المهمة نفسها. هذا هو النمط القائم على تنسيق Opus وإدارته الذي اقترحه المعلقون على Hacker News، مع الحفاظ على وضوح عمليات التسليم بحيث يمكن للمراجع البشري قراءتها. أما بالنسبة للمهام الصغيرة واضحة المعالم، فيمكنك الاستغناء عن Crew وإسناد المهمة مباشرة إلى sonnet-worker.

يقدم الاسم المستعار opusplan في Claude Code صيغة مشابهة لذلك داخل جلسة واحدة: حيث يعمل Opus في وضع التخطيط، وSonnet في وضع التنفيذ. مع مراعاة أن شق Sonnet هنا يعني Sonnet 5.5 فقط على واجهة برمجة تطبيقات Anthropic؛ أما على Bedrock أو Google Cloud أو Foundry فإنه يشير إلى إصدار أقدم من Sonnet. استخدم هذا الخيار إذا كان شخص واحد هو من يُدير الجلسة ويراجعها بالكامل، بينما يُفضل استخدام وكيلين منفصلين إذا كان هناك طرف آخر يحتاج إلى معرفة واضحة بالوكيل الذي خطط وذلك الذي نفّذ.

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

لا يُغيّر أيٌّ من هذا من هوية الجهة المسؤولة عن اعتماد العمل النهائي. فالوكلاء يبحثون وينفذون ويختبرون ويقدمون التقارير، بينما يتولى الفريق البشري تحديد التوجهات، ومنح الصلاحيات، وقبول النتائج. وتُحتسب التكاليف المذكورة أعلاه مباشرة ضمن فاتورة مزود الخدمة لديك، نظرًا لأن استخدام النماذج يتم عبر الاشتراكات أو مفاتيح API المعرفة في تلك الأدوات. كما أن سجل الإسناد، وسجل التشغيل، والأسئلة، والنتائج، والمراجعة البشرية تُحفظ جميعًا وتعود إلى المهمة بغض النظر عن النموذج الذي سيتصدر المشهد في الربع القادم. يظل هذا المنطق ساريًا عبر مختلف المزودين كما توضح المقارنة بين Sonnet 5.5 وGPT-6 Sol. فإذا كنت ترغب في مواصلة استخدام وكلاء برمجة متعددين بدلًا من التقيد بمنظومة تقنية واحدة، فهذه هي المشكلة الأساسية التي صُممت Sharkly لحلها.