هندسة السياق لوكلاء الذكاء الاصطناعي: دليل عملي (2026)
ما هي هندسة السياق، وكيف تختلف عن هندسة المطالبات (Prompt Engineering)، والتقنيات الأربع الأساسية، وكيف تتماشى الأطر الرئيسية معها، وكيفية قياسها، وكيفية تطبيقها في أنظمة الوكلاء المتعددة.
وكيل الذكاء الاصطناعي لا يكون جيدًا إلا بقدر جودة المعلومات الموجودة في نافذة سياقه في اللحظة التي يقرر فيها ما يفعله بعد ذلك — وتنظيم هذه المعلومات هو جوهر اللعبة كلها. إذا كانت هندسة التوجيهات (prompt engineering) هي كتابة تعليمة جيدة، فإن هندسة السياق (context engineering) هي إدارة بيئة المعلومات الكاملة التي يعمل النموذج ضمنها: التعليمات النظامية، والأدوات، والوثائق المسترجَعة، والذاكرة، والسجل الجاري للمهمة. ومع تحمّل الوكلاء لأعمال أطول ومتعددة الخطوات، أصبح هذا العامل هو الرافعة الأكبر التي تحدد نجاح الوكيل أو انهياره بصمت. يتناول هذا الدليل ما هي هندسة السياق، وكيف تختلف عن هندسة التوجيهات، والتقنيات الأساسية لها، وكيفية تطبيقها في أنظمة الوكلاء الفعلية.
لماذا تهم هندسة السياق
تهم هندسة السياق لأن نماذج اللغة الكبيرة تمتلك نافذة سياق محدودة، وطريقة ملء تلك النافذة تحدد جودة كل قرار يتخذه الوكيل. النموذج لا يكون جيدًا إلا بقدر جودة المعلومات المعروضة أمامه — أعطه القليل جدًا فسيهرطق (يهلوس)، وأعطه أكثر من اللازم أو النوع الخاطئ من المعلومات فتتراجع دقته.
هذا ليس قلقًا نظريًا. وثّق الباحثون تأثيرًا يُعرف بـ"الضياع في الوسط" (lost in the middle)، حيث تستخدم النماذج بشكل موثوق المعلومات الموجودة في بداية ونهاية السياق الطويل لكنها تتجاهل الحقائق المدفونة في الوسط. ويصف الممارسون مشكلة مرتبطة يسمونها "تعفن السياق" (context rot): فمع طول المحادثة أو تشغيل الوكيل، تتراكم الرموز (tokens) غير ذات الصلة، وتنخفض نسبة الإشارة إلى الضجيج، ويبدأ النموذج في اتخاذ خيارات أسوأ. النافذة لم تصغر — بل أصبحت مزدحمة بالفوضى.
هذا التحول في المصطلحات يعكس تحولًا حقيقيًا في الممارسة. في عام 2025، جادل أصوات بارزة في الذكاء الاصطناعي — من بينهم أندريه كارباثي وتوبي لوتكه من Shopify — بأن مصطلح "هندسة السياق" يصف ما يفعله فعليًا بناة تطبيقات LLM الجدية بشكل أفضل بكثير من مصطلح "هندسة التوجيهات". نشرت Anthropic توجيهات حول هندسة السياق الفعالة للوكلاء؛ وكتبت الفرق التي تقف خلف منتجات الوكلاء مثل Manus بالتفصيل عن الدروس التي تعلموها في إدارة السياق في بيئة الإنتاج. والتوافق العام هو: بالنسبة للأنظمة الوكيلية، السياق هو المنتج.
ما هي هندسة السياق؟
هندسة السياق هي فن تجميع المجموعة الصحيحة من الرموز (tokens) للنموذج في وقت الاستدلال، بحيث يكون لدى النموذج بالضبط ما يحتاجه لاتخاذ الإجراء الصحيح التالي — لا أكثر ولا أقل. يشمل "السياق" كل ما هو داخل النافذة:
- التعليمات النظامية — دور الوكيل، والقيود، وقواعد السلوك
- الأدوات وتعريفاتها — الإجراءات التي يمكن للوكيل اتخاذها، وكيفية وصفها
- المعرفة المسترجَعة — الوثائق، أو نتائج البحث، أو صفوف قاعدة البيانات المستحضرة لهذه المهمة
- الذاكرة — الحقائق المنقولة من وقت سابق في الجلسة أو من جلسات سابقة
- سجل المحادثة والإجراءات — السجل الجاري لما قيل وما تمّ فعله
- طلب المستخدم الحالي — الهدف المباشر
هندسة السياق هي مجموعة القرارات المتعلقة بما يدخل في كل من هذه الخانات، وبأي شكل، وفي أي وقت. وهي تتعامل مع نافذة السياق كمورد نادر يجب إدارته بعناية، لا كوعاء تستمر في سكب النص فيه.
نافذة السياق هي ميزانية انتباه محدودة — هندسة السياق تقرر ما يملأ كل خانة.
هندسة السياق مقابل هندسة التوجيهات
الفرق بين هندسة السياق وهندسة التوجيهات هو فرق في النطاق: هندسة التوجيهات تُحسّن تعليمة واحدة، بينما هندسة السياق تدير بيئة المعلومات الكاملة والديناميكية عبر مهمة متعددة الخطوات. هندسة التوجيهات هي مجموعة فرعية من هندسة السياق.
| هندسة التوجيهات | هندسة السياق | |
|---|---|---|
| النطاق | توجيهة/تعليمة واحدة | نافذة السياق كاملة عبر الزمن |
| الحالة | غالبًا بلا حالة، لمرة واحدة | تحمل حالة، تتطور عبر خطوات كثيرة |
| الاهتمام | الصياغة، الأمثلة، التنسيق | ما يجب تضمينه، واسترجاعه، وتذكّره، وحذفه |
| الاستخدام النموذجي | إكمال واحد أو دور محادثة واحد | الوكلاء المستقلون، المهام طويلة الأمد |
| الفشل الذي يمنعه | تعليمة غامضة أو مُفسَّرة بشكل خاطئ | تعفن السياق، التشتت، الحالة المتناقضة |
لا تزال هندسة التوجيهات مهمة — فالتوجيهة النظامية المصاغة بشكل جيد جزء من هندسة سياق جيدة. لكن بمجرد أن يعمل الوكيل لعشرات الخطوات، ويستدعي الأدوات، ويتراكم السجل، لا تعود صياغة أي توجيهة واحدة هي عقبة الطريق. ما يهم هو الانضباط الذي يدير كل ما يحيط بها.
التقنيات الأربع الأساسية
يمكن تلخيص معظم أعمال هندسة السياق في أربع عمليات على نافذة السياق. طريقة مفيدة لتذكرها: الكتابة، والاختيار، والضغط، والعزل.
الكتابة، الاختيار، الضغط، والعزل — العمليات الأربع التي تقف خلف كل قرار في هندسة السياق.
1. الكتابة — حفظ السياق خارج النافذة
ليس كل ما يحتاجه الوكيل ينبغي أن يعيش في التوجيهة. كتابة السياق تعني تخزين المعلومات خارجيًا — مذكرات مساعدة، ملفات، مخزن ذاكرة، قائمة مهام — بحيث تبقى محفوظة بعد نافذة واحدة ويمكن استحضارها عمدًا. الوكيل الذي يعمل لفترة طويلة ويكتب خطته إلى ملف ويعيد قراءتها يبقى على المسار الصحيح بشكل أفضل بكثير من وكيل يعتمد فقط على سجل المحادثة.
2. الاختيار — إدخال فقط ما هو ذو صلة الآن
اختيار السياق هو فن استرجاع المعلومة الصحيحة في اللحظة الصحيحة: الوثيقة المحددة، القرار السابق ذو الصلة، تعريف الأداة الواحدة التي تحتاجها هذه الخطوة. هنا يعيش الاسترجاع المعزز بالتوليد (RAG)، والبحث الدلالي، واختيار الأدوات الذكي. الهدف هو الدقة — سحب الحقائق الثلاث ذات الصلة، لا المئات الثلاثة المجاورة.
3. الضغط — تقليل الرموز مع الحفاظ على الإشارة
ضغط السياق يعني التلخيص أو التقليم بحيث تحمل النافذة المعنى، لا الحجم. تشمل التكتيكات الشائعة تلخيص المهام الفرعية المكتملة، وتقليم مخرجات الأدوات المطوّلة، واستبدال السجلات الطويلة بموجز مكثف. الضغط هو ما يسمح للوكيل بالعمل على مهمة أطول من ما تسمح به نافذة سياقه الأصلية.
4. العزل — تقسيم السياق عبر الوكلاء أو الحدود
عزل السياق يعني إعطاء أجزاء مختلفة من مشكلة نافذاتها النظيفة الخاصة — على سبيل المثال، إنشاء وكيل فرعي يملك فقط السياق الذي يحتاجه لمهمة فرعية واحدة، ثم إعادة النتيجة فقط. العزل يمنع تلوث جزء من عمل بجزء آخر، وهو أساس أنظمة الوكلاء المتعددة الموثوقة.
كيف تتوافق الأطر الرائدة
أحد مصادر الالتباس هو أن كل فرقة رئيسية تستخدم مصطلحاتها الخاصة لوصف العمليات الأساسية نفسها. تصف Anthropic وLangChain وبائعو قواعد البيانات البيانية مثل Neo4j هندسة السياق كل بطريقته الخاصة — لكنها تتوافق بشكل واضح مع العمليات الأربع أعلاه. هذا الجدول يوفّق بينها:
| العملية (هذا الدليل) | صياغة Anthropic | صياغة LangChain | صياغة الرسم البياني المعرفي / GraphRAG |
|---|---|---|---|
| الكتابة (حفظ خارج النافذة) | تدوين ملاحظات منظّم، ذاكرة الوكيل (NOTES.md، قوائم المهام) | التخزين والحالة (Store and State)؛ الأدوات التي تكتب عبر Command | الذاكرة طويلة المدى؛ الرسم البياني نفسه كمخزن دائم |
| الاختيار (استرجاع ما هو ذو صلة الآن) | السياق في الوقت المناسب، البحث الوكيلي، الاسترجاع الهجين | الاختيار الديناميكي للأدوات/الرسائل؛ الأدوات التي تقرأ | RAG الهجين، GraphRAG، "أقل سياق قابل للتطبيق" |
| الضغط (تقليل الرموز، الحفاظ على الإشارة) | التكثيف (Compaction)؛ إنفاق "ميزانية الانتباه" بحكمة | التلخيص الدوري عبر البرمجيات الوسيطة | ميزنة الرموز/التكلفة؛ "هرم السياق" |
| العزل (فصل نوافذ نظيفة) | معماريات الوكلاء الفرعيين التي تعيد ملخصات مكثفة | حدود دورة الحياة والوكلاء الفرعيون | التسليمات والبروتوكولات (مثل MCP) |
إن كنت قد قرأت هذه المصادر وشعرت بأنها تتعارض، فهذا هو السبب: إنها تصف نفس الحركات الأربع من زوايا مختلفة. اختر أي مصطلحات تناسب مجموعتك التقنية — العمليات هي ما يهم.
هندسة السياق لأنظمة الوكلاء المتعددة
في أنظمة الوكلاء المتعددة، تتحول هندسة السياق إلى مشكلة تنسيق: كل وكيل يحتاج سياقًا كافيًا لأداء عمله، لكن مشاركة الكثير منه تُنشئ ضجيجًا وتكلفة وحالة متناقضة. النمط الغالب هو منسّق (orchestrator) يحمل الخطة عالية المستوى ويفوّض مهام فرعية محددة النطاق إلى وكلاء فرعيين متخصصين، كل منهم يعمل في نافذة معزولة.
كل وكيل فرعي يحصل على نافذة نظيفة ومعزولة ويعيد نتيجة مكثفة فقط — مما يمنع التلوث المتبادل.
يعمل هذا بسبب مبدأ "العزل" أعلاه. الوكيل الفرعي المخصص للبحث والذي لا يرى سوى سؤال البحث ونتائجه الخاصة سيتفوق على وكيل يضطر أيضًا لتمشيط السجل غير ذي الصلة لمهمة ترميز وكيل شقيق. ثم يضغط المنسّق مخرجات كل وكيل فرعي إلى النتيجة الأساسية قبل دمجها مرة أخرى في السياق الرئيسي. عند تنفيذ ذلك بشكل جيد، هذه هي الطريقة التي تُشغّل بها الفرق وكلاء على مهام كانت ستفيض عن أي نافذة سياق واحدة عدة مرات.
أنماط الفشل الشائعة في هندسة السياق
معظم فشل الوكلاء يعود إلى حفنة من مشاكل السياق المتكررة. تسميتها يجعلها أسهل في التصميم ضدها:
| نمط الفشل | كيف يبدو | الحل الأساسي |
|---|---|---|
| تسمم السياق (Context poisoning) | هرطقة أو خطأ يدخل السياق ويُشار إليه مرارًا وتكرارًا، مما يضخّم الخطأ | العزل + الكتابة للحقائق الموثقة فقط |
| تشتت السياق (Context distraction) | تنمو النافذة كثيرًا فيصبح النموذج مركّزًا بشكل مفرط على السجل المتراكم ويتوقف عن التفكير في الهدف الفعلي | الضغط |
| ارتباك السياق (Context confusion) | معلومات غير ذات صلة تزدحم النافذة وتضلّل النموذج نحو خيار خاطئ | الاختيار بشكل أضيق |
| تصادم السياق (Context clash) | معلومات مسترجَعة حديثًا تتعارض مع ما هو موجود بالفعل في النافذة، ولا يستطيع النموذج التوفيق بينهما | الاختيار + الكتابة لمصدر واحد للحقيقة |
التقنيات الأربع الأساسية هي الترياق: الكتابة للتخفيف، الاختيار للبقاء ذا صلة، الضغط لتقليل الفوضى، والعزل لمنع التلوث المتبادل.
نمط فشل واحد نادرًا ما تتناوله الأدلة الشهيرة هو نمط أمني: حقن التوجيهات عبر السياق المسترجَع (prompt injection). عندما يستحضر الوكيل صفحة ويب، أو وثيقة، أو نتيجة أداة، قد يحتوي هذا المحتوى على تعليمات مصمّمة لاختراق الوكيل. تعامل مع كل ما تختاره لإدخاله في النافذة كإدخال غير موثوق — احتفظ بالبيانات المسترجَعة منفصلة عن التعليمات النظامية، ونفّذ الأدوات في بيئة معزولة (sandbox) بدلًا من تنفيذها مباشرة على جهاز موثوق.
كيف تقيس ما إذا كانت هندسة السياق تعمل
تقيس هندسة السياق بتتبع نجاح المهمة مقابل الرموز والوقت المستغرق للوصول إليه — هندسة السياق الجيدة ترفع معدل النجاح مع الحفاظ على التكلفة أو خفضها. تصف معظم الأدلة التقنيات لكنها لا تخبرك كيف تعرف إذا كانت تعمل؛ هذه هي المقاييس التي تغلق تلك الثغرة.
- معدل نجاح المهمة — نسبة عمليات التشغيل التي تصل إلى نتيجة صحيحة وكاملة. هذا هو مقياس النتيجة؛ كل ما عداه هو وسيلة للوصول إليه. تتبعه على مجموعة تقييم ثابتة من مهام تمثيلية بحيث يمكنك المقارنة قبل وبعد كل تغيير.
- كفاءة السياق (الرموز لكل مهمة ناجحة) — إجمالي الرموز المستهلكة مقسومًا على عدد المهام المكتملة بنجاح. انخفاض عدد الرموز لكل نجاح هو الإشارة الأوضح على أن الضغط والاختيار يؤتيان ثمارهما.
- استخدام النافذة — إلى أي مدى تكون نافذة السياق ممتلئة خلال المهمة. القرب المستمر من الحد الأقصى يتنبأ بتعفن السياق؛ وهو مؤشر مبكر يدل على حاجتك للضغط أو العزل.
- دقة واستدعاء الاسترجاع — من بين العناصر التي اخترتها لإدخالها في النافذة، كم منها كان ذا صلة فعلاً (الدقة)، ومن بين العناصر ذات الصلة المتاحة، كم منها استحضرته (الاستدعاء). ضعف الدقة يعني أنك تضيف ضجيجًا؛ وضعف الاستدعاء يعني أنك تُجوّع النموذج.
- الكمون والتكلفة لكل مهمة — السقف العملي. الاستكشاف "في الوقت المناسب" العدواني قد يحسّن الدقة لكنه يبطئ الوكيل؛ هذا المقياس يحافظ على صدق هذه المفاضلة.
الانضباط الذي يربط هذه المقاييس معًا هو اختبار الانحدار (regression testing): احتفظ بمجموعة مهام ثابتة، شغّلها بعد كل تغيير في التوجيهات، أو الاسترجاع، أو الذاكرة، وتابع تحرك الأرقام. هندسة السياق بدون حلقة تقييم هي تخمين محض.
كيف تطبّق Happycapy هندسة السياق
Happycapy هو حاسوب أصلي للوكلاء (agent-native) يُشغّل وكلاء الذكاء الاصطناعي — بما في ذلك Claude Code — مباشرة في متصفحك، وهندسة السياق مدمجة في طريقة عمل هؤلاء الوكلاء بدلًا من أن تُترك للمستخدم. ثلاثة خيارات تصميمية تقوم بمعظم العمل:
- المهارات (Skills) كسياق محدد النطاق. بدلًا من تفريغ كل قدرة في توجيهة واحدة، يتيح Happycapy للوكيل استحضار مهارة محددة — تصميم عرض تقديمي، تحليل جدول بيانات، إجراء بحث على الويب — بحيث تدخل فقط التعليمات والأدوات ذات الصلة إلى النافذة لتلك المهمة. هذا هو تطبيق مبدأي "الاختيار" و"العزل" بشكل تلقائي.
- بيئة معزولة دائمة مع ذاكرة وملفات. يعمل كل وكيل في مساحة عمل معزولة يمكنه فيها كتابة الخطط، والنتائج الوسيطة، والملاحظات إلى القرص واستحضارها لاحقًا — مبدأ "الكتابة"، بحيث يبقى التقدم محفوظًا بعد نافذة سياق واحدة.
- الوصول إلى أكثر من 150 نموذجًا. لكل خطوة احتياجات سياق مختلفة؛ وتوجيه العمل إلى النموذج المناسب هو بحد ذاته قرار في هندسة السياق.
النتيجة العملية هي أنه يمكنك تسليم مهمة طويلة ومتعددة الخطوات وترك الوكيل يدير سياقه الخاص في الخلفية، ثم تستلم النتيجة النهائية — دون ضبط التوجيهات يدويًا أو الإشراف على النافذة بنفسك.
البدء في هندسة السياق
لست بحاجة لإعادة بناء مجموعتك التقنية للبدء. ابدأ بأعلى العادات تأثيرًا:
- تعامل مع نافذة السياق كميزانية. قبل إضافة أي شيء، اسأل إن كان يستحق رموزه.
- انقل الحالة خارج التوجيهة. استخدم الملفات، أو المذكرات المساعدة، أو مخزن ذاكرة لأي شيء يحتاج الوكيل للاحتفاظ به.
- استرجع بشكل ضيق. اسحب الحقائق المحددة التي تحتاجها خطوة ما، لا وثائق كاملة.
- لخّص أثناء العمل. استبدل السجلات الطويلة ومخرجات الأدوات المطوّلة بملخصات مكثفة.
- اعزل المهام الفرعية. أعطِ كل عمل مستقل سياقه النظيف الخاص، خاصة في إعدادات الوكلاء المتعددة.
إن كنت تفضّل عدم ضبط أي من ذلك يدويًا، فإن Happycapy يُشغّل مهامك مع هذه الأنماط المدمجة فعلًا في الوكيل: فهو يدير نافذة سياقه الخاصة في الخلفية — يختار ويضغط ويعزل أثناء العمل — بحيث تصف النتيجة المرجوة فقط دون أن تلمس ميزانية الرموز بنفسك أبدًا.
أسئلة متكررة
س: هل هندسة السياق هي نفسها هندسة التوجيهات؟
لا. هندسة التوجيهات تُحسّن تعليمة واحدة؛ بينما هندسة السياق تدير بيئة المعلومات الكاملة التي يراها الوكيل عبر مهمة متعددة الخطوات — التعليمات، والأدوات، والبيانات المسترجَعة، والذاكرة، والسجل. هندسة التوجيهات هي جزء واحد من هندسة السياق.
س: لماذا تعتبر هندسة السياق مهمة خصيصًا لوكلاء الذكاء الاصطناعي؟
لأن الوكلاء يعملون لخطوات كثيرة، ويستدعون الأدوات، ويتراكم لديهم سجل، تمتلئ نافذة سياقهم بسرعة. وبدون إدارة نشطة، تزدحم الرموز غير ذات الصلة على حساب الإشارة وتتراجع قرارات الوكيل — مشكلة تُعرف بتعفن السياق. هندسة السياق تحافظ على تركيز النافذة على ما يهم.
س: ما هي التقنيات الأساسية لهندسة السياق؟
التقنيات الأربع الأساسية هي الكتابة (حفظ السياق خارج النافذة)، والاختيار (استرجاع فقط ما هو ذو صلة الآن)، والضغط (التلخيص لتوفير الرموز)، والعزل (إعطاء المهام الفرعية سياقها النظيف الخاص). معظم العمل العملي هو مزيج من هذه التقنيات.
س: هل هندسة السياق مهارة تستحق التعلم في 2026؟
نعم. مع بناء برمجيات أكثر على LLM والوكلاء المستقلين، تصبح القدرة على إدارة السياق بشكل جيد كفاءة أساسية للمطورين، ومصممي التوجيهات، وفرق منتجات الذكاء الاصطناعي — وهي بشكل متزايد الفرق بين وكيل يعمل بنجاح ووكيل لا يعمل.
س: كيف تقيس إن كانت هندسة السياق تعمل؟
تتبع معدل نجاح المهمة على مجموعة تقييم، بالإضافة إلى مقاييس الكفاءة: الرموز لكل مهمة ناجحة، استخدام نافذة السياق، دقة واستدعاء الاسترجاع، والكمون/التكلفة لكل مهمة. هندسة السياق الجيدة تزيد معدل النجاح مع الحفاظ على التكلفة أو خفضها. شغّل المجموعة بعد كل تغيير حتى ترى إن كان التعديل قد ساعد أو أضرّ.
س: هل أحتاج للقيام بهندسة السياق بنفسي لاستخدام وكلاء الذكاء الاصطناعي؟
ليس بالضرورة. منصات الوكلاء مثل Happycapy تبني إدارة السياق داخل النظام — بتحديد نطاق السياق عبر المهارات، وحفظ الحالة في بيئة معزولة، وعزل المهام الفرعية — بحيث يمكنك تشغيل عمل متعدد الخطوات دون ضبط نافذة السياق يدويًا.
