مطوّر ينقل سياق وكيل الذكاء الاصطناعي من المحادثات إلى المستودع: أداة doubled-graph

عندما تستبدل Claude Code بـ Codex أو بأداة أخرى، فإن أول فكرة تخطر لك: كيف أنقل سجل المحادثات. يرى كاتب هذا التحليل على Habr أن هذا هو السؤال الخاطئ. فمنذ ستة أشهر يحتفظ بسياق المشروع لا في المحادثات بل في المستودع، ويقول إن تغيير الوكيل لم يعد مؤلماً.

لماذا يُعدّ سجل المحادثات ذاكرة سيئة

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

وهناك عيب ثانٍ. فاستعادة السياق تتحول إلى ضريبة تُدفع في كل جلسة جديدة. وكلما تغيرت الأداة، سيكون عليك جمع المعرفة من جديد ومعرفة أي الرسائل المتناقضة كانت الأخيرة.

يقترح المؤلف اختباراً بسيطاً لقابلية النقل. افتح المستودع في وكيل لم يرَ المشروع من قبل، وأعطه موجّهاً واحداً: «اقرأ ما هنا وأخبرني كيف بُني المشروع وما الذي يجري فيه الآن». فإن كانت الإجابة دقيقة، فالسياق يعيش فعلاً في المستودع.

ما الذي يوجد في المستودع

الأساس هو منهجية GRACE من osovv (رخصة MIT): يُحفظ التصميم المقصود وحدود الوحدات وعمليات التحقق بجوار الشيفرة. وأضاف المؤلف ثلاثة أشياء: سيناريو لترحيل الشيفرة القائمة، ورسم استدعاءات بياني عبر CodeGraphContext، وغلاف MCP. ومعاً تشكّل هذه الأشياء أداة doubled-graph.

تُوسم الشيفرة بتعليقات-مراسٍ مزدوجة. فللوحدة MODULE_CONTRACT يحدد الغرض والنطاق والتبعيات، وللدالة CONTRACT يحدد المدخلات والمخرجات والآثار الجانبية، وتُقسَّم المنطقية إلى كتل. ويربط الحقل LINKS الملف بالوحدة، بحيث يعطي أمر grep العادي على معرّف مثل M-AUTH-VALIDATE الوكيلَ فقرتين لازمتين بدلاً من أربعين ملفاً. ويتحقق المدقق من تزاوج المراسي وتفرّدها ومطابقتها للصادرات الفعلية.

وهناك رسمان بيانيان. يصف declared التصميم المقصود ويوجد في .grace/graph/. أما computed فيُبنى من AST ويُظهر الواقع: من يستدعي من. وتقارن الأداة detect_changes بينهما وتجد التباينات: شيفرة بلا وحدة، ووحدة بلا شيفرة، وتبعيات قديمة، ووحدة بلا تحقق، وملف بلا وسم. ويحدّث خُطّاف post-commit الرسم computed، ويمكن ربط detect_changes بـ pre-commit أو CI. وقبل التعديل يسأل الوكيل أيضاً عمّا سيتأثر بالتغيير.

ترحيل المشاريع القديمة

تموت منهجيات «المواصفات أولاً ثم الشيفرة» عادةً في مشروع عمره عقد، لا توجد فيه مواصفات لكن الشيفرة تعمل. لذلك هناك وضعان. في migration تكون الحقيقة في الشيفرة: يستعيد الوكيل التصميم المقصود ويوسم الملفات ويمر ببوابات موافقة بشرية. وفي post_migration تكون الحقيقة في المخرجات، وأي تباين مشبوه. عندها توجد ثلاثة مخارج: تحديث المخرَج عبر حزمة تغييرات، أو إرجاع الشيفرة إلى العقد، أو تسجيل التباين في DRIFT.md وحظر الوحدة.

وثمة فكرة مستقلة هي belief-state. ففي النقاط الحرجة يكتب الوكيل في السجل أي افتراض غير بديهي اعتمده، مع المرساة وsession_id. وحين يصل بعد أشهر سجل من بيئة الإنتاج، يمكن استعادة حالة الذكاء الاصطناعي في ذلك الموضع.

القيود والخلاصة

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

لكن الفكرة جديرة بالاهتمام حتى دون المنهجية الكاملة. فإذا كنت تعمل مع عدة وكلاء، فانقل إلى المستودع على الأقل عقود الوحدات ورسم التبعيات البياني وقائمة عمليات التحقق، ودع CI يرصد التباينات مع الشيفرة. والتحقق من النتيجة سهل: أعطِ وكيلاً جديداً ذلك الموجّه الواحد نفسه. للتجربة: pipx install doubled-graph، ثم doubled-graph setup والموجّه الابتدائي من المجلد prompts.