هندسة وكلاء الذكاء الاصطناعي الذين يبنون البرمجيات وينشرونها: داخل بنية Jobbit

معظم "وكلاء الذكاء الاصطناعي" يتوقفون عند حدود المحادثة. فهم يجيبون، ثم يتولى الإنسان إنجاز العمل. أما المشكلة الهندسية المثيرة — والصعبة حقًا — فهي بناء وكلاء ينجزون العمل بأنفسهم: يكتبون تطبيقًا متكامل الطبقات (full-stack)، ويشغّلونه، ويصلحون أخطاءهم بأنفسهم، ثم ينشرونه إلى بيئة الإنتاج. هذه هي المشكلة التي يعمل عليها فريق الهندسة في Jobbit وقسم البحث والتطوير التابع له، Jobbit Labs (jobbitlabs.com)، كل يوم.

هذه المقالة غوص هندسي عميق في الأنماط الكامنة وراء وكلاء الذكاء الاصطناعي الذين يبنون البرمجيات وينشرونها — البنية، وأنماط الفشل، والدروس المستفادة. وهي عملية بشكل مقصود ومحايدة تجاه مزوّد النماذج: سواء كنت تبني على نماذج اللغة الكبيرة (LLMs)، أو التنسيق متعدد الوكلاء، أو استدعاء الأدوات (tool calling)، أو RAG، فإن هذه المبادئ تنتقل بينها جميعًا.

روبوتات الدردشة تجيب؛ الوكلاء يتصرفون

القفزة من روبوت الدردشة إلى الوكيل هي القفزة من توليد النص إلى اتخاذ إجراءات في العالم الواقعي. على الوكيل أن يخطط لمهمة متعددة الخطوات، ويستدعي الأدوات، ويقرأ النتائج، ويقرر ما يفعله تاليًا — ثم يكرر ذلك حتى يتحقق الهدف. هذه الحلقة، التي كثيرًا ما تُسمى الحلقة الوكيلية (agentic loop) أو حلقة التفكير-والفعل، هي قلب النظام النابض.

التحدي الهندسي أن كل خطوة قابلة للفشل. فقد يهلوس النموذج دالة غير موجودة، أو يكتب شيفرة لا تُترجَم برمجيًا، أو يسيء قراءة مخرجات أداة ما، أو ينحرف عن المهمة بهدوء. روبوت الدردشة الخاطئ ينتج جملة سيئة؛ أما الوكيل الخاطئ فينتج عملية نشر معطوبة. الموثوقية، لا القدرة الخام، هي العمل الهندسي الحقيقي.

البنية: المخطِّط، والمنفِّذ، والأدوات

تفصل منصة الوكلاء المتينة بين التخطيط والتنفيذ. فطبقة التخطيط تفكّك الهدف ("ابنِ تطبيق حجوزات مع مدفوعات") إلى خطوات محددة؛ وطبقة التنفيذ تنجز كل خطوة باستخدام الأدوات. الفصل بين هذين الجانبين يجعل النظام قابلًا للتنقيح: إذ يمكنك فحص الخطة بمعزل عن كيفية تنفيذ كل خطوة.

استخدام الأدوات (tool use) هو حيث يحصل الوكيل على يديه. الأدوات دوال محددة جيدًا يمكن للنموذج استدعاؤها — قراءة ملف، كتابة شيفرة، تشغيل عملية بناء، الاستعلام من قاعدة بيانات، النشر. والانضباط الهندسي هنا يكمن في تصميم الواجهة: تحتاج كل أداة إلى مخطط (schema) محكم لا لبس فيه، ومدخلات مُتحقَّق منها، ومخرجات مهيكلة يستطيع النموذج تحليلها بموثوقية. الواجهات الفضفاضة للأدوات مصدر رئيسي لفشل الوكلاء؛ والواجهات المحكمة هي أرخص مكسب في الموثوقية متاح لك.

في المهام المعقدة، كثيرًا ما يفسح الوكيل الواحد المجال لـالتنسيق متعدد الوكلاء — وكلاء متخصصون يخططون، ويكتبون الشيفرة، ويراجعون، ويتحققون، ينسّق بينهم منسّق (orchestrator). التفكيك يمنحك التركيز (لكل وكيل مهمة ضيقة وسياق ضيق) والتوازي (تشتغل المهام الفرعية المستقلة في آنٍ واحد). والمقابل هو عبء التنسيق، لذا يجب أن تكون طبقة التنسيق حتمية حيث يمكنها ذلك ومرنة حيث لا يمكنها.

تشغيل الشيفرة الحقيقية ونشرها بأمان

الوكيل الذي يكتب برمجيات عليه أن يشغّل تلك البرمجيات — وتشغيل شيفرة مولّدة من النموذج هو مشكلة أمنية قبل أي شيء آخر. والحل هو تنفيذ الشيفرة المعزول (sandboxed code execution): تُشغَّل الشيفرة غير الموثوقة في بيئة معزولة بموارد مقيدة، دون أي وصول إلى الأسرار، وضمن حدود شبكية ضيقة. الصندوق المعزول (sandbox) هو ما يتيح للوكيل أن يكرّر — يترجم، يختبر، يقرأ الخطأ، يصلح — دون تعريض المنصة أو المستخدمين الآخرين للخطر.

النشر هو الخطوة التي تحوّل التطبيق المولّد إلى منتج. أي أداة بناء تطبيقات بالذكاء الاصطناعي (AI app builder) حقيقية تمتلك المسار من الشيفرة إلى رابط حي: البناء، وتجهيز الاستضافة، وربط النطاق، وإنهاء اتصال TLS. هندسة هذا بإتقان تعني جعل عمليات النشر قابلة للتكرار والتراجع — المدخلات نفسها تنتج النتيجة نفسها، ويمكن التراجع عن عملية نشر سيئة. الجاهزية للتكرار (idempotency) والتراجع النظيف ليسا أمرين برّاقين، لكنهما ما يجعل النشر المستقل جديرًا بالثقة.

السياق، والذاكرة، والاسترجاع

نماذج اللغة الكبيرة لها سياق محدود، والمشاريع الحقيقية لا تتسع فيه. لذا يستثمر أي نظام وكلاء جاد بكثافة في هندسة السياق (context engineering): تحديد ما يراه النموذج في كل خطوة. حشو كل شيء في الموجّه (prompt) مكلف ويأتي بنتائج عكسية معًا — فالسياق غير ذي الصلة المفرط يُضعف الاستدلال.

هنا يثبت RAG (التوليد المعزَّز بالاسترجاع) وقواعد البيانات المتجهية (vector databases) جدارتهما. فبدلًا من إغراق السياق بقاعدة شيفرة كاملة، يسترجع النظام الملفات أو الرموز أو المستندات القليلة المتعلقة بالخطوة الحالية. وبالاقتران مع ذاكرة (memory) مهيكلة — سجل بالقرارات، والمواصفات المتطورة، وما جُرّب سابقًا — يبقي الاسترجاع الوكيل راسخًا على امتداد مهمة طويلة دون أن يتجاوز نافذة السياق. الاسترجاع الجيد غالبًا ما يكون رافعة جودة أكبر من نموذج أكبر.

الموثوقية: التقييمات، والتحقق، وحواجز الأمان

إن كانت ثمة فكرة واحدة تفصل هندسة الوكلاء الإنتاجية عن العروض التوضيحية، فهي هذه: لا يمكنك نشر ما لا يمكنك قياسه. الأنظمة الوكيلية احتمالية (stochastic)، لذا تُهندَس الموثوقية عبر التقييمات (evals) — مجموعات اختبار آلية تمنح الوكيل درجات على مهام تمثيلية وتلتقط الانحدارات قبل أن يلتقطها المستخدمون. أي تغيير "يبدو أفضل" لكنه يُسقط درجات تقييمك هو تغيير لا تنشره.

فوق التقييمات تجلس حواجز الأمان (guardrails) والتحقق (verification) أثناء التشغيل. والنمط الأكثر فعالية هو الفحص الذاتي الخصومي (adversarial self-checking): بعد أن ينتج الوكيل نتيجة — قطعة شيفرة، أو خطة، أو إصلاحًا — تأتي مرحلة تحقق منفصلة تحاول دحضها. هل تُترجَم الشيفرة برمجيًا؟ هل تنجح الاختبارات؟ هل تطابق المخرجات المخطط؟ معاملة التحقق كخطوة متشككة منفصلة تلتقط حصة كبيرة من حالات الفشل التي قد تفوّتها تمريرة واحدة واثقة. وتتولى إعادات المحاولة مع التباطؤ (backoff)، وقواطع الدارة (circuit breakers)، والتصعيد البشري معالجة الباقي.

قابلية ملاحظة يمكنك تنقيحها

حين يتخذ نظام مستقل عشرات القرارات في المهمة الواحدة، تحتاج إلى رؤيتها. قابلية الملاحظة (observability) — التتبع المهيكل لكل موجّه واستدعاء أداة ونتيجة — أمر غير قابل للتفاوض. وعندما يخطئ الوكيل، يكون التتبع (trace) هو الطريق لإيجاد الخطوة التي انحرفت بالضبط، وإعادة إنتاجها، وإصلاح السبب الجذري. فِرق الهندسة التي تعامل تتبعات الوكلاء كقياسات تتبع (telemetry) من الدرجة الأولى تنقّح خلال دقائق؛ والتي لا تفعل تنقّح خلال أيام.

الحافة والتوسع المرن

أحمال عمل الوكلاء متقطعة ومتأثرة بزمن الاستجابة، ما يجعل الحوسبة الطرفية (edge computing) ملاءمة طبيعية لها. التشغيل قرب المستخدمين — على منصات مثل Cloudflare Workers ومخازن البيانات الطرفية — يقلّص زمن ذهاب وإياب الطلب ويتوسع بمرونة مع الطلب. يعتمد Jobbit Labs على هذا النهج المُركَّز على الحافة في أجزاء من بنيته التحتية للبيانات والمنتج: موزّعة عالميًا، ذاتية التوسع، وادفع-مقابل-ما-تستخدمه، بحيث تتبع السعة الحِمل بدلًا من أن تظل خاملة.

طبقة الإنسان ضمن الحلقة

القطعة الأخيرة من البنية هي التي تفتقر إليها معظم منصات الوكلاء: مسار الإنسان ضمن الحلقة (human-in-the-loop). الذكاء الاصطناعي يتولى الحجم والسرعة، لكن بعض القرارات — المنطق الحساس أمنيًا، والصياغة القانونية، والحكم التصميمي — تخص الإنسان. هندسة هذا تعني بناء نقاط تسليم نظيفة يمكن لخبير بشري موثَّق التدخل عندها، مع ضمان وسيط (escrow) يحمي المعاملة. الوكيل والشبكة البشرية ليسا طبقتين متنافستين؛ بل هما خطة بديلة مصممة ضمن النظام تجعل الاعتماد عليه آمنًا.

دروس لمهندسي بناء الوكلاء

إن كنت تبني أنظمة وكيلية، فثمة مبادئ قليلة تردّ الاستثمار فيها أضعافًا مضاعفة.

صمّم واجهات أدوات محكمة. معظم حالات فشل الوكلاء تعود إلى أدوات غامضة. المخططات الصارمة والمدخلات/المخرجات المُتحقَّق منها هي أرخص موثوقية تشتريها على الإطلاق.

تحقّق بأسلوب خصومي. لا تثق بتمريرة أولى واثقة. أضف خطوة منفصلة مهمتها دحض النتيجة.

قِس بالتقييمات. ابنِ منظومة التقييم قبل أن توسّع الوكيل. لا يمكنك تحسين ما لا يمكنك تسجيل درجاته.

هندِس السياق، لا تحشُه. استرجع ما هو ذو صلة؛ واحفظ ما يهم. الموجّهات الأكبر ليست موجّهات أفضل.

اعزل كل ما هو غير موثوق. إن كان الوكيل يشغّل شيفرة، فالعزل شرط مسبق، لا ميزة إضافية.

أبقِ على مسار بشري. أكثر الأنظمة المستقلة أمانًا هو الذي يعرف متى يسأل إنسانًا.

الأسئلة الشائعة

ما الذي يجعل وكيل الذكاء الاصطناعي مختلفًا عن روبوت الدردشة؟

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

كيف تشغّل الشيفرة المولّدة بالذكاء الاصطناعي بأمان؟

عبر تنفيذ الشيفرة المعزول (sandboxed code execution): تُشغَّل الشيفرة غير الموثوقة في بيئة معزولة بموارد محدودة، دون وصول إلى الأسرار، وضمن شبكة مقيدة، بحيث يستطيع الوكيل أن يترجم، ويختبر، ويصلح دون تعريض المنصة للخطر.

لماذا التقييمات بهذه الأهمية لأنظمة الوكلاء؟

لأن الوكلاء احتماليون، تحتاج إلى تقييمات (evals) آلية لقياس الجودة على مهام تمثيلية والتقاط الانحدارات قبل النشر. وبدونها، تكون "التحسينات" مجرد تخمينات.

ماذا يفعل Jobbit Labs؟

Jobbit Labs (jobbitlabs.com) هو قسم البحث والتطوير والبيانات وراء Jobbit، ويركز على الهندسة الأثقل والكثيفة بالبيانات والمؤسسية — البحث، ومنصات البيانات، وأسس الوكلاء التي بُني عليها المنتج.

أيثير فضولك ما يكمن من هندسة وراء وكلاء ينشرون البرمجيات؟ استكشف jobbit.uk وjobbitlabs.com.