Tool ولا Skill ولا Sub-agent؟ كيف تفكك وكيل AI تضخم System Prompt الخاص به

⏱️ مدة القراءة: 2 دقيقة

ستجد في هذا المقال شرحًا مباشرًا وخطوات عملية مختصرة تساعدك على التطبيق بسرعة.






Tool ولا Skill ولا Sub-agent؟ كيف تفكك وكيل AI تضخم System Prompt الخاص به

📅 9 يونيو 2026 • 📂 وكلاء ذكاء اصطناعي Claude Anthropic Agent Architecture

تخيل أنك بنيت وكيل ذكاء اصطناعي (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)
  • 📋 كتابة تقارير أسبوعية للموظفين

كل مهمة بمفردها ليست معقدة. لكن المشكلة أن الفريق أضاف قدرات جديدة فوق بعضها بمرور الوقت دون إعادة تصميم البنية التحتية للوكيل. النتيجة؟ أصبح الوكيل بهذا الشكل:

📋 بنية Stock Pilot قبل إعادة التصميم:
System Prompt: 400 سطر من التعليمات — مزيج من سياسات التخزين، إجراءات الطلب، شروط الترويج، وغيرها.
عدد الأدوات: 12 أداة مختلفة — أدوات لسحب البيانات، أدوات للتحليل، أدوات لإعداد التقارير.
وكلاء فرعيون: 3 وكلاء — لكل نافذة سياق (Context Window) مستقلة تماماً.
نتائج التقييم (Evals): ٦٢٪ نجاح فقط (انخفضت من ٨٣٪).
رسم بياني لبنية Stock Pilot قبل إعادة التصميم — وكلاء متعددون حول Orchestrator
بنية Stock Pilot قبل إعادة التصميم: Orchestrator واحد مع 3 Sub-agents و 12 Tool
💡 تشبيه: تخيل أنك مدير مطعم. بدأت بقائمة طعام صغيرة من ١٠ أصناف. ثم أضفت ٥٠ صنفاً جديداً دون إعادة تنظيم المطبخ. الطهاة أصبحوا مرتبكين، يقرؤون التعليمات الخاطئة، ويجهزون الطلبات بطريقة غير فعّالة. هذا ما حدث مع Stock Pilot — الوكيل لديه الكثير من “التعليمات المتضاربة” في System Prompt الخاص به.

عند تشغيل الاختبارات (Evals)، ظهرت ثلاثة أعطال واضحة:

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

٢. ما الفرق بين Tool و Skill و Sub-agent؟

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

مخطط يوضح الفرق بين Tool و Skill و Sub-agent
الأدوات (Tools) والمهارات (Skills) والوكلاء الفرعيون — البدائيات الوكيلية الثلاث

🔧 Tools — الأدوات

Tool (أداة) هي وظيفة قابلة للتنفيذ يستطيع الوكيل استدعاءها لإنجاز مهمة محددة. مثل: تنفيذ كود، البحث في الملفات، تصفح الإنترنت.

متى تستخدمها؟ عندما يحتاج الوكيل لـ تنفيذ فعل — سحب بيانات، تشغيل برنامج، كتابة ملف. ابدأ دائماً بالأدوات الأساسية الشبيهة بالبشر (Human-like Primitives) مثل تنفيذ الأكواد، نظام الملفات، والبحث في الويب، وأضف أدوات مخصصة فقط عند الحاجة.

🧠 Skills — المهارات

Skill (مهارة) هي معلومات مغلّفة وقابلة للتركيب يمكن لـ Claude سحبها إلى سياقه (Context) عندما يدرك أنه بحاجة لها لإتمام مهمة معينة. هي مثل “ذاكرة احتياطية” يستخدمها الوكيل عند الحاجة فقط.

متى تستخدمها؟ عندما يكون لديك معلومات يحتاجها الوكيل بعض الوقت، ليس كل الوقت. مثل إجراءات التخزين، سياسات الشركة، معايير الجودة. بدلاً من حشو System Prompt بهذه المعلومات، ضعها في Skills.

🤖 Sub-agents — الوكلاء الفرعيون

Sub-agent (وكيل فرعي) هو وكيل مستقل تماماً بنافذة سياق خاصة به، وأدواته الخاصة، وتعليماته الخاصة. يعمل بشكل منفصل عن الوكيل الرئيسي.

متى تستخدمه؟ فقط عندما تحتاج فصل حقيقي للاهتمامات — مثلاً، مهمة معقدة تحتاج مواردها الخاصة. احذر! التواصل بين الوكيل الرئيسي والوكيل الفرعي هو أكثر نقاط الفشل شيوعاً، كما رأينا في فشل eval F2.

💡 التدرج في التعقيد — ابدأ من Tool:
أولاً: استخدم Tool — البدائيات الأساسية (Code Execution، File System، Web Search).
ثانياً: إذا احتجت معلومات مشروطة → استخدم Skill بدلاً من حشو System Prompt.
ثالثاً: فقط إذا كان لديك سبب قوي للعزل → استخدم Sub-agent.
القاعدة الذهبية: لا تتجه للـ Sub-agent أبداً كأول حل.

٣. البدائيات البشرية — المفاتيح الخفية لبناء وكيل ناجح

أحد أهم المفاهيم في المحاضرة هو البدائيات البشرية (Human-like Primitives). الفكرة بسيطة: الوكيل الذكي يجب أن يمتلك نفس الأدوات التي يمتلكها الإنسان عندما يجلس أمام الكمبيوتر.

عندما تأتي إلى العمل، ماذا لديك؟

  • 💻 كمبيوتر مع نظام ملفات — تستطيع فتح الملفات وحفظها
  • 🌐 متصفح — تستطيع البحث في الإنترنت
  • ⌨️ كتابة وتنفيذ كود — إذا كنت مبرمجاً
  • 📋 قائمة مهام (To-Do List)
البدائيات البشرية: Code Execution, File System, Web Search
البدائيات الأساسية: Code Execution، File System، Web Search — نفس أدوات المبرمج البشري
💡 تشبيه: Claude Code — وكيل البرمجة الشهير من Anthropic — يعمل بكفاءة عالية ليس لأن Claude “مبدع” في البرمجة فقط، بل لأننا أعطيناه نفس الأدوات التي يمتلكها المبرمج البشري — نظام ملفات، محطة أوامر (Terminal)، ومتصفح. أي نموذج أفضل (Claude أفضل هذا الأسبوع مقارنة بالشهر الماضي) سيستخدم نفس هذه الأدوات بطريقة أذكى. الفرق؟ نفس الأدوات، لكن “عقل” أكبر.

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

شرح تحليل CSV باستخدام Code Execution بدلاً من Context Window
Code Execution يتفوق على Context Window عند تحليل البيانات — أقل 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 يستدعيها الوكيل عند الحاجة.

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

٥. متى تستخدم MCP؟ (ومتى لا تستخدمه)

MCP (Model Context Protocol) هو بروتوكول يسمح للوكيل بالاتصال بخوادم أدوات خارجية. لكن Will يحذر من التوجه إلى MCP كأول حل:

«نرى الكثير من المطورين يتجهون إلى MCP أولاً، وينتهي بهم الأمر في نظام بيئي فوضوي مليء بخوادم MCP متداخلة ومتكررة.»

التدرج الموصى به عند بناء الأدوات:

  1. البدائيات الأساسية لـ Claude Code (Code Execution، File System، Web Search)
  2. Tools محلية مخصصة للوكيل فقط (Local Tools)
  3. فقط عند الحاجة: MCP — عندما يكون لديك مجموعة أدوات مشتركة بين عدة وكلاء أو عملاء
تدرج MCP vs أدوات مدمجة
التدرج في الأدوات: البدائيات المدمجة → Tools محلية → MCP فقط عند الحاجة

أيضاً، Code Execution يمكن أن يكون بديلاً عملياً لـ MCP في كثير من الحالات — بدلاً من توصيل وكيلك بـ MCP Server، أعطه القدرة على استخدام APIs عبر كتابة كود مباشرة. هذا يقلل من استهلاك Context ويزيد المرونة.

٦. Hill Climbing — كيف تحسّن وكيلك تدريجياً

Hill Climbing (تسلق التل) هي منهجية تستخدمها Anthropic داخلياً لتحسين الوكلاء. الفكرة:

  1. 🏔️ شغّل التقييمات (Evals) للحصول على خط أساس (Baseline)
  2. 🔧 حسّن التصميم — استخدم أدوات أنسب، Skills، إلخ.
  3. 📊 أعد تشغيل التقييمات لترى إن تحسّن الأداء
  4. 🔄 كرّر — كل دورة تمثل “تسلقاً” نحو قمة الأداء المطلوب
💡 تشبيه: تخيل أنك تحاول الوصول لقمة جبل في الظلام. كل خطوة صغيرة نحو الأعلى تمنحك رؤية أفضل للطريق. في Hill Climbing للوكلاء، التقييمات (Evals) هي “ضوءك في الظلام” — كل مرة تشغّلها ترى إن كنت تتجه للأعلى أم للأسفل. لا توجد خريطة كاملة، فقط اختبارات متكررة تقودك تدريجياً للقمة.
دورة Hill Climbing: Evals → تحسين → Evals → تحسين
دورة Hill Climbing: تقييم → تحسين → تقييم → تحسين… كل دورة تقربك من القمة

٧. النتائج: من ٦٢٪ إلى ٩٢٪

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

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

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

جدول يقارن قبل وبعد من حيث الكلفة والسرعة
النتائج النهائية: تحسن دراماتيكي في سرعة التنفيذ والتكلفة ونتائج التقييمات

٨. دروس مستفادة ونصائح عملية

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

📚 المصادر والمراجع

💎 الخاتمة

بناء وكيل ذكاء اصطناعي لا يعني تعقيد الأمور. بالعكس — أفضل الوكلاء هم الأبسط. ابدأ بالأدوات البشرية الأساسية (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 —


Comments

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *