Vercel Agent: ذكاء اصطناعي لأتمتة التعامل مع الحوادث في بيئة الإنتاج

في 9 يوليو 2026 أطلقت Vercel نسخة تجريبية عامة من Vercel Agent، وهو ذكاء اصطناعي لأتمتة التعامل مع الحوادث في بيئة الإنتاج. الوكيل مدمج مباشرة في منصة النشر، ويحقق في المشكلات بصورة مستقلة، ويصلح أخطاء البناء، ويراجع طلبات الدمج (pull requests)، دون أن يطلب صلاحيات زائدة ودون أن يُجري أي تغيير من دون موافقة صريحة.

كيف يتعامل الوكيل مع الحوادث

يراقب Vercel Agent السجلات والمقاييس وسجل عمليات النشر باستمرار. وعندما يتعطل شيء ما، كأن يُنشر في الساعة 23:00 إصدار معيب فيبدأ المسار `/checkout` بإرجاع أخطاء 500، يقرأ الوكيل آثار المكدس (stack traces) ويربطها بالكوميت المحدد ويقترح التراجع قبل أن يتمكن مهندس المناوبة من فتح حاسوبه المحمول. ووفق بيانات Vercel، التي اختبرت الوكيل على عمليات النشر الخاصة بها طوال عدة أشهر، يقل الزمن الفاصل بين التنبيه والتخفيف من الأثر في هذا السيناريو عن ثلاث دقائق.

أبرز الحقائق:

• النسخة التجريبية العامة — 9 يوليو 2026
• الوكيل متاح عبر Vercel Dashboard وGitHub وCLI
• يعمل افتراضيًا في وضع القراءة فقط (read-only)
• يعمل بهوية مستقلة خاصة به — `vercel-agent`، وليس باسم المستخدم
• التراجع وفتح طلب الدمج (PR) وتعديل الإعدادات — فقط بعد موافقة صريحة

ما الذي يميز نموذج الأمان؟

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

اعتمدت Vercel مسارًا ثالثًا. يعمل Vercel Agent بوصفه جهة مستقلة (principal) باسم `vercel-agent`، وليس تحت حسابك. وتُسجَّل كل خطوة يتخذها على حدة: من طلبها، ومن وافق عليها، وما الذي حدث بالضبط. ولا يحصل الوكيل إلا على الصلاحيات التي منحتها له صراحةً ضمن خطة عمل محددة.

«الصلاحيات التي تمنحها للوكيل هي مخاطرة تتحمّلها»، بحسب فريق

Vercel.

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

ما الذي يمكن تكليف الوكيل به مباشرة

إلى جانب المراقبة المستقلة، يمكن استخدام الوكيل بصورة مباشرة في المهام التالية:

• مراجعة طلب الدمج — يكتشف تراجعات الأداء والتغييرات المحفوفة بالمخاطر التي لا يلتقطها نظام التكامل المستمر (CI) المعتاد
• تتبع ارتفاع التكاليف — يحدد سبب ارتفاع الفاتورة (مثلًا، صفحة تُعرض على الخادم مع كل طلب بدلًا من التخزين المؤقت) ويقترح طلب دمج يتضمن الإصلاح
• إصلاح البناء المعطّل — يقرأ السجلات ويحدد الإعداد المسبب للمشكلة ويختبر التعديل في بيئة معزولة (sandbox) ثم يطلب إذنًا بتطبيقه
• الفحص قبل الإصدار — يحلل علم الميزة (feature flag) من خلال الشيفرة والمقاييس الحية ويبيّن ما إذا كان طرحها آمنًا

ماذا يعني ذلك

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

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

متى يتصرف الوكيل من تلقاء نفسه ومتى ينتظر الموافقة؟

يعمل Vercel Agent افتراضيًا في وضع القراءة فقط: يقرأ السجلات والمقاييس وعمليات النشر بنفسه، ويضع خطة ويقترحها. أما التراجع أو تعديل الإعدادات أو فتح طلب دمج (PR) فتُنفَّذ فقط بعد تأكيد صريح، عبر Dashboard أو GitHub أو CLI.

بماذا يختلف

Vercel Agent عن مساعد الذكاء الاصطناعي في بيئة التطوير المتكاملة (IDE)؟

الوكيل مدمج في بنية Vercel التحتية، ويصل مباشرة إلى السجلات والمقاييس وسجل عمليات النشر الفعلية دون نقل البيانات يدويًا. كما يستطيع، بعد الموافقة، تنفيذ عمليات فعلية على البنية التحتية (تراجع، PR، إعدادات)، وليس الاكتفاء بتقديم النصائح.

كيف يحقق الذكاء الاصطناعي في حوادث بيئة الإنتاج؟

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

هل يستطيع الذكاء الاصطناعي تغيير الشيفرة دون موافقة؟

لا. لا يطلب Vercel Agent صلاحيات زائدة ولا يمس أي شيء دون موافقة صريحة؛ فجميع الإجراءات الحرجة تتطلب تأكيدًا.