الخلاصة السريعة: توقّف عن البحث عن النموذج الأمثل الوحيد. طابق كل نموذج مع شكل المهمة التي أمامه: استدلال عميق للمعمارية وإعادات الهيكلة عبر الملفات، وسرعة ورخص للكود النمطي والاختبارات، وسياق طويل لأسئلة المستودع بالكامل، واتباع مستقر للأدوات في التعديلات متعددة الخطوات. اختيار النموذج يدويًا لكل طرفية يفي بالغرض مع وكيل أو اثنين. أما بمجرد تشغيل عدة مهام عبر مستودعات مختلفة، فمكان هذا التطابق هو وكيل محفوظ، لا رأسك. إليك الخريطة، ومثالًا عمليًا، وقائمة تحقق يمكنك تنفيذها اليوم.
لديك خمس نوافذ طرفية مفتوحة. واحدة تحمل إعادة هيكلة معقدة، وأخرى تحتاج دفعة من اختبارات الوحدة، وثالثة تجيب عن أسئلة حول قاعدة كود بالكاد تتذكرها، ورابعة تلاحق اختبار تكامل متذبذبًا، وخامسة تعيد تسمية رمز عبر أربعين ملفًا. كل واحدة منها تطرح السؤال الصامت نفسه: أي نموذج يدير هذا؟ وجّه نموذج استدلال ثقيلًا إلى إعادة التسمية وستحرق رموزًا ودقائق على عمل ينجزه أي نموذج سريع بإتقان. وجّه نموذجًا سريعًا إلى تغيير المعمارية وسيفوته اعتماد يبعد ثلاثة ملفات. الشكوى المتكررة نادرًا ما تكون «النماذج سيئة». بل «لا أعرف أيها أستخدم».
الحل ليس لوحة صدارة. فالترتيب يتغير كل بضعة أسابيع، والفائز في معيار عام غالبًا ما يكون الخيار الخاطئ لمهمتك تحديدًا. الخطوة المتينة هي مطابقة النموذج لشكل المهمة: مقدار الاستدلال الذي تحتاجه، وحجم السياق الذي يجب أن تحمله، ومدى موثوقية اتباعه للأدوات، ومقدار ما ستنفقه في كل تشغيل. هذه الخصائص تكاد لا تتغير حتى مع تغيّر أسماء النماذج.
هنا تستحق طبقة المهام مكانها. Sharkly منصة متكاملة لأوامر الوكلاء وإدارتهم. تجلس فوق وكلاء البرمجة لديك، فتصبح مسألة «أي نموذج لأي مهمة» قرارًا لا تعيد اتخاذه في كل طرفية. تحفظ القرار مرة واحدة على هيئة «وكيل»، وهو تهيئة قابلة لإعادة الاستخدام تتكون من دور وبيئة تشغيل وقواعده، ثم تسند المهمة إلى الوكيل الذي يناسب شكلها. أنت تملك وكلاء برمجة بالفعل، وSharkly يحوّلهم إلى فريق.
طابِق النموذج مع شكل المهمة، لا مع لوحة الصدارة
اختيار النموذج هو في حقيقته أربعة أسئلة، تُطرح بالترتيب.
- عمق الاستدلال. هل تحتاج المهمة إلى تخطيط متعدد الخطوات عبر الملفات، أم أنها تغيير محلي ميكانيكي؟ المعمارية وإعادات الهيكلة المعقدة وتصحيح الأخطاء من الجذر تكافئ نموذج استدلال أقوى. أما إعادة التسمية والتنسيق وتوليد الهياكل الأولية فلا.
- حجم السياق. هل يحتاج النموذج إلى استيعاب مستودع كامل، أو مواصفة طويلة، أو سجل ضخم دفعة واحدة؟ أسئلة قاعدة الكود بأكملها وعمليات الترحيل الكبيرة تكافئ نموذجًا بسياق طويل حتى لو كان استدلاله أضعف قليلًا.
- موثوقية اتباع الأدوات. العمل متعدد الخطوات (حرّر، شغّل الاختبارات، اقرأ المخرجات، حرّر مجددًا) يقف أو يسقط على مدى ثبات النموذج في استخدام الأدوات دون الخروج عن النص. النموذج الذي يستدل ببراعة لكنه ينسى تشغيل الاختبار أسوأ هنا من نموذج أكثر استقرارًا.
- السرعة والتكلفة. العمل الكثيف منخفض المخاطر (الاختبارات، الكود النمطي، سلاسل التوثيق) يجب أن يذهب إلى أسرع نموذج وأرخصه الذي يجتاز الحد المطلوب. واحتفظ بالاستدلال المكلف للمهام التي تتوقف عليه.
استخدم نموذج استدلال ثقيلًا عندما تكلفك الخطوة الخاطئة بعد ظهر كامل من تصحيح الأخطاء. واستخدم نموذجًا سريعًا رخيصًا عندما تكون المهمة ميكانيكية وسهلة التحقق. في معظم الأيام تحتاج كليهما، على مهام مختلفة، في الوقت نفسه. لهذا يبدو إعداد نموذج عام واحد خاطئًا: فهو يفرض إجابة واحدة على مهام تريد إجابات مختلفة.
خريطة تقريبية من نوع المهمة إلى دور النموذج
أسماء المهام أدناه تعمّر أطول من أي إصدار نموذج بعينه. اقرأ بطاقة النموذج الحالية لدى المزوّد قبل أن تربط فئة باسم معيّن، ثم احتفظ بالفئة.
| المهمة التي أمامك | حسّن من أجل | دور النموذج |
|---|---|---|
| المعمارية، إعادة هيكلة عبر الملفات، مراجعة التصميم | عمق الاستدلال | نموذج استدلال ثقيل |
| تصحيح الأخطاء من الجذر، مطاردة الاختبارات المتذبذبة | استدلال + أدوات مستقرة | نموذج استدلال ثقيل |
| أسئلة وأجوبة على المستودع كاملًا، ترحيل كبير، عمل بمواصفات طويلة | حجم السياق | نموذج بسياق طويل |
| اختبارات الوحدة، الكود النمطي، سلاسل التوثيق، الهياكل الأولية | السرعة والتكلفة | نموذج سريع ورخيص |
| إعادة تسمية ميكانيكية، تنسيق، تعديل جماعي | السرعة | نموذج سريع ورخيص |
| حلقة وكيل متعددة الخطوات (حرّر، اختبر، كرر) | موثوقية اتباع الأدوات | مستخدم أدوات مستقر |
ملاحظتان صادقتان. أولًا، «ثقيل» لا تعني «أفضل دائمًا». في إعادة التسمية، نموذج الاستدلال العميق أبطأ وأغلى وليس أصح من نموذج سريع. ثانيًا، بيئة تشغيل مثل Claude Code أو Codex أو Gemini CLI تحمل نموذجها الافتراضي الخاص، ويستمر استخدام النموذج عبر الاشتراكات أو مفاتيح API المهيأة في الأداة، لذا خياراتك الحقيقية هي النماذج التي يدفع فريقك مقابلها بالفعل، مطابقةً لهذه الفئات. ومعايير المهام العامة مثل SWE-bench تخبرك تقريبًا بأي فئة يقع النموذج، لا أي نموذج تحتاجه مهمتك بالتحديد.
حيث يتوقف اختيار النموذج لكل طرفية عن التوسّع
مع وكيل أو اثنين، الاختيار اليدوي كافٍ. تفتح طرفية، وتضبط النموذج، وتتذكر ما في كل واحدة لأنها اثنتان فقط. الإعداد الذي ينجح اليوم هو شخص وأداة أو أداتان.
تبدأ المشكلة عند الكم. شغّل ست مهام عبر ثلاثة مستودعات وسيصبح تطابق النموذج بالمهمة في رأسك: أي طرفية هي الرخيصة، وأي مستودع ضبطته على نموذج الاستدلال الثلاثاء الماضي، ولماذا يزحف الترحيل (لأنك تركته على النموذج السريع). وعندما يتولى زميل عملك، لا ينتقل هذا التطابق مع المهمة؛ بل يبقى في ذاكرتك، وتتناثر النتائج عبر طرفيات خاصة بدلًا من أن تعود إلى أي مكان مشترك.
الـوكيل تهيئة محفوظة لكيفية التعامل مع نوع من العمل: دور، وبيئة تشغيل ونموذجها، والقواعد المرافقة لها. فبدلًا من إعادة تقرير النموذج لكل طرفية، تبني الوكيل مرة واحدة («كاتب الاختبارات» على نموذج سريع، و«معيد الهيكلة» على نموذج استدلال) ثم تسند المهمة إلى الوكيل الذي يناسب شكلها. وهكذا يصبح اختيار النموذج قابلًا لإعادة الاستخدام، لا لعبة ذاكرة. الوكلاء يبحثون وينفذون ويختبرون ويقدّمون التقارير؛ أما البشر فيحددون الاتجاه ويقبلون النتيجة. يعود التنفيذ والعوائق والنتائج إلى المهمة، فيصبح منطق كل اختيار نموذج مرئيًا من الطلب إلى الإصدار، لا مدفونًا في سجل تمرير.
Sharkly ليس بديلًا عن Claude Code أو Codex أو أدوات التنفيذ الأخرى. إنه يضيف طبقة المهام والسياق والمراجعة المشتركة حول النماذج التي يشغلها فريقك بالفعل. إذا كنت لا تشغّل سوى وكيل واحد في طرفية واحدة، فلست بحاجة إليه. وبمجرد أن تبدأ بتشغيل عدة وكلاء على التوازي، يصبح قرار مطابقة النموذج بالضبط هو الشيء الذي يستحق الحفظ.
مثال عملي: ثلاث مهام، ثلاثة وكلاء
لنفترض أن سبرنتًا يضع ثلاث مهام في قائمة الانتظار.
- SH-312: إعادة تسمية
UserSessionإلىAuthSessionفي كل المستودع. ميكانيكية وسهلة التحقق. وجّهها إلى وكيل «معيد تسمية» على نموذج سريع رخيص. يعدّل، ويشغّل مدقّق الأنواع، ويعيد فرقًا نظيفًا. وإنفاق رموز نموذج الاستدلال هنا لا يجلب شيئًا. - SH-318: مسار الدفع يخصم مرتين عند إعادة المحاولة. تصحيح أخطاء من الجذر عبر الخدمات. وجّهها إلى وكيل «مصحّح أخطاء» على نموذج استدلال ثقيل باستخدام أدوات مستقر. يحتاج إلى التخطيط، وقراءة السجلات، وتكوين فرضية واختبارها. أما النموذج السريع هنا فيخمّن ويهدر دورة مراجعة.
- SH-324: أجب عن سؤال «كيف تتطابق فواتيرنا مع Stripe؟» انطلاقًا من قاعدة الكود. سؤال على المستودع كاملًا. وجّهه إلى وكيل «محلّل قاعدة الكود» على نموذج بسياق طويل يستطيع استيعاب الملفات ذات الصلة دفعة واحدة.
يعمل كل وكيل في شجرة عمل معزولة خاصة به، فيشتغل ثلاثة نماذج على ثلاث مهام في وقت واحد دون أن يتداخل بعضها مع بعض. وتعود كل نتيجة إلى مهمتها مع ملخص التغيير والأدلة. وهكذا تراجع ثلاث تسليمات منتهية، لا ثلاث طرفيات عليك إعادة تركيبها من الذاكرة. وتتوقف الأتمتة حيث يلزم حكمك: تقبل، أو تطلب تغييرات، أو تقرر الدمج.
قائمة التحقق التي يمكنك تنفيذها اليوم
نفّذ هذا قبل دفعتك التالية من عمل الوكلاء.
- [ ] لكل مهمة، حدّد شكلها أولًا: ثقيلة الاستدلال، أم ثقيلة السياق، أم ثقيلة حلقة الأدوات، أم ميكانيكية عالية الحجم.
- [ ] أسند أرخص نموذج يجتاز الحد المطلوب لهذا الشكل. واحتفظ بنموذج الاستدلال للمهام التي تكلفك فيها الخطوة الخاطئة وقتًا حقيقيًا.
- [ ] ضع العمل طويل السياق على نموذج بسياق طويل، لا على نموذج الاستدلال المفضل لديك بحكم العادة.
- [ ] في الحلقات متعددة الخطوات، رجّح موثوقية اتباع الأدوات على ترتيب المعيار الخام.
- [ ] دوّن التطابق مرة واحدة على هيئة وكيل قابل لإعادة الاستخدام لكل دور، حتى تتوقف أنت ورفاقك عن إعادة تقريره لكل طرفية.
- [ ] أبقِ شخصًا للقبول النهائي. النموذج يختار المسار، وأنت تعتمد النتيجة.
طابِق النموذج مع المهمة، واحفظ التطابق كـوكيل، ولن يُجاب عن السؤال الذي بدأ كل هذا («أيها أستخدم؟») إلا مرة واحدة لكل دور بدلًا من مرة لكل طرفية.
إذا أردت الاستمرار في استخدام عدة وكلاء برمجة بدلًا من الالتزام بنموذج واحد لكل شيء، فهذه هي المشكلة التي بُني Sharkly حولها. يمكنك اختيار النموذج يدويًا في كل طرفية، أو إدارة سير العمل كاملًا في مكان واحد وترك كل نتيجة تعود إلى المهمة.
الأسئلة الشائعة
هل أستخدم النموذج الأعلى ترتيبًا في كل شيء؟ لا. فأفضل نموذج عام أبطأ وأغلى مما ينبغي في العمل الميكانيكي، وليس أصح فيه. الترتيب يخبرك بأي فئة يقع النموذج؛ وشكل مهمتك يخبرك بأي فئة تحتاج. ومطابقة الاثنين أفضل من الافتراضي بالفائز في لوحة الصدارة.
كيف أختار نموذجًا عندما لا أعرف صعوبة المهمة بعد؟ ابدأ رخيصًا ثم اصعد. أعطِ المهمة لنموذج سريع أولًا. وإذا تعثر أو خمّن أو فشل في المراجعة، فهذه إشارتك إلى أن المهمة ثقيلة الاستدلال، فترقّيها إلى نموذج أقوى. وخطوة المراجعة بمشاركة الإنسان هي حيث تلتقط عدم التطابق قبل أن يُطلق.
هل يختار Sharkly النموذج نيابة عني؟ لا، Sharkly لا يختار النموذج من تلقاء نفسه. أنت تربط دورًا ببيئة تشغيل ونموذجها عندما تبني وكيلًا، ثم تسند المهام إلى الوكيل الذي يناسب شكل العمل. يبقى الاختيار لك؛ وSharkly يجعله قابلًا لإعادة الاستخدام ويبقي نتيجة كل تشغيل على المهمة بدلًا من طرفية خاصة.
