مقدمة

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

ملخص أساسي

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

هندسة السياق (Context Engineering)

كما قال Andrej Karpathy، تعتبر النموذجات اللغوية الكبيرة (LLM) كنوع من “أنظمة التشغيل الجديدة”. إن الـ LLM هي وحدة المعالجة المركزية، بينما تعتبر “نافذة السياق” بمثابة الذاكرة العشوائية RAM، حيث تعمل كذاكرة العمل للنموذج. ومثلما سعة الـ RAM محدودة، تواجه نافذة سياق الـ LLM أيضًا قيودًا بسبب سعة معالجة مصادر السياق المختلفة. واحدة من المهام الأساسية لنظام التشغيل هي إدارة كيفية استخدام ذاكرة وحدة المعالجة المركزية بفعالية، وتلعب “هندسة السياق” دورًا مشابهًا. وقد لخص Karpathy ذلك بشكل ممتاز:

هندسة السياق هي “فن وعلم دقيق لتعبئة نافذة السياق بدقة للخطوة التالية (الحساب).”

عند بناء تطبيقات الـ LLM، أي نوع من السياقات يجب علينا إدارته؟ تغطي فكرة هندسة السياق المفاهيم التالية:

• التعليمات (Instructions) – كلمات الدليل، الذاكرة، أمثلة قليلة، وصف الأدوات، إلخ.
• المعرفة (Knowledge) – الحقائق، الذاكرة، إلخ.
• الأدوات (Tools) – معلومات التغذية المرتدة لاستدعاء الأدوات.

الهندسة السياقية للوكيل الذكي

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

ومع ذلك، فإن المهام طويلة الأمد والتغذيات المرتبطة باستدعاء الأدوات تُشير إلى أن الوكلاء عادةً ما تستهلك كمية كبيرة من الـ token. هذا قد يؤدي إلى العديد من المشاكل: تجاوز قيود سعة نافذة السياق، مما يؤدي إلى زيادة التكاليف والكمون، بل ويقلل من أداء الوكيل. أشار Drew Breunig بوضوح إلى أن السياق الطويل جدًا قد يؤدي إلى مشاكل أداء بعدة طرق:

• تسمم السياق (Context Poisoning): عندما تدخل المعلومات الخاطئة (الأوهام) إلى السياق.
• تشتت السياق (Context Distraction): عندما تكون المعلومات السياقية كثيرة لدرجة أنها تغمر معرفة التدريب الأصلية للنموذج.
• تشويش السياق (Context Confusion): عندما تؤثر المعلومات السياقية غير ذات الصلة على استجابة النموذج.
• تعارض السياق (Context Clash): عندما تتنافى أجزاء مختلفة من السياق مع بعضها البعض.

نظرًا لهذه المشاكل، أكدت شركة Cognition AI على أهمية هندسة السياق:

“هندسة السياق”… في الواقع، هي المهمة الأساسية لمهندسي بناء الوكلاء الذكية.

كما أكدت شركة Anthropic:

يحتاج الوكلاء عادةً إلى إجراء مئات من الدردشات، مما يتطلب منا اعتماد استراتيجيات صارمة لإدارة السياق.

كيف يتعامل مطورو اليوم مع هذه التحديات؟ سأقوم بتلخيص الأساليب الحالية في أربع فئات: **الكتابة (Write)، التصفية (Select)، الضغط (Compress)، والعزل (Isolate)**، وسأقوم بتقديم أمثلة لكل منها.

كتابة السياق (Write Context)

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

مناطق التخزين المؤقت (Scratchpads)

عندما يحل البشر المشكلات، يكتبون الملاحظات ويتذكرون بعض الأمور لاستخدامها لاحقًا في المهام المرتبطة. الوكلاء أيضًا بدأوا في اكتساب هذه القدرة! تُعد كتابة الملاحظات في منطقة التخزين المؤقت، طريقة لاستمرارية المعلومات أثناء أداء الوكيل للمهمة. الفكرة الرئيسية هي حفظ المعلومات خارج نافذة السياق، ولكن يمكن استرجاعها من قبل الوكيل في أي وقت. تقدم أنظمة الأبحاث المتعددة الوكلاء التابعة لشركة Anthropic مثالًا واضحًا على ذلك:

“الباحث الرئيسي” سيبدأ أولًا في التفكير في طرق لحل المشكلة، ويقوم بحفظ خطته في “الذاكرة” لاستدامة السياق، لأن تجاوز نافذة السياق 200,000 توكن قد يؤدي إلى قطعها، مما يجعل الحفاظ على الخطة أمرًا حيويًا.

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

الذاكرة (Memories)

تساعد منطقة التخزين المؤقت الوكيل في حل المهام ضمن جلسة واحدة، لكن في بعض الأحيان يحتاج الوكيل إلى تذكر الأشياء عبر جلسات متعددة. قدم نموذج Reflexion مفهوم التفكير بعد كل دورة من دورة الوكيل، وأعاد استخدام هذه الذكريات الناتجة عن الذات. بينما يستطيع نموذج Generative Agents دمج الذكريات بشكل دوري من مجموعة ردود الوكيل السابقة.

تُستخدم هذه المفاهيم في العديد من المنتجات الشائعة مثل ChatGPT وCursor وWindsurf. لديها آلية لتوليد الذاكرة الطويلة تلقائيًا بناءً على تفاعل المستخدم مع الوكيل.

تصفية السياق (Select Context)

تصفية السياق تعني سحب المعلومات المطلوبة إلى نافذة السياق لمساعدة الوكيل في تنفيذ المهمة.

مناطق التخزين المؤقت (Scratchpads)

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

الذاكرة (Memories)

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

ومن التحديات الكبيرة هو ضمان أن الذكريات المصفاة ذات صلة. يستخدم العديد من الوكلاء الشائعة جزءًا صغيرًا من ملفات ثابتة، تُحمّل دائمًا في السياق. على سبيل المثال، تستخدم العديد من الوكلاء البرمجية الملفات للاحتفاظ بالتعليمات (“ذاكرة برمجية”)، أو في بعض الحالات، للاحتفاظ بالأمثلة (“ذاكرة سياقية”). يستخدم Claude Code ملف CLAUDE.md، بينما تستخدم Cursor وWindsurf ملفات القواعد.

ومع ذلك، إذا خزن الوكيل كمية كبيرة من الحقائق أو العلاقات (مثل نوع “الذاكرة الدلالية”)، تصبح عملية التصفية أكثر صعوبة. يُعتبر ChatGPT مثالًا جيدًا، حيث يخزن ويصفّي من كمية كبيرة من الذكريات الخاصة بالمستخدم.

تعتبر عمليات تضمين المتجهات و/أو الرسوم البيانية المعرفية تقنيات شائعة لفهرسة الذاكرة للمساعدة في التصفية. ومع ذلك، لا تزال التصفية تتسم بالتحديات. في معرض AIEngineer، شارك Simon Willison مثالًا على فشل تصفية الذاكرة: حيث استرجع ChatGPT موقعه من الذاكرة، وأدرجه بشكل غير مقصود في الصورة التي طلبها. هذه الاسترجاعات غير المتوقعه أو غير المرغوب فيها من الذاكرة قد تجعل بعض المستخدمين يشعرون بأن نافذة السياق “لم تعد خاصة بهم”!

الأدوات (Tools)

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

المعرفة (Knowledge)

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

فهرسة الكود بذاتها لا تعني الاسترجاع السياقي… ما نقوم به هو تحليل الكود من خلال AST (شجرة التركيب المجردة) وتقسيمه على حدود ذات معنى دلالي… لكن مع ازدياد حجم مكتبة الكود، يصبح البحث باستخدام تضمين المتجهات كأسلوب استرجاع غير موثوق… نحن مضطرون للاعتماد على مجموعة من التقنيات، مثل grep/البحث في الملفات، واسترجاع البيانات بناءً على الرسوم البيانية المعرفية، بالإضافة إلى… خطوة إعادة ترتيب، حيث يتم تصنيف السياق حسب الصلة.

ضغط السياق (Compress Context)

ضغط السياق يعني الإبقاء فقط على الـ token الضرورية لتنفيذ المهمة.

تلخيص السياق (Context Summarization)

يمكن أن تمتد تفاعلات الوكيل عبر مئات الجولات، باستخدام أدوات تستهلك كمية كبيرة من الـ token. يُعتبر التلخيص وسيلة شائعة للتعامل مع هذه التحديات. إذا كنت قد استخدمت Claude Code، فقد شهدت تطبيقه العملي. عندما تتجاوز استخدام نافذة السياق نسبة 95%، يقوم Claude Code بتنفيذ “ضغط تلقائي”، لتلخيص المحاورات الكاملة بين المستخدم والوكيل. يمكن أن يتم هذا التلخيص بطرق متعددة، مثل التلخيص المتكرر أو التلخيص الهيكلي.

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

اقتطاع السياق (Context Trimming)

غالبًا ما يستخدم التلخيص الـ LLM لاستخراج أجزا السياق الأكثر صلة، بينما اقتطاع السياق يميل إلى أن يكون أكثر تخليصًا أو كما أوضح Drew Breunig، “التقليم” للسياق. يمكن تنفيذ ذلك باستخدام قواعد خوارزمية صريحة، مثل إزالة الرسائل القديمة من قائمة الرسائل. أشار Drew أيضًا إلى Provence، وهو مقلم سياقي تم تدريبه على مهام السؤال والجواب.

عزل السياق (Isolating Context)

عزل السياق يعني تقسيم السياق لمساعدة الوكيل على تنفيذ المهمة.

أكثر من وكيل (Multi-agent)

إحدى الطرق الأكثر شيوعًا لعزل السياق هي تقسيمه إلى عدة وكلاء فرعيين. أحد دوافع مكتبة Swarm الخاصة بـ OpenAI هو “فصل النقاط الأساسية”، أي أن فريقًا من الوكلاء يتولى معالجة المهام الفرعية. كل وكيل لديه مجموعة محددة من الأدوات، وتعليمات، ونافذة سياق خاصة به.

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

الوكلاء الفرعيون يعملون بالتوازي، موجهين من خلال سياقاتهم الخاصة، مع استكشاف جوانب مختلفة من المشكلة.

بالطبع، تواجه الوكالات المتعددة تحديات أيضًا، بما في ذلك استهلاك الـ token (على سبيل المثال، يشير تقرير Anthropic إلى أن استخدام الـ token الخاص بهم 15 مرة أكثر من المحادثة)، والحاجة إلى إدارة دقيقة لتحفيز تخطيط الوكلاء الفرعيين، بالإضافة إلى تنسيق العمل بين الوكلاء الفرعيين.

عزل السياق عبر البيئات (Context Isolation with Environments)

يعرض مشروع HuggingFace Deep Research مثالًا مثيرًا آخر لعزل السياق. تستخدم معظم الوكلاء واجهات تطبيقات استدعاء الأدوات، التي تعود بأشياء JSON (معلمات الأدوات)، ثم تُمرر إلى الأدوات (مثل واجهة تطبيق بحث) للحصول على التغذية الراجعة (مثل نتائج البحث). بينما تستخدم HuggingFace وكيل CodeAgent، الذي يخرج مباشرةً بالشيفرة التي تحتوي على استدعاء الأدوات المطلوبة. ثم يتم تشغيل هذه الشيفرة في بيئة صندوق الرمل. السياق المحدد الناتج عن استدعاءات الأدوات فقط هو الذي يعود إلى الـ LLM.

هذا يسمح بعزل السياق عن الـ LLM في البيئة. تشير Hugging Face إلى أنها وسيلة رائعة لعزل الأشياء التي تستهلك كمية كبيرة من الـ token:

يتمكن وكلاء الشيفرة من التعامل بشكل أفضل مع الحالة… تحتاج إلى تخزين الصور/الصوت/بيانات أخرى لاستخدامها لاحقًا؟ لا توجد مشكلة، فقط قم بتخصيصها كمتغير، يمكنك استخدامه لاحقًا.

الحالة (State)

من الجدير بالذكر أن كائن حالة التشغيل للوكيل يعد أيضًا وسيلة جيدة لعزل السياق. يمكن أن يعمل كمثل صندوق الرمل. يمكن تصميم كائن الحالة بنمط (Schema، مثل نموذج Pydantic) يتضمن حقول يمكن كتابتها في السياق. يمكن أن يُظهر حقل في النمط (مثل messages) في كل جولة من التفاعلات للـ LLM، لكن النمط يمكن أن يعزل المعلومات في حقول أخرى لاستخدامها بشكل أكثر انتقائية.

الخاتمة

لا تزال أنماط هندسة سياق الوكيل تتطور باستمرار، لكن يمكننا تلخيص الأساليب الشائعة في أربع فئات: الكتابة، التصفية، الضغط، والعزل:

• كتابة السياق تعني حفظ المعلومات خارج نافذة السياق لاستخدامها أثناء أداء الوكيل للمهمة.
• تصفية السياق تعني سحب المعلومات المطلوبة إلى نافذة السياق لمساعدة الوكيل في تنفيذ المهمة.
• ضغط السياق يعني الإبقاء فقط على الـ token الضرورية لتنفيذ المهمة.
• عزل السياق يعني تقسيم السياق لمساعدة الوكيل على تنفيذ المهمة.

إن فهم واستخدام هذه الأنماط هو عمل أساسي عند بناء وكلاء ذكيين فعالين اليوم.