مهارة أساسية في هندسة الذكاء الاصطناعي: استخدام وكلاء البرمجة
مهارة أساسية في هندسة الذكاء الاصطناعي هي استخدام وكلاء البرمجة. مهارتك في توجيههم لكتابة الكود وتنفيذ المهام غير البرمجية، مثل تحليل البيانات أو إدارة عمليات النظام، تمكنك من إنجاز المزيد بكثير.
الوتيرة السريعة لتطور وكلاء البرمجة تعني أن هذه المهارة تتطور بسرعة أيضًا — أسرع من المهارات العليا الأخرى في هندسة الذكاء الاصطناعي. الوكلاء الاحتكاريون (مثل Claude Code و Codex و Cursor) والوكلاء مفتوحة المصدر (مثل OpenCode و Pi) يتقدمون بقفزات نوعية عبر تحسينات في كل من الأدوات والنماذج. لذا، مواكبة كيفية استخدام وكلاء البرمجة تتطلب عملية مستمرة من التجريب والبناء والتعلم.
من خلال مقابلة العشرات من كبار مهندسي الذكاء الاصطناعي والتفكير في استخدام فريقنا الخاص لوكلاء البرمجة، وجدنا سير عمل ثابتًا عالي المستوى لبناء البرمجيات باستخدامهم. الخطوات الرئيسية هي:
- التخطيط. يشمل ذلك (i) العصف الذهني، الذي قد يتضمن البحث والتجريب وفهم قاعدة الكود الحالية (إن وجدت) و (ii) كتابة مواصفات تلتقط المتطلبات والتصميم التقني والهندسة المعمارية، متبوعة بتوليد خطة تنفيذ. قد تراجع الخطة أيضًا لاستجواب الافتراضات الرئيسية والتحقق من الأمان والهندسة المفرطة وغيرها من الثغرات.
- التنفيذ، حيث تقوم بالبناء والاختبار والتحقق، مع التوازن الصحيح بين استقلالية الوكيل والإشراف البشري. يتضمن ذلك (i) جعل الوكيل يبني البرنامج، بمستوى مُعاير من استقلالية الوكيل و (ii) التحقق من مخرجاته عبر فحوصات آلية و/أو بشرية.
- النشر والمراقبة، حيث تقوم (i) بالنشر، ربما مع حاجز من خلال خط أنابيب CI/CD أو حواجز بشرية إضافية، و (ii) استخدام الوكلاء لمراقبة السجلات، وكشف المشكلات، واقتراح وتنفيذ التحسينات.
سير العمل عالي المستوى هذا مشابه لذلك المستخدم عادةً لبناء البرمجيات قبل وكلاء البرمجة. الآن، نركز بشكل أقل بكثير على الكود وبدلاً من ذلك نركز على تحديد ما يجب بناؤه، وتصميم الهندسة المعمارية، وكتابة المواصفات، والتحقق من المخرجات.
يمكن أن تختلف مدة كل خطوة بشكل كبير بين المشاريع، ويمكن حذف الخطوات. على سبيل المثال، قد يتم وصف مواصفات نموذج أولي جديد (أي مبني من الصفر) بشكل فضفاض في موجه مكتوب بسرعة، بينما قد تتطلب مواصفات مشروع قائم (بني) مع العديد من المستخدمين جهدًا أكبر بكثير للكتابة والتحقق. علاوة على ذلك، سير العمل متكرر للغاية، ويعرف المطورون المهرة متى يجب أن تقودهم التعليقات من خطوة لاحقة إلى العودة إلى خطوة سابقة. على سبيل المثال، إذا فشل التحقق، فإنهم يعرفون كيفية توجيه الوكيل لإعادة البناء وإصلاح الأخطاء؛ أو إذا كشفت المراقبة عن مشكلات، فكيفية جعل الوكلاء يقومون بتحديث النظام وإعادة نشره.
لاستخدام وكلاء البرمجة بفعالية في سير العمل هذا، المهارات الرئيسية هي:
- توجيه سير العمل
- تمكين استقلالية الوكيل
- مراجعة العمل
- تخصيص الوكيل وبيئته
- أساسيات وكلاء البرمجة
توجيه سير العمل. أنت تعرف كيفية التنقل في كل خطوة من سير العمل أعلاه. يتضمن ذلك تحديد مقدار الجهد البشري ومقدار جهد الوكيل الذي يجب إنفاقه على كل منها ومتى تعود إلى خطوة سابقة للتكرار. يتطلب فهمًا عميقًا للمفاضلات بين السرعة والتكلفة والمخاطر التقنية والجهد البشري، حتى تتمكن من تحديد مقدار البحث والتخطيط المسبق، ومتى تحتفظ بالملكية البشرية للعمل الحرج، وكيفية اختيار الهندسة المعمارية، وكم التفاصيل التي يجب كتابتها في مجموعة من أدوات التخطيط (مثل المواصفات)، وكيفية تحليل العمل إلى خطوات قابلة للتحقق.
تمكين استقلالية الوكيل. عند تطبيق وكيل برمجة على خطوات سير العمل، تختار مستوى الاستقلالية: هل تراقبه وتتبادل التفاعل ذهابًا وإيابًا أم تفوض له جزءًا أكبر من العمل؟ ومتى تحدد هدفًا واضحًا وتجعله يكرر حتى ينجح؟ بالإضافة إلى ذلك، عليك إدارة السياق بعناية للوكيل. مع تقدم البناء عبر مراحل مختلفة، ستقوم بمعايرة متى تتأكد من أن الدروس الرئيسية وملاحظات المستخدمين والافتراضات — بما في ذلك الافتراضات التي تغيرت في منتصف البناء — يتم التقاطها لاستخدام الوكيل في المراحل اللاحقة. بالإضافة إلى ذلك، ستقرر متى تقوم بإعداد العديد من الوكلاء للتشغيل بالتوازي على تحليل المهمة — إما عن طريق إشراف بشري أو وكيل عالي المستوى ينسق هؤلاء الوكلاء الآخرين — وكيفية إدارة الانتباه البشري عبر جلسات الوكيل المتزامنة. أنت تعرف أيضًا كيفية تشغيل الوكلاء بأمان، وتحديد الأذونات وحواجز الإجراءات بشكل مناسب للسماح بالتطوير بسرعة مع الحد من مخاطر التسريبات أو فقدان البيانات أو الأضرار الأخرى.
مراجعة العمل. مخرجات وكيل البرمجة غير مؤكدة. لا نعرف مسبقًا الأفكار الجيدة التي قد يبتكرها والأخطاء التي سينفذها. مراجعة المخرجات والتحقق منها هي خطوة رئيسية لضمان حصولك على النتيجة التي تريدها وإعادة توجيه الوكيل إذا لم يكن الأمر كذلك. ستقوم بتصميم اختبار وتحقق يتناسبان مع المهمة، وتطبيق التحقق السلوكي والوظيفي حسب الحاجة. قد تختبر أيضًا تدفقات المستخدم، ربما عن طريق جعل الوكيل يقدم لقطات شاشة كدليل على النجاح أو الفشل. للتقييم النوعي/السلوكي، يمكن استخدام مجموعات التقييم، ربما مع LLM كحكم.
تحتاج أيضًا إلى تحديد مقدار هذه الاختبارات التي يجب أن تكون آلية. بعض سير العمل سيكون بها جميع الاختبارات والتحقق مؤتمتة بالكامل حتى يتمكن الوكيل من التحقق من عمله ومعرفة متى نجح في إكمال المهمة. عليك تقييم الاختبارات للتأكد من أنها تتوافق مع أهدافك، وستقوم بتطويرها إذا لم تكن كذلك. بالإضافة إلى ذلك، تستخدم مراجعة الكود الوكيلية وتجري عمليات تدقيق أمنية وهندسية مدعومة بالذكاء الاصطناعي. عندما لا تكون مراجعة الذكاء الاصطناعي كافية، تقوم بإدراج مراجعات بشرية بحكمة لسلوك الكود (ونادرًا، للكود نفسه) مع استكشاف كيفية أتمتة هذه المراجعة بشكل أكبر. أخيرًا، تتحقق من النشر ويمكنك تشغيل المراقبة وإدارة الحوادث باستخدام الوكلاء.
تخصيص الوكيل وبيئته. قدرتك على تحديث كل من الوكيل والبيئة التي يعمل فيها تسمح لوكلائك بالحصول بكفاءة على السياق الذي يحتاجونه، والوصول إلى الأدوات، والبناء بشكل صحيح وفعال. أنت تعرف كيفية دمج مهارات الوكيل والإضافات وخوادم MCP. من حين لآخر ستقوم بتقليمها عندما لا تكون ضرورية (مثل عندما يلغي نموذج جديد مهارة قديمة). يمكنك استخدام الخطافات لأتمتة الأجزاء القابلة للتكرار من عملية التطوير، مثل تشغيل مراجعات الكود الآلية أو خطوط أنابيب CI/CD. يمكنك أيضًا الحفاظ على البيئة التي يعمل فيها الوكيل: تحديث السياق الثابت (مثل AGENTS.md أو CLAUDE.md) بمعلومات حول قاعدة الكود والافتراضات المعمارية الرئيسية وأسلوب الكود وأنماط الوصول إلى البيانات. أنت تعرف كيفية الحفاظ على الحالة عبر جلسات متعددة وعبر وكلاء متوازيين، وتجميع تعلمات الوكيل بمرور الوقت، ربما عن طريق تشغيل استعراضات ما بعد التشغيل لالتقاط ما نجح وما لم ينجح. أنت تعرف أيضًا كيفية إعداد اصطلاحات وهيكل متسقين لجعل قاعدة الكود قابلة للتنقل للوكيل، وكيفية تنظيف الديون الناتجة عن الوكيل من حين لآخر. عندما تعمل في فريق، تفكر في كيفية تنسيق السياق عبر وكلاء المطورين المختلفين.
أساسيات وكلاء البرمجة. أخيرًا، لاتخاذ قرارات جيدة طوال الوقت، لديك فهم جيد لكيفية عمل وكلاء البرمجة: كيف يقومون بالبحث/الاسترجاع في قاعدة الكود، وكيف يديرون نوافذ السياق الخاصة بهم، وكيف تؤثر العمليات المختلفة (مثل إضافة استدعاءات الأدوات، وخوادم MCP، إلخ) على السياق، وكيف يتفاعل الوكلاء والوكلاء الفرعيون، وكيف يتم بناء الوكيل عن طريق تغليف أداة حول LLM. هذا يجعل الوكيل أقل غموضًا ويساعدك على التعرف على أنماط الفشل، مثل الهندسة المفرطة لحل بسيط، أو فقدان الدقة لأن الوكيل يفتقر إلى عملية تحقق صريحة، أو التوقف قبل الهدف، أو إجراءات الوكيل التي تخاطر بتدمير الملفات أو بيانات الإنتاج. يساعدك أيضًا على التفكير في حالة الوكيل وتوجيهه من خلال إعطائه الوصفة أو السياق الصحيحين. وعند مراقبة تشغيل، يسمح لك هذا الفهم باكتشاف أفضل عندما يخرج الوكيل عن المسار ويتطلب تدخلك.
أجد أن وسائل التواصل الاجتماعي غالبًا ما تقدم أوصافًا مبسطة لكيفية استخدام وكلاء البرمجة. على سبيل المثال، من المفيد أحيانًا جعل الوكلاء يعملون بشكل مستقل لساعات ويحرقون ملايين أو عشرات الملايين من الرموز. لكن حاليًا، الفائدة العملية للمهام طويلة الأمد — خاصة بالنسبة لتكلفتها — تم تضخيمها بشكل غير واقعي. بدلاً من ذلك، معظم الاستخدام الفعال لوكلاء البرمجة هو عملية معقدة ومتكررة للغاية، والقدرة على التدخل بحكم عالي المهارة تعطي نتائج أفضل بكثير.
مهارتك في استخدام وكلاء البرمجة ستجعلك بانيًا فعالاً. هذا يضعك في موقع يسمح لك أيضًا بتوجيه البناء العام. سأقول المزيد عن هذا في مقال مستقبلي.
