raise: تبديل ذري لملفات تعريف تكوين وكلاء الذكاء الاصطناعي

الاسم نطق صوتي. Raise. Rice-aise. بأي حال، هي الأداة التي حلّت مشكلة انجراف التكوين التي كانت تُبطّئني بشكل صامت كل أسبوع لأشهر قبل أن أعترف أنها مشكلة.

لماذا توجد

أنا استشاري. هذا يعني عملاء مختلفين وقواعد كود مختلفة ونوافذ سياق مختلفة - وتكوينات وكلاء مختلفة بشكل حرج. يحتاج الـsystem prompt لـClaude Code الخاص بعميلي في البنية التحتية معرفة تخطيط Terraform الخاص بهم واصطلاحات التسمية وعملية PR. نفسه لشركة ناشئة منتج يبدو مختلفاً تماماً. Gemini CLI له صيغة تكوين منفصلة. Codex لديه آخر. OpenCode لديه آخر. Pi لديه آخر.

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

الحل الانضباطي - “كن أكثر حرصاً فقط” - لا يتراكم. كنت أحتاج الحل الأدواتي.

كيف يعمل

raise ملف Go ثنائي واحد. يقرأ دليلاً من ملفات تعريف مسمّاة، حيث كل ملف تعريف هو شجرة دليل تعكس مواقع التكوين للأدوات التي تريد إدارتها. حين تُشغّل raise use <profile>، ينفّذ تبديلات symlink ذرية عبر كل موقع أداة مُهيّأ في آنٍ واحد.

“ذري” هي الكلمة المفتاحية. النهج القديم لهذه المشكلة - “اكتب script shell يُنسخ ملفات” - لديه نافذة فشل. إن أخطأ الـscript في المنتصف، أنت في حالة هجينة حيث بعض الأدوات لديها التكوين الجديد وبعضها لديها القديم. هذا أسوأ من أي من الحالتَين النظيفتَين. تستخدم raise روابط symlink بدلاً من النسخ وتُبدّل الهدف في استدعاء syscall rename(2) واحد لكل موقع، وهو بقدر ما يمكنك الحصول عليه من ذرية على نظام ملفات POSIX.

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

دعم سبع عشرة أداة تطلّب مراجعة سبعة عشر اصطلاح تكوين مختلف. بعض الأدوات تستخدم ~/.config/<tool>/config.json. بعضها يستخدم ~/.toolrc. بعضها لديه دليل، بعضها ملف واحد، بعضها لديهما معاً وكل منهما يعني شيئاً مختلفاً. سجل الأدوات في raise يشفّر هذا لكل أداة - أين يعيش التكوين وما صيغته وأي الحقول بيانات اعتماد. إضافة أداة جديدة هي ثلاثة إضافات للسجل وثبتة fixture.

ما الذي يثير الاهتمام

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

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

الاسم جاء من محادثة حول مفهوم هندسة الـprompt لـ”رفع الحد الأدنى” لمخرجات الوكيل. ملف التعريف الخاطئ للسياق يخفض الحد الأدنى بشكل نشط. raise يبقيه حيث ينتمي.

ما الذي كنت سأغيّره

بيان بيانات الاعتماد يُصان يدوياً حالياً. أريد معالج تشغيل أول يفحص ملفات التكوين الموجودة لديك، ويُحدّد القيم التي تشبه بيانات الاعتماد (أنماط مفاتيح API وصيغ الرمز وسلاسل bearer)، ويقترح بياناً تلقائياً. المعلومات موجودة؛ تتطلب فقط قراءة واستدلالات.

أريد أيضاً أمر raise diff <profile-a> <profile-b>. الآن عليك مراجعة أدلة ملفات التعريف بنفسك. فرق منظَّم يُبرز تغييرات system-prompt بشكل منفصل عن تغييرات إعدادات الأداة سيجعل تدقيق ملفات التعريف أسرع بكثير، خاصة حين لم تلمس تعاقداً مع عميل لأسابيع ولا تتذكر بالضبط ما هيّأته.

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