Cloudflare تفتح مصدر Cloudflare OS لبناء وكلاء وتطبيقات داخلية بضوابط وصول دقيقة

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

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

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

لذلك أعادت الشركة بناء Cloudflare OS بحيث تكون الحوكمة الأمنية جزءاً من المنصة نفسها. يبدأ كل agent أو تطبيق بلا أي صلاحيات، ثم يمكن منحه وصولاً إلى مورد محدد عبر binding مكتوب النوع، مثل env.PROJECT، من دون أن يحصل على credential نفسه. كما تعمل شيفرة الخادم داخل Dynamic Worker مع تعطيل الاتصال الصادر بالإنترنت افتراضياً، فيما تعمل شيفرة العميل داخل sandbox في المتصفح.

تعتمد المنصة على مكوّنات تسمّيها Cloudflare باسم Gatekeepers. يعمل كل Gatekeeper كـ Worker مخصص لخدمة خارجية، يفهم API والموارد والعمليات المتاحة فيها، ويحتفظ ببيانات الاعتماد ويتولى OAuth وتطبيق السياسات وتسجيل ما تمت قراءته أو تنفيذه. وبدلاً من منح الوكيل وصولاً واسعاً إلى حساب GitHub مثلاً، يمكن للـ Gatekeeper قصره على Repository واحد، أو السماح بقراءة Issues دون source code، أو إخفاء حقول معينة، أو طلب موافقة قبل دمج Pull Request.

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

من جانب الإنتاجية، يمكن للـ workspace إجراء بحث وتحليل عبر كتابة كود للبحث والفلترة والربط، بدلاً من إدخال مجموعات بيانات كاملة في context window للنموذج. ويمكنه إنتاج مستندات وعروض وجداول بيانات تظل مرتبطة ببيانات حية، أو بناء تطبيقات تعاونية لها واجهة ومنطق وحالة مستقلة، أو تحويل المهام المعروفة إلى workflows حتمية في معظم خطواتها مع استخدام النموذج فقط حيث تكون الحاجة إلى الحكم أو التوليد.

التطبيقات التي ينشئها Cloudflare OS ليست نماذج أولية تحتاج إلى تصدير ونشر منفصل. كل تطبيق يتضمن client code وserver code وAPI وحالة دائمة. يُشغّل الخادم عند الطلب كـ Dynamic Worker ويُنشأ كـ Durable Object Facet، مع قاعدة SQLite خاصة بالتطبيق. وتتواصل واجهة المتصفح مع الخادم عبر Cap’n Web، نظام RPC مفتوح المصدر من Cloudflare قائم على object capabilities.

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

وتدعم المنصة استخدام أي نموذج، مع مرور طلبات inference عبر Cloudflare AI Gateway. يتيح ذلك للمؤسسة تحديد النماذج المتاحة، وتوجيه المهام إلى النموذج المناسب، ومتابعة الإنفاق بحسب الشخص أو الفريق أو workspace، مع ميزانيات وrate limits.

يتوفر Cloudflare OS الآن على GitHub عبر مستودعين: cloudflare-os للنواة، وcloudflare-os-starter كمثال للنشر مبني على طريقة تشغيل Cloudflare داخلياً. ويمكن للمؤسسات نشره في حساباتها واستخدام سياسات Cloudflare Access وإعدادات AI Gateway وتكاملاتها الخاصة. وتقول الشركة إنها تعمل أيضاً على تقديمه كمنتج مُدار داخل Cloudflare Dashboard، وإضافة containers لتدفقات عمل التطوير، وإتاحة workspaces ضمن Slack وأدوات محادثة أخرى.