راجعت ثلاثمئة سجل إخفاق للوكلاء. المشكلة لم تكن في الـ prompt أبدًا.

ثلاثمئة سجل إخفاق للوكلاء. أمضيت أسبوعين أمر عليها واحدًا واحدًا، مصنِّفًا كل حالة حسب السبب الجذري. النتيجة فاجأتني: مشكلات الـ prompt لم تتجاوز نحو 12%. الباقي؟ كان السياق إما ملوثًا، أو فائضًا عن الحد، أو غائبًا كليًا. تبديل النماذج لم يجدِ. تبديل الأدوات لم يجدِ. النمط تكرر في كل مرة.

لقد كنت غارقًا في مجال context engineering منذ فترة، لذا حين ظهر مشروع مفتوح المصدر اسمه Agent Skills for Context Engineering وسرعان ما تجاوز عشرة آلاف نجمة على GitHub، أعرت له اهتمامي. المشروع مرخص بـ MIT، بناه مهندس context يُدعى Muratcan Koylan، واستشهد به مختبر ذكاء اصطناعي في جامعة بكين. هذه النقطة الأخيرة هي ما دفعتني فعليًا إلى استنساخه.

نافذات السياق الأصغر أكثر دقة

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

كلما طال السياق، فقد النموذج القدرة على تتبع ما في منتصفه. هذا ما يُعرف بتأثير المنحنى على شكل U: يقرأ النموذج البداية والنهاية جيدًا، لكنه يتخطى كل ما بينهما. جربت هذا بنفسي: ملأت السياق حتى 128K توكن، ثم ضغطت المعلومات ذاتها إلى 32K. النسخة المضغوطة حققت دقة أعلى.

تكلفة المعالجة لا تتدرج خطيًا مع عدد التوكنات، بل ترتفع بصورة أسية. تقليص السياق إلى النصف خفّض زمن الاستجابة بين 40 و60 بالمئة. حتى مع prefix caching، تظل المدخلات الطويلة مكلفة. الخلاصة في جملة واحدة: المهم هو قدر المعلومات المفيدة التي تضغطها في ميزانية توكن محددة.

أوصاف الأدوات تحدد 80% من أداء الوكيل

يمكنك أن تكتب prompt مثاليًا، لكن إن كانت أوصاف أدواتك مهملة، فسيختار الوكيل الأداة الخطأ. تُعبّر عن هذا المجموعة بصورة دقيقة: “الأدوات عقود يقرأها LLM، لا البشر.” حين بنى فريقي MCP server، أعدنا كتابة أوصاف الأدوات وفق هذا الدليل، فتراجعت أخطاء اختيار الأدوات بشكل ملحوظ.

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

أنظمة الوكلاء المتعددة تحتاج معمارية قبل أن تحتاج وكلاء

توقع أن يتعاون وكلاء متعددون تلقائيًا بمجرد تشغيلهم هو ضرب من التمني. يُعرّف المشروع ثلاثة أنماط بوضوح: المنسق orchestrator الذي يوجّه وكلاء تابعين، والنموذج المتماثل peer-to-peer حيث يتواصل الوكلاء كأنداد، وسلسلة التفويض الهرمية.

بعد تجربة الأنماط الثلاثة في بيئة الإنتاج، وجدت أن نمط المنسق كان الأكثر قابلية للتنبؤ والأسهل في تشخيص الأخطاء. الوكلاء التابعون مرروا النتائج عبر نظام الملفات. نمط peer-to-peer أدى دورًا أفضل في المهام الإبداعية لكنه خاطر بحلقات لانهائية. للاستعلامات المنظمة، الملفات المشتركة تفوقت على vector search. في التطبيق العملي، وجدت أن ثلاثة وكلاء هو السقف الذي يضمن الاستقرار.

البحث الشعاعي وحده لا يستطيع إدارة الذاكرة

يجد vector search جملة من نوع “اشترى العميل X المنتج Y في التاريخ Z” بسهولة. لكنه لا يستطيع الإجابة عن “ماذا اشترى أيضًا العملاء الذين اقتنوا المنتج Y؟” المعلومات العلاقاتية تضيع في الـ embeddings.

تقترح المجموعة معمارية ذاكرة رباعية المستويات: ذاكرة عمل داخل نافذة السياق، وذاكرة قصيرة الأمد خلال الجلسة، وذاكرة طويلة الأمد عبر الجلسات، وذاكرة دائمة كأرشيفات. النمط الذي وجدته أكثر عملية هو استخدام نظام الملفات كذاكرة: تتنقل في السياق بـ ls وgrep بدلًا من استعلامات embedding. تفريغ نتائج الأدوات في ملف scratchpad وفّر مساحة واسعة من نافذة السياق.

التقييم هو المهارة الأكثر إهمالًا في عمل الوكلاء

كان هذا هو القسم الذي كدت أتخطاه، فإذا به الأكثر قيمة. يتضمن المشروع إطار تقييم بـ TypeScript يستخدم LLMs كمحكّمين، بل يُولّد معايير التسجيل تلقائيًا.

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

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

حين يُخطئ وكيلك في شيء ما، افحص السياق قبل أن تُحمّل النموذج المسؤولية. المشروع هنا.