Cloudflare OS: شرح منصة وكلاء الذكاء الاصطناعي مفتوحة المصدر

Cloudflare فتحت مصدر مساحة العمل الذكية التي بنتها لموظفيها. إليك ما بداخلها فعلاً.

Cloudflare OS منصة مفتوحة المصدر لمساحة عمل وكلاء ذكاء اصطناعي تعمل من داخل المتصفح، أطلقتها Cloudflare في 5 أغسطس 2026 برخصة Apache 2.0. ورغم الاسم، فهي ليست نظام تشغيل بالمعنى الذي نعرفه في Windows أو Linux — لا يوجد "kernel" يُقلع على عتاد فعلي. هي منصة مبنية بالكامل فوق Cloudflare Workers، تمنح كل موظف في الشركة وكيل ذكاء اصطناعي (AI Agent) خاصاً به، ومجموعة من موصلات "Gatekeeper" المُحكَمة للوصول إلى الأنظمة الداخلية، وقدرة على تحويل أي محادثة إلى تطبيق صغير قابل للمشاركة يُسمى Gadget — دون كتابة سطر كود واحد، أو مع كود كامل إن أردتَ تعديله بنفسك.

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

أنا مصطفى أمان، وفي مدونة وادي التكنولوجيا أكتب أدلة تقنية عملية عن الأدوات والبنية التحتية التي يستخدمها المتخصصون والمطورون فعلاً، لا مجرد أخبار منقولة. لنتعرّف على ماهية Cloudflare OS، وكيف بُنيت، وهل تستحق النشر في شركتك أو لا.

ما هو Cloudflare OS فعلاً (وليس ما يوحي به الاسم)؟

الاسم مُضلِّل عمداً، وCloudflare نفسها تعترف بذلك في ملف README الخاص بالمشروع. لا يوجد جدولة لدورات المعالج (Scheduler)، ولا برنامج تشغيل لنظام الملفات، ولا شجرة أجهزة. ما تحصل عليه بدلاً من ذلك أقرب إلى مزيج من Google Docs قابل للاستضافة الذاتية، وصندوق عزل للكود (Sandbox)، ووسيط صلاحيات — إلا أن كل مستند أو جدول بيانات أو تطبيق يبدأ كمحادثة مع وكيل ذكاء اصطناعي.

تستخدم Cloudflare مصطلح "نظام تشغيل" بمعنيين محددين، وبمجرد أن تفصل بينهما يصبح المنتج أكثر منطقية:

• نظام تشغيل للشركة، لا للحاسوب. المقصود أنه الطبقة التي يستخدمها الموظفون لإنجاز العمل بمساعدة الذكاء الاصطناعي، بأمان كافٍ ليطمئن فريق الأمن — بحسب تعبير Cloudflare نفسها.
• نظام تشغيل لأحمال عمل الذكاء الاصطناعي. تماماً كما تدير النواة التقليدية العمليات ووصولها للعتاد، فإن الخلفية البرمجية لـ Cloudflare OS (المسمّاة حرفياً workshop-backend في المستودع) تدير الوكلاء وتُنظّم وصولهم لبيانات الشركة والخدمات الخارجية.

كيف تترابط الطبقات الثلاث الأساسية في Cloudflare OS — كل طلب من الوكيل يمرّ عبر طبقة Gatekeeper قبل الوصول لأي نظام خارجي.

عملياً، تتكوّن المنصة من ثلاث قطع:

1. مساحة عمل الوكيل (Agent Workspace). واجهة محادثة تعمل من المتصفح، يكون فيها الوكيل مُلمّاً بالمهارات والسياق الذي جهّزته شركتك، وقادراً على كتابة الكود وتشغيله في بيئة معزولة.
2. إطار الأمان والحوكمة. نظام Gatekeeper، الذي يُنظّم كل طلب واحد يقوم به الوكيل أو التطبيق خارج حدود صندوق العزل الخاص به.
3. Gadgets. تطبيقات شخصية قابلة للتعديل — ما يبدأ بطلب مثل "لخّص لي هذا الجدول" قد يتحوّل إلى أداة داخلية صغيرة يستخدمها فريق كامل ويستمر في تعديلها بمجرد التحدث مع الوكيل.

بنى المشروعَ Kenton Varda، أحد مهندسي Cloudflare Workers نفسها، وقد صرّح بوضوح أن المشروع امتداد روحي لمشروع Sandstorm.io، وهو مشروع عزل سحابي شخصي عمل عليه قبل عقد من الزمن. إن كنتَ تتابع منصة Cloudflare اللاخادمية، فهذا التاريخ يفسّر كثيراً من قرارات التصميم هنا — خصوصاً ما يتعلق بالعزل. وإن كنتَ مهتماً بالاتجاه الأوسع لوكلاء الذكاء الاصطناعي الذين يعملون معاً بشكل مستقل، فإن دليلنا عن بناء فريق من وكلاء الذكاء الاصطناعي يغطي المفاهيم الأساسية التي تحوّلها منصات مثل Cloudflare OS الآن إلى منتج فعلي.

Gadgets: تطبيقات تُبنى وتُعدَّل عبر المحادثة

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

كل Gadget يعمل داخل بيئة عزل خاصة به: الكود الذي يعمل على الخادم يُنفَّذ داخل Dynamic Worker مع تعطيل الاتصال الخارجي افتراضياً، والكود الذي يعمل على المتصفح يُنفَّذ داخل إطار متصفح معزول (Sandboxed Frame). لا يستطيع أي منهما الوصول للإنترنت المفتوح، ولا لأنظمتك الداخلية، إلا إذا منحته صلاحية صريحة عبر Gatekeeper. هذا المبدأ — "يبدأ بلا صلاحية وصول لأي شيء" — هو أهم قرار تصميمي في المنصة بأكملها، وكل شيء آخر مبني حوله.

دورة حياة الـ Gadget: يُنشئه الوكيل من محادثة، يبقى كتطبيق معزول دائم، ويمكن مشاركته كأداة حيّة أو تصديره كـ Blueprint قابل لإعادة الاستخدام.

Gatekeepers: كيف يؤمّن Cloudflare OS وصول الوكلاء فعلياً

إذا سبق أن بنيتَ شيئاً باستخدام Model Context Protocol (المعروف اختصاراً بـ MCP)، فستشعر أن Gatekeepers مألوفة للوهلة الأولى — وخوادم MCP مدعومة فعلاً كنوع واحد من أنواع Gatekeeper. لكن النطاق هنا أوسع عمداً. الـ Gatekeeper هو Worker مخصص لخدمة واحدة، يقف بين الوكيل ونظام خارجي واحد: GitHub، قاعدة بيانات داخلية، ويكي الشركة، أياً كان. هو من يتولّى مصافحة OAuth، ويحمل بيانات الاعتماد (Credential)، وينفّذ السياسة التي ضبطتها، ويسجّل بالضبط ما تمت قراءته. إن لم تكن ملماً بكيفية عمل تدفقات المصادقة القائمة على OAuth، فإن دليلنا لأساسيات APIs يشرح المفاهيم الأساسية التي تُبنى عليها Gatekeepers.

الفارق المهم هنا هو شيء لا يمنحك إياه MCP وحده: بروتوكول MCP يخبرك أي أدوات يُسمح للوكيل باستدعائها. لكنه لا يخبرك أي صفوف، أو ملفات، أو مستودعات لمس الوكيل فعلياً أثناء استخدامه لتلك الأداة. الـ Gatekeeper يفعل ذلك. وجّه واحداً منها نحو GitHub، وستستطيع حصر الوكيل في مستودع واحد فقط، والسماح له بقراءة الـ issues دون الكود المصدري، وإخفاء حقول معينة، وفرض حدود معدل الطلبات، وطلب موافقة بشرية قبل فتح أي pull request — موافقات لا تُعطِّل، وفق تصريح Varda، إلا الإجراءات ذات التأثير الفعلي (الكتابة)، لا عمليات القراءة ضمن الموارد المصرَّح بها أصلاً. وإن كنتَ لا تزال تتعلّم أساسيات Git وGitHub التي يُبنى عليها هذا النوع من التكامل، فإن دليلنا للمبتدئين في Git وGitHub نقطة انطلاق جيدة قبل إعداد Gatekeeper لـ GitHub.

وهناك طبقة ثانية أراها جديدة فعلاً: تتبّع الملاحظة (Observation Tracking). كل مورد يقرأه الوكيل يُسجَّل، ويرافق ذلك السجل كل ما ينتجه الوكيل لاحقاً. إذا بنى الوكيل لوحة بيانات من جدول قاعدة بيانات حسّاس، وفتح زميل تلك اللوحة لاحقاً، فإن Cloudflare OS يعيد التحقق من صلاحيات ذلك الزميل مقابل البيانات الأصلية قبل عرض أي شيء له — وليس فقط مقابل اللوحة نفسها. هذا يسدّ ثغرة حقيقية: أن يجمع الوكيل بيانات من نظامين مختلفين ويسلّم النتيجة لشخص صلاحياته أقل مما تتطلبه البيانات، دون أي أثر لما لمسه فعلياً.

كيف يبدو إعداد Gatekeeper فعلياً؟

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

يُعرَّف الـ Gatekeeper كـ Worker بإعداد منظّم يحدّد الخدمة المستهدفة، وطريقة المصادقة، وقواعد النطاق، وسياسة الموافقة. يتبع الإعداد نمطاً تصريحياً (Declarative) — تصف فيه ما "يُسمح" للوكيل بفعله، وكل ما لم يُذكر صراحةً يُرفض افتراضياً. إليك مثالاً مبسّطاً لـ Gatekeeper خاص بـ GitHub، يمنح الوكيل وصولاً للقراءة فقط لمشكلات (issues) مستودع واحد:

// gatekeeper-config.ts — Gatekeeper للقراءة فقط من issues في GitHub
export default {
  name: "github-issues-readonly",
  service: "github",
  auth: {
    type: "oauth",
    scopes: ["repo:read"],
  },
  policy: {
    allowedResources: [
      "repos/your-org/your-repo/issues",
      "repos/your-org/your-repo/issues/comments",
    ],
    blockedFields: ["author.email"],      // إخفاء حقل محدد
    rateLimit: { requests: 100, windowSeconds: 3600 },
    requireApproval: {
      onWrite: true,              // موافقة بشرية لعمليات الكتابة
      onRead: false,              // القراءة تمر دون توقف
    },
  },
  observationTracking: true,          // تسجيل كل مورد يقرأه الوكيل
};

أهم الخصائص التي تستحق الفهم هنا:

• allowedResources — آلية تحديد النطاق. بدلاً من منح وصول لمنظمة GitHub كاملة، تحدّد بالضبط مسارات الـ API التي يمكن للوكيل لمسها. كل ما هو خارج هذه القائمة يُحظر بصمت — الوكيل لا يعلم حتى بوجود الباقي.
• blockedFields — إخفاء على مستوى الحقل. حتى ضمن الموارد المسموحة، يمكنك حجب حقول بيانات محددة قبل وصولها للوكيل. في هذا المثال، يُحذَف بريد صاحب الـ issue من كل استجابة.
• rateLimit — تقييد لكل Gatekeeper على حدة. منفصل تماماً عن أي حدود على النموذج نفسه — يتحكم في عدد الطلبات التي يستطيع الوكيل توجيهها لهذه الخدمة تحديداً ضمن نافذة زمنية معينة.
• requireApproval — مفتاح "الإنسان في الحلقة". ضبط onWrite: true يعني أن الوكيل يستطيع قراءة الـ issues بحرية، لكن أي تعديل — إنشاء issue، تعليق، فتح pull request — يُوضع في قائمة انتظار موافقة بشرية قبل تنفيذه.
• observationTracking — عند تفعيله، يُسجَّل كل مورد يقرأه الوكيل عبر هذا الـ Gatekeeper كـ "ملاحظة". ذلك السجل يرافق كل ما ينتجه الوكيل، بحيث تستطيع عمليات التحقق اللاحقة مراجعة صلاحيات المشاهد الأصلي.

بالنسبة لـ Gatekeepers القائمة على MCP تحديداً، فإن الإعداد يُغلّف تعريف خادم MCP الموجود عندك ويضيف طبقة السياسة فوقه. إن كنتَ تشغّل خوادم MCP بالفعل في بنيتك، فمسار الانتقال بسيط — تحتفظ بنفس تعريفات الأدوات وتضيف حولها نطاقاً وحدود معدل وقواعد موافقة. مقارنتنا بين MCP وAPI تشرح الفروقات الأساسية إن كنتَ لا تزال تقرر كيف يتناسب MCP مع بنيتك.

هل يمكنك فعلاً استضافة Cloudflare OS ذاتياً؟

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

• النشر على حساب Cloudflare الخاص بك. المسار الأسرع: شغّل os.cloudflare.app/deploy وستُنشئ Cloudflare OS نسختها على بنيتك التحتية، مستخدمةً Workers وDurable Objects وAI Gateway الخاصة بك لتوجيه النماذج. ستحتاج أيضاً لإعداد Cloudflare Access للمصادقة.
• تشغيلها بالكامل على خوادمك الخاصة. بما أن workerd، وهو بيئة تشغيل Workers نفسها، مفتوح المصدر، فإن Cloudflare OS يمكن تقنياً أن تعمل على بنية تحتية تتحكم بها بالكامل، دون أي اعتماد على سحابة Cloudflare إطلاقاً.

من واقع اختباري، المسار الثاني يعمل، لكن التجربة الأفضل — النشر بنقرة واحدة، AI Gateway المُدار، تكامل Access — مبنية بوضوح حول سحابة Cloudflare نفسها. لا أعتبر هذا نقداً بقدر ما هو منطق تجاري واضح: امنح البرنامج مجاناً، واربح من البنية التحتية التي يعمل عليها بأفضل شكل. إن كنتَ تقيّم هذا الخيار لشركة غارقة بالفعل في AWS أو Azure، فخصّص وقت هندسة حقيقياً لمسار الاستضافة الذاتية الكامل، لا النشر بنقرة واحدة. لنظرة أوسع على كيفية مقارنة بنية قواعد البيانات السحابية بين المزودين الكبار، تغطي مقارنتنا لقواعد البيانات السحابية بين AWS وAzure وGoogle Cloud المشهد الذي ستعمل ضمنه.

فيما يخص اختيار النموذج، لا تحصرك Cloudflare OS بمزوّد واحد. كل طلب استدلال يمرّ عبر AI Gateway، وهنا يكمن التحكم الإداري الفعلي — أي النماذج متاحة لأي فريق، ميزانيات الإنفاق لكل شخص أو فريق، حدود المعدل، وقواعد التوجيه التي تُرسِل المهام الروتينية لنماذج أرخص وأسرع بينما تحتفظ بالنماذج الأقوى للمهام التي تحتاج قدرة استدلال أعمق. إن كنتَ قد جرّبت بناء chatbot خاص بك على Workers AI من قبل، فسيبدو هذا امتداداً طبيعياً لنفس البنية التحتية — راجع دليلنا لبناء chatbot ذكاء اصطناعي على Cloudflare Workers AI إن لم تكن قد فعلتَ ذلك بعد.

المتطلبات والتكلفة التقديرية لتشغيل Cloudflare OS

شيء واحد لم أجد مقالة تشرحه بوضوح: ماذا تحتاج فعلياً — وكم ستدفع — قبل أن تُنجز Cloudflare OS أي شيء مفيد. المنصة مفتوحة المصدر ومجانية للنشر، لكن "مجانية للنشر" و"مجانية للتشغيل" أمران مختلفان بمجرد أن تبدأ تكاليف الاستدلال وDurable Objects وAI Gateway بالتراكم. إليك تفصيلاً صادقاً بناءً على نشري التجريبي الخاص.

ما تحتاجه قبل البدء

• حساب Cloudflare على خطة Workers المدفوعة (5 دولارات شهرياً). خطة Workers المجانية لها حدود صارمة على زمن المعالج (10 ملي ثانية لكل استدعاء) وعدد الطلبات، وستستنفدها Cloudflare OS بسرعة — خصوصاً مع تدخّل Durable Objects، وهي غير متاحة أصلاً في الخطة المجانية. اعتبر خطة Workers المدفوعة بـ 5 دولارات شهرياً حداً أدنى إلزامياً.
• تفعيل AI Gateway. هذه طبقة توجيه النماذج التي يمرّ عبرها كل استدعاء استدلال. AI Gateway نفسها مجانية للإعداد حالياً، لكن استدعاءات النماذج التي تمر عبرها تُحاسَب حسب المزوّد الذي تختاره — سواء نماذج Workers AI الخاصة بـ Cloudflare، أو OpenAI، أو Anthropic، أو أي مزوّد آخر مدعوم.
• Cloudflare Access (للمصادقة). إن كنتَ تنشر للفريق، تتولى Access الهوية وتسجيل الدخول. Access مشمولة في خطة Zero Trust المجانية حتى 50 مستخدماً. بعد ذلك، تنتقل لخطط Zero Trust المدفوعة.
• بيانات اعتماد API خارجية واحدة على الأقل لأي Gatekeeper تخطط لإعداده — رمز وصول شخصي لـ GitHub، سلسلة اتصال قاعدة بيانات، تسجيل تطبيق OAuth لويكي شركتك، إلخ. بدون Gatekeeper واحد متصل على الأقل، يبقى الوكيل محصوراً في صندوق عزله دون أي وصول لما هو خارجه.

التكلفة الشهرية التقديرية

الأرقام الدقيقة تعتمد بشكل كبير على حجم الفريق وكثافة الاستخدام، لكن إليك نطاقاً واقعياً لفريق صغير (5–15 مستخدماً) بناءً على ما لاحظته:

إن كنتَ تخطط لتشغيل المسار المستضاف ذاتياً بالكامل عبر workerd دون أي اعتماد على سحابة Cloudflare، فستختفي تكاليف Workers وDurable Objects وAccess — لكنك ستحتاج لتوفير قدرتك الحاسوبية الخاصة، وطبقة مصادقتك الخاصة، وبنية توجيه النماذج الخاصة بك. للفرق التي تشغّل بيئات homelab افتراضية بالفعل، تساعدك مقارنتنا بين VMware وProxmox في اختيار المُحاكي الافتراضي (Hypervisor) المناسب لتشغيلها عليه.

كيف تقارَن Cloudflare OS بما تستخدمه على الأرجح الآن؟

معظم الفرق التي تقيّم هذا الخيار لا تبدأ من الصفر — هي تستخدم شيئاً بالفعل. إليك كيف يختلف نهج Cloudflare OS عن أشيع إعدادين أصادفهما.

مقارنة بإعداد وكلاء بسيط قائم على MCP. إن كنتَ قد وصّلتَ وكيلاً بعدة خوادم MCP، فلديك بالفعل وصول للأدوات. ما تفتقر إليه على الأرجح هو طبقة صلاحيات تتتبّع مصدر البيانات — أي سجلات لمسها الوكيل فعلياً — أو قائمة انتظار موافقة تقاطع الوكيل فقط عند الكتابة. تضيف Gatekeepers في Cloudflare OS طبقة الحوكمة هذه فوق (وحرفياً حول، بالنسبة لخوادم MCP) نفس الفكرة. إن كنتَ لا تزال تقرر كيف يتناسب MCP مع بنيتك أصلاً، فإن مقارنتنا بين MCP وAPI نقطة انطلاق جيدة قبل تقييم Gatekeepers فوقه.

مقارنة بأداة أتمتة بلا كود. منصات مبنية حول مُنشئ سير عمل مرئي ممتازة في "عندما يحدث X، نفّذ Y"، لكنها ليست مصممة لتسليم الوكيل صندوق عزل وتركه يكتب كوداً حراً لأداة داخلية لمرة واحدة. تدعم Cloudflare OS الوضعين صراحةً — سير عمل حتمي للتسلسلات المعروفة والمتكررة، وجلسات وكيل مفتوحة للعمل الأكثر فوضوية والمعتمد على الحكم البشري. إن كنتَ تشغّل أتمتات مجدولة حالياً، فيغطي دليلنا لأتمتة n8n النهج القائم على سير العمل الذي تقترب منه ميزة workflows في Cloudflare OS مفاهيمياً.

جدول مقارنة الميزات

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

إن كان اهتمامك بـ Cloudflare OS نابعاً من رغبتك في أن تسترجع الوكلاء معلومات دقيقة من مستنداتك الخاصة بدلاً من الهلوسة، فيستحق فهم طبقة الاسترجاع الكامنة تحت أي من هذه الأدوات أولاً — يشرح دليلنا لشرح RAG بالضبط كيف يعمل هذا التأسيس. وللتفريق بين نماذج الذكاء الاصطناعي الكامنة وراء هذه الأدوات، توفّر مقارنتنا بين Machine Learning وDeep Learning وGenerative AI الأساس المفاهيمي.

من يجب أن ينشرها فعلياً الآن؟

بناءً على ما هو موجود في المستودع اليوم، أقسّم الأمر كالتالي:

• يستحق التجربة الآن: الفرق التي تشغّل بالفعل أحمال عمل إنتاجية على Cloudflare Workers، وفرق تقنية المعلومات/الأمن التي تريد طريقة محكومة تسمح للموظفين غير التقنيين ببناء أدوات داخلية صغيرة دون فتح تذكرة دعم لكل واحدة منها.
• يستحق الاختبار في مختبر، لا في الإنتاج: أي شخص يقيّمها كمنصة وكلاء عامة الغرض. تصفها Cloudflare نفسها بأنها وصول مبكر — أول تعديل بعد الإطلاق في المستودع كان إصلاح خطأ في تسجيل الخروج، وصرّح القائمون عليها أن إعادة كتابة كاملة (v2) مخططة. الحواف الخشنة متوقعة ومُعترَف بها.
• ربما ليست الخيار المناسب بعد: المنظمات التي لا بصمة لها على Cloudflare أصلاً، ولا رغبة لديها في إدارة Gatekeepers قائمة على OAuth لكل تكامل. مسار الاستضافة الذاتية في مكان آخر موجود، لكنه ليس التجربة المصقولة.

5 أخطاء يجب تجنّبها عند تقييم Cloudflare OS

1. الافتراض أن "مفتوحة المصدر" تعني "تعمل في أي مكان بنفس الجودة". تعمل تقنياً على workerd المفتوحة المصدر، لكن أدوات النشر وتكامل AI Gateway والمصادقة عبر Access مبنية جميعاً لسحابة Cloudflare أولاً. خطّط وفقاً لذلك.
2. نشر Gatekeeper بصلاحيات أوسع مما تحتاجه المهمة. نموذج الأمان بأكمله يعتمد على تحديد النطاق — مستودع واحد بدلاً من منظمة GitHub كاملة، قراءة فقط بدلاً من قراءة وكتابة. تعامل مع كل Gatekeeper جديد كما تتعامل مع تطبيق OAuth جديد يطلب صلاحيات.
3. معاملتها كجاهزة للإنتاج من اليوم الأول. هي وصول مبكر بحسب اعتراف Cloudflare نفسها. شغّلها في مختبر أو حالة استخدام داخلية منخفضة المخاطر قبل أن تثق بها في أي شيء يواجه العملاء.
4. تجاهل ضوابط إنفاق النماذج. بما أن AI Gateway تسمح لأي فريق بتشغيل وكلاء، اضبط ميزانيات وحدود معدل لكل شخص أو فريق من اليوم الأول — لا بعد أول فاتورة مفاجئة.
5. الخلط بين Gadgets والسكريبتات المُولَّدة. الـ Gadget كائن دائم، قابل للمشاركة، له صلاحياته الخاصة. لا تتخطَّ إعداد قواعد المشاركة والوصول فقط لأنها بدأت كطلب سريع لمرة واحدة.

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

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