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

تبدأ بتنفيذ ميزة في Claude Code. تتوقف عند خطأ في الأنواع معقّد، فتسلّم المستودع نفسه إلى Codex، لأنه أكثر قدرة على هذا النوع من العمل الشاق. يصلح Codex الخطأ، لكنه الآن لا يعرف شيئًا عن الغرض من الميزة، ولا عن الملفات التي اتفقتم مسبقًا على عدم المساس بها، ولا عن معنى «الانتهاء» هنا. تعيد شرح الأمر برمّته من ذاكرتك. وبعد عشر دقائق تعود إلى Claude Code، وقد نسي هو أيضًا. تقدّم الكود إلى الأمام، لكن السياق لم يتقدّم.

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

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

لماذا لا ينتقل السياق بين الوكلاء

يعيش سياق مهمة برمجية في ثلاثة أماكن، وواحد فقط منها قابل للنقل.

الأول هو ملف التعليمات: CLAUDE.md وAGENTS.md وGEMINI.md. قواعد ثابتة، وأعراف، وأوامر تشغيل الاختبارات. والثاني هو حالة الجلسة: سجل ما قلته أنت والوكيل للتو، وما جرّبه، وما استبعده. والثالث هو المخرج نفسه، أي الفرق في الكود على القرص أو الفرع.

الثالث وحده ينتقل مجانًا. يمكن لوكيل مختلف أن يقرأ الكود، لكنه لا يستطيع قراءة محادثة لم يكن طرفًا فيها، ولن يقرأ ملف تعليمات موجّهًا إلى أداة أخرى. وهذا هو الحدّ الذي يستحق أن نقوله بوضوح: التبديل بين الوكلاء يحفظ الكود ويُسقط التعليل. يبقى الـ commit. أما «السبب» فكان في ذاكرة مؤقتة رآها وكيل ولن يراها التالي أبدًا.

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

اجعل القواعد الثابتة ملفًا واحدًا يقرأه كل وكيل

ابدأ بالمكسب السهل. يقرأ Claude Code ملف CLAUDE.md، ويقرأ Codex ملف AGENTS.md، ويقرأ Gemini CLI ملف GEMINI.md. المهمة نفسها، وثلاثة أسماء ملفات. وإن أبقيتها منفصلة، فإنها تنحرف، ويصبح الوكيل الذي انتقلت إليه متّبعًا لقواعد قديمة بينما تظن أنت أنه ليس كذلك.

اكتب القواعد مرة واحدة، ووجّه أسماء الملفات الأخرى إليها. على macOS أو Linux:

# AGENTS.md is the source of truth; the others are aliases
ln -s AGENTS.md CLAUDE.md
ln -s AGENTS.md GEMINI.md
git add AGENTS.md CLAUDE.md GEMINI.md

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

نمط الفشل الذي يجب الحذر منه: وضع تفاصيل خاصة بمهمة معيّنة في هذه الملفات. فملف التعليمات مخصص للقواعد الصحيحة عبر كل مهمة في المستودع. «نستخدم Vitest، لا Jest» مكانه هنا. أما «أكمل منطق إعادة المحاولة في الدفع ولا تلمس middleware المصادقة» فليس مكانه هنا؛ فهو صحيح لمهمة واحدة هذا الأسبوع وخاطئ في الأسبوع التالي. والخلط بين الاثنين يعني أن كل وكيل يقرأ تعليمات كانت مخصصة لعمل تم تسليمه بالفعل.

انقل سياق العمل، لا القواعد فحسب

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

الحل اليدوي هو مذكرة تسليم. قبل أن تبدّل الوكلاء، اطلب من الوكيل الحالي أن يكتب موقعه: الهدف، والملفات التي غيّرها، وما تحقق منه، والشيء الوحيد الذي لم يكن متأكدًا منه. الصق ذلك في الوكيل التالي كأول رسالة. إنه ينجح، ويكفي لتبديل واحد. والنمط يستحق الاستيعاب بحد ذاته؛ وشكل المذكرة الجيدة مشمول في قوالب تسليم الوكيل.

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

حيث يتوقف الحل اليدوي عن التوسع

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

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

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

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

قائمة التحقق التي يمكنك تنفيذها اليوم

امضِ في هذا بالترتيب. العناصر الثلاثة الأولى لا تكلّف شيئًا؛ والرابع هو ما تتخرّج إليه عندما تتوقف الثلاثة الأولى عن مجاراتك.

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

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