31 مصطلحاً في عالم وكلاء البرمجة بالذكاء الاصطناعي، مصنّفةً في خمسة محاور

كل أسبوع يظهر مصطلح جديد في مجرى أخباري. Context engineering. Harness engineering. RLM. Progressive disclosure. أستخدم وكلاء البرمجة بالذكاء الاصطناعي يومياً، وكانت المفردات تتراكم بوتيرة أسرع من استيعابي لها.

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

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

تصميم. تقسيم. تحكم. تذكّر. ربط.

تصميم ما يراه الوكيل

يعالج نموذج الذكاء الاصطناعي شيئاً واحداً فحسب: نافذة السياق الخاصة به. كل system prompt، وتعليمات المستخدم، والملفات المرفقة، وسجل المحادثة، وكتل الذاكرة، والـ skills المحمّلة، كلها تُدمج في تدفق واحد من الـ tokens. هذا التدفق هو كون النموذج بأكمله. ملف AGENTS.md الذي تعتمده كثير من الفرق لضبط سلوك الوكيل ليس سوى قطعة أخرى ضمن هذا التدفق.

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

Context هو كل ما يستطيع النموذج الرجوع إليه: system prompts، وسجل المحادثة، والملفات المرفقة، والذاكرة، والـ skills، ومخرجات الأدوات مجتمعةً. Context engineering هو فن تحديد ما يدخل وما يُستبعد وبأي ترتيب. الفرق مهم. رأيت prompts متطابقة تنتج نتائج متباينة تبايناً كبيراً بحسب ما إذا كان ملف من 2000 سطر موضوعاً قبل التعليمات أم بعدها. الترتيب ليس مجرد شكل.

Intent هو هدف المستخدم الحقيقي، الذي قد يختلف عما يكتبه حرفياً. حين تكتب “صحّح الاختبارات”، قد يكون القصد “اجعل CI يعمل” أو “أعد هيكلة مجموعة الاختبارات لتتوافق مع الـ API الجديدة”. توجيه الوكيل يبدأ من هنا، والخطأ في فهم الـ intent ينعكس على كل ما يليه.

Skill هو حزمة قابلة لإعادة الاستخدام من التعليمات المتخصصة تُحمَّل في السياق عند استدعائها. فكّر فيها كدالة للـ prompts. بدلاً من لصق نفس التعليمات من 200 سطر في كل مرة تريد سلوكاً معيناً، تستدعي /refactor-clean فيدخل محتوى الـ skill إلى نافذة السياق عند الطلب.

Progressive disclosure هو نمط التصميم الذي لا تحمّل فيه جميع الـ skills في السياق دفعةً واحدة. بدلاً من ذلك، يحمّل الوكيل فقط الـ skill التي يحتاجها في اللحظة الراهنة. نشرت Anthropic هذا النهج في منشور مدونتها عن الـ skills. الأمر مهم لأن مساحة نافذة السياق محدودة. تحميل 40 skill مسبقاً يستهلك tokens قبل أن يبدأ النموذج في العمل. يُبقي progressive disclosure النافذة خفيفة والنموذج مركّزاً.

النمط الخاطئ الذي وقعت فيه مراراً في البداية: حشو السياق بأكثر مما يحتمل ثم التساؤل عن سبب تراجع جودة مخرجات النموذج. نافذة الـ 200K token هي حد نظري أقصى. عملياً، حين تحسب system prompts وتعريفات MCP server وسجل المحادثة، قد تنخفض المساحة القابلة للاستخدام إلى 70K أو أقل. Context engineering يعني احترام هذا القيد.

تقسيم العمل بين الوكلاء

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

Subagent هو عملية فرعية يُفوّض إليها الوكيل الرئيسي بعض الأعمال. يحافظ الوكيل الرئيسي على نظافة سياقه الخاص بإحالة المهام المتخصصة. في Claude Code، حين تطلق مهمة بحث في الخلفية، فذلك subagent يعمل في نافذة سياق خاصة به ولا يُعيد سوى النتيجة.

Swarm هو نمط تعمل فيه وكلاء متعددون بالتوازي على أجزاء مختلفة من المسألة ذاتها. إن احتجت لتحليل خمسة ملفات في آنٍ واحد، يتيح لك الـ swarm أن يتولى كل وكيل ملفاً واحداً بدلاً من أن يعالجها وكيل واحد بالتسلسل.

Fleet هو النظرة التشغيلية لوكلائك النشطين. إنه مصطلح إدارة لا مصطلح بنية. حين يكون لديك ثلاثة subagents ووكيلان في الخلفية، فتلك المجموعة هي الـ fleet.

Handoff هو نقل العمل من وكيل إلى آخر أو من شخص إلى آخر. في سير العمل التسلسلي، يكمل الوكيل A مرحلته ثم يُحيل إلى الوكيل B. التفصيل المهم هو ما الذي يُنقل: المخرجات فحسب، أم السياق الكامل؟ معظم عمليات الـ handoff تنقل ملخصاً، مما يعني احتمال فقدان المعلومات وينبغي أخذ ذلك في الحسبان.

Background agent يعمل بشكل غير متزامن دون تفاعل من المستخدم. يدعم هذا النمط كل من GitHub Copilot Workspace وAnthropic Claude Code. تصف المهمة، تغلق جهازك، ويعمل الوكيل باستقلالية. تجد النتائج حين تعود.

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

التحكم في طريقة تنفيذ الوكلاء

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

Harness هو الإطار التشغيلي الذي يُغلّف تنفيذ الوكيل والتحقق من مخرجاته ودورة حياته. يشمل كل شيء من فحوصات الصلاحيات إلى التحقق من المخرجات إلى منطق إعادة المحاولة. Harness engineering هو تصميم القيود وحلقات التغذية الراجعة داخل هذا الإطار. أدخلت OpenAI هذا المصطلح إلى الاستخدام الواسع حين نشرت كيف أنتج Codex أكثر من مليون سطر من الكود باستخدام أنماط harness منظّمة.

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

Diff هو المقارنة بين الكود قبل تغييرات الوكيل وبعدها. تشكّل الـ diffs مع الـ traces العمود الفقري للتحقق. لا يمكنك مراجعة ما لا تراه، والـ diffs تجعل تغييرات الوكيل قابلة للمراجعة بالطريقة ذاتها التي تجعل بها pull requests تغييرات المطورين قابلة للمراجعة.

Guardrails هي قواعد وفحوصات تحقق تمنع المخرجات الخطرة. قد تكون بسيطة كـ”لا تنفّذ أوامر shell تحتوي على rm -rf” أو متطورة كمصنّفات محتوى تمنع ظهور البيانات الحساسة في المخرجات.

Sandbox هي بيئة تنفيذ معزولة بصلاحيات محدودة. يعمل Codex داخل Docker sandbox حيث يستطيع الوكيل كتابة الكود وتشغيل الاختبارات لكنه لا يستطيع الوصول إلى الشبكة أو تعديل النظام المضيف. هذا هو الفرق بين “أخطأ الوكيل” و”أخطأ الوكيل وأثّر ذلك على بيئة الإنتاج”.

CLI (command-line interface) يشهد عودة في عصر الوكلاء. تشغيل الأدوات عبر الطرفية أكثر كفاءة من حيث الـ tokens مقارنةً بالتوجيه عبر طبقات البروتوكول. حين يكلّف كل token مالاً ويستهلك مساحة من السياق، تصبح مباشرة الـ CLI ذات أهمية.

REPL (read-eval-print loop) هي بيئة تفاعلية لتنفيذ الكود فورياً. يستخدمها الوكلاء لاختبار الفرضيات والتحقق من النتائج الوسيطة والتكرار على الحلول دون كتابة ملفات على القرص أولاً.

التذكر عبر الجلسات

للنماذج اللغوية الكبيرة حدٌّ صارم: نافذة السياق. حين تمتلئ، تُحذف المحتويات الأقدم. بالنسبة للمهام التي تمتد لساعات أو أيام، هذا يمثّل مشكلة حقيقية.

Memory هو أي نظام يحفظ سجل المحادثة وحالة المهمة خارج نطاق نافذة سياق واحدة. Memory hierarchy ينظّم هذه المخازن في طبقات، عادةً قصيرة المدى (المحادثة الجارية)، ومتوسطة المدى (الجلسات الأخيرة)، وطويلة المدى (المعرفة الدائمة). هذا التصميم يوازي تراتبية ذاكرة التخزين المؤقت في المعالجات للسبب ذاته: أنماط الوصول المختلفة تحتاج استراتيجيات تخزين مختلفة.

Embeddings تحوّل النص إلى متجهات رقمية تعبّر عن المعنى الدلالي. وهي أساس RAG (retrieval-augmented generation)، حيث يبحث الوكيل في قاعدة بيانات متجهية لسحب المعلومات ذات الصلة إلى نافذة سياقه. حين “يتذكر” وكيلك شيئاً من جلسة سابقة، فهو في الغالب يُجري بحث تشابه قائماً على الـ embeddings.

Long-running agent يحافظ على حالته عبر نوافذ سياق متعددة، ويعمل على مهام تستغرق أطول من جلسة واحدة. هذا يستلزم إدارة الحالة خارجياً لأن النموذج ذاته لا يملك ذاكرة دائمة.

Ralph Loop، الذي ابتكره Geoffrey Huntley، هو حلقة برمجة ذاتية تحل مشكلة الذاكرة بطريقة عملية. كل تكرار يبدأ instance جديدة للوكيل، لكن التقدم يُحفظ عبر git commits وملفات التقدم. تقرأ الـ instance الجديدة تاريخ git والملاحظات لتفهم ما أُنجز، ثم تكمل من حيث توقف السابق. يعظّم هذا الأسلوب استثمار وقت الاستدلال بالتكرار المتواصل، إذ تستفيد كل حلقة من السياق المتراكم في المستودع نفسه.

RLM (Recursive Language Model) يتبع مقاربة مختلفة جذرياً. بدلاً من تغذية النموذج بمدخلات طويلة مباشرةً (مما قد يتجاوز نافذة السياق)، يخزّن RLM البيانات الأصلية في متغيرات REPL ويتيح للنموذج كتابة كود لاستكشافها. يُجري النموذج استعلامات محددة على البيانات المخزّنة عبر استدعاءات دوالّ تعاودية. لأن البيانات الأصلية لا تدخل نافذة السياق أبداً، لا تُفقد المعلومات بالاقتطاع. يدّعي مؤلفو البحث أن هذا النهج يتعامل مع مدخلات تعادل 100 ضعف نافذة السياق الاعتيادية.

كلا النهجين يُقرّ بالقيد ذاته لكنهما يحلّانه بطريقتين مختلفتين. Ralph Loop يعمل ضمن محدودية نافذة السياق بالاعتماد على التخزين الخارجي. RLM يتحايل على نافذة السياق بالكامل بإبقاء البيانات خارجها. لا يتفوق أحدهما بصورة مطلقة؛ الاختيار الصحيح يعتمد على ما إذا كانت مشكلتك في استمرارية المهمة (Ralph Loop) أم في حجم المدخلات (RLM).

ربط الوكلاء بالعالم الخارجي

الوكيل الذي لا يصل إلى أدوات خارجية أو APIs أو خدمات محدود بمجرد توليد النص. البروتوكولات تحل مشكلة التكامل.

MCP (Model Context Protocol) يُوحّد طريقة اتصال النماذج بالأدوات الخارجية. من دون MCP، يستلزم دمج N نموذجاً مع M أداة ما يساوي N × M تطبيقاً مخصصاً. مع MCP، يُطبّق كل نموذج وكل أداة البروتوكول مرةً واحدة، مما يُخفّض تكلفة التكامل إلى N + M. هذا المبدأ هو ما جعل USB ناجحاً: اتفق على واجهة واحدة ويتصل بها كل شيء.

ACP (Agent Communication Protocol) يُوحّد التواصل بين المحررات وعملاء البرمجة. تقود تطويره كل من Zed وJetBrains. المشكلة التي يحلها مشابهة لـ MCP لكنها في طبقة مختلفة: بدلاً من model-to-tool، هي editor-to-agent.

LSP (Language Server Protocol) هو المعيار الراسخ لتواصل المحررات مع خوادم تحليل الكود. وهو الدليل الأصلي على أن توحيد البروتوكولات يصلح في أدوات المطورين. بحث المراجع الذي يأخذ مع grep 30 ثانية يكتمل في 50 ميلي ثانية عبر LSP. يتراجع استهلاك الـ tokens من 2000+ إلى نحو 500 لأن LSP يُعيد نتائج دقيقة ومنظّمة بدلاً من محتويات الملفات الخام. LSP هو أيضاً النموذج المرجعي لتصميم ACP، وهذا منطقي: شكل المشكلة متطابق تقريباً.

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

الخريطة وليست الأرض

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

قيمة هذه المحاور الخمسة ليست في حفظ التعريفات. بل في امتلاك إطار ذهني يخبرك على الفور أين يقع المصطلح الجديد حين تصادفه. حين يذكر أحدهم “agent memory”، تعرف أنه ينتمي إلى المحور الرابع. حين يُطلق بروتوكول جديد، تعرف أنه في المحور الخامس. الإطار يستوعب المفردات الجديدة دون أن يتفكك.

ما زلت أبحث عن مصطلحات بانتظام. الفرق أنني الآن أعرف الرف الذي تنتمي إليه.