أطلقت Anthropic نموذج Claude Sonnet 5.5 في 28 سبتمبر 2026 بوصفه العضو الأسرع والأقل كلفة في عائلة 5.5. تقول الشركة إنه يولّد المخرجات أسرع بأكثر من 30% من Sonnet 5، وإن كلفة المهمة قد تنخفض حتى 30% مع بقاء أسعار الـTokens المعلنة كما هي. هذه قياسات صادرة عن Anthropic، وليست ضمانًا مستقلًا لكل تطبيق.
القصة الهندسية الأهم ليست نتيجة Benchmark واحدة. يغيّر Sonnet 5.5 معاملات الطلب وسلوك Thinking واختيار الأدوات وبنية Response Blocks وتكامل Computer Use. لذلك قد يؤدي تبديل Model ID وحده إلى خطأ HTTP 400 أو اختفاء رسائل التقدم أو إبطال سجل محادثة جرى تعديله أو تغيير كلفة Tool Loop من دون ملاحظة.
تذكر صفحة النموذج الرسمية Context Window بحجم مليون Token، وMaximum Output يصل إلى 128K، وAdaptive Thinking، وDefault Effort بقيمة high. ويقدّم إعلان الإطلاق النموذج للمهام اليومية محددة النطاق وإصلاح العلل وإنتاج ملفات جيدة، بينما يبقى Opus 5.5—وفق توصيف الشركة—للأعمال المفتوحة الأصعب التي تحتاج حكمًا مستمرًا. يجب أن يحافظ Production Routing على هذا الفرق بدل التعامل مع Sonnet الجديد كبديل شامل.
ابدأ باقتصاد المهمة لا سعر الـToken
يحافظ Sonnet 5.5 على السعر القياسي: دولاران لكل مليون Input Tokens وعشرة دولارات لكل مليون Output Tokens، مع 0.20 دولار لـCache Reads. وينبع ادعاء Anthropic بانخفاض كلفة المهمة من استخدام Tokens أقل وإنجاز العمل أسرع، لا من خفض List Price. وهذا فرق مهم لأن فاتورة Agent تتجاوز Request واحدة وResponse واحدة.
قِس التنفيذ كاملًا: Uncached Input وCache Writes وCache Reads وThinking والمخرجات الظاهرة وTool Calls وRetries والزمن والمحاولات الفاشلة ووقت المراجع. ثم اقسم الكلفة على النتائج المقبولة. قد يكون Run وفّر 25% من Output Tokens لكنه احتاج تصحيحًا بشريًا إضافيًا، فيصبح أسوأ. وقد يكون Request أعلى كلفة لكنه ينهي المهمة بنصف عدد المحاولات، فيصبح أفضل.
عرّف فئات الأحمال قبل اختيار Route. فـExtraction حتمي وإصلاح برمجي محدود وترحيل بين Repositories ومراجعة معمارية غامضة تحمل مخاطر فشل مختلفة. وجّه وفق الدليل الذي جمعته لكل فئة، لا وفق تفضيل عام لنموذج واحد.
تعامل مع الترحيل كتغيير في عقد الطلب
يحدد دليل الترحيل إعدادات قد تعيد أخطاء: Manual Thinking Budgets وSampling Parameters غير الافتراضية وAssistant Prefills وForced Tool Choice ووضع Thinking من نوع disabled. صحيح أن Model ID هو claude-sonnet-5-5، لكن وحدة النشر الحقيقية هي Request Bundle محددة الإصدار تضم النموذج وSystem Instructions والأدوات وResponse Parser وسياسة Retry وEffort Level.
احصر كل Request Builder قبل تعديل إعدادات الإنتاج. ابحث عن قيم صريحة لـtemperature وtop-p وtop-k، وThinking Budgets، وAssistant-message Prefills، وTool Choice من نوع any أو Named Tool، وPositional Parsing مثل افتراض أن العنصر الأول نص، وإصدارات Computer Use القديمة، وBeta Headers التي ترفضها Toolset الجديدة.
احتفظ بالحزمتين القديمة والجديدة جنبًا إلى جنب. Rollback يعيد اسم النموذج فقط بينما يبقي Parser والمعاملات الجديدة ليس Rollback. أعطِ الحزمة Version واضحًا وسجّله في كل Trace، واجعل تغيير التوجيه قابلًا للتراجع بصورة مستقلة.
Thinking يغيّر الحالة والقراءة والكلفة
يعمل Adaptive Thinking عندما تحذف حقل thinking. ولإيقاف التفكير المسبق يستخدم Sonnet 5.5 وضع between_tools الجديد عند Effort من low أو medium أو high؛ أما disabled القديم فيعيد خطأ. وعند xhigh أو max لا يقبل between_tools. لذلك Effort جزء من العقد وليس Tuning تجميليًا.
قد يبدأ Response بـThinking Blocks، فاقرأ كل Content Block بحسب Type بدل افتراض أن أول Block يحتوي Text. وفي Tool Loop أعد Thinking Blocks كما هي ضمن Assistant Turn. توثق Anthropic أن Thinking Blocks في Sonnet 5.5 مرتبطة بالنموذج وبسابقة المحادثة. وقد يؤدي تعديل History سابقة ثم إعادة إرسال تلك Blocks إلى خطأ في الحسابات التي تطبّق الربط.
حافظ على Execution History بنمط Append-only. وإذا تغيرت تعليمات المنتج أو الأدوات وسط المحادثة، فاستخدم الآليات الموثقة للتغيير أو ابدأ Run جديدة من Application State متحقق منها. لا تجعل Reasoning مخفيًا النسخة الوحيدة من Task State. السجل القابل للنقل هو طلب المستخدم وTool Results المتحقق منها وحالة التطبيق الدائمة ودليل الإكمال الصريح.
كما تُحسب Thinking Tokens من Maximum Output وتُفوّتَر كإخراج. أعد ضبط max_tokens وتنبيهات الكلفة؛ فقد يتوقف Tool Task طويل إذا استهلك التفكير معظم ميزانية كانت مصممة للنص الظاهر فقط.
استبدل فرض الأداة بإنفاذ داخل التطبيق
يرفض Sonnet 5.5 Tool Choice من نوع any أو فرض Named Tool. والترحيل الموثق هو Auto Tool Selection مع Strict Schemas حين تكون مدعومة. يزيل هذا التغيير مفتاحًا مريحًا في الـAPI، لكنه لا يجب أن يزيل ضمان المنتج.
إذا كان Workflow يشترط Lookup قبل الإجابة، فاكتب الشرط بوضوح وتحقق منه في Application State. وإذا احتاج Mutation إلى Approval، فنفّذ الموافقة خارج النموذج. تحقق من الأداة المختارة وSchema وصلاحية المستخدم وResource Scope وIdempotency Key والانتقال المتوقع للحالة. قرار النموذج باستخدام أداة ليس Authorization Boundary.
تقلل Strict Tools المدخلات المشوهة، لكنها لا تثبت صحة العملية. احتفظ بالتحقق الدلالي داخل الكود: أن Order يخص Tenant الحالي، وأن Refund لا يتجاوز المبلغ المحصل، وأن Deployment يستهدف Environment مسموحة، وأن الفعل المدمر يملك موافقة حالية.
حافظ على وضوح التقدم ولا تعتبر السرد حقيقة تشغيلية
تذكر وثائق ما الجديد أن النص الطويل بين Tool Calls قد ينتقل إلى Thinking Blocks. ومع Display افتراضي بقيمة omitted قد تبدو الواجهة التي كانت تعرض هذا النص صامتة رغم استمرار الطلب. إنه تغيير في شكل الرد من دون API Failure.
قرر هل يحتاج المنتج Model Narration أم Operational Progress. يجب أن تأتي حالة التشغيل من Executor: تم قبول المهمة، بدأت الأداة، ننتظر الموافقة، جرى جدولة Retry، تم التحقق من المخرج. تبقى هذه الحالات موثوقة عبر إصدارات النماذج. وإذا أفادت Summarized Model Updates المستخدم في Run طويلة، فاعرضها منفصلة وسمّها تعليق تقدم لا Audit Log.
اختبر فترات الصمت. قِس الزمن حتى أول إشارة ظاهرة، والزمن بين Milestones متحقق منها، والمدة التي يظن المستخدم بعدها أن التنفيذ عالق. قد يكون النموذج أسرع بينما تبدو التجربة أبطأ إذا اختفت Progress Messages.
ابنِ Router حول فئات أحمال خضعت للتقييم
تقدم Anthropic Sonnet 5.5 كنموذج سريع للمهام محددة النطاق وOpus 5.5 للأعمال المفتوحة الأكثر تعقيدًا. حوّل هذا التموضع إلى Routing Policy صريحة. ابدأ بـWorkload Metadata: فئة المهمة والمخاطر وحجم السياق وعدد الأدوات والمدة المتوقعة وقابلية التراجع ومعيار الجودة المطلوب.
استخدم Sonnet لفئة فقط بعد اجتياز Acceptance Set الخاصة بها. وصعّد عندما تتجاوز المهمة حدودًا معلنة—مثل امتداد Architecture Review إلى خدمات أكثر من المتوقع، أو فشل المحاولة الأولى في Critical Check، أو طلب فعل غير قابل للعكس. لا توجّه وفق طول Prompt وحده؛ فقد تمنح جملة قصيرة صلاحية لعملية عالية المخاطر.
تجنب Model Switching خفيًا داخل المحادثة نفسها. لأن توافق Thinking Blocks يختلف بين النماذج، قد يفقد Fallback الحالة الخفية حتى لو نجحت API Request. وعند الحاجة إلى التصعيد، ابنِ Handoff Package جديدة من حقائق دائمة: الهدف والقيود والمدخلات المتحقق منها والخطوات المكتملة وTool Outputs والأسئلة المفتوحة.
أعد اختبار مستويات Effort كلها
أعيدت معايرة Effort Levels. توصي Anthropic بالبدء من medium للأعمال Agentic محددة جيدًا، والانتقال إلى high للمهام الأصعب أو الأطول؛ أما Chat والأحمال الحساسة للزمن فقد تبدأ من low أو medium. نقل Label السابقة من النموذج القديم لا يحافظ على زمن أو عمق Thinking أو الكلفة نفسها.
استخدم Evaluation Set ثابتة من أعمال تشبه الإنتاج. ضمّن الحالات الشائعة الناجحة والمدخلات الغامضة وفشل الأدوات والسياق الطويل ورفض الصلاحية والتسليم المكرر ومهمة يجب أن تُرفض أو تُصعّد. قِس Postconditions دقيقة: نجحت الاختبارات، طابقت الحقائق مصادرها، حدث Side Effect مرة واحدة، لم يقع فعل ممنوع، وفهم المستخدم الحالة النهائية.
لكل فئة حمل وEffort Level، سجّل Accepted-task Rate وCritical Failure Rate والكمون الوسطي والطرفي وInput/Output Tokens وعدد Tool Calls ونسبة Retry ودقائق المراجعة والكلفة الكلية لكل مهمة مقبولة. Benchmarks الشركة فرضيات مفيدة؛ قرار الإصدار يحتاج دليلك المحلي.
انشر حزمة الإصدار كاملة بنمط Canary
ابدأ بـOffline Replay. ثم شغّل Shadow Traffic مع تعطيل Mutations وقارن النتائج من دون عرضها للمستخدم. وعندما تحقق الحزمة الجديدة المعيار، انشر Canary لشريحة صغيرة مؤهلة خلف Stable Route Key كي لا يتنقل المستخدم أو Organization بين الحزمتين عبر الطلبات.
حدد Rollback Thresholds قبل الإطلاق: خطأ في فعل حرج، تراجع Accepted-task Rate، ارتفاع Refusals، وp95 Latency، وRetry Rate، وكلفة المهمة المقبولة، ومدة الصمت في Progress. يجب أن تسمي التنبيهات فئة الحمل وBundle Version لا اسم النموذج فقط.
احتفظ بـTraces مع ضوابط البيانات الحساسة: Request Bundle Version وEffort وإصدارات الأدوات وCache State وStop Reason وأنواع Blocks وSide Effects المتحقق منها ونتيجة القبول. لا تسجل محتوى Thinking الخاص كاختصار للمراقبة. تحتاج دليلًا يشرح التنفيذ، لا نسخة من Reasoning مخفي.
القرار العملي
Claude Sonnet 5.5 مرشح جدي للأحمال Agentic وKnowledge Work الكبيرة عندما تكون المهام محددة جيدًا. تنشر Anthropic تحسنًا ملحوظًا في السرعة والكفاءة، لكن وثائقها نفسها توضح أن API Contract تغيرت بطرق قد تكسر التكاملات الحالية.
نفّذ الترحيل عندما تجتاز Request Bundle الجديدة Contract Tests، وتتحسن المهام الحقيقية عند Effort المختار، وتبقى Tool Authorization داخل التطبيق، وتظل Progress مفهومة، ويمكن استعادة الحزمة السابقة كاملة بسرعة. وجّه وفق النتيجة المقبولة وكلفة الفشل—لا وفق حماس الإطلاق أو List Price أو Benchmark واحدة.
الميزة الدائمة ليست مجرد استخدام نموذج أحدث. إنها امتلاك Release Process تستطيع تقييم كل تغيير في النموذج وتوجيهه ومراقبته والتراجع عنه بلا تخمين.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
