كيف تطبّق وكلاء الذكاء الاصطناعي المهارات فعليًا: مقارنة شاملة عبر المنصات

مقدمة

يواجه كل إطار عمل لوكلاء الذكاء الاصطناعي نفس السؤال الجوهري: كيف تجعل نموذج لغة كبير (LLM) بارعًا في شيء محدد؟ يمتلك النموذج بذاته معرفة عامة واسعة، لكن عندما تحتاج منه إجراء مراجعة للكود أو نشر بنية تحتية أو التنقل في Minecraft — فإنه يحتاج إلى تعليمات متخصصة ووصول للأدوات وسياق مجال محدد.

هذه هي مشكلة حقن المهارات. وكل إطار عمل رئيسي يحلّها بطريقة مختلفة.

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

حللنا 11 منصة رئيسية لوكلاء الذكاء الاصطناعي لفهم أين تُوضع المهارات بالضبط في الطلب، ومتى تُحمّل، وكم تكلّف من رموز، وكيف تنجو عندما تمتلئ نافذة السياق. هذه ليست مقارنة سطحية للميزات. لقد تعمّقنا في الكود المصدري والتوثيق ومخططات البنية لرسم خريطة دقيقة لآليات الحقن في كل منصة.

جدول المقارنة الشامل

إليك النظرة العامة الكاملة قبل أن نتعمّق في التفاصيل.

آليات الحقن: أين ومتى وكيف

الاستمرارية وتكلفة الرموز والسلوك الدائم

هل أنت مستعد لتنمية عملك؟

ابدأ تجربتك المجانية اليوم وشاهد النتائج في غضون أيام.

طلب عرض توضيحي تسجيل الدخول

ماذا يعني “حقن المهارات” فعليًا

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

“المهارة” في سياق الوكيل هي أي حزمة منظّمة من الخبرة تغيّر طريقة تصرف الوكيل. يمكن أن تكون:

• تعليمات تخبر الوكيل كيف يتعامل مع مجال محدد (إرشادات مراجعة الكود، قوائم فحص النشر)
• تعريفات أدوات تمنح الوكيل دوال قابلة للاستدعاء (تكاملات API، عمليات الملفات)
• أمثلة قليلة تُري الوكيل كيف يبدو الناتج الجيد
• معرفة مسترجعة من قواعد بيانات المتجهات أو مستندات خارجية

آلية الحقن — أين ومتى يدخل هذا المحتوى إلى السياق — تحدد ثلاث خصائص حاسمة:

1. كفاءة الرموز: كم رمزًا تستهلك المهارة، وهل تُدفع هذه التكلفة حتى عندما لا تكون المهارة مطلوبة؟
2. الموثوقية: هل سيستخدم الوكيل المهارة باستمرار عندما تكون ذات صلة، أم قد يفوّت الإشارة؟
3. قابلية التوسع: كم عدد المهارات التي يمكن للوكيل الوصول إليها قبل أن يؤدي تضخم السياق إلى تدهور الأداء؟

كل إطار عمل يقدّم مفاضلات مختلفة عبر هذه الأبعاد الثلاثة. دعنا نفحص كلًا منها.

طيف الحقن: من الدائم إلى عند الطلب

عبر جميع المنصات الـ 11، تقع مناهج حقن المهارات على طيف من “كل شيء يُحمّل مقدمًا” إلى “لا شيء يُحمّل حتى يُطلب صراحةً.”

في أحد الطرفين، تحقن منصات مثل CrewAI وSuperAGI وCAMEL-AI المحتوى الكامل لكل مهارة مفعّلة في كل استدعاء LLM. يمتلك الوكيل دائمًا خبرته الكاملة المتاحة. بسيط وموثوق، لكنه مكلّف في الرموز.

في الطرف الآخر، يستخدم Claude Code وLangChain Deep Agents وOpenAI Responses API الكشف التدريجي — يرى الوكيل فقط أسماء المهارات وأوصافها المختصرة عند بدء التشغيل، ويُحمّل المحتوى الكامل عند الطلب. فعّال وقابل للتوسع، لكنه يتطلب من الوكيل التعرف على متى يحتاج مهارة ما.

في الوسط، يستخدم AutoGen Teachability وVoyager الاسترجاع الدلالي لحقن المهارات الأكثر صلة فقط في كل دور، مما يخلق نمط حقن ديناميكي حساس للسياق.

وهناك مناهج فريدة: DSPy يجمّع أمثلة قليلة محسّنة دون اتصال ويضمّنها بشكل دائم في طلبات الوحدات. MetaGPT يرمّز المهارات كقوالب إجراءات تُفعّل فقط عندما ينتقل دور محدد إلى إجراء محدد.

دعنا نفحص كلًا بالتفصيل.

انضم إلى نشرتنا الإخبارية

احصل على أحدث النصائح والاتجاهات والعروض مجانًا.

عنوان البريد الإلكتروني

اشترك

Claude Code: كشف تدريجي ثلاثي الطبقات

يطبّق Claude Code واحدة من أكثر بنى حقن المهارات تطورًا، باستخدام نظام كشف تدريجي ثلاثي الطبقات يوازن بين الوعي وكفاءة الرموز.

الطبقة 1: دائمة الحضور في السياق

عند بدء الجلسة، يُحقن اسم ووصف كل مهارة متاحة في رسالة system-reminder — كتلة بيانات وصفية يراها النموذج دائمًا. تكلّف هذه حوالي 250 حرفًا لكل مهارة، وتستهلك حوالي 1% من ميزانية نافذة السياق لجميع أوصاف المهارات مجتمعة (حوالي 8 آلاف حرف كميزانية احتياطية، قابلة للتجاوز عبر متغير البيئة SLASH_COMMAND_TOOL_CHAR_BUDGET).

بالمثل، الأدوات المؤجلة — الأدوات التي لم تُحمّل مخططاتها JSON الكاملة بعد — تظهر كقائمة أسماء فقط في كتل system-reminder. اعتبارًا من Claude Code v2.1.69، حتى أدوات النظام المضمّنة مثل Bash وRead وEdit وWrite وGlob وGrep مؤجلة خلف ToolSearch، مما يقلل سياق أدوات النظام من حوالي 14-16 ألف رمز إلى حوالي 968 رمزًا.

يرى الوكيل ما يكفي ليعرف ما هو متاح دون دفع تكلفة الرموز للتعريفات الكاملة.

الطبقة 2: عند التفعيل

عندما يكتب المستخدم أمرًا مائلًا (مثل /commit) أو يطابق النموذج تلقائيًا مهارة بناءً على وصفها، يُحمّل متن SKILL.md الكامل كرسالة محادثة عبر أداة المهارة. يحتوي هذا المتن على التعليمات الكاملة — أحيانًا آلاف الرموز من الإرشادات التفصيلية.

تفصيل مهم: المعالجة المسبقة للأوامر تُنفّذ أولًا (أي توجيهات !command في ملف المهارة تُنفّذ ويحل ناتجها محل التوجيه)، وبمجرد التحميل، يبقى متن المهارة في المحادثة لبقية الجلسة.

الطبقة 3: عند الطلب

الموارد الإضافية — المستندات المرجعية والنصوص البرمجية وملفات الأصول — تُقرأ فقط عندما يقرر النموذج صراحةً استخدام أداة Read للوصول إليها. لا تُحمّل تلقائيًا أبدًا.

سلوك ضغط السياق

عندما تقترب المحادثة من حد السياق ويُفعّل الضغط، يُعيد Claude Code إلحاق المهارات المستدعاة مؤخرًا بميزانية 5 آلاف رمز لكل مهارة وحد أقصى مجمّع 25 ألف. المهارات المستدعاة مؤخرًا تحظى بالأولوية. المهارات الأقدم قد تُسقط كليًا.

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

CrewAI: حقن كامل في كل طلب مهمة

يتّخذ CrewAI النهج المعاكس للكشف التدريجي. عندما تُفعّل مهارة لوكيل ما، يُحقن محتواها الكامل في كل طلب مهمة ينفّذه الوكيل.

كيف يعمل

المهارات في CrewAI هي أدلة مستقلة، كل منها يحتوي على ملف SKILL.md يضم بيانات وصفية YAML أمامية (الاسم، الوصف، الرخصة، التوافق، الأدوات المسموح بها) ومتن markdown. يميّز نظام المهارات بين المهارات والأدوات: المهارات تحقن تعليمات وسياقًا يشكّلان طريقة تفكير الوكيل، بينما توفر الأدوات دوال قابلة للاستدعاء للإجراءات.

أثناء تهيئة الوكيل، يستدعي Agent.set_skills() الدالة discover_skills() لمسح أدلة المهارات على مستوى البيانات الوصفية، ثم activate_skill() لقراءة محتويات المهارات الكاملة. في وقت تنفيذ المهمة، تستدعي _finalize_task_prompt() الدالة format_skill_context() لكل مهارة مفعّلة وتُلحق كل محتوى المهارات المنسّق بطلب المهمة.

يستقبل LLM: [رسالة النظام] + [طلب المهمة + كل محتويات المهارات]

تأثيرات الرموز

يفرض CrewAI تحذيرًا ناعمًا عند 50,000 حرف لكل مهارة لكن بدون حد صارم. يوصي التوثيق بإبقاء المهارات مركّزة وموجزة لأن الحقن الكبير في الطلبات يخفف انتباه النموذج — مصدر قلق حقيقي بالنظر إلى الأبحاث حول تآكل السياق.

المفاضلة مباشرة: يمتلك الوكيل دائمًا الخبرة الكاملة المتاحة (موثوقية عالية)، لكن تكلفة الرموز تتناسب خطيًا مع عدد المهارات لكل مهمة (كفاءة منخفضة). للوكلاء ذوي 1-2 مهارة مركّزة، هذا يعمل جيدًا. للوكلاء الذين يحتاجون مجموعات قدرات واسعة، يصبح مكلفًا بسرعة.

لا استمرارية عبر المهام

كل مهمة تحصل على حقن جديد. لا يوجد تراكم لمحتوى المهارات عبر المهام — وهذا في الواقع ميزة وليس عيبًا. يعني أن كل مهمة تبدأ بسياق نظيف، متجنبةً مشاكل التقادم التي يمكن أن تخلقها الاستمرارية القائمة على الجلسات.

LangChain Deep Agents: تحميل يتحكّم فيه الوكيل عبر SkillsMiddleware

يطبّق LangChain Deep Agents نظام مهارات متطور قائم على البرمجية الوسيطة حيث يقرر الوكيل نفسه متى يحمّل المحتوى الكامل للمهارة — نموذج كشف تدريجي حقيقي يتحكّم فيه الوكيل بالتفعيل.

المستويات الثلاثة

المستوى 1 (الفهرس): تحلل SkillsMiddleware كل البيانات الوصفية الأمامية لملفات SKILL.md عند بدء التشغيل وتحقن فهرسًا خفيفًا في رسالة النظام. يحتوي هذا الفهرس على الأسماء والأوصاف فقط، بتكلفة حوالي 278 رمزًا لكل مهارة مقابل 3,302 رمز للمحتوى الكامل.

المستوى 2 (المحتوى الكامل): عندما يحدد الوكيل أن مهارة ذات صلة، يستدعي read_file() على مسار ملف SKILL.md للمهارة. هذا استدعاء أداة عادي — الإطار لا يحقن المتن؛ الوكيل يتخذ قرارًا مدروسًا لتحميله. يدخل المحتوى الكامل سجل المحادثة كنتيجة أداة.

المستوى 3 (التعمّق): المواد الداعمة والمستندات المرجعية والنصوص البرمجية لا يُوصل إليها إلا عندما يقرأها الوكيل صراحةً.

كفاءة الرموز في الممارسة

مع 12 مهارة، يقلل الكشف التدريجي السياق من حوالي 30,000 رمز (كلها محمّلة) إلى حوالي 600 رمز (الفهرس فقط)، ويتوسع إلى 2,000-5,000 عند تحميل المهارات ذات الصلة لمهمة محددة. هذا تخفيض محتمل بنسبة 83-98% في استهلاك الرموز المتعلقة بالمهارات.

يمكن طبقات مصادر مهارات متعددة، وعندما تتعارض الأسماء، يفوز المصدر الأخير. الملفات التي تتجاوز 10 ميغابايت تُتخطى تلقائيًا.

الاختلاف الرئيسي عن Claude Code

بينما يستخدم Claude Code أداة مهارة مخصصة لتفعيل التحميل، يعيد Deep Agents استخدام أداة read_file الموجودة لدى الوكيل. هذا يعني أن آلية التحميل شفافة — يقرأ الوكيل ملفات المهارات بنفس الطريقة التي يقرأ بها أي ملف آخر. الجانب السلبي هو عدم وجود سلوك ضغط خاص: محتوى المهارة الذي يدخل سجل المحادثة يخضع لقص الرسائل القياسي في LangChain، بدون معاملة تفضيلية.

OpenAI Responses API و Agents SDK: تحميل مؤجل تديره المنصة

تطبّق OpenAI حقن المهارات من خلال آليتين مختلفتين لكنهما متوافقتان فلسفيًا: نوع أداة tool_search في Responses API وأداة ToolSearchTool في Agents SDK.

Responses API: tool_search

يسمح نوع أداة tool_search (متاح على GPT-5.4+) للمطورين بتأجيل أسطح الأدوات الكبيرة حتى وقت التشغيل. ثلاث استراتيجيات تأجيل متاحة:

• تأجيل دالة فردية: @function_tool(defer_loading=True) — يرى النموذج اسم الدالة ووصفها لكن مخطط المعاملات مؤجل. يوفر رموز على مستوى المعاملات.
• تأجيل مساحة الأسماء: tool_namespace(name=..., description=..., tools=[...]) — تجمع الدوال تحت مساحة أسماء واحدة. يرى النموذج فقط اسم ووصف مساحة الأسماء، مما يوفر رموزًا أكثر بكثير.
• تأجيل خادم MCP: HostedMCPTool(tool_config={..., "defer_loading": True}) — يؤجل أسطح أدوات خادم MCP بالكامل.

عندما يحدد النموذج أنه يحتاج أداة محددة، يصدر استدعاء tool_search. تعيد API 3-5 تعريفات أدوات ذات صلة، تُحقن في نهاية نافذة السياق للحفاظ على تخزين الطلبات المؤقت.

Agents SDK: ToolSearchTool

يوفر Agents SDK مكافئًا برمجيًا. تُسجّل مساحات أسماء الأدوات لكن لا تُحمّل:

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

في وقت التشغيل، يرى الوكيل فقط أسماء مساحات الأسماء. يستدعي ToolSearchTool("crm") لاكتشاف وتحميل المخططات الكاملة، ثم يمكنه استدعاء أدوات فردية ضمن مساحة الأسماء تلك.

لا استمرارية عبر الطلبات

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

AutoGen Teachability: استرجاع دلالي لكل دور

تتّخذ قدرة Teachability في AutoGen نهجًا مختلفًا جذريًا عن كل إطار عمل آخر في هذه المقارنة. بدلاً من حقن محتوى مهارات ثابت، تسترجع ديناميكيًا “مذكرات” ذات صلة من قاعدة بيانات متجهات ChromaDB في كل دور.

حلقة الاسترجاع لكل دور

تسجّل Teachability خطّافًا على process_last_received_message يعترض كل رسالة مستخدم واردة قبل أن يعالجها الوكيل:

1. يستخرج TextAnalyzerAgent المفاهيم الرئيسية من الرسالة الواردة
2. تُستخدم هذه المفاهيم للاستعلام من ChromaDB (باستخدام تضمينات Sentence Transformer افتراضيًا)
3. تُسترجع أفضل K مذكرة الأكثر صلة (قابلة للتكوين عبر max_num_retrievals، الافتراضي 10)
4. تُلحق المذكرات المسترجعة بنص الرسالة قبل أن يراها الوكيل

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

حلقة التعلم

بعد أن يستجيب LLM، يحلل خطّاف ثانٍ الاستجابة بحثًا عن تعلّمات جديدة:

1. يحدد TextAnalyzerAgent المعرفة الجديدة في الاستجابة
2. تُستخرج مذكرات جديدة كأزواج مفتاح-قيمة (نص إدخال ← نص إخراج)
3. تُخزّن هذه المذكرات في ChromaDB، متاحة للأدوار والجلسات المستقبلية

هذا يخلق حلقة تعلم حقيقية حيث يراكم الوكيل الخبرة بمرور الوقت.

الاستمرارية عبر الجلسات

تُعدّ AutoGen Teachability واحدة من ثلاث منصات فقط في مقارنتنا (إلى جانب Voyager وDSPy) التي تحتفظ بالمهارات عبر الجلسات. تعيش قاعدة بيانات ChromaDB على القرص، مما يعني أن الوكيل يمكنه التعلم من التفاعلات يوم الاثنين وتطبيق تلك المعرفة يوم الجمعة.

يتحكم معامل recall_threshold (الافتراضي 1.5) في مدى تشابه الرسالة مع مذكرة مخزّنة ليتم الاسترجاع، ويمكن لـ reset_db مسح الذاكرة بالكامل عند الحاجة.

كفاءة الرموز

بما أن فقط المذكرات ذات الصلة تُحقن في كل دور (عادةً 3-5)، فإن تكلفة الرموز محدودة بشكل طبيعي بغض النظر عن حجم قاعدة بيانات المذكرات. وكيل لديه 10,000 مذكرة مخزّنة يدفع فقط مقابل الحفنة الأكثر صلة بالدور الحالي.

Semantic Kernel: مخططات الإضافات كتعريفات أدوات دائمة الحضور

يتّخذ Semantic Kernel من Microsoft نهجًا مباشرًا: الإضافات هي مجموعات من كائنات KernelFunction مسجّلة مع Kernel، ومخططاتها مكشوفة لـ LLM كتعريفات أدوات استدعاء دوال.

مساران للحقن

استدعاء الدوال: عند تعيين ToolCallBehavior.AutoInvokeKernelFunctions، تُرسل كل الدوال المسجّلة إلى LLM كأدوات متاحة في كل طلب API. يقرر LLM أيها يستدعي؛ ويتولى Semantic Kernel الاستدعاء وتوجيه النتائج.

قوالب الطلبات: يسمح بناء جملة قوالب Semantic Kernel ({{plugin.function}}، Handlebars، أو Liquid) باستدعاء الدوال مباشرةً أثناء عرض القالب. تُضمّن النتائج مباشرة في نص الطلب قبل وصوله إلى LLM — شكل من أشكال التقييم الفوري بدلاً من استدعاء الأدوات الكسول.

لا كشف تدريجي

يُضمّن مخطط كل إضافة مسجّلة في كل استدعاء API. لا يوجد تحميل مؤجل مدمج، ولا تجميع مساحات أسماء، ولا تفعيل عند الطلب. يوصي التوثيق صراحةً باستيراد الإضافات المطلوبة لسيناريو محدد فقط لتقليل استهلاك الرموز والاستدعاءات الخاطئة.

هذا يجعل Semantic Kernel واحدة من أكثر المنصات قابلية للتنبؤ — تعرف دائمًا بالضبط ما يمكن للوكيل الوصول إليه — لكنه يحدّ من قابلية التوسع. وكيل لديه 50 دالة مسجّلة يدفع تكلفة المخطط الكامل في كل استدعاء.

الاستمرارية

تسجيل الإضافات يكون لكل نسخة Kernel وفي الذاكرة. لا توجد آلية مدمجة لاستمرارية المهارات عبر الجلسات.

MetaGPT: قوالب الإجراءات ضمن إجراءات التشغيل القياسية المبنية على الأدوار

يرمّز MetaGPT المهارات ليس كحزم مستقلة بل كقوالب إجراءات مضمّنة ضمن إجراءات التشغيل القياسية (SOPs) التي تحكم سلوك الأدوار.

بنية الدور والإجراء

كل Role في MetaGPT لديه بادئة شخصية تُحقن في الطلبات ومجموعة من فئات Action. كل إجراء يحتوي على وكيل LLM يُستدعى عبر aask()، الذي يستخدم قوالب طلب بلغة طبيعية لتنظيم استدعاء LLM.

عند تفعيل Role._act()، يدعم ثلاثة أوضاع تفاعل:

• "react": يختار LLM الإجراءات ديناميكيًا في حلقات تفكير-عمل
• "by_order": تُنفّذ الإجراءات تسلسليًا بترتيب محدد مسبقًا
• "plan_and_act": يخطط الوكيل أولًا، ثم ينفّذ الإجراءات وفقًا للخطة

نافذة حقن ضيقة

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

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

استمرارية لدور واحد

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

Voyager: استرجاع مهارات قائم على التضمين للتعلم مدى الحياة

يطبّق Voyager، وكيل استكشاف Minecraft من NVIDIA وCaltech، واحدة من أكثر بنى حقن المهارات أناقةً: مكتبة متنامية من البرامج المتحقق منها تُسترجع بتشابه التضمين.

مكتبة المهارات

عندما يكتب Voyager كودًا يجتاز التحقق الذاتي (كود Mineflayer JavaScript المولّد يعمل فعلًا في اللعبة)، يُخزّن الكود وسلسلة التوثيق الخاصة به في قاعدة بيانات متجهات. يصبح تضمين سلسلة التوثيق مفتاح الاسترجاع.

الاسترجاع لكل مهمة

في كل مهمة جديدة يقترحها المنهج التلقائي:

1. يُضمّن وصف المهمة وتغذية البيئة الراجعة
2. بحث تشابه جيب التمام ضد كل تضمينات المهارات المخزّنة
3. تُسترجع أفضل 5 مهارات الأكثر صلة
4. يُضمّن كود المهارات المسترجعة في طلب وكيل الإجراء كأمثلة قليلة

يبدو الطلب هكذا:

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

يمكن للكود المولّد استدعاء المهارات المسترجعة بالاسم، مما يمكّن بناء المهارات التركيبي — سلوكيات معقدة تُبنى من بدائيات أبسط ومتحقق منها.

استمرارية مدى الحياة

مكتبة المهارات هي آلية “التعلم مدى الحياة” الأساسية. تنمو عبر عمر الوكيل بالكامل، والمهارات الجديدة تُبنى على القديمة. على عكس معظم الأطر حيث تُؤلّف المهارات من قبل البشر، مهارات Voyager تُولّد وتُتحقق وتُخزّن بواسطة الوكيل نفسه.

تكلفة الرموز محدودة بشكل طبيعي: بغض النظر عمّا إذا كانت المكتبة تحتوي على 50 أو 5,000 مهارة، كل مهمة تدفع فقط مقابل أفضل 5 استرجاعات.

DSPy: أمثلة قليلة مُجمّعة كمهارات مجمّدة

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

عملية التجميع

يتولى محسّنان رئيسيان عملية التجميع:

BootstrapFewShot: يستخدم وحدة معلّم لتوليد تتبعات عبر البرنامج. التتبعات التي تجتاز مقياسًا يحدده المستخدم تُحتفظ بها كعروض توضيحية. كل وحدة dspy.Predict ضمن البرنامج تحصل على مجموعتها الخاصة المنسّقة من العروض التوضيحية.

MIPROv2 (محسّن اقتراح التعليمات المتعدد v2): عملية من ثلاث مراحل:

1. التمهيد: توليد مجموعات عروض توضيحية مرشحة
2. الاقتراح: توليد نصوص تعليمات مرشحة تدرك كلاً من توزيع البيانات والعروض التوضيحية
3. البحث: تحسين بايزي عبر الفضاء المشترك للتعليمات × العروض التوضيحية عبر جميع الوحدات

تتحكم معاملات مثل max_bootstrapped_demos (أمثلة مولّدة) وmax_labeled_demos (من بيانات التدريب) في عدد الأمثلة التي تنتهي في طلب كل وحدة.

ثابتة بعد التجميع

بمجرد التجميع، تُخزّن العروض التوضيحية في خاصية demos لكل وحدة Predict وتُنسّق في الطلب عند كل استدعاء LLM. لا تتغير وقت التشغيل — “المهارة” مجمّدة.

هذا يعني أن مهارات DSPy هي الأكثر قابلية للتنبؤ في مقارنتنا: تكلفة الرموز معروفة بعد التجميع، لا يوجد تباين بين الأدوار، ويرى الوكيل دائمًا نفس العروض التوضيحية. الجانب السلبي هو عدم المرونة — لتغيير المهارات، يجب إعادة التجميع.

الاستمرارية

تُسلسل البرامج المُجمّعة إلى JSON، بما في ذلك جميع العروض التوضيحية. إنها مستمرة بالكامل وقابلة للتحميل عبر الجلسات، مما يجعل DSPy واحدة من أكثر آليات تخزين المهارات متانةً.

SuperAGI: تسجيل مقدّم قائم على مجموعات الأدوات

يستخدم SuperAGI نمط مجموعة أدوات تقليدي حيث تُسجّل كل الأدوات عند تهيئة الوكيل.

كل مجموعة أدوات توسّع BaseToolkit مع:

• خاصيتي name وdescription
• دالة get_tools() تعيد قائمة من نسخ BaseTool
• get_env_keys() لمتغيرات البيئة المطلوبة

تُثبّت مجموعات الأدوات من مستودعات GitHub عبر مدير أدوات SuperAGI. عند تهيئة الوكيل، تعيد BaseToolkit.get_tools() كل الأدوات، وتُكشف مخططاتها الكاملة لـ LLM كتعريفات استدعاء دوال.

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

CAMEL-AI: تسجيل أدوات ChatAgent

يتبع CAMEL-AI نمط تسجيل مقدّم مماثل. تُمرر الأدوات من مجموعات أدوات متنوعة (مثل MathToolkit وSearchToolkit) كقائمة إلى ChatAgent(tools=[...]) عند التهيئة.

يؤكد الإطار على أن الدوال المخصصة تحتاج أسماء وسائط واضحة وسلاسل توثيق شاملة حتى يتمكن النموذج من فهم الاستخدام — مخطط الأداة هو محتوى “المهارة” الوحيد الذي يراه النموذج. لا توجد آلية حقن تعليمات منفصلة.

تشمل الإضافات الأخيرة دعم MCP (بروتوكول سياق النموذج) عبر MCPToolkit، مما يسمح لـ ChatAgent بالاتصال بخوادم MCP وتسجيل أدوات خارجية. هذا يوسّع سطح الأدوات المتاح لكنه لا يغيّر نموذج الحقن — كل أدوات MCP المكتشفة لا تزال تُسجّل مقدمًا.

مقارنة عبر المنصات

متى تُحقن المهارات

نماذج الاستمرارية

نجاة ضغط السياق

نمط الكشف التدريجي

الاتجاه المعماري الأبرز عبر هذه المنصات هو تبنّي الكشف التدريجي — مفهوم مستعار من تصميم واجهات المستخدم حيث تُكشف المعلومات تدريجيًا بناءً على الحاجة.

لماذا يهمّ الكشف التدريجي

النهج الساذج لحقن المهارات — تحميل كل شيء مقدمًا — يخلق مشكلتين:

1. هدر الرموز: معظم المهارات ليست ذات صلة بمعظم الأدوار. تحميل 20 متن مهارة كامل عندما يُحتاج 1-2 فقط لكل دور يُهدر أكثر من 90% من الرموز المتعلقة بالمهارات.
2. تخفيف الانتباه: تُظهر الأبحاث حول تآكل السياق أن نماذج اللغة الكبيرة تؤدي بشكل أسوأ عندما يحتوي سياقها على كميات كبيرة من المعلومات غير ذات الصلة. المزيد من المهارات في السياق يمكن أن يقلل فعليًا من جودة تطبيق المهارة.

يحلّ الكشف التدريجي كلتا المشكلتين بالحفاظ على فهرس خفيف للمهارات المتاحة مع تحميل المحتوى الكامل فقط عند الحاجة.

تنويعات التطبيق

Claude Code يستخدم نظامًا مخصصًا: بيانات وصفية للمهارات في رسائل system-reminder، وأداة مهارة للتفعيل، وToolSearch لمخططات الأدوات المؤجلة. يدير الإطار الحقن تلقائيًا مع ضغط قائم على الأولوية.

LangChain Deep Agents يستخدم قدرة قراءة الملفات الموجودة لدى الوكيل: SkillsMiddleware تحقن الفهرس، ويحمّل الوكيل المحتوى الكامل عبر read_file(). هذا أكثر شفافية لكنه يوفر تحسينًا أقل على مستوى الإطار.

OpenAI Responses API يستخدم تجميعًا قائمًا على مساحات الأسماء مع بحث تديره المنصة: توفر مساحات أسماء الأدوات أوصافًا عالية المستوى، ويعيد tool_search المخططات ذات الصلة. تتولى المنصة منطق البحث بالكامل.

توفير الرموز في الممارسة

الأرقام مقنعة. مع 12 مهارة:

• حقن دائم (نمط CrewAI/SuperAGI): ~30,000 رمز
• فهرس الكشف التدريجي فقط: ~600 رمز
• الفهرس + مهارتان مفعّلتان: ~2,000-5,000 رمز

هذا تخفيض بنسبة 83-98% في استهلاك الرموز المتعلقة بالمهارات لكل دور. على مدار جلسة طويلة مع مئات الأدوار، تتضاعف التوفيرات بشكل كبير.

الأنماط المعمارية والمفاضلات

عبر جميع المنصات الـ 11، تبرز أربعة أنماط معمارية مميزة:

النمط 1: الحقن الدائم

تستخدمه: CrewAI، SuperAGI، CAMEL-AI، Semantic Kernel

كيف يعمل: المحتوى الكامل للمهارات أو مخططات الأدوات حاضرة في كل استدعاء LLM.

المزايا:

• أقصى موثوقية — يمتلك الوكيل دائمًا الخبرة الكاملة المتاحة
• أبسط تطبيق — لا حاجة لمنطق تفعيل
• تكاليف رموز متوقعة — نفسها في كل دور

العيوب:

• تكلفة الرموز تتناسب خطيًا مع عدد المهارات
• تخفيف الانتباه مع كثرة المهارات
• لا يتوسع لأكثر من ~5-10 مهارات لكل وكيل

الأفضل لـ: الوكلاء المركّزين ذوي 1-3 مهارات أساسية ذات صلة دائمًا.

النمط 2: الكشف التدريجي

تستخدمه: Claude Code، LangChain Deep Agents، OpenAI Responses API/Agents SDK

كيف يعمل: بيانات وصفية خفيفة حاضرة دائمًا؛ المحتوى الكامل يُحمّل عند الطلب.

المزايا:

• يتوسع لعشرات أو مئات المهارات المتاحة
• تكلفة رموز ضئيلة عندما لا تكون المهارات مطلوبة
• يحافظ على ذاكرة الطلبات المؤقتة عند إلحاق المخططات الكاملة في النهاية

العيوب:

• قد يفوّت الوكيل إشارة تفعيل مهارة ذات صلة
• تأخير إضافي من خطوة التفعيل
• تطبيق إطار عمل أكثر تعقيدًا

الأفضل لـ: الوكلاء متعددي الأغراض الذين يحتاجون الوصول إلى قدرات كثيرة لكنهم يستخدمون قليلًا منها لكل مهمة.

النمط 3: الاسترجاع الدلالي

تستخدمه: AutoGen Teachability، Voyager

كيف يعمل: استعلامات قاعدة بيانات المتجهات تُبرز المهارات/المعرفة ذات الصلة بناءً على التشابه الدلالي مع السياق الحالي.

المزايا:

• تكلفة رموز محدودة بشكل طبيعي بغض النظر عن حجم المكتبة
• صلة المحتوى تتحسن مع نمو المكتبة بمرور الوقت
• تعلم وتراكم عبر الجلسات
• لا حاجة لتفعيل صريح — تُحسب الصلة تلقائيًا

العيوب:

• جودة الاسترجاع تعتمد على جودة نموذج التضمين
• خطر استرجاع معلومات قديمة أو خاطئة بشكل دقيق
• تتطلب بنية تحتية لقاعدة بيانات المتجهات
• أقل قابلية للتنبؤ — أدوار مختلفة تحمّل محتوى مختلف

الأفضل لـ: الوكلاء الذين يتعلمون من التجربة ويحتاجون تراكم معرفة المجال بمرور الوقت.

النمط 4: الحقن المُجمّع/الثابت

تستخدمه: DSPy، MetaGPT

كيف يعمل: تُجمّع المهارات في محتوى طلب ثابت (DSPy) أو تُفعّل من خلال قوالب إجراءات صارمة (MetaGPT).

المزايا:

• أكثر سلوك قابل للتنبؤ — نفس المحتوى في كل مرة
• يمكن إجراء التحسين دون اتصال (تجميع DSPy)
• لا عبء وقت تشغيل لاختيار المهارات
• فعّال مثبت للمهام المحددة جيدًا والقابلة للتكرار

العيوب:

• غير مرن — تغيير المهارات يتطلب إعادة التجميع (DSPy) أو تغييرات في الكود (MetaGPT)
• لا يمكنه التكيف مع المواقف الجديدة خارج الأمثلة المُجمّعة
• عملية تجميع DSPy نفسها تتطلب العديد من استدعاءات LLM

الأفضل لـ: خطوط أنابيب الإنتاج ذات المهام المحددة جيدًا حيث الموثوقية أهم من المرونة.

التأثيرات العملية لبناة الوكلاء

اختيار النمط المناسب

بنية حقن المهارات المناسبة تعتمد على ملف وكيلك:

إذا كان لوكيلك دور ضيق ومحدد جيدًا (مثل روبوت مراجعة كود، وكيل دعم عملاء لمنتج واحد)، فالحقن الدائم (نمط CrewAI/SuperAGI) هو الأبسط والأكثر موثوقية. تكلفة الرموز لـ 2-3 مهارات دائمة الحضور يمكن إدارتها، وتتجنب تعقيد منطق التفعيل.

إذا كان وكيلك يحتاج قدرات واسعة لكنه يستخدم قليلًا منها في كل تفاعل (مثل مساعد مطور، وكيل أتمتة متعدد الأغراض)، فالكشف التدريجي (نمط Claude Code/Deep Agents) هو الفائز الواضح. توفير الرموز بنسبة 83-98% على نطاق واسع أكبر من أن يُتجاهل.

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

إذا كان وكيلك يشغّل خطوط أنابيب محددة جيدًا (مثل معالجة البيانات، توليد التقارير، سير عمل موحّد)، فالحقن المُجمّع (نمط DSPy) يمنحك أكثر سلوك محسّن وقابل للتنبؤ.

النهج الهجين

لفرق وكلاء الإنتاج حيث يحتاج الوكلاء للعمل فورًا، نوصي بنهج هجين:

المهارات الأساسية (1-2 لكل وكيل، تحدد خبرتهم الأساسية في المجال): تُحقن دائمًا في رسالة النظام، بنمط CrewAI. هذه قدرات غير قابلة للتفاوض يحتاجها الوكيل في كل دور.

المهارات الموسّعة (قدرات إضافية قد يحتاجها الوكيل): بيانات وصفية فقط في رسالة النظام، تُحمّل عبر آلية بحث/تحميل عند الحاجة، بنمط Deep Agents. تُوسّع مجموعة قدرات الوكيل دون دفع تكلفة الرموز عندما لا تكون ذات صلة.

المعرفة المكتسبة (خبرة مجال متراكمة): تُخزّن في قاعدة بيانات متجهات وتُسترجع دلاليًا لكل دور، بنمط AutoGen. يسمح هذا للوكيل بالتحسن بمرور الوقت دون تأليف مهارات يدوي.

تتوافق هذه البنية متعددة الطبقات بشكل طبيعي مع كيفية بناء رسالة النظام: التاريخ ← الشخصية ← تعليمات النظام ← المهارات الأساسية ← فهرس المهارات ← سياق الدور/الفريق. تضيف المهارات الأساسية والفهرس تكلفة رموز متوقعة وقابلة للإدارة، بينما تظهر محتويات المهارات الكاملة فقط عند الحاجة.

أفضل ممارسات ميزانية الرموز عبر الأطر

بغض النظر عن نمط الحقن الذي تستخدمه، تنطبق استراتيجيات إدارة الرموز هذه بشكل عام:

ترتيب صديق للتخزين المؤقت

رتّب السياق غير المتغير (تعليمات النظام، مخططات الأدوات) في مقدمة الطلب. لدى المزودين الذين يدعمون تخزين الطلبات المؤقت، تكلّف الرموز المخزّنة مؤقتًا 75% أقل. يحقن كل من Claude Code وOpenAI مخططات الأدوات المكتشفة في نهاية السياق تحديدًا للحفاظ على إصابات التخزين المؤقت على البادئة الثابتة.

التفريغ

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

التقليص

اضغط سجل المحادثة من خلال التلخيص. استخرج الحقائق الرئيسية من التبادلات الطويلة إلى تمثيلات مكثفة. كل إطار عمل ذي استمرارية قائمة على الجلسات يستفيد من إدارة سجل محادثة عدوانية.

الاسترجاع بدلاً من التحميل المسبق

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

العزل

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

الخاتمة

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

يتقارب المجال بوضوح نحو الكشف التدريجي كنمط مفضّل للوكلاء متعددي الأغراض، حيث توصّل كل من Claude Code وLangChain Deep Agents وOpenAI بشكل مستقل إلى بنى ثلاثية المستويات متشابهة. في الوقت نفسه، تخدم الأنماط المتخصصة مثل الاسترجاع الدلالي (AutoGen، Voyager) والحقن المُجمّع (DSPy) مجالات مهمة لا يعالجها الكشف التدريجي وحده.

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

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