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

المقدمة

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

النمط الأول هو وكيل البرمجة المحلي. Claude Code وCursor وWindsurf وGitHub Copilot CLI — هذه وكلاء ذكاء اصطناعي تعمل على جهاز المطور، وتصل إلى نظام الملفات المحلي، وتعزز سير عمل مستخدم واحد. إنها تفاعلية، قائمة على الجلسات، وشخصية بعمق. يكتب المطور طلباً، يعمل الوكيل، ثم يراجع المطور ويكرر العملية.

النمط الثاني هو الخدمة الوكيلية السحابية. Codex من OpenAI يطلق بيئات معزولة لكل مهمة. Cloud Agents من Cursor، التي أُطلقت في فبراير 2026، تعمل على أجهزة افتراضية مخصصة تبني البرمجيات وتختبرها وتسلم طلبات سحب جاهزة للدمج مع عروض فيديو توضيحية. وكيل البرمجة في GitHub Copilot، المتاح بشكل عام منذ سبتمبر 2025، يعمل بشكل غير متزامن في بيئات سحابية مدعومة بـ GitHub Actions. هذه خدمات مدعومة بالذكاء الاصطناعي منشورة في السحابة تعالج الطلبات برمجياً — تدير مهام التطوير، وتحلل المستندات، وتنسق سير العمل. إنها مستقلة، مدارة عبر واجهات برمجة التطبيقات (API)، ومتعددة المستأجرين.

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

نمط الوكيل المحلي

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

كيف يوسع الوكلاء المحليون قدراتهم

يعتمد الوكلاء المحليون على ثلاث آليات توسعة:

المهارات (Skills — ملفات تعليمات بصيغة Markdown) — ملفات نصية محلية تشفر الإجراءات والمعرفة المتخصصة والتعليمات المحددة. يقرأها الوكيل من القرص ويدمج محتواها في نافذة السياق الخاصة به. تبرز بنية من طبقتين في أنظمة الذكاء الاصطناعي الإنتاجية: المهارات تتعامل مع المعرفة والتوجيه السلوكي، بينما بروتوكولات الأدوات تتعامل مع التنفيذ. وفقاً لتحليل من The New Stack، يمكن لهذا الفصل أن يقلل تكاليف الرموز بشكل كبير مقارنة بترميز جميع التعليمات كتعريفات أدوات. نشرت Microsoft مستودعاً مفتوح المصدر للمهارات على GitHub، وتفهرس السجلات المجتمعية الآن آلاف ملفات المهارات القابلة لإعادة الاستخدام.

أدوات سطر الأوامر (CLI) والنصوص البرمجية — يمكن للوكيل تنفيذ أدوات سطر الأوامر التي ثبتها المطور وصادق عليها. Git وواجهات سطر الأوامر لمزودي السحابة ومديرو الحزم وأدوات البناء وأدوات التدقيق — مجموعة أدوات التطوير المحلية بأكملها متاحة. تستخدم هذه الأدوات أوراق اعتماد المطور الحالية، لذا لا توجد مصادقة إضافية للتكوين. GitHub Copilot CLI، الذي أصبح متاحاً بشكل عام في فبراير 2026، يجسد هذا النمط — وكيل أصلي في الطرفية يخطط ويبني ويراجع ويتذكر عبر الجلسات دون مغادرة سطر الأوامر.

خوادم MCP (اختياري) — يمكن للوكلاء المحليين الاتصال بخوادم Model Context Protocol للوصول إلى الخدمات البعيدة، لكن عملياً، العديد من حالات الاستخدام المحلية مغطاة بالكامل بالمهارات وأدوات CLI. يصبح MCP ذا صلة عندما يحتاج الوكيل إلى وصول منظم إلى مصادر بيانات بعيدة أو واجهات برمجة تطبيقات بدون مكافئات CLI.

لماذا يهيمن هذا النمط على سير عمل المطورين

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

هذه البساطة تفسر الاعتماد السريع لوكلاء البرمجة المحليين. محرك Cascade في Windsurf يفهرس قاعدة الكود المحلية بالكامل ويحتفظ بذاكرة مستمرة لبنية المشروع واتفاقيات البرمجة. Claude Code يقرأ ملفات المشروع وينفذ الأوامر مباشرة. لا توجد خطوة نشر، ولا بنية تحتية للتوفير، ولا مصادقة للتكوين بخلاف ما يملكه المطور بالفعل.

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

نمط الوكيل السحابي

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

النمط السحابي ينضج بسرعة. Cloud Agents من Cursor تعمل على أجهزة افتراضية معزولة، ووفقاً للشركة، فإن 30% من طلبات السحب المدمجة في Cursor تُنشئها الآن هذه الوكلاء. Codex من OpenAI يعمل في حاويات آمنة ومعزولة مع تعطيل الوصول إلى الإنترنت أثناء التنفيذ، مما يقصر التفاعل على الكود المقدم عبر المستودعات فقط. وكيل البرمجة في GitHub Copilot يتعامل مع المهام ذات التعقيد المنخفض إلى المتوسط بشكل غير متزامن في بيئات تطوير سحابية.

كيف يوسع الوكلاء السحابيون قدراتهم

يحتاج الوكلاء السحابيون إلى آليات توسعة مختلفة جذرياً:

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

مصادقة OAuth 2.1 — يخدم الوكلاء السحابيون مستخدمين متعددين، كل منهم بحساباته وصلاحياته الخاصة. مواصفات MCP، المحدثة في إصدارها المستقر بتاريخ 25 نوفمبر 2025، تصنف خوادم MCP كخوادم موارد OAuth 2.1. هذا يفرض مصادقة لكل مستخدم مع PKCE لجميع العملاء، بحيث تُعالج طلبات كل مستخدم بأوراق اعتماده الخاصة. يجب على العملاء تطبيق Resource Indicators (RFC 8707) لمنع سرقة الرموز من قبل خوادم خبيثة.

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

لماذا يفشل النمط المحلي هنا

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

مهارات كملفات محلية؟ لا يوجد نظام ملفات محلي مستمر. يعمل الوكيل السحابي في حاوية قد تُدمر وتُعاد إنشاؤها في أي وقت. يجب تجميع المهارات مع عملية النشر أو تحميلها من سجل — وليس قراءتها من قرص المطور.

أدوات CLI بأوراق اعتماد ضمنية؟ لا توجد أوراق اعتماد ضمنية. يخدم الوكيل السحابي مستخدمين كثيرين، كل منهم يحتاج مصادقته الخاصة. حساب خدمة مشترك بصلاحيات واسعة هو ثغرة أمنية. OAuth لكل مستخدم هو النهج المسؤول الوحيد.

جلسات طرفية تفاعلية؟ لا يوجد طرفية. يستقبل الوكيل السحابي طلبات API ويعيد استجابات API. لا يوجد إنسان في الحلقة لكل قرار. يجب أن يكون الوكيل مستقلاً بما يكفي للتعامل مع الطلبات دون توجيه، مع إعادة محاولات تلقائية وحلول بديلة ومعالجة أخطاء.

خمسة أبعاد للتباين

1. المصادقة

محلي: أوراق اعتماد المطور الحالية — مفاتيح SSH وملفات تعريف الارتباط في المتصفح ورموز CLI ومتغيرات البيئة — جميعها مكونة مرة واحدة وتستخدمها كل البرامج على الجهاز، بما في ذلك الوكيل.

سحابي: OAuth 2.1 لكل مستخدم. يجب مصادقة كل طلب وفقاً لصلاحيات المستخدم المحدد. دعم OAuth 2.1 المدمج في مواصفات MCP، مع PKCE الإلزامي وResource Indicators، صُمم خصيصاً لهذا النمط متعدد المستأجرين.

2. الوصول إلى البيانات

محلي: وصول مباشر إلى نظام الملفات. يقرأ الوكيل الكود والمستندات والتكوين مباشرة من القرص. صفر زمن استجابة شبكي. Windsurf يفهرس المشروع بالكامل باستخدام RAG على الملفات المحلية، ليبني فهماً مستمراً لقاعدة الكود.

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

3. إدارة الحالة

محلي: ضمنية. تحافظ جلسة الطرفية على الحالة. يرى المطور سجل المحادثة. الملفات على القرص تستمر بين الجلسات. نظام ذاكرة Windsurf يتعلم حتى اتفاقيات المشروع بشكل مستقل مع مرور الوقت.

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

4. التوسعة

محلي: مهارات (ملفات) + أدوات CLI (ملفات تنفيذية) + MCP اختياري. نموذج التوسعة أصلي لنظام الملفات. يمكن للمطور كتابة ملف Markdown بتعليمات النشر ويتبعها الوكيل فوراً.

سحابي: MCP (بروتوكول شبكي) + تكاملات API مخصصة. نموذج التوسعة أصلي للشبكة. نقل Streamable HTTP، المقدم في أوائل 2025، يجعل خوادم MCP قابلة للنشر كدوال بدون خادم، مما يقلل البنية التحتية إلى نقطة نهاية HTTP واحدة.

5. معالجة الأخطاء

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

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

منطقة التداخل: عندما تلتقي المهارات بـ MCP

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

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

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

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

التقارب القادم

رغم هذه الاختلافات، يتحرك النمطان نحو بعضهما البعض:

الوكلاء العاملون في الخلفية يطمسون الحدود. الوضع بدون واجهة (Headless) في Claude Code يعمل محلياً لكنه يعمل بشكل مستقل — لا إنسان في الحلقة عند كل خطوة. Cloud Agents من Cursor ووكيل البرمجة من GitHub Copilot يعملان في السحابة لكنهما يُفعّلان من قبل مطورين أفراد. الحدود بين المحلي والسحابي تصبح أقل عن مكان تشغيل الوكيل وأكثر عن من يخدم.

المهارات تصبح قابلة للتوزيع. مفهوم التعليمات المنظمة مع ملفات مرجعية ليس محلياً بطبيعته. مستودع المهارات المفتوح المصدر من Microsoft والسجلات المجتمعية تجعل المهارات قابلة للمشاركة عبر الفرق والوكلاء. نشرت Anthropic حزمة SDK بلغة Python لاستهلاك المهارات برمجياً، مما يمكّن الوكلاء السحابيين من الاستفادة من المعرفة القائمة على المهارات دون الوصول إلى نظام الملفات.

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

تنسيق متعدد الوكلاء يظهر. أفادت Gartner بارتفاع بنسبة 1,445% في الاستفسارات حول الأنظمة متعددة الوكلاء من الربع الأول 2024 إلى الربع الثاني 2025. نمط التخطيط والتنفيذ — حيث ينشئ نموذج قادر استراتيجية وتنفذ نماذج أرخص الخطوات الفردية — يُعتمد في الإنتاج، مع إبلاغ بعض الفرق عن تخفيضات كبيرة في التكاليف. يشارك كل من الوكلاء المحليين والسحابيين في سير العمل المنسقة هذه.

إرشادات عملية

ابنِ وكيلاً محلياً عندما:

• تعزز سير عمل مطور واحد
• يحتاج الوكيل وصولاً مباشراً لنظام الملفات للكود والتكوين
• التشغيل التفاعلي مع إنسان في الحلقة مقبول أو مرغوب
• يمكن الاستفادة من أدوات CLI وأوراق الاعتماد الحالية
• أمان الكود يتطلب إبقاء المصادر على جهاز المطور

ابنِ وكيلاً سحابياً عندما:

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

ابنِ كليهما عندما:

• يحتاج المطورون وكلاء برمجة (محلي) والمنتج يحتاج وكلاء خدمة مستقلين (سحابي)
• المعرفة المتخصصة المشفرة في المهارات يمكن أن تُفيد كلا النمطين
• خوادم MCP يمكنها خدمة كل من الوكلاء المحليين والسحابيين عبر نفس البروتوكول
• تريد المؤسسة وكلاء محليين لسرعة التطوير ووكلاء سحابيين لموثوقية الإنتاج

الخاتمة

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

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

المصادر والقراءات الإضافية

• Model Context Protocol OAuth 2.1 Authorization Specification — Anthropic
• Claude Code Skills Documentation — Anthropic
• How MCP Uses Streamable HTTP for Real-Time AI Tool Interaction — The New Stack
• Skills vs MCP: Agent Architecture — The New Stack
• Cursor Cloud Agents: Autonomous Coding on Virtual Machines — TechCrunch
• GitHub Copilot: Meet the New Coding Agent — GitHub Blog
• Introducing Codex — OpenAI
• Agentic AI: Design Reliable Workflows Across the Hybrid Cloud — Red Hat
• Google’s Eight Essential Multi-Agent Design Patterns — InfoQ
• Agentic AI Strategy — Deloitte Tech Trends 2026