هندسة السياق: ما هي وكيف أستخدمها لبناء وكلاء ذكاء اصطناعي أفضل

جدول المحتويات

نُشر في يوليو 2026.

TL;DR: هندسة التحفيز تتعلق باختيار الكلمات؛ هندسة السياق تتعلق بهندسة المعلومات. لديك نافذة سياق محدودة وكل رمز مميز هو مقايضة. أقوم بهيكلة سياق الوكيل في أربع طبقات وأعامل النافذة كميزانية. هذا حسّن الموثوقية أكثر من تبديل النماذج.

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

لا يزال معظم الناس يتحدثون عن “هندسة التحفيز” باعتبارها المهارة الحاسمة للعمل مع الذكاء الاصطناعي. هندسة التحفيز حقيقية ومهمة. لكنها جزء من انضباط أوسع — ومعاملتها باعتبارها العمل بأكمله هو السبب في أن كثيراً من الوكلاء الذين يبدون جيدين في التجريبي ينهارون في الإنتاج.

لماذا أصبحت “هندسة التحفيز” الإطار الخاطئ

“هندسة التحفيز” تعني أن الرافعة الرئيسية هي النص الذي تكتبه في موجّه النظام أو رسالة المستخدم. اقضِ وقتاً كافياً في صياغة التعليمات الصحيحة والصياغة الصحيحة والتنسيق الصحيح، وسيفعل النموذج ما تحتاجه.

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

• تاريخ المحادثة (ما حدث في الأدوار السابقة)
• المستندات أو البيانات التي استرجعتها وحقنتها
• نتائج استدعاءات الأدوات التي رآها النموذج حتى الآن
• عدد الرموز المميزة وموضع كل قطعة معلومات

إذا كنت تفكر فقط في صياغة التحفيز وتتجاهل بقية ما يملأ نافذة السياق، فأنت تُحسّن إدخالاً واحداً بينما تترك الآخرين غير مُدارين. لهذا فإن “هندسة السياق” هي الإطار الأكثر دقة للعمل الجاد مع الوكلاء.

ما هي هندسة السياق في الحقيقة

هندسة السياق هي انضباط تحديد أي المعلومات تدخل نافذة سياق النموذج، وبأي ترتيب، وفي أي نقطة من المحادثة.

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

هندسة السياق هي ممارسة التعامل مع تلك النافذة كمورد يُدار بشكل متعمد:

• ماذا يحتاج النموذج أن يعرف لإكمال هذه الخطوة؟
• ماذا كان يحتاج أن يعرف في خطوة سابقة لكنه لم يعد يحتاجه؟
• ما الثابت عبر تشغيلات مقابل ما هو ديناميكي لكل طلب؟
• أين في النافذة يجب أن تظهر كل معلومة؟

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

الطبقات الأربع التي أصمّمها

كل وكيل أبنيه لديه أربع طبقات سياق مختلفة. أفكر في كل منها بشكل منفصل.

الطبقة 1: موجّه النظام

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

الخطأ الذي يرتكبه معظم الناس هنا هو كتابة موجّه النظام مرة واحدة واعتباره منتهياً. في الممارسة العملية، يحتاج موجّه النظام إلى الإجابة بوضوح على ثلاثة أسئلة:

1. لماذا هذا الوكيل؟ (يحتاج النموذج إلى نطاق محدد، لا مهمة مبهمة.)
2. ماذا يجب أن يفعل عندما يكون الإدخال غامضاً أو غير مكتمل؟
3. ما الذي لا يجب أن يفعله أبداً؟ (القيود السلبية مهمة.)

احتفظ بموجّه النظام في حدوده الدنيا. كل جملة غير ضرورية هي عبء يتنافس مع المحتوى الديناميكي حيث يحدث التفكير الحقيقي.

نصيحة عملية: إذا كنت تستخدم Claude مع واجهة برمجة التطبيقات، استخدم cache_control على موجّه نظامك. موجّه نظام كبير ومستقر مخزّن مؤقتاً يكلف ما يقارب 10% مما يكلفه غير المخزّن لكل دور.

الطبقة 2: تاريخ المحادثة

في وكيل متعدد الأدوار، تاريخ المحادثة ديناميكي ويتزايد مع كل دور. بدون إدارة، يصبح أكبر محرك لتضخم السياق.

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

ما أفعله:

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

الطبقة 3: المحتوى المسترجع

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

مبدآن أطبّقهما:

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

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

الطبقة 4: مخرجات الأدوات

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

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

ميزانية السياق: ما يُدرَج وما يُحذف

أستخدم نموذجاً ذهنياً بسيطاً: نافذة السياق ميزانية وكل رمز مميز إنفاق. قبل كل دور وكيل، أسأل:

• ما الذي يحتاج النموذج معرفته الآن لأداء هذه الخطوة؟
• ما الذي يمكنني حذفه أو تلخيصه دون فقدان شيء مهم؟
• ما الذي مكرّر عبر الطبقات؟

الهدف هو ملء النافذة بـأعلى إشارة معلومات ممكنة في كل خطوة، لا أن أكون شاملاً.

ثلاثة أخطاء في هندسة السياق ارتكبتها في الإنتاج

1. الطوابع الزمنية العائمة في البادئة الثابتة. كنت أضع التاريخ الحالي: {{التاريخ}} في أعلى موجّه النظام. يتغير ذلك النص كل يوم، مما أبطل ذاكرة التخزين المؤقت بصمت كل 24 ساعة. انقل المعلومات المتغيرة — الطوابع الزمنية، معرّفات المستخدم — إلى نهاية السياق، بعد البادئة الثابتة.

2. معاملة مخرجات الأدوات كإضافة فحسب. كنت أشغّل حلقات وكيلية حيث تبقى كل نتيجة استدعاء أداة في السياق. في الدور الثامن، كان النموذج يستدل من سياق 80% منه مخرجات أدوات قديمة.

3. تخطي التقييم عند تغيير السياق. تغييرات السياق هي تغييرات في سلوك النموذج. أشغّل الآن نفس إطار التقييم على تغييرات السياق كما أفعل على تغييرات التحفيز.

سير عملي في هندسة السياق عملياً

قبل كتابة سطر واحد من كود الوكيل، أرسم الطبقات:

موجّه النظام:         ~500 رمز مميز، ثابت، مخزّن مؤقتاً
ميزانية التاريخ:       ~2000 رمز مميز كحد أقصى، مُلخَّص بعد كل خطوة
السياق المسترجع:       ~1000-3000 رمز مميز لكل خطوة، الأجزاء ذات الصلة فقط
ميزانية المخرجات:      الخطوة الحالية فقط، مُلخَّص للأمام

سؤال اختيار النموذج يأتي بعد ذلك. بمجرد معرفة هندسة السياق التي أحتاج، أختار النموذج الأرخص الذي يحافظ على مستوى الموثوقية في ظل تكوين السياق الصحيح.

الأسئلة الشائعة

ما الفرق بين هندسة التحفيز وهندسة السياق؟

هندسة التحفيز تركّز على صياغة موجّه نظامك ورسائل المستخدم. هندسة السياق هي الانضباط الأوسع: تحديد أي المعلومات تدخل نافذة السياق الكاملة — بما فيها تاريخ المحادثة والبيانات المسترجعة ومخرجات الأدوات — وبأي ترتيب وبأي تكلفة من الرموز المميزة.

ما حجم موجّه النظام المثالي؟

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

هل هندسة السياق أكثر أهمية لبعض النماذج من غيرها؟

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

كيف أعرف إذا كانت هندسة السياق تعمل؟

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

هل يجب دائماً ضغط التاريخ أو تلخيصه؟

للوكلاء المعاملاتية القصيرة: لا. للوكلاء متعددة الأدوار التي تُجري أكثر من 5-6 تبادلات: نعم، دائماً. القاعدة التجريبية التي أستخدمها — بمجرد أن تتجاوز ميزانية التاريخ 30% من إجمالي ميزانية السياق، أبدأ التلخيص.