الوكلاء بحاجة إلى ذاكرة موثوقة لا إلى السجل الكامل: كيف نبني السياق

عندما حُظر Claude Code فجأة، انتقل صاحب التحليل المنشور على Habr إلى Codex، ليكتشف أمرًا مزعجًا: بقيت الشيفرة على القرص، لكن أشهرًا من النقاشات حول المعمارية والأخطاء والتجارب المستبعدة ظلت عالقة في الأداة القديمة. ومن أصل 25 مشروعًا و53 محادثة، نقلت أداة الاستيراد المدمجة نحو 50 جلسة، مع ربط غير صحيح بالمشاريع. ثم اندلع نقاش في التعليقات، وهو أكثر إثارة للاهتمام من عملية الانتقال نفسها.

كان النقاش يدور حول مهام مختلفة

قال بعضهم: احتفظوا بالقرارات والخطط في Git، فسجل المحادثات عديم القيمة. واقترح آخرون استخدام المهارات (skills)، وقواعد المعرفة، والمواصفات. وذكّر فريق ثالث بأن الحالة الداخلية لاستدلال النموذج لا تنتقل بين مزودي الخدمة. كان الجميع على حق، لكن كل طرف كان يعالج مهمة مختلفة.

المهمة الأولى: منح الوكيل فهمًا محدثًا للمشروع. هنا تكفي ملفات AGENTS.md أو CLAUDE.md، والتوثيق الحديث، وسجلات القرارات المعمارية (ADR)، وخطط العمل، والاختبارات. وفي قواعد الشيفرة الكبيرة، تضاف أدوات للتنقل: فأداة Aider Repo Map، مثلًا، تنشئ خريطة موجزة للمشروع تراعي ميزانية التوكنات. والمهمة الثانية: استعادة الخبرة السابقة، أي ما جُرّب، وما استُبعد، ولماذا. أما الثالثة فهي استئناف عمل انقطع بعد بلوغ الحد المسموح في منتصف الطريق، من دون أن يكتب أحد ملف HANDOFF.md.

لكن Git ليس ذاكرة بحد ذاته. إنه نظام للتحكم في الإصدارات، وتتحدد قيمته بما تضعونه فيه ومدى حداثته.

مثال: خطأ TUN في Windows

يطوّر الكاتب NetRuleRouter، وهو برنامج لتوجيه حركة البيانات. وأثناء تقصي الخطأ 5010 في Windows TUN، اكتشف الوكيل عبر Hansard أن حاسوب TUF المحمول المستخدم للاختبار جهاز Windows منفصل، ويحتوي على نسخة محلية من المستودع. هذه معلومات لا مكان لها في توثيق المعمارية، لكنها توفر الوقت عند تشخيص المشكلات. ويقر الكاتب بصراحة بأنه لم يقس بعد ما إذا كان Hansard قد سرّع إصلاح الخطأ.

ومن الأدوات المشابهة deja-vu، التي تفهرس سجلات وكلاء البرمجة، وتستطيع استعادة العمل غير المكتمل، والبحث عن الجلسات المرتبطة بملف، ووضع علامات على الحلول المستبعدة. أما baton فتنقل الجلسات بين وكلاء سطر الأوامر عندما يعجز الوكيل السابق عن الرد.

الذاكرة لها تكلفة وقد تخطئ

في تجربة مع MemShelf، بلغ حجم الفهرس وملخصات 157 حلقة نحو 36.6 ألف توكن في اليوم الـ38، أي 18.3% من نافذة تضم 200 ألف توكن. وخلال فترة منفصلة مدتها 30 يومًا، لم يجد الكاتب أي استدعاء لأدوات الذاكرة عبر MCP. ولاحظ مطورو kaeru أمرًا مشابهًا بعد دراسة أكثر من 13 ألف ملف سجل: ففي رصد محدود شمل سبع جلسات، لم يفتح الوكلاء الاستدلالات المحفوظة ولو مرة واحدة. العينات صغيرة، لكن المشكلة واضحة: إما أن تبقى الذاكرة عبئًا غير مستخدم، وإما أن تُحقن في السياق بوتيرة مفرطة فتزحمه.

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

ما العمل عمليًا؟

سير العمل المقترح بسيط: العثور على المعلومة، وتحديد حالتها، والتحقق من حداثتها، وتطبيقها والتحقق من النتيجة، ثم توثيق النتيجة.

• تعاملوا مع المحادثة التي عثرتم عليها باعتبارها بيانات عن الماضي، لا تعليمات جديدة.
• حددوا المصدر والتاريخ، وما إذا كانت المعلومة فرضية أم نتيجة مؤكدة أم خيارًا مستبعدًا.
• طابقوها مع الشيفرة الحالية والاختبارات والتوثيق.
• دوّنوا ما تأكدتم منه في خطة أو سجل قرارات معمارية (ADR) أو قاعدة معرفة (KB).

يحفظ الأرشيف شواهد الماضي، بينما تضم قاعدة المعرفة ما يستطيع المشروع الاعتماد عليه الآن. وهذه الأخيرة تتقادم أيضًا، لذا يجب مطابقة المعرفة الحالية مع مصدر مستقل: الشيفرة، أو الاختبارات، أو نتائج التشغيل.

بالنسبة إلى أداة صغيرة، يكفي ملف AGENTS.md والاختبارات، وتكون الرسوم البيانية المعقدة للمواصفات زائدة عن الحاجة. أما في مشروع كبير يعمل فيه عدة وكلاء، فمن المنطقي التفكير في جهة رقابة مستقلة، كما يفعل أحد المعلقين، وفي إضافة مؤشرات للموثوقية إلى السجلات. ولمعرفة ما إذا كانت الذاكرة مفيدة، لا تكتفوا بقياس «عثر على المعلومة أم لم يعثر عليها»، بل قيّموا القدرات التي يتناولها LongMemEval (ICLR 2025): العثور على المعلومات، والربط بين جلسات متعددة، ومراعاة الزمن.

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