أي وكيل برمجة يجب أن يتولى هذه المهمة؟

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

لديك Claude Code في نافذة طرفية، وCodex في أخرى، وربما Gemini CLI في ثالثة. ثم تصل مهمة: إصلاح اختبار متقلّب، أو إضافة نقطة نهاية، أو إعادة هيكلة وحدة تستوردها ثلاثة ملفات أخرى. أي وكيل يتولاها؟ يجيب معظمنا بحكم العادة، أو حسب النافذة النشطة أصلًا. وهذا ينجح إلى أن تعجز عن تذكّر أي وكيل أسندت إليه الترحيل، أو يحرّر اثنان منهما الملف نفسه.

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

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

التوجيه قرار، لا تفضيل

لنبدأ بتعريف واضح. التوجيه هو مطابقة مهمة بالوكيل الذي ينبغي أن ينفذها. وهو ليس اختيار الوكيل المفضّل لديك، ولا اختيار نموذج. أي نموذج لأي مهمة برمجية سؤال منفصل وأضيق يقع في طبقة أدنى؛ نحن هنا نقرر أي وكيل (Claude Code أو Codex أو Gemini CLI أو OpenCode وغيرها) يتلقى العمل.

تحمل المهمة خصائص تحدد مسارها قبل أن تدخل القدرة في الصورة:

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

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

وجّه حسب شكل المهمة، قبل أن توجّه حسب القدرة

تختلف وكلاء البرمجة فعليًا. قد يتقن أحدها تخطيط المهام الطويلة متعددة الخطوات؛ وقد يكون آخر أدق في التعديلات الجراحية أو أسرع في الحلقات القصيرة. لكن الحقيقة المجردة هي: أنها تختلف على قاعدة شفرتك أنت، والسبيل الوحيد للمعرفة هو مراقبتها وهي تعمل عليها. تقيس المعايير المرجعية مجموعة مسائل ثابتة في لحظة ثابتة، وهي ليست مستودعك ولا الشهر القادم. قارن الوكلاء على قاعدة شفرتك أنت قبل أن تثق بأي تصنيف.

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

لا شيء من ذلك يسمّي فائزًا، لأنه لا يوجد فائز. هناك توافق بين مهمة وسلوك ملاحَظ لوكيل، وهذا التوافق هو ما توجّه بناءً عليه.

القيود التي تحسم التوجيه قبل أن تحسمه القدرة

ثمّة قيدان يتغلبان على القدرة في كل مرة، وكلاهما يتعلق بالتنسيق لا بالمهارة.

الأول هو تداخل الملفات. خمسة وكلاء يحررون مستودعًا واحدًا يبدو أمرًا فعّالًا، إلى أن يلمس اثنان الملفات نفسها وتجد نفسك تحل تعارض دمج أنشأته عن قصد. الحل هو العزل: امنح كل مهمة نسختها المستخرجة الخاصة حتى لا يتصادم الوكلاء. worktrees وكلاء البرمجة، نسخة مستخرجة لكل مهمة يشرح الآلية، ويغطي تشغيل عدة وكلاء في مستودع واحد ما ينهار دونها. وعندما تلمس مهمتان الملفات نفسها، فالمسار ليس «الوكيل الأفضل»، بل «أي وكيل، داخل worktree منفصل».

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

حيث يتوقف التوجيه في رأسك عن التوسّع

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

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

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

لا تحتاج إلى أي من هذا لتشغيل وكيل واحد ببراعة. ويمكنك أيضًا تشغيل Claude Code وCodex معًا على قاعدة شفرة واحدة يدويًا، وهذا معقول لوكيلين. وتتغيّر المعادلة عندما تتجاوز قرارات التوجيه ما تستطيع حمله في رأسك: وكلاء متعددون، ومهام متعددة، ومستودعات متعددة، وفريق يحتاج أن يرى اللوح نفسه.

قائمة تحقق للتوجيه يمكنك تطبيقها اليوم

قبل أن تسند مهمة إلى وكيل، مرّرها على هذه البنود:

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

وجّه حسب المهمة، لا حسب التصنيف. أفضل وكيل لمهمة هو الذي يتلاءم شكله مع العمل الماثل أمامك، ولا يبقى قرار التوجيه زهيد الكلفة إلا إذا عاش في مكان تراه.

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

الأسئلة الشائعة

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

كيف يختلف هذا عن اختيار نموذج؟ اختيار النموذج يحدث في طبقة أدنى، داخل الوكيل. التوجيه يحدد أي وكيل يتلقى المهمة؛ أما سؤال النموذج فيحدد ما يعمل داخل جلسة ذلك الوكيل. راجع أي نموذج لأي مهمة برمجية للقرار الأضيق.

متى أحتاج فعليًا إلى أداة لهذا؟ عندما تتجاوز قرارات التوجيه ما تستطيع تتبعه في رأسك، وهو ما يحدث عادةً عند نحو ثلاثة وكلاء وعدة مهام مفتوحة، أو عندما يحتاج فريق إلى رؤية القرارات نفسها. أما مع وكيل أو اثنين، فيكفي جدول ذهني ونوافذ طرفية منفصلة.

هل يستبدل Sharkly Claude Code أو Codex؟ لا. Sharkly ليس بديلًا عن Claude Code أو Codex أو أدوات التنفيذ الأخرى. إنه يضيف طبقة المهام المشتركة والحاسوب والسياق والمراجعة حول وكلاء البرمجة الذين يستخدمهم فريقك بالفعل.