أطلقت شركة Anthropic نموذج Claude Haiku 5.5 في 7 أكتوبر، ولخّصت وظيفته في عبارة واحدة: "يتكامل بشكل رائع مع Opus 5.5 وSonnet 5.5 كوكيل فرعي في مهام البرمجة". ويحدد منشور الإطلاق سعره عند 0.10 دولار لكل مليون توكن إدخال و0.50 دولار لكل مليون توكن إخراج للمطالبات التي تصل إلى 100 ألف توكن، ويرتفع إلى 0.50 دولار و2.50 دولار لما يتجاوز ذلك. وتصف اثنتان من شهادات العملاء الست الواردة في الصفحة النمط نفسه: تشغّل Rogo وكيلاً فرعياً بنموذج Haiku 5.5 لاستخراج أرقام الإيرادات من تقرير 10-K المالي بينما يتولى نموذج أكبر إعداد العرض التقديمي، وتشغله Cognition كـ "مساعد" تحت إشراف Opus 5.5 في Devin Fusion.
يركز هذا التوصيف على النموذج نفسه. أما بالنسبة لفريق يدير عدة وكلاء، فالسؤال الأصعب يتعلق بلوحة إدارة المهام؛ فالوكيل الفرعي يعمل داخل جلسة تشغيل تابعة لوكيل آخر، وليس لديه مهمة (Task) خاصة به، ولا مسؤول محدد (Assignee)، ولا حالة مستقلة، ولذلك عندما يرتكب خطأً ما، يُنسب هذا الخطأ مباشرة إلى الوكيل الرئيسي. لقد أصبحت المهام منخفضة التكلفة رخيصة بما يكفي لإنجاز الكثير منها، والقرار الحقيقي الآن هو: أين ينبغي أن تكون نتائج هذه المهام مرئية؟
خلاصة القول
احتفظ بنموذج Haiku 5.5 كوكيل فرعي داخل الجلسة عندما يقتصر استهلاك مخرجاته ومراجعتها على الوكيل الرئيسي: كعمليات البحث، والتلخيص، والاستكشاف، وضغط السياق. وخصّص له وكيلاً مستقلاً ومهمة منفصلة عندما تُعتمد مخرجاته للتسليم النهائي، أو عندما يتعين على شخص مراجعتها وقبولها، أو عندما يكون عرضة للفشل بمفرده. في Claude Code، ثبّت model: claude-haiku-5-5 في ملف الوكيل الفرعي بدلاً من استخدام الاسم المستعار haiku، وتذكر أن الوكيل الفرعي المدمج Explore يعمل على نموذج المحادثة الرئيسية وليس على Haiku. وفي Sharkly، يتم تعيين الوكيل الاقتصادي عبر إعداد Custom arguments، مما يتيح لكلا المسارين مشاركة جهاز Computer واحد. تتولى الوكلاء مهام البحث والتنفيذ والاختبار وإعداد التقارير، بينما يتولى البشر تحديد الاتجاه ومنح الصلاحيات واعتماد النتائج.
الوكيل الفرعي غير مرئي من الأعلى
الوكيل الفرعي هو مساعد ينشئه الوكيل الرئيسي داخل جلسته الخاصة، ويسند إليه مهمة محددة، ثم يقرأ إجابته. هذا هو التصميم الأنسب للعديد من المهام، لكنه يشكل أيضاً حداً فاصلاً: فكل ما يفعله الوكيل الفرعي يتم داخل جلسة تشغيل واحدة.
أما من منظور لوحة إدارة المهام، يختلف هذان الخياران في إجابة كل سؤال قد يطرحه مدير المشروع.
| السؤال | Haiku 5.5 كوكيل فرعي داخل الجلسة | Haiku 5.5 كوكيل مستقل في مهمة خاصة |
|---|---|---|
| من المسؤول عن النتيجة؟ | الوكيل الرئيسي، ضمنياً | المسؤول عن المهمة، صراحةً |
| أين تظهر تفاصيل العمل؟ | داخل جلسة تشغيل الوكيل الرئيسي ورده النهائي | في المهمة الخاصة به، وحالة التشغيل، وسجل التنفيذ |
| من يراجع العمل؟ | النموذج الرئيسي، قبل متابعة عمله | شخص، أو مراجع، قبل قبول النتيجة |
| ماذا يحدث عند الفشل؟ | يتداركه الوكيل الرئيسي أو يمرره للمخرجات | تُظهر المهمة الفشل بشكل مستقل |
| هل يمكن لشخص الإجابة على استفساراته أثناء التشغيل؟ | لا، فهو يتواصل مع الوكيل الرئيسي فقط | نعم، يعود السؤال إلى المهمة وصندوق الوارد |
| ما هي تكلفة الإعداد؟ | مجرد ملف في المستودع البرمجي | إعداد وكيل ومهمة مستقلة |
لقد تطرقنا سابقاً في هذه المدونة إلى النسخة الخاصة بـ Codex من هذه المشكلة: بمجرد أن تتشعب الجلسة إلى وكلاء فرعيين متعددين، يصبح الرد الموحد هو الشيء الوحيد الذي يراه المراجع. ويجعل نموذج Haiku 5.5 هذه المقايضة أكثر إغراءً، لأن Anthropic صممته وسعّرته خصيصاً لهذا الدور. ينجح أسلوب Rogo لأن الوكيل الرئيسي يستهلك سطر الإيرادات ويدرجه ضمن عرض تقديمي، وهو منتج يراجعه شخص قبل اعتماده؛ وبالتالي، فإن أي خطأ يرتكبه الوكيل الفرعي سيظهر أثناء تلك المراجعة.
والآن، تخيّل نقل النموذج نفسه إلى مهمة تكون مخرجاتها هي المنتج النهائي نفسه: مثل ترحيل برمجي، أو تعديل إعدادات، أو تصحيح بيانات، أو الرد على عميل. إذا كان يعمل كوكيل فرعي، فلن يصل هذا العمل إلى لوحة المتابعة إلا كجزء من ملخص الوكيل الرئيسي؛ ولن يرى أحد أي جزء من التعديلات صدر عن هذا النموذج الاقتصادي، وبالتالي فإن الشخص الذي يعتمد المهمة يوافق على عمل لا يمكنه معرفة مصدره بدقة.
القاعدة مكتوبةً بوضوح
أجابت مقالات Luna عن مسألة تحديد الأعمال التي تنتمي إلى الفئة الاقتصادية: وجّه العمل بناءً على إمكانية التحقق منه، وليس على صعوبته. ويضيف Haiku 5.5 محوراً ثانياً: فبمجرد أن يصبح العمل منخفض التكلفة للغاية، حدد مكان تشغيله بناءً على الجهة التي تستهلك مخرجاته.
Haiku 5.5 placement rule
In-run subagent when ALL of these hold:
- the output is read by the lead agent, not shipped
- the lead checks or uses it before continuing
- a wrong answer shows up downstream, inside reviewed work
examples: file lookups, codebase exploration, log and doc summaries,
classification, pulling one fact from a long document
Own Agent and own Task when ANY of these hold:
- the output ships (a diff, a message, a record, a submitted form)
- a person has to accept it
- it can fail, stall, or need a human answer independently
- you want its acceptance rate measured separately from the lead's
استخدم وكيلاً فرعياً عندما يتقارب العمل نحو إجابة واحدة يحتاجها الوكيل الرئيسي. واستخدم مهمة منفصلة عندما يكون العمل من النوع الذي يرغب الفريق في إسناده إلى اسم مسؤول محدد.
هناك خيار وسيط في Sharkly؛ ففي ميزة فرق العمل Crew، يشير الوكيل القائد إلى الأعضاء لمساهمات محددة، ويعمل هؤلاء الأعضاء ضمن المهمة نفسها ويضيفون نتائجهم إلى المحادثة الخاصة بها. وبذلك، يكون العضو المعتمد على Haiku 5.5 مرئياً في المهمة دون الحاجة إلى إنشاء مهمة منفصلة له. استخدم هذا الخيار عندما يتولى شخص واحد مراجعة النتيجة المجمعة واعتمادها، وقسّم العمل إلى مهام منفصلة عندما يراجع أشخاص مختلفون أجزاءً مختلفة.
إعداد كلا المسارين
يتضمن كل مسار إعداداً واحداً يسهل الوقوع في الخطأ عند ضبطه.
مسار الوكيل الفرعي في Claude Code. يتطلب Claude Code الإصدار v2.1.293 أو أحدث لتشغيل Haiku 5.5. ويقبل حقل model الخاص بالوكيل الفرعي القيم sonnet، أو opus، أو haiku، أو fable، أو معرّف النموذج الكامل، أو inherit، وفقاً لـ توثيق الوكلاء الفرعيين. احرص على تثبيت المعرّف الكامل:
---
name: lookup
description: Find files, symbols and config values. Read-only.
model: claude-haiku-5-5
---
Answer with paths and line numbers. Do not edit files.
يكمن الفخ في الاسم المستعار؛ فوفقاً لـ توثيق إعداد النماذج، يشير الاسم المستعار haiku إلى Haiku 5.5 فقط على واجهة برمجة تطبيقات Anthropic API. أما على منصات Amazon Bedrock وGoogle Cloud وMicrosoft Foundry وClaude Platform on AWS، فإنه لا يزال يشير إلى Haiku 4.5. وبالتالي، فإن ملف وكيل فرعي تتم مشاركته عبر بيئات تشغيل على مزودين مختلفين قد يشغّل نموذجين مختلفين تحت الاسم نفسه. يحدد المتغير ANTHROPIC_DEFAULT_HAIKU_MODEL ما يعنيه haiku، وما يستخدمه Claude Code للوظائف التي تعمل في الخلفية على كل خادم استضافة.
المفاجأة الثانية هي أن الوكيل الفرعي المدمج Explore يستخدم نموذج المحادثة الرئيسية، وليس Haiku. فإذا كان الوكيل الرئيسي يعتمد على Opus 5.5، فسيتم الاستكشاف باستخدام Opus 5.5 أيضاً. ويقترح التوثيق نفسه إنشاء وكيل فرعي على مستوى المستخدم أو المشروع باسم Explore لتجاوز الوكيل المدمج، مع تعيين model: haiku لتشغيل الاستكشاف بنموذج أقل تكلفة. أطلق هذا الاسم على الملف المذكور أعلاه مع الاحتفاظ بالمعرّف الكامل.
مسار الوكيل المستقل في Sharkly. لا تختار Sharkly النماذج بنفسها؛ حيث ينص توثيق الوكلاء على ما يلي: "يتبع الوكيل النموذج الافتراضي لبيئة التشغيل. ولا يضمن أو يعرض اسم نموذج محدد. لتغيير النماذج، حدد أحدها في Custom arguments على مستوى الوكيل أو بيئة التشغيل". لا توجد قائمة منسدلة لاختيار النموذج ولا يوجد تحكم في عمق التفكير على مستوى الوكيل. ولذلك، يكون الوكيل الاقتصادي عبارة عن وكيل ثانٍ على جهاز الـ Computer نفسه وبيئة تشغيل Claude Code Runtime نفسها، مع تحديد claude-haiku-5-5 في وسائط Custom arguments الخاصة به، بينما يحتفظ الوكيل الرئيسي بإعداده الافتراضي. يوضح الدليل الإرشادي المخصص، تشغيل وكلاء Claude Haiku 5.5 في Sharkly، خطوات هذا الإعداد بالتفصيل.
ونظراً لأن المهمة لا تعرض اسم النموذج، أضف سطراً واحداً إلى تعليمات الوكيل الاقتصادي: اذكر اسم النموذج في الرد النهائي. في Claude Code، يتم ضبط جهد التفكير لنموذج Haiku 5.5 افتراضياً على medium ولا يمكن إيقاف التفكير، لذا فإن مستوى الجهد الذي تحدده هناك هو ما يحدد تكلفة كل تشغيل.
أين يظهر تأثير قفزة الـ 100 ألف توكن
يحدد قرار موضع التشغيل أيضاً السعر الذي ستدفعه؛ فتكلفة Haiku 5.5 هي 0.10 دولار / 0.50 دولار لكل مليون توكن فقط طالما ظلت المطالبة عند 100 ألف توكن أو أقل. وما يزيد عن ذلك، تقفز الأسعار إلى 0.50 دولار / 2.50 دولار، أي خمسة أضعاف. وتذكر Anthropic أن ما يقارب 90% من الطلبات الموجهة إلى Haiku 4.5 كانت تقع دون هذه العتبة.
ويمثل استدعاء الوكيل الفرعي النمط الذي يبقى دون هذا الحد: تكليف محدد، وقراءة سريعة، وإجابة واحدة في المقابل. أما الوكيل المستقل الذي يعمل على مهمة طويلة فهو النمط الذي يتجاوزه؛ حيث يقوم Claude Code بضغط سياق النماذج التي تدعم مليون توكن افتراضياً مثل Haiku 5.5 عند حوالي 967 ألف توكن، وهو ما يتجاوز بكثير حد الـ 100 ألف، ولذلك قد تقضي جلسة Haiku 5.5 الطويلة معظم جولاتها الأخيرة بالسعر الأعلى. والحل للمهمة الطويلة هو تقسيمها، وليس إعادتها لتعمل داخل جلسة الوكيل الرئيسي.
يمنح هذا التمييز بين الخيارين ميزة اقتصادية واضحة؛ فاستخدم الوكيل الفرعي داخل الجلسة للمهام القصيرة كثيفة القراءة التي يسهل فيها الحفاظ على السعر المنخفض، واستخدم وكيلاً مستقلاً للأعمال الجاهزة للتسليم النهائي، مع تحديد حجم تلك المهام بحيث تنتهي جلسة التشغيل قبل استنفاد سياقها.
أمران لم يتغيرا
كانت Anthropic واضحة وصريحة بشأن حدود إمكانيات النموذج؛ إذ يظل Sonnet 5.5 وOpus 5.5 "الخيارين الأفضل لمهام البرمجة المعقدة القائمة على الوكلاء". ويُظهر جدول الإطلاق أن Haiku 5.5 حقق 39.2% في اختبار Terminal-Bench 4.0 مقابل 70.6% لـ Sonnet 5.5، وكلاهما عند أقصى جهد تفكير. لذلك، فإن Haiku 5.5 هو منفّذ أو مساعد، وليس وكيلاً قائداً.
كما أن انخفاض تكلفة العامل لا يجعل قبول نتائجه أقل تكلفة؛ فسواء تم تشغيل Haiku 5.5 كوكيل فرعي أو كوكيل مستقل، لا بد أن يتحمل شخص ما مسؤولية النتيجة. يخفي مسار الوكيل الفرعي تلك المسؤولية داخل جلسة تشغيل الوكيل الرئيسي، بينما يحدد مسار الوكيل المستقل اسماً وحالة واضحة لها. وفي مهام المتصفح وسطح المكتب، حيث يمكن أن تنتهي الجلسة دون إكمال نصف العمل، قد يصبح هذا الفارق مكلفاً للغاية وبسرعة، وهو ما نناقشه في مقال وكلاء المتصفح الاقتصاديون وطابور المراجعة. أما المقارنة بين Haiku 5.5 وGPT-6 Luna بالسعر المعلن نفسه فهي مسألة أخرى تناولناها في مقال بيئتا تشغيل اقتصاديتان بالسعر نفسه.
دوّن قاعدة تحديد الموضع واعتمدها: خصّص الوكلاء الفرعيين لعمليات البحث التي يراجعها الوكيل الرئيسي، واجعل لأي عمل موجه للتسليم مهمة خاصة به. وإذا كنت تدير بالفعل عدة وكلاء، فإن Sharkly تمنحك منصة موحدة لإدارة مهامهم ونتائجهم.
