ذاكرة الوكيل المحمولة: احتفظ بالسياق عبر Claude Code وCursor وCodex وGemini

انتقل من Claude Code إلى Cursor في منتصف المشروع وسينسى وكيلك كل شيء: قرار البنية الذي اتخذته الأسبوع الماضي، والخطأ الذي أصلحته بالفعل، والطريقة التي تفضّل بها كتابة commits. لم ينتقل السياق — بل بقي محاصرًا داخل الأداة الأولى. الذاكرة المحمولة للوكيل هي النمط الذي يحل هذه المشكلة: طبقة ذاكرة واحدة يشاركها وكلاؤك، بحيث يتبعك السياق عبر Claude Code وCursor وCodex وGemini CLI بدلًا من البدء من الصفر في كل مرة تبدّل فيها الأدوات.

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

ما هي الذاكرة المحمولة للوكيل؟

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

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

تعني المحمولية شيئين:

• متعددة الأدوات: تعمل الذاكرة ذاتها في Claude Code وCodex وCursor وGemini CLI وأي شيء آخر يمكنه قراءتها.
• بلا ارتباط بمزود: يمكنك مغادرة أداة — أو طبقة الذاكرة ذاتها — دون إعادة بناء معرفتك.

لماذا يتعطل السياق عند التبديل

يخزّن كل وكيل الذاكرة بتنسيقه وموقعه الخاص. لدى Claude Code نظام ذاكرة واحد؛ ولدى Cursor نظام آخر. عندما تعرف وكلاء مختلفون أشياء مختلفة، تُعيد الجلسة التالية طرح سؤال أجبت عنه بالفعل، أو تكرر خطأً ارتكبته من قبل.

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

الأساليب الرئيسية للذاكرة المحمولة

ثمة ثلاثة أنماط واسعة مستخدمة اليوم. تختلف أساسًا في كيفية تخزين السياق وكيفية الاتصال بالوكلاء.

1. خوادم الذاكرة المستندة إلى MCP

يربط الأسلوب الأكثر شيوعًا خادم ذاكرة بكل وكيل عبر بروتوكول سياق النموذج (MCP). يمنح MCP أي أداة طريقة قياسية للاتصال بأي وكيل، بحيث يمكن لطبقة ذاكرة واحدة خدمة عملاء كثيرين عبر البروتوكول ذاته.

تسلك مشاريع مفتوحة المصدر مثل agentmemory وMemorix هذا المسار. يصف agentmemory نفسه بأنه ذاكرة دائمة لـ Claude Code وCursor وGemini CLI وCodex CLI وأي عميل MCP، مثبَّت عالميًا ومسجَّل كخادم MCP. أما Memorix فهو طبقة ذاكرة مشتركة تُعطي الأولوية للتخزين المحلي وتحتفظ بذاكرة المشروع تحت مشروع Git بدلًا من داخل نافذة دردشة أو أداة واحدة.

الفائدة: اضبطه مرة واحدة، وسيرى كل وكيل قادر على MCP الذاكرة ذاتها. المقايضة هي خدمة قيد التشغيل واعتماد على دعم MCP في كل عميل.

2. خزائن الملفات المسطّحة المحايدة من حيث المزود

يتجاوز أسلوب أخف قواعد البيانات والخوادم كليًا. Agent Memory OS هو نظام ذاكرة محمول مبني من ملفات Markdown عادية وعدد قليل من السكريبتات الصغيرة، بلا قاعدة بيانات ولا خدمة للتشغيل. يعمل مع Claude Code وCodex وGemini CLI وCursor أو أي شيء آخر يمكنه قراءة الملفات، ويحتفظ بملف هوية محايد من حيث المزود بشكل متعمد حتى لا يعني تبديل الأدوات إعادة بناء إعدادك.

الاسترجاع هنا عادةً معجمي — يصنّف موجّه ملاحظات Markdown مقابل استعلامك ويعيد أكثرها صلة — بدلًا من التضمينات. الفائدة هي البساطة والمحمولية وانعدام البنية التحتية. المقايضة هي استدعاء أقل تطورًا من نظام مدعوم بمتجه على قواعد المعرفة الكبيرة.

3. طبقات الذاكرة المستضافة / المدعومة بالبروتوكول

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

الفائدة هي عمل تشغيلي أقل وميزات مدمجة أكثر؛ المقايضة هي الوثوق بخدمة خارجية بسياقك ومراقبة نوع جديد من الارتباط — هذه المرة في طبقة الذاكرة ذاتها.

كيفية الاختيار — وتجنب الارتباط مجددًا

الهدف من المحمولية هو حرية التبديل. حافظ على ذلك:

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

طريقة سريعة لمقارنة الخيارات:

إلى أين يتجه هذا

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

ابنِ سير عمل متعدد الوكلاء يتذكر

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