Claude Code 2.1.296: حين يصبح اختيار النموذج سياسة على مستوى سير العمل لا قراراً لكل وكيل

كلما كبر خط العمل المبني على وكلاء البرمجة، ظهر سؤال مزعج لا علاقة له بجودة الكود: أي نموذج يشغّل أي وكيل، ومن يقرر ذلك، وكم يكلّف؟ في 9 أكتوبر 2026 أصدرت Anthropic النسخة 2.1.296 من Claude Code، وبين عشرات التغييرات فيها خطوة صغيرة في ظاهرها كبيرة في أثرها: متغيّر بيئة يثبّت نموذجاً واحداً لكل وكلاء سير العمل، فيتحول اختيار النموذج من قرار فردي لكل وكيل إلى سياسة على مستوى خط العمل كله.

ما الجديد في هذا الإصدار؟

بحسب ملاحظات الإصدار على GitHub والتغطيات التي لخّصتها، أبرز الإضافات:

• CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL: متغيّر يشغّل كل وكلاء سير العمل (Workflow) على نموذج واحد، بينما تحتفظ بقية الوكلاء الفرعيين بنماذجها.
• autoCompactWindow: إعداد يعمل في ترويسة تعريف الوكيل الفرعي وفي تعريفات --agents، ويسمح للوكيل الفرعي بضغط سياقه تلقائياً قبل أن تصل المحادثة الرئيسية إلى عتبتها هي.
• خيار allow_large في أداة القراءة: لقراءة ملف نصي كبير في استدعاء واحد حين يتسع السياق.
• CLAUDE_CODE_OVERLOADED_RETRY_MAX_DELAY_MS: لضبط أقصى مهلة تراجع عند أخطاء الحمل الزائد (529).
• رفع حد وصف أدوات MCP وتعليمات الخادم من 2048 إلى 4096 حرفاً.
• مفتاح code في سياسات بوابة تطبيقات Claude: يطبّق إعدادات cli نفسها ويسري أيضاً في تبويب Code في تطبيق سطح المكتب.

لماذا تهمّ فكرة تثبيت النموذج؟

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

1. قابلية التوقع في الفاتورة. حين تعرف النموذج الذي يعمل عليه كل وكيل في الخط، يسهل تقدير تكلفة المهمة الواحدة.
2. تجانس الجودة. كل خطوات سير العمل تعمل بالقدرات نفسها، فيسهل تفسير الأخطاء وإعادة إنتاجها.
3. ضبط مركزي. تغيير النموذج في مكان واحد بدل تعديل تعريفات متفرقة.

المسألة لم تعد «هل النموذج جيد؟» بل «من يملك قرار اختياره، وأين يُكتب هذا القرار؟». حين يصبح الجواب سطراً واحداً في بيئة التشغيل، يصير قابلاً للمراجعة والتدقيق.

مقارنة سريعة

الأسلوب	ما يحدده	متى يناسب
نموذج لكل وكيل فرعي	الوكيل نفسه	مهام متنوعة تحتاج قدرات مختلفة
نموذج واحد لسير العمل	خط العمل كله	خطوط ثابتة تهمّها التكلفة والتجانس

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

الضغط التلقائي للوكلاء الفرعيين

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

ما الذي يتعلق بالأمان؟

شملت الإصلاحات نقاطاً تهمّ من يشغّل الوكلاء في بيئات مُدارة:

• إصلاح خطاف مُدار (Managed hook) كان يرفض استدعاءً دون أن ينهي الدور.
• فحوص أذونات Bash لم تعد توافق تلقائياً على بعض الأوامر التي تسند قيمة إلى BASH_ARGV0 ثم تستعملها؛ صارت تطلب موافقة صريحة.
• أداة Workflow لم تعد ترفض ملفات السكربت ذات نهايات الأسطر CRLF، وهو إصلاح يريح من يعمل على ويندوز.

هذه تفاصيل تبدو صغيرة، لكن الأمان في وكلاء البرمجة يتحقق غالباً من مثلها: ثغرة تخطي إذن في حالة حدّية نادرة.

كيف تستفيد منه عملياً؟

1. حدّد أي خطوط العمل ثابتة. إن كان لديك سير عمل متكرر، كمراجعة الطلبات أو توليد الاختبارات، ثبّت له نموذجاً واحداً يوازن بين الجودة والتكلفة.
2. ابدأ بنموذج أرخص ثم ارفع. قِس معدل نجاح المهام على النموذج الأرخص، ولا ترفع إلا إن كانت النتيجة غير مقبولة.
3. سجّل الإعداد في المستودع. وثّق المتغيّر وقيمته في ملف التشغيل أو دليل الفريق ليعرف الجميع لماذا اختير ذلك النموذج.
4. جرّب الضغط التلقائي على وكيل واحد أولاً وراقب هل يفقد معلومات مهمة قبل تعميمه.
5. راجع حدود MCP الجديدة. إن كانت أدواتك تحتاج وصفاً أطول، فالسقف الآن 4096 حرفاً، لكن الوصف الأقصر يوفّر سياقاً أكثر.

أخطاء شائعة عند تثبيت النموذج

التحكم المركزي مريح، لكنه قد يتحول إلى فخ إن طُبّق بلا قياس. هذه أكثر الأخطاء التي ينبغي تجنبها:

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

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

أسئلة شائعة

هل يغيّر المتغيّر الجديد نموذج الجلسة الرئيسية؟

لا. بحسب الوصف المنشور، يثبّت النموذج لوكلاء سير العمل فقط، أما بقية الوكلاء الفرعيين فتحتفظ بنماذجها.

هل يوفّر تثبيت نموذج أرخص المال فعلاً؟

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

أين أجد القائمة الكاملة للتغييرات؟

في صفحة الإصدار الرسمية على GitHub وفي سجل التغييرات في توثيق Claude Code، وتضم عشرات التغييرات غير ما ذُكر هنا.

الخلاصة

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

المصادر: ملاحظات الإصدار على GitHub، Claude Updates، Creators Toolbox، AI TLDR.