كيف بنيت مساعد كود شخصي باستخدام LiteLLM؟

دراسة حالة تقنية شاملة تشرح كيفية بناء مساعد كود شخصي محلي وخفيف باستخدام LiteLLM لتوحيد نماذج Gemini و Claude داخل VS Code بدون استهلاك موارد الجهاز.

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

قررت أن آخذ خطوة للوراء وأبني مساعد الكود الشخصي الخاص بي، بيئة موحدة Model Agnostic لا تعتمد على مزود واحد، وتعمل مباشرة من داخل محررات الأكواد التي أفضلها مثل OpenCode و VS Code. الأهم من ذلك؟ أن تعمل هذه البيئة بخفة متناهية وبدون استهلاك موارد جهازي المحدودة، بعيداً عن تعقيدات الحاويات الثقيلة.

كيف بنيت مساعد كود شخصي باستخدام LiteLLM؟

بيئة العمل والمتطلبات التقنية

لتنفيذ هذه المعمارية، ركزت على إبقاء الأمور بسيطة وخفيفة جداً لضمان أعلى أداء ممكن، خصوصاً على الأجهزة ذات الموارد المحدودة (مثل معالجات i3 مع 4GB رام أو معالجات AMD مع 8GB رام):
Python 3.10 أساس البيئة الافتراضية.
مكتبة LiteLLM (لإنشاء الخادم المحلي وتوحيد واجهات برمجة التطبيقات).
محرر VS Code واجهة كتابة الأكواد.
إضافة مثل Continue.dev أو أي إضافة تدعم واجهة برمجة تطبيقات OpenAI.
مفاتيح واجهة برمجة التطبيقات (API Keys) لنماذج Gemini و Claude.

ملاحظة هامة: لن نستخدم Docker هنا أبداً. الحاويات تستهلك جزءاً كبيراً من الذاكرة العشوائية (RAM) وتؤدي إلى بطء ملحوظ في الأجهزة الاقتصادية، لذا سنعتمد كلياً على بيئة Python الافتراضية (Virtual Environment) النظيفة.

لماذا نحتاج إلى خادم محلي موحد؟

في عالم مليء بنماذج الذكاء الاصطناعي، يمتلك كل نموذج نقطة قوة فريدة. على سبيل المثال، أعتمد بشكل يومي وروتيني على نموذج Gemini 3.5 Flash لأنه سريع جداً، ذكي في استيعاب سياق الملفات الكبيرة، ومثالي لمهام البرمجة اليومية السريعة والتحليل. في المقابل، عندما أحتاج إلى بناء هياكل معمارية معقدة (Complex Architectures) أو كتابة تصميم لنظام قواعد بيانات متداخل، أتوجه فوراً إلى Claude.

المشكلة التقنية هنا تكمن في "التجزئة" (Fragmentation). كل شركة (Google, Anthropic, OpenAI) تستخدم هيكلية بيانات مختلفة (JSON Payload) لنقطة النهاية (Endpoint) الخاصة بها. إذا أردت دمج هذه النماذج في بيئة التطوير (IDE) الخاصة بك، ستضطر إلى كتابة طبقة توافقية (Adapter Layer) لكل نموذج. هنا يأتي دور LiteLLM. هذه الأداة الرائعة تعمل كخادم وسيط (Proxy Server) محلي، تستقبل الطلبات بصيغة OpenAI القياسية – والتي تدعمها معظم إضافات محررات الأكواد – ثم تقوم بترجمتها وتوجيهها (Routing) إلى النموذج المطلوب بسلاسة تامة.

التحديات التقنية في بناء المساعد

واجهت عدة تحديات أثناء بناء هذه البرمجية:
تعدد مفاتيح واجهات برمجة التطبيقات (API Keys): إدارة هذه المفاتيح بشكل آمن وتمريرها في كل طلب دون فضحها في الكود المصدري.
زمن الاستجابة (Latency): التأكد من أن وجود خادم وسيط محلي لا يضيف تأخيراً زمنياً (Overhead) ملحوظاً عند تدفق الكود (Streaming) إلى المحرر.
اختلاف هياكل البيانات: نماذج Claude تستخدم نظام messages بشكل صارم ومختلف قليلاً عن نظام الأدوار التقليدي في النماذج القديمة، وكان التحدي في التأكد من تمرير السياق (Context) بدقة دون فقدان أي تعليمات برمجية.

تشريح الشفرة: بناء وتكوين الخادم الوسيط

للبدء، سنقوم بإنشاء بيئة افتراضية وتثبيت LiteLLM. قمت بكتابة سكربت بسيط في سطر الأوامر (Terminal) لتجهيز كل شيء:
# إنشاء بيئة افتراضية جديدة للحفاظ على نظافة النظام
python -m venv aiproxy_env
# تفعيل البيئة (لأنظمة ويندوز استخدم: aiproxy_env\Scripts\activate)
source aiproxy_env/bin/activate
# تثبيت أداة الخادم الوسيط
pip install litellm[proxy]
شرح أوامر التهيئة:

في السطور السابقة، ركزنا على عزل بيئة العمل باستخدام venv. هذه الخطوة حيوية في عالم Python خصوصاً عند العمل على أنظمة ويندوز لضمان عدم تعارض مكتبات الخادم مع أي مشاريع خلفية (Backend) أخرى تعمل عليها، مثل مشاريع Django أو Flask. بعد تفعيل البيئة، قمنا بتثبيت litellm مع إضافة [proxy] والتي تجلب الحزم اللازمة لتشغيل الخادم المحلي المستند إلى FastAPI تحت الغطاء.

الآن، نأتي إلى العقل المدبر لنظام التوجيه (Routing)، وهو ملف التكوين config.yaml. قم بإنشاء هذا الملف في جذر المشروع:
model_list:
  # النموذج الأول: للمهام اليومية السريعة والتحليل (السرعة والكفاءة)
  - model_name: daily-coder
    litellm_params:
      model: gemini/gemini-3.1-flash
      api_key: os.environ/GEMINI_API_KEY
      
  # النموذج الثاني: للمهام المعمارية المعقدة والتحليل العميق
  - model_name: senior-architect
    litellm_params:
      model: anthropic/claude-3-opus-20240229
      api_key: os.environ/ANTHROPIC_API_KEY

litellm_settings:
  drop_params: true
شرح الشفرة سطراً بسطر:
model_list: هذه المصفوفة تحدد النماذج التي سيستضيفها خادمنا المحلي.
model_name: daily-coder: قمت بإنشاء اسم بديل (Alias) للنموذج. بدلاً من التعامل مع أسماء النماذج الطويلة والمعقدة، قمت بتسمية نموذج Gemini 3.1 Flash بـ daily-coder. هذا التجريد (Abstraction) يجعل من السهل تغيير النموذج الفعلي لاحقاً دون الحاجة لتعديل إعدادات محرر الأكواد.
model: gemini/gemini-3.1-flash: هنا نحدد المزود والنموذج الفعلي. LiteLLM يفهم تلقائياً أنه سيتصل بخوادم Google.
api_key: os.environ/GEMINI_API_KEY: هذه حركة ذكية. بدلاً من كتابة المفتاح كنص صريح (Hardcoding)، نأمر LiteLLM بجلبه من متغيرات البيئة في نظام التشغيل. هذا يضمن أمان المفاتيح.
drop_params: true: إعداد سحري في litellm_settings. أحياناً يرسل محرر الأكواد معلمات (Parameters) مدعومة في OpenAI ولكنها غير مدعومة في Gemini أو Claude. هذا الإعداد يقوم بإسقاط أي معلمات غير مدعومة بصمت لتجنب تعطل الطلب (Crash).
لتشغيل الخادم، نقوم أولاً بتصدير المفاتيح ثم تشغيل الخادم:
export GEMINI_API_KEY="your_gemini_key_here"
export ANTHROPIC_API_KEY="your_claude_key_here"
# تشغيل الخادم المحلي على المنفذ 4000
litellm --config config.yaml --port 4000
تحليل التشغيل:

عند تنفيذ الأمر الأخير، سيقوم تطبيقنا بإطلاق خادم ويب محلي خفيف الوزن يعمل على http://localhost:4000. ما حدث هنا هو أننا استبدلنا الاعتماد على حاويات Docker التي تستهلك جيجابايت من الذاكرة، بخادم مبني على ASGI يستهلك بضع عشرات من الميجابايتات فقط، وهو أمر ممتاز للحفاظ على سرعة حواسيبنا الشخصية وترك مساحة الذاكرة (RAM) لمتصفح الويب ومحرر الأكواد.

تلميحة برمجية: يمكنك استخدام ملف .env ووضع مفاتيحك داخله، وتشغيل الأمر litellm --env .env --config config.yaml لتجنب تصدير المتغيرات يدوياً في كل مرة تفتح فيها الطرفية (Terminal).
تنبيه تقني: لا تقم أبداً برفع ملف config.yaml أو .env إلى مستودعات GitHub إذا كانت تحتوي على أي مفاتيح صريحة. استخدم ملف .gitignore وتأكد من استبعادها تماماً لتجنب سرقة الرصيد.

دمج ببيئة التطوير (OpenCode و VS Code)

بعد تشغيل الخادم، سيبدو محرر الأكواد الخاص بك وكأنه يتحدث مع واجهة OpenAI الأصلية. داخل إضافة الذكاء الاصطناعي في محرر VS Code أو OpenCode (مثل أداة Continue.dev أو Cline)، قم بضبط إعدادات النماذج لتشير إلى خادمك المحلي.

إليك كيف يبدو شكل الإعداد (JSON) داخل المحرر لربطه بالنماذج التي برمجناها:
{
  "models": [
    {
      "title": "Gemini 3.1 Flash (Daily)",
      "provider": "openai",
      "model": "daily-coder",
      "apiBase": "http://localhost:4000",
      "apiKey": "sk-local-dummy-key"
    },
    {
      "title": "Claude 3 (Architect)",
      "provider": "openai",
      "model": "senior-architect",
      "apiBase": "http://localhost:4000",
      "apiKey": "sk-local-dummy-key"
    }
  ]
}

كيف تعمل هذه الهيكلية؟

في إعدادات المحرر (IDE)، نخبر الأداة أن تتعامل مع النماذج على أنها من نوع openai (كمزود). نقطة السحر الحقيقية تكمن في توجيه الـ apiBase إلى الخادم المحلي الخاص بنا http://localhost:4000. وضعنا apiKey وهمي لأن الخادم المحلي الخاص بنا لا يطلب مصادقة محلية (المصادقة الحقيقية تحدث في الخلفية داخل config.yaml قبل الإرسال إلى Google أو Anthropic). لقد حققنا الآن دمجاً مثالياً: نستطيع تظليل أي كود في المحرر، وطلب تحليله سريعاً عبر Gemini 3.1 Flash، أو طلب بناء نظام معقد عبر Claude، كل ذلك من واجهة واحدة!

حالات فشل الإتصال

ماذا لو انقطع الاتصال أو تم استنفاد الرصيد المتاح (Rate Limit) لنموذج Claude أثناء جلسة برمجة مكثفة؟

يجب أن نضع احتمالات الفشل في الحسبان. LiteLLM يسمح لنا بإنشاء "توجيه احتياطي" (Fallback Routing). إذا تعذر الوصول لنموذج، يقوم تلقائياً بإعادة توجيه الطلب (Payload) إلى نموذج آخر دون أن تشعر بتوقف المحرر عن العمل، مما يضمن استمرارية سير العمل.

لماذا الـ Model Agnostic هو المستقبل؟

الاعتماد الكلي على منصة واحدة يعرضك لما يُعرف بـ (Vendor Lock-in). اليوم، قد يكون Gemini 3.1 Flash هو الأسرع لمهامك، وغداً قد تطلق شركة مثل DeepSeek أو Qwen نماذج مفتوحة المصدر تتفوق في البرمجة. من خلال بناء هذا الخادم الوسيط، قمت بتجريد (Abstracting) طبقة الذكاء الاصطناعي عن بيئة التطوير الخاصة بك. يمكنك استبدال، إضافة، أو إزالة أي نموذج مستقبلاً عبر تعديل بسيط في ملف config.yaml دون لمس إعدادات محرر الأكواد الخاص بك. هذا هو النهج الأفضل الذي تتبناه الشركات الكبرى لتقليل التكاليف وزيادة المرونة.

تطوير الكود

مهمتك الآن هي تطوير الخادم الذي بنيناه ليتحمل الانقطاعات المفاجئة: لنفترض أن نموذج Claude الذي أسميناه senior-architect نفد رصيده. قم بالبحث في توثيق LiteLLM عن ميزة الـ fallbacks، وقم بتعديل ملف config.yaml ليقوم بتوجيه الطلب تلقائياً إلى نموذج محلي (مثل Qwen) أو إلى Gemini في حال فشل Claude في الرد.
تلميحة الحل والأكواد المقترحة

ستحتاج إلى إضافة مفتاح fallbacks على مستوى إعدادات النموذج في ملف YAML وتحديد قائمة بأسماء النماذج البديلة التي سيحاول الاتصال بها بالترتيب.

الخاتمة

لقد قمنا بتصميم وبناء مساعد كود شخصي مرن للغاية. لم نكتفِ فقط بحل مشكلة التشتت بين المتصفحات، بل بنينا طبقة وسطى قوية تمنحنا تحكماً مطلقاً في تدفق البيانات والنماذج التي نستخدمها. استخدمنا بيئة Python افتراضية بدلاً من حاويات Docker للحفاظ على خفة ومرونة الأداء وتوفير موارد حاسوبنا لتشغيل المحرر براحة تامة. الاعتماد على Gemini 3.1 Flash للمهام اليومية و Claude للهياكل المعقدة عبر واجهة موحدة، رفع من إنتاجيتي في كتابة الأكواد بشكل لا يصدق.

كيف تدير بيئة الذكاء الاصطناعي داخل محرر الأكواد الخاص بك؟ هل جربت دمج نماذج أخرى مثل DeepSeek أو Qwen؟ شاركني رأيك وهيكليتك المفضلة في التعليقات.

هل واجهتك مشكلة أثناء تطبيق هذا المشروع؟

لا تبرمج بمفردك! شارك لقطة شاشة للخطأ (Screenshot) في مجتمعنا لنحلها معاً.

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