شرح OTUS على Habr كيف تعمل وكلاء AI لتطوير البرمجيات: من التوكنات إلى الأدوات

نشرت موقع Habr تحليلاً تفصيلياً لكيفية عمل وكلاء الذكاء الاصطناعي للتطوير. يزيل النص هالة "السحر" ويُظهر أنه وراء الواجهة المريحة توجد آليات محددة تماماً: الرموز (tokens)، والموجّه النظام، والأدوات، وسجل الحوار، ودورة استدعاءات متكررة للنموذج.

الهندسة المعمارية الأساسية للوكيل

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

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

السياق والسعر

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

• طول موجّه النظام
• حجم سجل الحوار
• عدد رموز الإدخال والإخراج
• تخزين مؤقت للبادئات المكررة
• عدد استدعاءات الدالة الوسيطة

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

الأدوات والاستدلال

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

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

كما ورد في المادة، الوكيل ليس سحراً، بل مجموعة من القرارات المعمارية. وتُحدد جودة هذا الوكيل ليس بنموذج واحد مثير للإعجاب، بل بكيفية تجميع المهندس للدائرة بأكملها.

ماذا يعني هذا

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