Tool ولا Skill ولا Sub-agent؟ كيف تفكك وكيل AI تضخم System Prompt الخاص به
📍 فهرس المحتويات
- ١. مشكلة الوكيل المتضخم — قصة Stock Pilot
- ٢. ما الفرق بين Tool و Skill و Sub-agent؟
- ٣. البدائيات البشرية — المفاتيح الخفية لبناء وكيل ناجح
- ٤. استبدال System Prompt الطويل بـ Skills
- ٥. متى تستخدم MCP؟ (ومتى لا تستخدمه)
- ٦. Hill Climbing — كيف تحسّن وكيلك تدريجياً
- ٧. النتائج: من ٦٢٪ إلى ٩٢٪
- ٨. دروس مستفادة ونصائح عملية
تخيل أنك بنيت وكيل ذكاء اصطناعي (AI Agent) — برنامج يستطيع تنفيذ مهام معقدة نيابة عنك — يعمل بشكل رائع. زبائنك سعداء، فريقك فخور، وكل شيء على ما يرام. لكن بعد أسابيع قليلة، يطلب منك أحد الزبائن إضافة ميزة جديدة. فتضيفها. ثم ميزة أخرى، فتضيفها. ومع كل إضافة، تزداد التعليمات التي تعطيها للوكيل (System Prompt).
قبل أن تدرك ذلك، أصبح System Prompt الخاص بك مئات الأسطر، وأصبح لديك 12 أداة (Tools) و 3 وكلاء فرعيين (Sub-agents). وفجأة، الوكيل الذي كان يعمل بكفاءة بدأ يتراجع — أخطاء جديدة ظهرت، أداء أبطأ، ونتائج غير متوقعة. هل هذا يبدو مألوفاً؟
هذا بالضبط هو السيناريو الذي تناولته محاضرة Will من فريق Applied AI في Anthropic ضمن فعالية “Code with Claude London 2026”. في هذه المحاضرة، استخدم Will مثالاً عملياً لوكيل إدارة مخزون اسمه Stock Pilot، وشرح بالتفصيل كيف تفكيك وكيل متضخم واستعادة أدائه باستخدام ثلاثة مبادئ أساسية: Tools (الأدوات)، Skills (المهارات)، و Sub-agents (الوكلاء الفرعيون).
١. مشكلة الوكيل المتضخم — قصة Stock Pilot
قبل أن نتعمق في الحلول، دعنا نفهم المشكلة. Stock Pilot هو وكيل مخصص لإدارة المخزون في شركة تجزئة متوسطة الحجم. يقوم بعدة مهام:
- 🔴 التنبيه عند انخفاض المخزون (Low Stock Alerts)
- 📊 التنبؤ بالطلب (Demand Forecasting) — توقع الكمية المطلوبة في المستقبل
- 🏭 اختيار الموردين (Supplier Selection)
- 📝 إعداد أوامر الشراء (Purchase Orders / POs)
- 📋 كتابة تقارير أسبوعية للموظفين
كل مهمة بمفردها ليست معقدة. لكن المشكلة أن الفريق أضاف قدرات جديدة فوق بعضها بمرور الوقت دون إعادة تصميم البنية التحتية للوكيل. النتيجة؟ أصبح الوكيل بهذا الشكل:
• System Prompt: 400 سطر من التعليمات — مزيج من سياسات التخزين، إجراءات الطلب، شروط الترويج، وغيرها.
• عدد الأدوات: 12 أداة مختلفة — أدوات لسحب البيانات، أدوات للتحليل، أدوات لإعداد التقارير.
• وكلاء فرعيون: 3 وكلاء — لكل نافذة سياق (Context Window) مستقلة تماماً.
• نتائج التقييم (Evals): ٦٢٪ نجاح فقط (انخفضت من ٨٣٪).

عند تشغيل الاختبارات (Evals)، ظهرت ثلاثة أعطال واضحة:
- F1 — مسح المخزون المنخفض اليومي: الوكيل يصل للحل الصحيح لكن بطريق طويلة غير فعّالة.
- F2 — عملية الطلب تحت باقة ترويجية: الوكيل الفرعي يؤدي المهمة صح، لكن هناك انهيار في التواصل بين الوكيل الفرعي والوكيل الرئيسي (Orchestrator).
- R8 — التنبؤ خلال شهر ترويجي: سياسات متناقضة في System Prompt تجعل الوكيل يستخدم مُعامِل ترويج خاطئ (1.35 بدلاً من 3.1).

٢. ما الفرق بين Tool و Skill و Sub-agent؟
هذا هو السؤال المحوري في المحاضرة. متى تستخدم كل واحدة من هذه “البدائيات الوكيلية” (Agentic Primitives)؟

🔧 Tools — الأدوات
Tool (أداة) هي وظيفة قابلة للتنفيذ يستطيع الوكيل استدعاءها لإنجاز مهمة محددة. مثل: تنفيذ كود، البحث في الملفات، تصفح الإنترنت.
متى تستخدمها؟ عندما يحتاج الوكيل لـ تنفيذ فعل — سحب بيانات، تشغيل برنامج، كتابة ملف. ابدأ دائماً بالأدوات الأساسية الشبيهة بالبشر (Human-like Primitives) مثل تنفيذ الأكواد، نظام الملفات، والبحث في الويب، وأضف أدوات مخصصة فقط عند الحاجة.
🧠 Skills — المهارات
Skill (مهارة) هي معلومات مغلّفة وقابلة للتركيب يمكن لـ Claude سحبها إلى سياقه (Context) عندما يدرك أنه بحاجة لها لإتمام مهمة معينة. هي مثل “ذاكرة احتياطية” يستخدمها الوكيل عند الحاجة فقط.
متى تستخدمها؟ عندما يكون لديك معلومات يحتاجها الوكيل بعض الوقت، ليس كل الوقت. مثل إجراءات التخزين، سياسات الشركة، معايير الجودة. بدلاً من حشو System Prompt بهذه المعلومات، ضعها في Skills.
🤖 Sub-agents — الوكلاء الفرعيون
Sub-agent (وكيل فرعي) هو وكيل مستقل تماماً بنافذة سياق خاصة به، وأدواته الخاصة، وتعليماته الخاصة. يعمل بشكل منفصل عن الوكيل الرئيسي.
متى تستخدمه؟ فقط عندما تحتاج فصل حقيقي للاهتمامات — مثلاً، مهمة معقدة تحتاج مواردها الخاصة. احذر! التواصل بين الوكيل الرئيسي والوكيل الفرعي هو أكثر نقاط الفشل شيوعاً، كما رأينا في فشل eval F2.
أولاً: استخدم Tool — البدائيات الأساسية (Code Execution، File System، Web Search).
ثانياً: إذا احتجت معلومات مشروطة → استخدم Skill بدلاً من حشو System Prompt.
ثالثاً: فقط إذا كان لديك سبب قوي للعزل → استخدم Sub-agent.
القاعدة الذهبية: لا تتجه للـ Sub-agent أبداً كأول حل.
٣. البدائيات البشرية — المفاتيح الخفية لبناء وكيل ناجح
أحد أهم المفاهيم في المحاضرة هو البدائيات البشرية (Human-like Primitives). الفكرة بسيطة: الوكيل الذكي يجب أن يمتلك نفس الأدوات التي يمتلكها الإنسان عندما يجلس أمام الكمبيوتر.
عندما تأتي إلى العمل، ماذا لديك؟
- 💻 كمبيوتر مع نظام ملفات — تستطيع فتح الملفات وحفظها
- 🌐 متصفح — تستطيع البحث في الإنترنت
- ⌨️ كتابة وتنفيذ كود — إذا كنت مبرمجاً
- 📋 قائمة مهام (To-Do List)

لماذا هذا مهم؟ لأن هذه البدائيات تسمح للوكيل بأن يكون مرناً. إذا أردت تحليل ملف CSV ضخم، لا تحمّل الملف كاملاً في Context Window — أعط الوكيل أداة Code Execution ليكتب سكريبت Python ويحلّل البيانات برمجياً. هذا يستهلك أقل بكثير من الـ Tokens.

٤. استبدال System Prompt الطويل بـ Skills
الخطوة الأولى في إعادة تصميم Stock Pilot كانت تفريغ System Prompt من 400 سطر إلى 50 سطراً فقط، ونقل المعلومات إلى Skills.
الفرق بين System Prompt و Skill:
- System Prompt: موجود في “عقل” الوكيل طول الوقت — يستهلك Tokens حتى لو لم تكن المهمة بحاجته.
- Skill: مثل رف مكتبة — الوكيل يذهب إليه فقط عندما يحتاج المعلومة. لا يستهلك Tokens بدون داعي.
لكي تستخدم Progressive Disclosure (الإفصاح التدريجي) عبر Skills: ضع في System Prompt فقط المعلومات التي يحتاجها الوكيل بغض النظر عن المهمة. أما المعلومات المشروطة — سياسات التخزين، إجراءات الطلب — فاجعلها Skills يستدعيها الوكيل عند الحاجة.

طلب Will من Claude Code عبر Claude Managed Agents أن ينظر إلى ملف agent.py ويسأل: “هل يمكنني استخدام Skills بدلاً من System Prompt الطويل؟”. قام Claude بتحليل الـ System Prompt، استخرج السياسات والإجراءات، وحوّلها إلى Skills منفصلة. ثم اختصر الـ System Prompt إلى 50 سطراً فقط.

٥. متى تستخدم MCP؟ (ومتى لا تستخدمه)
MCP (Model Context Protocol) هو بروتوكول يسمح للوكيل بالاتصال بخوادم أدوات خارجية. لكن Will يحذر من التوجه إلى MCP كأول حل:
«نرى الكثير من المطورين يتجهون إلى MCP أولاً، وينتهي بهم الأمر في نظام بيئي فوضوي مليء بخوادم MCP متداخلة ومتكررة.»
التدرج الموصى به عند بناء الأدوات:
- ✅ البدائيات الأساسية لـ Claude Code (Code Execution، File System، Web Search)
- ✅ Tools محلية مخصصة للوكيل فقط (Local Tools)
- ✅ فقط عند الحاجة: MCP — عندما يكون لديك مجموعة أدوات مشتركة بين عدة وكلاء أو عملاء

أيضاً، Code Execution يمكن أن يكون بديلاً عملياً لـ MCP في كثير من الحالات — بدلاً من توصيل وكيلك بـ MCP Server، أعطه القدرة على استخدام APIs عبر كتابة كود مباشرة. هذا يقلل من استهلاك Context ويزيد المرونة.
٦. Hill Climbing — كيف تحسّن وكيلك تدريجياً
Hill Climbing (تسلق التل) هي منهجية تستخدمها Anthropic داخلياً لتحسين الوكلاء. الفكرة:
- 🏔️ شغّل التقييمات (Evals) للحصول على خط أساس (Baseline)
- 🔧 حسّن التصميم — استخدم أدوات أنسب، Skills، إلخ.
- 📊 أعد تشغيل التقييمات لترى إن تحسّن الأداء
- 🔄 كرّر — كل دورة تمثل “تسلقاً” نحو قمة الأداء المطلوب

٧. النتائج: من ٦٢٪ إلى ٩٢٪
بعد تطبيق التحسينات الثلاث — Skills بدلاً من System Prompt الطويل، البدائيات البشرية بدلاً من الأدوات المتخصصة، وإعادة تصميم الوكلاء الفرعيين — كانت النتائج مذهلة:

• استهلاك Tokens: من 200,000+ Token → انخفاض كبير (بسبب استخدام Code Execution بدلاً من تحميل البيانات كاملة)
• التكلفة: انخفضت تبعاً لانخفاض الـ Tokens
• وقت التنفيذ: أقل بكثير
• نتائج التقييم (Evals): من 62% إلى 92%!
• System Prompt: من 400 سطر إلى 15 سطراً فقط
السر الأكبر؟ Code Execution. بدلاً من تحميل ملفات CSV كاملة في Context Window (مكلفة جداً من الـ Tokens)، أعطى Will للوكيل القدرة على كتابة وتنفيذ كود Python لتحليل البيانات. النتيجة: الوكيل يستهلك Tokens أقل بكثير، يعمل أسرع، ونتائجه أفضل.

٨. دروس مستفادة ونصائح عملية
- ابدأ بسيطاً: ابدأ بالبدائيات البشرية (Code Execution، File System، Web Search) — نفس الأدوات التي يمتلكها الإنسان أمام الكمبيوتر.
- لا تحشو System Prompt: 15-50 سطراً كافية. استخدم Skills للمعلومات المشروطة.
- Skills ≠ أدوات: Skills معلومات، Tools تنفيذ. لا تخلط بينهما.
- Sub-agents للعزل الحقيقي فقط: التواصل بين الوكيل الرئيسي والفرعي هو أكثر نقطة فشل شيوعاً.
- لا تتجه لـ MCP أولاً: ابدأ بالأدوات المدمجة، ثم المحلية، ثم MCP عند الحاجة فقط.
- اكتب Evals دائماً: بدون تقييم، لا يمكنك قياس التحسن. استخدم Hill Climbing لتحسين الوكيل تدريجياً.
- Code Execution هو السلاح السري: بدلاً من إغراق الوكيل بالبيانات، أعطه القدرة على معالجتها برمجياً.

🔗 روابط ذات صلة
📚 المصادر والمراجع
- 📺 المحاضرة الأصلية: Tool, skill, or subagent? — Code with Claude London 2026
- 📄 وثائق Anthropic الرسمية — بناء الوكلاء
- 🛠️ Claude Code على GitHub — راجع البدائيات المدمجة
- 📋 فعالية Code with Claude London 2026
💎 الخاتمة
بناء وكيل ذكاء اصطناعي لا يعني تعقيد الأمور. بالعكس — أفضل الوكلاء هم الأبسط. ابدأ بالأدوات البشرية الأساسية (Code Execution، File System، Web Search)، استخدم Skills لتنظيم المعلومات بدلاً من System Prompt الضخم، ولا تلجأ للوكلاء الفرعيين أو MCP إلا عند الضرورة القصوى. والأهم من كل ذلك — اختبر كل تغيير تجريه باستخدام Evals منهجية، وتسلق نحو التحسن خطوة بخطوة.
إذا كان وكيلك بدأ يظهر تراجعاً في الأداء، فكر في تطبيق Progressive Disclosure (الإفصاح التدريجي) — الوكيل الذكي لا يحتاج أن يحمل كل شيء في عقله. يحتاج فقط أن يعرف أين يجد المعلومات عندما يحتاجها.
❓ الأسئلة الشائعة
ما الفرق بين Tool و Skill في Claude Managed Agents؟
Tool هي وظيفة قابلة للتنفيذ — الوكيل يستدعيها لفعل شيء (تشغيل كود، البحث في ملف). Skill هي معلومات مغلّفة — الوكيل يسحبها إلى Context عندما يحتاج معرفة إجراء أو سياسة معينة. باختصار: Tools تفعل، Skills تعرف.
متى يكون استخدام Sub-agent ضرورياً؟
عندما تحتاج عزلاً حقيقياً للسياق — مثلاً وكيل يعمل على بيانات حساسة يجب ألا يطلع عليها الوكيل الرئيسي. لكن احذر: التواصل بين الوكيل الرئيسي والفرعي هو أكبر مصدر للأخطاء في الأنظمة المعقدة.
هل MCP أفضل من Code Execution لتوصيل الأدوات؟
ليس بالضرورة. Code Execution غالباً ما يكون أبسط وأقل استهلاكاً للـ Context. استخدم MCP فقط عندما يكون لديك مجموعة أدوات مشتركة بين عدة وكلاء أو عملاء مختلفين.
كيف أبدأ بتقييم وكيلي (Evals)؟
ابدأ بـ 12-15 مهمة تقييم تغطي المهام الأساسية التي تتوقع من وكيلك أداءها. استخدم مزيجاً من التقييم الحتمي (Deterministic) — مثل عدد الـ Tokens المستخدمة ووقت التنفيذ — و غير الحتمي (Non-deterministic) — مثل جودة المخرجات باستخدام LLM كحَكَم.
كم يجب أن يكون طول System Prompt المثالي؟
وفقاً لهذه المحاضرة، 15-50 سطراً هو النطاق المثالي. System Prompt يجب أن يحتوي فقط على المعلومات التي يحتاجها الوكيل بغض النظر عن المهمة. كل شيء آخر → Skills.
— نُشر على lira-now.com في 9 يونيو 2026 —

اترك تعليقاً