GitHub Universe 2026: ما الذي تحتاج إليه وكلاء البرمجة بالذكاء الاصطناعي إلى جانب نماذج أفضل؟

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

تضع فعالية GitHub Universe 2026 وكلاء الذكاء الاصطناعي في صميم النقاش حول تطوير البرمجيات، لكن السؤال الأهم لم يعد ما إذا كان نموذج الذكاء الاصطناعي قادرًا على كتابة الشيفرة. بل أصبح: هل يستطيع الوكيل إنجاز عمل حقيقي، والتحقق من نتائجه، والعمل ضمن أذونات محددة، والحفاظ على السياق اللازم لمواصلة تقدم المشروع؟

من المقرر إقامة فعالية المطورين الرئيسية لدى GitHub يومي 28 و29 أكتوبر في سان فرانسيسكو وعبر الإنترنت، في وقت تتوسع فيه وكلاء البرمجة من الإكمال التلقائي وإنشاء الشيفرة إلى سير عمل تطوير متعدد الخطوات. ويقدم جدول الأعمال المنشور لمحة مفيدة عما هو قادم: ذاكرة الوكلاء، والمهارات القابلة لإعادة الاستخدام، والتفويض في MCP، والتحقق من الشيفرة، وأمن سلسلة توريد البرمجيات. وهذه أيضًا من المشكلات التي تجعل البنية التحتية المحلية للتطوير أكثر أهمية.

ما هي فعالية GitHub Universe 2026؟

GitHub Universe هو فعالية المطورين الرئيسية لدى GitHub، ويجمع المطورين والقائمين على صيانة المشاريع مفتوحة المصدر ومختصي الأمن والفرق الهندسية وشركاء التقنية. ومن المقرر إقامة فعالية 2026 يومي 28 و29 أكتوبر في مركز فورت ماسون بسان فرانسيسكو، مع إتاحة المشاركة الافتراضية أيضًا.

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

للاطلاع على التفاصيل والجدول الحاليين للفعالية، تفضل بزيارة الموقع الرسمي لفعالية GitHub Universe 2026.

ما الذي يكشفه جدول أعمال GitHub Universe 2026 عن وكلاء البرمجة بالذكاء الاصطناعي؟

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

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

تظهر هذه المحاور في معاينة GitHub لعشر جلسات تقنية في Universe المنشورة. وهي توفر أساسًا أقوى لفهم الفعالية من محاولة التنبؤ بإطلاق منتجات لم يُعلن عنها.

لماذا تحتاج وكلاء البرمجة بالذكاء الاصطناعي إلى ذاكرة أفضل، لا إلى مزيد من السياق فحسب

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

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

وهذا يقود إلى تمييز عملي بين ثلاثة أنواع من المعلومات:

  • سياق العمل: الملفات والتعليمات والرموز البرمجية ذات الصلة بالمهمة الحالية.
  • ذاكرة المشروع: القرارات الدائمة والاتفاقيات والمشكلات المعروفة والحلول السابقة.
  • السجلات التاريخية: عمليات الإيداع وطلبات السحب والسجلات ومخرجات الاختبارات التي يمكن استرجاعها عند الحاجة.

لا ينبغي أن يضطر الوكيل المفيد إلى حمل سجل المستودع بأكمله في كل طلب. بل يحتاج إلى طريقة لاسترجاع المعلومات المناسبة في الوقت المناسب والتمييز بين التعليمات الحالية والقرارات المتقادمة.

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

لماذا أصبح سياق الوكيل جزءًا من البنية التحتية

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

مع توسع سير العمل المدعوم بالذكاء الاصطناعي، قد تشمل بيئة تشغيل الوكيل ما يلي:

  • التعليمات والاتفاقيات الخاصة بالمستودع،
  • المهارات القابلة لإعادة الاستخدام وسير العمل الخاص بالمهام،
  • تعريفات الأدوات وإعدادات خوادم MCP،
  • بيانات الاعتماد وسياسات الأذونات،
  • بيئات الاختبار واعتماديات البناء،
  • توثيق المشروع والقرارات السابقة.

لا ينبغي التعامل مع هذه المكونات على أنها قابلة للتبادل. فالـ skill يشرح كيفية تنفيذ مهمة؛ وسياق المشروع يوضح البيئة التي ينبغي تنفيذ المهمة فيها؛ والأذونات تحدد الإجراءات المسموح بها؛ أما السجلات الدائمة فتحفظ ما حدث.

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

لماذا تحتاج وكلاء الذكاء الاصطناعي إلى أذونات مفروضة، لا إلى تعليمات في المطالبات فحسب

إن قدرة الوكيل على قراءة التعليمات البرمجية لا تعني بالضرورة أنه آمن لدمج طلب سحب أو نشر إصدار أو تعديل البنية التحتية لبيئة الإنتاج. وتزداد خطورة المشكلة عندما يستطيع الوكيل استدعاء أدوات خارجية عبر خوادم MCP أو تنفيذ أوامر في بيئة تطوير.

تركز إحدى جلسات Universe المقررة، افتح طلبات السحب، ولا تدمجها: التفويض الدقيق لخوادم MCP المستضافة، على التفويض المرتبط بالهوية أمام خادم MCP. ويتمثل المثال الأساسي فيها في قاعدة تسمح للوكيل بفتح طلب سحب، لكنها تمنعه من دمج التغيير.

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

بالنسبة إلى مسارات عمل التطوير العملية، يعني ذلك فصل إمكانات مثل:

  • قراءة مستودع دون تعديله،
  • إنشاء فرع دون دمجه في فرع محمي،
  • تشغيل الاختبارات دون الوصول إلى بيانات اعتماد بيئة الإنتاج،
  • إعداد مسودة إصدار دون نشره،
  • الوصول إلى ملفات المشروع دون الوصول إلى بيانات شخصية أخرى.

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

هل يمكن الوثوق بالتعليمات البرمجية التي يولدها الذكاء الاصطناعي من دون تحقق أفضل؟

إنشاء التعليمات البرمجية ليس سوى خطوة واحدة في تطوير البرمجيات. فقد تنجح رقعة برمجية في التجميع وتجتاز اختباراتِها، لكنها تظل قادرة على تعطيل سير عمل المستخدم، أو إساءة فهم أحد المتطلبات، أو إخفاء مشكلة لا تغطيها مجموعة الاختبارات.

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

يمثل هذا تحولًا جوهريًا من التساؤل عما إذا كان النموذج قادرًا على إنتاج تعليمات برمجية تبدو معقولة، إلى التساؤل عما إذا كان الوكيل قادرًا على تقديم أدلة تثبت صحة التغييرات التي أجراها.

يتطلب سير عمل أكثر موثوقية طبقات متعددة من التحقق:

  1. الفحوصات الساكنة: تحقّق من التنسيق والأنواع ومشكلات التعليمات البرمجية الواضحة.
  2. الاختبارات الآلية: شغّل اختبارات الوحدة والتكامل والانحدار ذات الصلة.
  3. فحوصات على مستوى التطبيق: تحقّق من السلوك المتوقع أن يختبره المستخدمون.
  4. مراجعة التغييرات: افحص الفرق والافتراضات والتبعيات والآثار الجانبية غير المقصودة.
  5. إصدار مضبوط: اشترط الموافقة المناسبة قبل وصول التغييرات عالية التأثير إلى بيئة الإنتاج.

لا تضمن هذه الفحوصات صحة العمل، لكنها تجعل فحص عمل الوكيل أسهل وتشخيص الأعطال أيسر. فالهدف ليس أن يعلن الوكيل اكتمال المهمة، بل جمع ما يكفي من الأدلة لتبرير هذا الاستنتاج.

لماذا يزيد وكلاء البرمجة بالذكاء الاصطناعي أيضًا مخاطر سلسلة توريد البرمجيات

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

تتضمن قائمة الجلسات المنشورة من GitHub نقاشات حول ما يحدث خلف الكواليس npm install وكيف يمكن للمهاجمين استهداف مسارات عمل GitHub Actions وبنية الإصدار. وتكتسب هذه المواضيع أهميتها لأن أمن التطبيقات يتجاوز التعليمات البرمجية التي يكتبها الوكيل.

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

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

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

ماذا يعني هذا للبنية التحتية للذكاء الاصطناعي المحلي والخوادم المنزلية؟

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

يمكن لإعداد تطوير محلي توزيع هذه المسؤوليات بدلًا من مطالبة جهاز واحد بالقيام بكل شيء.

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

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

لا يعني ذلك أن جهاز التخزين المتصل بالشبكة (NAS) يحل محل GitHub أو مسار التكامل المستمر الآمن أو محطة عمل مزودة بوحدة معالجة رسومات. فلكل منها دور مختلف. يوفر GitHub تعاونًا مستضافًا وسير عمل للمستودعات؛ وتشغّل آلة التطوير عمليات البناء والاختبارات؛ وتتولى موارد حوسبة الذكاء الاصطناعي الاستدلال؛ ويحفظ التخزين الدائم البيانات والسجلات التي ينبغي أن تبقى بعد انتهاء المهمة.

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

هل ينبغي تشغيل وكلاء البرمجة محليًا أم في السحابة؟

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

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

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

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

ما الذي ينبغي للمطورين متابعته في GitHub Universe 2026؟

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

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

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

للاطلاع على البرنامج الكامل وأي تحديثات تسبق الفعالية، راجعوا المعاينة المنشورة للجلسات التقنية والموقع الرسمي للفعالية.

الصورة الأكبر: تطوير الذكاء الاصطناعي يتحول إلى مسألة بنية تحتية

يستحق GitHub Universe 2026 المتابعة، ليس لأن كل مهام البرمجة ستصبح مستقلة قريبًا، بل لأن سير عمل المطورين حول الذكاء الاصطناعي يزداد تعقيدًا. تولّد النماذج الشيفرة، وتستدعي الوكلاء الأدوات، وتقدم الاختبارات أدلة، وتقيّد الأذونات الإجراءات، ويساعد سياق المشروع المستمر على مواصلة العمل عبر الجلسات.

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

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

هذه هي الإشارة الأجدر بالاهتمام من مؤتمر GitHub Universe 2026: كلما ازدادت قدرات وكلاء البرمجة، أصبحت البنية التحتية المحيطة بهم جزءًا أكبر من التحدي الهندسي.

مركز حملة Zima

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.