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

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

نُشر في أغسطس 2026.

TL;DR: هندسة السياق هي منظومة تحديد أي الرموز (tokens) تستحق مكانًا في نافذة سياق الوكيل عند كل خطوة — تعليمات النظام، تعريفات الأدوات، البيانات المُسترجَعة، وسجل المحادثة، كلها تتنافس على المساحة المحدودة نفسها. هندسة التوجيه تسأل كيف أصوغ هذا؛ هندسة السياق تسأل ماذا يحتاج النموذج فعلاً أن يعرفه الآن. نمط الفشل الشائع ليس عادةً قلة السياق — بل زيادته: سجل قديم، مخططات أدوات غير ذات صلة، ومستندات مُسترجَعة لم يطلبها أحد، كل ذلك يُخفّف الإشارة ويرفع التكلفة. أُطبّق ميزانية ثابتة لكل فئة، وأقتطع السجل قبل الهوية، وألخّص قبل أن أقتطع.

قراءة المُشغّل: الوكلاء الأصعب في تصحيح أخطائهم لم يفشلوا لأن النموذج كان ضعيفًا. فشلوا لأنني تركت نافذة السياق تتحول إلى درج مبعثر: ستة مخططات أدوات لم تكن المهمة تحتاجها، سجل محادثة انحرف 40 جولة عن الطلب الأصلي، مستند مُسترجَع كان مرتبطًا تقنيًا لكنه عديم الفائدة عمليًا. إصلاح التوجيه لم يُساعد. إصلاح ما كان أمام التوجيه، ساعد.

هندسة التوجيه منحتك وكيلاً يعمل. هندسة السياق هي ما يُبقيه يعمل بمجرد أن يتعامل مع حجم حقيقي، وسجل حقيقي، وحالات حدّية حقيقية — وهي المهارة التي أُمضي فيها الآن وقتًا أطول من صياغة التوجيه نفسه.

هندسة التوجيه وهندسة السياق ليستا الوظيفة نفسها

التوجيه هو تعليمة واحدة. السياق هو كل ما يراه النموذج عند التصرف بناءً على تلك التعليمة: توجيه النظام، الأدوات التي يمكنه استدعاؤها، ما استرجعتَه أو بحثتَ عنه، ومقدار المحادثة أو سجل التشغيلات السابقة الذي قررتَ حمله معك. هندسة التوجيه تُحسّن صياغة الأول. هندسة السياق تُحسّن تركيبة الأربعة جميعًا.

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

الأربعة أشياء التي تتنافس على المساحة

في كل جولة، تتنافس أربع فئات على المساحة المحدودة نفسها:

1. تعليمات النظام — الهوية، القواعد، تنسيق المخرجات. راجع الطبقات الخمس التي أستخدمها لتوجيهات النظام — هذه هي الفئة الوحيدة التي ينبغي أن تبقى شبه ثابتة، لأن تخزين التوجيه المؤقت (caching) لا يُجدي نفعًا إلا حين لا تتحرك البادئة.
2. تعريفات الأدوات — مخططات كل أداة قد يستدعيها الوكيل في هذه الجولة، سواء احتاجها أم لا.
3. البيانات المُسترجَعة — أي شيء يُستخرَج من قاعدة بيانات، أو مخزن متجهات (vector store)، أو استدعاء API: الذاكرة، المستندات، سجلات العملاء.
4. سجل المحادثة أو التشغيل — ما حدث بالفعل في هذه الجلسة أو هذا التشغيل.

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

الخطأ يكاد يكون دائمًا زيادة، لا نقصًا

عندما يتصرف وكيل بشكل سيئ، الغريزة هي إضافة المزيد من السياق — مزيد من التعليمات، مزيد من الخلفية، مزيد من السجل “احتياطًا”. في تجربتي، هذا غالبًا عكس الصحيح.

مخططات أدوات كثيرة جدًا. رأيتُ وكيلاً يستدعي الأداة الخاطئة لا لأن الصحيحة كانت مفقودة، بل لأنها كانت مدفونة خلف ست أدوات أخرى لم تكن المهمة بحاجة إليها. أرسل فقط الأدوات ذات الصلة بالخطوة الحالية، لا صندوق الأدوات كاملاً في كل استدعاء. طبقة توجيه (routing) تُقرر أي مجموعة فرعية من الأدوات تُعرَض، رخيصة البناء وتُسدّد تكلفتها من أول مرة تمنع فيها استدعاءً خاطئًا.

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

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

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

الميزانية التي أُطبّقها فعلاً

عبر أكثر من 30 وكيلاً في الإنتاج، أُحدّد ميزانية رموز صريحة لكل فئة قبل بناء الوكيل، لا بعد أن يبدأ بالتصرف بشكل سيئ:

ترتيب هذا العمود الأخير هو إطار القرار الحقيقي: السجل أولاً، ثم اتساع الاسترجاع، ثم نطاق الأدوات، وتعليمات النظام أخيرًا. السجل هو الأرخص للضغط دون خسارة الدقة — موجز من جملتين عن “ما حدث في الجولات 1-30” عادةً ما يحمل القيمة التشغيلية نفسها التي يحملها النسخ الكامل. تقليص تعليمات النظام هو الأخطر، لأن هناك يكمن السلوك الفعلي للوكيل.

لخّص قبل أن تقتطع

الاقتطاع (truncation) — إسقاط الجولات الأقدم ببساطة — هو النسخة الخام من هذا. يعمل حتى تحتوي الجولة المُسقَطة على الحقيقة الوحيدة التي احتاجها الوكيل. النمط الأفضل هو الضغط (compaction): قبل إسقاط السجل الخام، اطوِه في موجز مُهيكَل قصير يلتقط القرارات والحقائق، واحتفظ بهذا الموجز بشكل دائم حتى بعد اختفاء الجولات الخام.

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2-3 جمل: ما تقرر، أو حُلّ، أو لا يزال مفتوحًا
  keyFacts: Record<string, string>; // حقائق ثابتة يستحق الاحتفاظ بها حرفيًا
  turnCount: number; // كم عدد الجولات الخام التي يستبدلها هذا الموجز
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // نموذج رخيص يلخّص يكفي دائمًا تقريبًا لهذه الخطوة
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

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

الاسترجاع: نتائج أقل وأكثر صلة تتفوق على نتائج أكثر

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

الافتراضي عندي هو البدء بـ k صغير (2-4) وتوسيعه فقط إذا استطعتُ إظهار، بحالات حقيقية، أن الإجابة مفقودة فعلاً عند هذا الاتساع — لا لأن شبكة أوسع تبدو أكثر أمانًا. إذا كانت جودة الاسترجاع غير متسقة، فالحل عادةً استعلام أفضل أو خطوة إعادة ترتيب (re-ranking)، لا k أكبر.

اربطه بالتكلفة والدقة

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

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

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

خلاصة المُشغّل

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

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

ما هي هندسة السياق لوكلاء الذكاء الاصطناعي؟

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

هل هندسة السياق مختلفة عن هندسة التوجيه؟

نعم. هندسة التوجيه تُحسّن صياغة تعليمة واحدة. هندسة السياق تُحسّن كل شيء آخر يراه النموذج إلى جانب تلك التعليمة — أي الأدوات مُتاحة، وماذا استُرجِع، وكم من السجل يُحمَل معه. توجيه مصاغ جيدًا يفشل رغم ذلك إن كان محاطًا بمخططات أدوات غير ذات صلة أو سجل قديم.

كم من سجل المحادثة ينبغي أن يحتفظ به وكيل الذكاء الاصطناعي؟

أقل مما تظن. نافذة منزلقة محدودة (10-20 جولة حديثة أمر نموذجي) مع موجز مُختصَر لكل ما هو أقدم عادةً ما تتفوق على نسخ خام كامل، لأنها تزيل الضجيج دون خسارة الحقائق المهمة. اضغط قبل إسقاط السجل، ولا تكتفِ بالاقتطاع.

هل تعني نافذة سياق أكبر أنني بحاجة إلى هندسة سياق أقل؟

لا — فهي تُزيل السقف التقني الصارم لكن ليس مشكلة التكلفة أو الضجيج. نافذة أكبر تجعل الإهمال أرخص، لكن كل رمز غير ذي صلة لا يزال يُخفّف الإشارة التي يجب على النموذج معالجتها ولا يزال يُكلّف مالاً في كل طلب لا يكون إصابة تخزين مؤقت. المنظومة مهمة بالقدر نفسه عند 200 ألف رمز كما هي عند 8 آلاف.

ذات صلة: كيف تكتب توجيهات نظام لوكلاء ذكاء اصطناعي لا تفشل في الإنتاج · كيف تُضيف ذاكرة إلى وكيل ذكاء اصطناعي · تخزين التوجيه المؤقت: خفّض تكاليف Claude دون تغيير النموذج · منظومة التقييم التي أستخدمها لإطلاق وكلاء الذكاء الاصطناعي

تحتاج مساعدة في تصميم سياق وذاكرة وكيل لحالتك الاستخدامية؟ تواصل معي — أصمم أنظمة وكلاء الإنتاج لفرق المشغّلين.