فلانت: كيف حول مطور Go نموذج Zed و Gemini إلى وكيل ذكاء اصطناعي مفيد

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

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

كان وضع الوكيل قادراً على كتابة وإعادة هيكلة الأكواد، لكنه كثيراً ما يتطلب إعادة يدوية، لذا كانت دورة "تحديد المهمة — التحقق — إعادة الكتابة" تستغرق وقتاً أطول من العمل العادي بدون ذكاء اصطناعي. كانت المرحلة التالية مع الوصول المؤسسي إلى عدة نماذج. قيّم المؤلف جودة إجابات GPT-4o أعلى بكثير من GigaChat، لكن هذا لم يحل المشكلة الرئيسية.

عندما فتحت الشركة الوصول عبر مفتاح API، حاولوا مكونات شهيرة مثل Cline و Continue في بيئة التطوير المتكاملة. كانت النتيجة ضعيفة مرة أخرى: كان الاقتران بين بيئة التطوير المتكاملة ومنطق الواجهة الويب والنموذج الخارجي يبطئ الأمور، والعمل بقي ثقيلاً. كانت وكلاء المحطة الطرفية نقطة تحول.

كان OpenCode شهيراً بين الزملاء، لكن المؤلف اختار Crush لسهولة التثبيت وحقيقة أن الأداة مكتوبة بلغة Go. هناك حصل على فائدة حقيقية للمرة الأولى: كان الوكيل قادراً على تحليل المشروع وقراءة الملفات وكتابة الأكواد واستخدام LSP و MCP. مع ذلك، لم يكن وكيل المحطة الطرفية النقطة النهائية.

للعمل اليومي مع مستودع Git وقاعدة الأكواد، كانت سهولة المحرر تفتقد دائماً. لذا انتقل المؤلف إلى Zed — محرر سريع قائم على Rust مع لوحة ذكاء اصطناعي مدمجة وحكيله الخاص ودعم للوكلاء الخارجيين عبر ACP. في المقالة، يشرح بالتفصيل كيفية توصيل Zed بخدمة LLM مؤسسية عبر Open-WebUI وواجهة برمجية متوافقة مع OpenAI، واختيار نموذج Gemini 3 Flash وتكوين ملف تعريف write بالأدوات الضرورية: التشخيصات وقراءة الملفات والبحث ولعرض القائمة والمحطة الطرفية والتفكير والبحث على الويب.

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

لجعل الوكيل يعمل بشكل أقرب إلى دلالات الأكواد، يقوم بتوصيل gopls في وضع MCP التجريبي. نظراً لأن LSP العادي في Zed موجه حالياً نحو البشر وليس الوكلاء، يتعين عليه تشغيل gopls-mcp منفصل مع متغيرات البيئة الخاصة به والمهلة الزمنية المتزايدة. لكن بعد ذلك يحصل الوكيل على فئة مختلفة من الأدوات: نظرة عامة على مساحة العمل وواجهات برمجية الحزم والبحث عن الرموز والمراجع والإعادة الآمنة والتشخيصات وحتى التحقق من الاعتماديات ضد الثغرات المعروفة.

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

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

عندما يرى الوكيل المشروع ليس من خلال البحث الأعمى عن السلاسل بل من خلال LSP و MCP، وعندما تم إعطاؤه الأدوار والملفات التعريفية والسياق الصحيح مسبقاً، يتوقف عن كونه مساعداً صاخباً ويبدأ في توفير الوقت الفعلي على الأكواد والملاحة والتحققات.