Google تطلق colab-mcp: كيف تؤتمت وكلاء الذكاء الاصطناعي دفاتر Colab في بيئات الإنتاج

أطلقت Google خادم colab-mcp المفتوح المصدر، الذي يتيح لوكلاء الذكاء الاصطناعي إدارة دفاتر Google Colab عبر MCP وتنفيذ الشيفرة في بيئة التشغيل (runtime) دون عمل يدوي في الواجهة.

كيف يعمل colab-mcp

colab-mcp هو خادم MCP لـ Google Colab يحوّل الدفتر العامل في المتصفح إلى بيئة عمل قابلة للبرمجة. لا يقتصر دور الوكيل على قراءة بنية الدفتر، بل يستطيع أيضاً إضافة الخلايا وتشغيل الشيفرة واستلام النتائج في صورة استدعاءات أدوات (tool calls) عادية. يوضح الشرح كيف يُبنى هذا النموذج بدءاً من سجل أدوات أساسي وصولاً إلى خادم متكامل على FastMCP، كي يفهم المطوّر ليس واجهة API فحسب، بل الآلية الداخلية لتسجيل الأدوات وJSON Schema والتوزيع غير المتزامن للاستدعاءات.

يبدأ المؤلفون بـ MCPToolRegistry بسيط مكتوب يدوياً بلغة Python. يتضح من هذا المثال كيف تتحول الدالة إلى أداة، وكيف يُشتق مخطط المعاملات من تلميحات الأنواع (type hints)، وكيف يستدعي العميل الأداة بالاسم مع الوسائط. هذه المقاربة مفيدة خارج Colab أيضاً: فهي تشرح النموذج الأساسي لـ MCP بلا سحر الإطار البرمجي، وتساعد على فهم ما يفعله FastMCP فعلياً حين تُعرض على الوكيل قائمة الإجراءات المتاحة.

ويُركَّز بشكل خاص على أن Google تعتمد بنية ثنائية الأوضاع. في وضع Session Proxy Mode يعمل الوكيل عبر جسر WebSocket بين عميل MCP المحلي وCollab المفتوح في المتصفح. أما في Runtime Mode فيتصل مباشرة بالنواة (kernel) وينفّذ شيفرة Python دون أي إجراءات بصرية في الواجهة. هذا الفصل مهم: الوضع الأول مناسب للعمل التفاعلي مع الدفتر، والثاني لسيناريوهات headless التي تتطلب تشغيل الحسابات مباشرة وتنفيذاً مستقراً للشيفرة على جانب بيئة التشغيل.

خمس خطوات نحو وكيل

ينقسم الجزء العملي إلى خمس كتل مستقلة تنتقل من العرض التجريبي إلى أنماط الإنتاج. يبني المؤلف أولاً سجل MCP بسيطاً يدوياً ويسجّل فيه أدوات مثل execute_code وadd_code_cell وadd_text_cell وget_cells. ثم يُنقل النهج نفسه إلى FastMCP، حيث يُشغَّل خادم أكثر واقعية بمجموعة من أدوات proxy وruntime. وهكذا لا نحصل على بنية مجردة، بل على مسار متدرج: نفهم البروتوكول أولاً، ثم نستبدل التفاصيل محلية الصنع ببنية تحتية عاملة.

بعد ذلك يعرض الشرح كيف تبدو الصلة الحية بين الوكيل وColab. يُشغَّل في المثال خادم WebSocket محمي برمز (token)، ويُحاكى اتصال عميل المتصفح، ويُتحقق من مرور استدعاءات JSON-RPC بين الواجهة الأمامية وعميل MCP. ثم يُبنى محرك runtime يحتفظ بحالة دائمة، ويعتمد التهيئة الكسولة (lazy initialization)، ويعالج المخرجات على طريقة Jupyter. أي إن الوكيل لا يرى مجرد حقيقة تنفيذ الشيفرة، بل نتيجة منظَّمة وأخطاء وبيانات وسيطة يمكنه البناء عليها في الخطوة التالية.

المستوى التالي هو حلقة وكيل متكاملة. يتلقى الوكيل مهمة بلغة طبيعية، ويختار الأداة المناسبة، وينفّذ الشيفرة، ويحلّل النتيجة، ويتخذ خطوة إضافية عند الحاجة. وبحسب المؤلفين، هذا هو النمط المستخدم في الربط الفعلي مع Claude Code وGemini CLI. وبذلك يصبح Colab خلفية حسابية (backend) يديرها نموذج LLM كجزء من مسار العمل العام، بدلاً من أن يكون علامة تبويب منفصلة للعمل اليدوي.

• سجل MCP أساسي وتوليد المخططات
• الانتقال إلى FastMCP وخادم أكثر واقعية
• Session Proxy Mode مع WebSocket ورمز مصادقة وJSON-RPC
• Runtime Mode مع تنفيذ مباشر للشيفرة وحفظ حالة النواة
• حلقة وكيل كاملة مع اختيار الأدوات وتحليل النتائج

الموثوقية والتشغيل

أكثر الأجزاء عملية هو تنسيق الإنتاج فوق بيئة التشغيل. تعرض المقالة RobustNotebookOrchestrator الذي يضيف إعادة محاولة تلقائية مع exponential backoff، ومهلاً زمنية عبر asyncio.wait_for، وتنفيذاً للخلايا يراعي التبعيات. إذا فشلت خلية واحدة يمكن تخطي الخطوات اللاحقة المعتمدة عليها، ويمكن تشغيل كتل معينة بالقوة عند الحاجة. هذا النهج مفيد للدفاتر الطويلة ومهام GPU وخطوط المعالجة (pipelines)، حيث لا ينبغي لخطأ في المنتصف أن يعطّل العملية كلها بصورة غير متوقعة، بل أن يُحصر ويُسجَّل بشكل صحيح.

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

ويعرض المؤلف أيضاً طريقاً سريعاً للتشغيل دون تكامل كبير: تثبيت uv، وإضافة colab-mcp إلى إعدادات MCP، وفتح Colab في المتصفح، ثم إعطاء الوكيل أمراً بلغة طبيعية، مثل بناء دفتر لتحليل البيانات. وتُدعم العملاء المحليون الشائعون مثل Claude Code وGemini CLI وWindsurf، أما للوكلاء المخصصين فيُعرض قالب اتصال عبر API مع وصف الأدوات وحلقة معالجة tool_use. هذا يخفض عتبة الدخول: يمكن أولاً ربط عميل جاهز، ثم كتابة الطبقة الخاصة بالوكيل لاحقاً.

ماذا يعني ذلك

يدفع colab-mcp بـ Google Colab من نمط الدفتر اليدوي نحو بيئة قابلة للبرمجة لوكلاء الذكاء الاصطناعي. وبالنسبة للمطورين، هو طريق مباشر لأتمتة تحليل البيانات والتجارب وتدريب النماذج دون كتابة أتمتة منفصلة للواجهة ودون التنقل المستمر بين المحادثة والشيفرة والمتصفح. وإذا ترسّخت هذه الأداة في منظومة MCP، فقد يصبح Colab واحداً من أكثر الخلفيات الحسابية راحة لسيناريوهات الوكلاء.