لحظة يونكس في صناعة الروبوتات الشبيهة بالبشر
خطاب
قبل البداية
هذا الأسبوع ألقيت كلمة رئيسية مدتها 10 دقائق في المؤتمر الأول لشركاء الذكاء المجسّد التابع لـ China Mobile.
لم تكن كلمة طويلة جدًا، لكنها بالنسبة إلى BridgeDP كانت لحظة ثقيلة جدًا بالمعنى — للمرة الأولى نشرح بشكل كامل وعلني شيئًا كنّا قد فهمناه بوضوح خلال السنوات الثلاث الماضية.
تحدثنا عن هذا الموضوع داخليًا لفترة طويلة، وترددنا كثيرًا في ما إذا كان من المناسب أن نطرحه بهذا الشكل المبكر. لكننا قررنا في النهاية أن نقوله — لأننا نؤمن أكثر فأكثر بأن هذا ليس شأن شركة BridgeDP وحدها، بل هو أهم مشكلة بنيوية يواجهها قطاع الروبوتات البشرية بأكمله.
أريد هنا أن أوسّع ما قلته سابقًا وأكتبه بتفصيل أكبر. إذا كنت قد حضرت تلك الدقائق العشر في القاعة، فهذه النسخة هي "النسخة الموسعة" منها؛ وإذا لم تكن قد حضرت، فهذه ستكون أكمل.
والآن إلى النص.
16 شركة، الشيء نفسه
خلال الأشهر الثمانية عشر الماضية، شهدنا داخل الشركة أمرًا لم يلتفت إليه العالم الخارجي كثيرًا، لكننا نراه بالغ الأهمية —
قدرات التحكم الحركي من الصفر إلى الواحد لدى 16 شركة روبوتات بشرية أُنجزت هنا لدينا.
16 شركة، 16 خط منتجات مستقل، 16 فريقًا مختلفًا.
بينها أقسام أعمال روبوتات بشرية في شركات مدرجة، وشركات ناشئة بارزة حصلت على عدة جولات تمويل، ومشاريع خرجت من مؤسسات بحثية، وحتى شركات تكامل أنظمة مخضرمة دخلت إلى الروبوتات الثنائية الحركة من أشكال أخرى. مواردهم ونقطة انطلاقهم وأسلوبهم التقني كلها مختلفة جدًا.
لكننا رأينا أمرًا واحدًا — مهندسو الخوارزميات لديهم كانوا يعملون تقريبًا في الشيء نفسه تمامًا.
المشكلات التي يطرحونها على فريقنا الهندسي من النوع نفسه. سجلات الأخطاء التي يرسلونها إلينا متشابهة جدًا في البنية. وحتى طرق حل المشكلات في النهاية كانت تتقارب إلى عدد محدود من المسارات المتشابهة.
وبشكل محدد، كانوا جميعًا يحلون هذه الأمور:
تجريد العتاد: كيف نُوحّد واجهة يمكن للخوارزميات العليا أن تستدعيها، رغم اختلاف المفاصل والمحركات وأجهزة الاستشعار وترددات التحكم بين المنصات
التحكم الحركي: كيف ننشر السياسة/الاستراتيجية التي تم تدريبها بالتعلّم المعزز على روبوت حقيقي من دون مشاكل
مواءمة المحاكاة: كيف نجعل النموذج الذي يعمل جيدًا في المحاكاة يعمل جيدًا أيضًا على العتاد الحقيقي
تغذية البيانات الراجعة: كيف نعيد بيانات الروبوت من العالم الحقيقي إلى جولة التدريب التالية بحيث تتطور القدرات باستمرار
هذه الأمور الأربعة، تكاد كل شركة تصنع روبوتات بشرية تعمل عليها.
داخل كل فريق هندسي في هذه الشركات، 60% إلى 70% من الجهد البشري يُصرف على حل مشكلات تكاد تكون نفسها عند الآخرين تمامًا.
هذا الأمر جعلنا نتوقف طويلًا ونتأمل داخل الشركة.
لم نكن نفكر: "هذه فرصة تجارية" — فهذه فكرة قصيرة الأمد جدًا. ما كنا نفكر فيه هو:
لماذا يحدث هذا؟ لماذا 16 شركة مستقلة تمامًا تعمل على الشيء نفسه؟ هل حدث هذا في التاريخ من قبل؟ وإذا حدث، فكيف انتهت القصة؟
صدى التاريخ مرتين
في الحقيقة، هذا الأمر ليس غريبًا علينا.
في قطاع الحوسبة خلال النصف قرن الماضي، حدث السيناريو نفسه تقريبًا مرتين على الأقل.
قبل أكثر من نصف قرن: قبل ظهور Unix
في ستينيات وسبعينيات القرن العشرين، عصر الحواسيب المركزية. كانت IBM تكتب نظام تشغيلها بنفسها، وDEC تكتب نظام تشغيلها بنفسها، وBurroughs تكتب نظام تشغيلها بنفسها، وHoneywell تكتب نظام تشغيلها بنفسها. كل شركة حواسيب كانت تكتب لعتادها نظام تشغيل لا يعمل إلا على عتادها هي.
كان على مطوري التطبيقات، إذا انتقلوا إلى جهاز من شركة أخرى، أن يتعلموا من جديد تقريبًا أوامر النظام الجديدة، وصيغ الملفات الجديدة، وأدوات التطوير الجديدة. كانت قدرات قطاع الحوسبة بأكمله محبوسة داخل "الطبقات العمودية" الخاصة بكل شركة على حدة.
حتى جاء عام 1969، حين بدأ مهندسان من مختبرات بيل، Ken Thompson و Dennis Ritchie، بكتابة شيء أسمياه Unix. كانت فلسفة Unix بسيطة جدًا — بناء نظام تشغيل عابر للعتاد، قابل للنقل، ويمكن لأي شخص تعديله، ويمكن لأي شخص توسيعه.
لم يكن Unix "منتجًا" من شركة معينة؛ بل كان إعادة تعريف لمعنى "ما ينبغي أن يكون عليه نظام التشغيل". لقد حوّل "القطع المتفرقة" إلى "بنية تحتية".
والقصة بعد Unix نعرفها جميعًا اليوم: Linux و BSD و macOS و Android و iOS — فمعظم أنظمة التشغيل التي تعمل اليوم في العالم هي أحفاد مباشرون أو غير مباشرين لفلسفة Unix.
الانطلاقة الحقيقية لقطاع الحوسبة لم تبدأ بالترانزستور، بل بدأت بـ Unix.
قبل نحو 20 سنة: قبل ظهور Android
في بدايات القرن الحادي والعشرين، قبيل عصر الهواتف الذكية. كان لدى نوكيا Symbian، وكان لدى بلاك بيري BlackBerry OS، وكانت لدى موتورولا برمجياتها الخاصة، وكل شركة هواتف كانت تكتب لعتادها برمجيات لا تعمل إلا على عتادها هي.
كان من شبه المستحيل على مطوري التطبيقات أن يبنوا تطبيقًا يعمل على عدة هواتف في الوقت نفسه — إذ كان عليك تكييفه بشكل منفصل مع برمجيات كل شركة. وقد جرى حبس منظومة التطبيقات المحمولة داخل "الطبقات العمودية" الخاصة بكل شركة هواتف.
في عام 2008، أُطلق Android. لم يكن Android هاتفًا — بل كان نظام تشغيل يمكن لأي شركة هواتف أن تأخذه وتستخدمه، ويجب عليها أن تستخدم نفس الواجهة للاتصال بمنظومة التطبيقات.
والقصة بعد Android نعرفها أيضًا: منظومة التطبيقات المحمولة بأكملها احتاجت 5 سنوات فقط لتقطع الطريق الذي استغرق 20 سنة في منظومة تطبيقات الحواسيب الشخصية.
البنية نفسها مرتين
هاتان المرّتان من "لحظات نظام التشغيل" كانتا متطابقتين بشكل مذهل من حيث البنية:
كان هناك نموذج حوسبة جديد ينشأ (الحواسيب المركزية / الهواتف الذكية)
كانت كل شركة عتاد تعيد اختراع البرمجيات الأساسية نفسها
كانت العقبة الحقيقية في القطاع ليست "الخوارزميات ليست جيدة بما يكفي" أو "العتاد ليس قويًا بما يكفي"، بل في غياب طبقة بنية تحتية معترف بها على نطاق واسع، تتيح إعادة استخدام القدرة عبر أنواع مختلفة من العتاد
وعندما ظهرت تلك الطبقة، انطلق القطاع كله بسرعة تفوق ما سبق بكثير
وبعد تأمل طويل، استنتجنا أن: قطاع الروبوتات البشرية اليوم يقف في الموقع البنيوي نفسه تمامًا الذي وقفت فيه تلك المرّتان.
ما ينقص ليس الخوارزميات الأذكى
ماذا يعني هذا؟ استنتاجنا هو الآتي —
عصر الروبوتات البشرية لا ينقصه خوارزميات أذكى، بل ينقصه أن تصبح برمجيات الروبوتات أكثر عمومية.
أعرف أن هذه الجملة قد تبدو غير بديهية قليلًا.
خلال العامين الماضيين، تركزت أنظار القطاع كله تقريبًا على "الخوارزميات" — تعلم معزز أقوى، ونماذج VLA أكبر، وسياسات طرفية أكثر ذكاءً من البداية إلى النهاية. كل ورقة بحث جديدة، وكل عرض توضيحي جديد، كانت تدفع أنظار القطاع نحو فكرة أن "الأذكى أفضل".
لا ننكر أهمية أن تصبح الخوارزميات أذكى. لكن ما نريد قوله هو —
إذا كانت المشكلة الوحيدة التي تعوق قطاع الروبوتات البشرية اليوم هي أن "الخوارزميات ليست ذكية بما يكفي"، فسيتم حل هذه المشكلة طبيعيًا خلال 12 إلى 24 شهرًا — لأن سرعة تطور الخوارزميات هي من الأسرع في قطاع الذكاء الاصطناعي اليوم.
لكن إذا نظرت فعلًا إلى مقدار الجهد الذي تنفقه هذه الشركات الـ 16 كل يوم على الهندسة، فستجد أن الوقت الذي تقضيه في "جعل خوارزمية ذكية تعمل على روبوت حقيقي بثبات وأمان وقابلية للتكرار" أكبر بكثير من الوقت الذي تقضيه في "جعل الخوارزمية أذكى".
ولهذا أقول — ما ينقص ليس الخوارزميات الأذكى، بل أن تصبح البرمجيات أكثر عمومية.
الخوارزمية الذكية، إذا لم تعمل إلا على منصة معينة جدًا، وفي سيناريو معين جدًا، وخلال فترة معينة جدًا — فإن قيمتها بالنسبة إلى القطاع كله تبقى محدودة.
فقط عندما يمكن لخوارزمية ذكية أن تُنشر عبر منصات مختلفة، وتُنفَّذ بثبات على مستوى أجزاء الألف من الثانية، وتظل متوافقة باستمرار مع العالم الحقيقي، عندها تصبح فعلًا "قدرة صناعية".
ولكي يتحقق ذلك، يحتاج هذا القطاع إلى "نظام تشغيل".
واليوم نحن نعتقد —
"لحظة Unix لقطاع الروبوتات البشرية تحدث الآن."
هذه هي الجملة التي قلتها في الخطاب، وهي أيضًا الفكرة الأساسية التي تريد هذه المقالة كلها أن تقولها.
ما ليس هو
إذن، ما هو نظام التشغيل في عصر الروبوتات البشرية؟
هذا سؤال أصعب من سؤال "ما ليس هو". لأن في القطاع اليوم عدة أسماء مألوفة لدى الجميع، ومن السهل جدًا أن يظن المرء أن "ذلك الشيء هو نظام التشغيل".
لذلك أريد أن أبدأ بثلاثة أشياء ليست هي.
ليس ROS
ROS أداة ممتازة جدًا. كثير من مهندسينا داخل الشركة نشؤوا أصلًا في عالم ROS، ونحن نكنّ له احترامًا كبيرًا.
لكن ROS ليس نظام التشغيل لعصر الروبوتات البشرية.
ROS في جوهره إطار اتصال بين الوحدات، يتيح دمج وحدات الإدراك والتخطيط والتحكم وغيرها داخل نظام الروبوت. وقد نشأ من استكشافات مجتمع الأبحاث في حدود 2007، وكان التجريد الأساسي فيه هو Node/Topic/Service، أي آلية تمرير رسائل مبنية على النشر والاشتراك.
هذه الفكرة بحد ذاتها ممتازة. لكنها لم تُصمَّم يومًا للنشر على نطاق إنتاجي واسع — فهي لا تحل مشكلة التجريد عبر العتاد، ولا تحل مشكلة التحكم الآني على مستوى أجزاء الألف من الثانية، ولا تحل مشكلة تراكم القدرات عبر منصات مختلفة.
دور ROS في عصرنا يشبه دور "الأنابيب (pipe)" في بدايات Unix — آلية اتصال مفيدة، لكنها ليست نظام التشغيل نفسه.
ليس NVIDIA Isaac
Isaac أيضًا منتج ممتاز جدًا. فهو، في المحاكاة والتدريب والبيانات الاصطناعية، يقدم للقطاع كله بنية تحتية مهمة للغاية.
لكن Isaac ليس نظام التشغيل لعصر الروبوتات البشرية.
Isaac هو منصة وقت التدريب (Training-time) — فهو يتيح لروبوت في العالم الافتراضي أن يتعلم أداء مهمة ما. وحدود قدرته تنتهي عند "التدريب" و"المحاكاة".
لكنه لا يحل مشكلة واحدة — كيف يعمل روبوت حقيقي، في مصنع حقيقي، أو منزل حقيقي، أو طريق حقيقي، كل مللي ثانية، وكل يوم، وكل سنة.
وهنا يوجد تمييز يُستهان به بشدة في القطاع — وقت التدريب (Training-time) ووقت التشغيل (Runtime) شيئان مختلفان تمامًا.
أن تجعل الروبوت "يتعلم" حركة ما، وأن تجعله في العالم الفيزيائي الحقيقي يمشي بثبات، ويتحرك بأمان، ويستمر في الأداء — فهذان مشكلتان هندسيتان مختلفتان، ويتطلبان قدرات نظامية مختلفة.
Isaac يقوم بجانب "وقت التدريب" على نحو متين جدًا. لكن في جانب "وقت التشغيل"، لا يوجد اليوم جواب معترف به على نطاق واسع في القطاع.
ليس نموذج VLA الكبير
نماذج VLA (Vision-Language-Action) الكبيرة هي أحد أكثر الاتجاهات التي لفتت الانتباه في قطاع الروبوتات البشرية من 2024 إلى 2026. وتعمل على هذا الاتجاه شركات مثل Physical Intelligence وGoogle DeepMind وGalbot وZhiyuan، إلى جانب فرق ممتازة كثيرة أخرى.
لكن نموذج VLA الكبير ليس أيضًا نظام التشغيل لعصر الروبوتات البشرية.
النموذج الكبير VLA يقوم بشيء مهم جدًا — إنه يحل مسألة "ماذا يجب أن يفعل الروبوت". فإذا أُعطيَ أمرًا لغويًا ومدخلًا بصريًا، يخرج النموذج نية حركة عالية المستوى.
هذا هو العقل الإدراكي للروبوت. وهو أمر بالغ الأهمية. لكنه لا يحل نوعًا آخر من المشكلات —
بعد إعطاء تلك النية العالية المستوى، كيف نحوّلها إلى خرج عزم مفاصل مستقر على مستوى أجزاء الألف من الثانية؟ كيف نضمن أثناء التنفيذ ألا يسقط الروبوت، وألا يؤذي الناس، وألا يتلف نفسه؟ كيف نحافظ على الثبات في التشغيل 24/7؟ وكيف نواصل العمل رغم تآكل العتاد، وانجراف الحساسات، وتغير البيئة؟
هذا النوع من المشكلات لم تحله نماذج VLA الكبيرة، ولا تنوي أن تحله — لأنها تعالج طبقة "ماذا نفعل".
ولكي يتحول عقل يعرف "ماذا يفعل" إلى روبوت قادر فعلًا على "الأداء بثبات وأمان واستمرار"، نحتاج إلى حزمة كاملة من القدرات النظامية بينهما. وهذه الحزمة لا يوجد لها اليوم اسم متفق عليه على نطاق القطاع.
فما هو بالضبط
بعد أن تحدثنا عن ثلاثة أشياء "ليست هي"، لنتحدث عما هي.
نحن نسميه — Runtime Robot OS، أي نظام تشغيل الروبوت وقت التشغيل.
وفي هذا الاسم كلمة مفتاحية: "Runtime" — وقت التشغيل.
وهي تقابل مفهوم "وقت التدريب". وقت التدريب يهتم بسؤال: هل يمكن للروبوت أن يتعلم؟ بينما يهتم وقت التشغيل بسؤال: هل يمكن للروبوت أن يعمل في العالم الحقيقي؟ هاتان مهمتان متساويتان في الأهمية، لكنهما مشكلتان مختلفتان، وتحتاجان إلى نظامين مختلفين.
يجب أن يمتلك Runtime Robot OS ثلاث خصائص في آن واحد:
تجريد عتادي عبر المنصات (Multi-Embodiment Abstraction)
يجب أن يتيح للسياسات والنماذج والتطبيقات العليا ألا تشعر باختلافات العتاد السفلي — سواء كانت المنصة ثنائية الحركة أو رباعية أو بعجلات وأرجل، وسواء كانت المفاصل مباشرة الدفع أو مدفوعة بمخفضات، وسواء اختلفت تشكيلات الحساسات، يجب أن يصل إليها المستوى العلوي بطريقة موحّدة.
وفي التاريخ، قامت أنظمة التشغيل بهذا مرتين من قبل:
أنظمة تشغيل الحواسيب الشخصية جعلت التطبيقات لا تشعر بما إذا كانت وحدة المعالجة Intel أو AMD، ولا بنوع البطاقة الرسومية
أنظمة تشغيل الهواتف جعلت التطبيقات لا تشعر بأي شركة هواتف صُنع العتاد لديها
وعلى Runtime Robot OS أن يقوم بهذه المرة الثالثة — أن يجعل تطبيقات الروبوت لا تشعر بأي منصة ينتمي إليها الروبوت.
تنفيذ آمن في الوقت الحقيقي على مستوى أجزاء الألف من الثانية (Real-time Safe Execution)
يجب أن يكون قادرًا، على مستوى كل مللي ثانية — وليس كل ثانية، ولا كل 100 مللي ثانية — على ضمان أن خرج عزم المفاصل، وقيود التحكم بالقوة، وحدود الأمان، كلها مستقرة، ويمكن التنبؤ بها، ولا تخرج عن السيطرة.
وهنا يكمن أكبر فرق بين الروبوت و"البرمجيات العادية" — البرمجية العادية إذا علقت قليلًا فالمستخدم يعيد تشغيلها وينتهي الأمر؛ أما الروبوت إذا علِق قليلًا فقد يؤذي إنسانًا أو نفسه أو البيئة.
الأمان الزمني الحقيقي على مستوى أجزاء الألف من الثانية هو الحد الأدنى الصارم لـ Runtime Robot OS.
قدرة تعلم تتوافق باستمرار مع العالم الحقيقي (Continual Real-world Alignment)
الروبوت ليس جهازًا يُبرمج مرة واحدة ثم يبقى كما هو إلى الأبد. فهو يعمل في العالم الحقيقي، والحساسات تنحرف، والعتاد يتآكل، والبيئة تتغير، والمهام تتطور.
يجب أن يمتلك Runtime Robot OS القدرة على ترسيخ خبرة كل روبوت في العالم الحقيقي، وإعادة تدويرها إلى الخلف، وتدريبها كقدرة من الجيل التالي، ثم دفعها بأمان إلى جميع الروبوتات.
هذه هي "الحديقة الدوارة للبيانات" الحقيقية في عصر الروبوتات. وهي ليست الشيء نفسه مثل "التعلّم المعزز من ردود فعل المستخدمين" في قطاع النماذج الكبيرة اليوم — فهناك النص، وهنا الفيزياء.
هذه الأشياء الثلاثة لم ينجزها أي نظام موجود اليوم مجتمعةً في آن واحد.
قام ROS بجزء من تجريد الاتصال، لكنه لا يملك القدرة عبر المنصات ولا الأمان الزمني الحقيقي ولا حلقة التعلم المغلقة.
وقام Isaac بجزء من قدرات وقت التدريب، لكنه ليس في وقت التشغيل.
وقام VLA بجزء من التجريد الإدراكي، لكنه لا يحل التنفيذ أو التعلم المستمر.
فقط عندما ينجز نظام واحد هذه الأشياء الثلاثة معًا يستحق أن يُسمّى "نظام التشغيل لعصر الروبوتات".
لماذا نؤمن بأن هذا ممكن
عند هذه النقطة قد يسأل أحدهم —
"ما تقوله يبدو مهمًا جدًا، لكن هل يمكن حقًا بناءه؟ أم أنه مجرد مفهوم لعرض تقديمي؟"
هذا سؤال منطقي جدًا. وأريد أن أجيب عنه بجدية.
قبل ثلاث سنوات، عند تأسيس BridgeDP، اتخذنا قرارًا له دلالة عميقة بالنسبة لنا اليوم — ألا نصنع روبوتًا كاملًا، ولا نموذجًا كبيرًا، ولا تطبيقًا؛ بل نركّز تحديدًا على طبقة "التحكم الحركي".
في عام 2023 لم يكن هذا القرار يبدو ذكيًا جدًا — في ذلك الوقت كان صنع العتاد الكامل هو الشيء الرائج، وكانت النماذج الكبيرة هي الساخنة، وكانت التطبيقات هي التي لديها العملاء. أما التركيز على "الطبقة الوسطى" تحديدًا فكان صعب الشرح خارجيًا، وضاغطًا داخليًا أيضًا.
لكننا اتخذنا هذا القرار بناءً على قناعة:
قطاع الروبوتات سيتدرج طبقيًا في النهاية. ومن يستطيع تحويل القدرة الحركية من "تسليم مشروع" إلى "بنية تحتية"، سيكون قد أمسك بأحد أهم مداخل تحويل العالم المادي إلى عالم ذكاء اصطناعي.
وبعد ثلاث سنوات، أصبح لدينا اليوم بعض الحقائق القابلة للتحقق:
26 شركة روبوتات بشرية تستخدم قدرات التحكم الحركي لدينا
أكثر من 50 طرازًا من الروبوتات الساقية ذات الفوارق الهيكلية الكبيرة — ثنائية، رباعية، بعجلات وأرجل، بتوزيعات مفاصل مختلفة وبطرق دفع مختلفة — تعمل على نفس منظومة التعلم الحركي والتحكم
المدة الهندسية اللازمة لتحويل روبوت جديد من مجرد توصيل عتاده إلى الحصول على أول مشية قابلة للاستخدام، انخفضت من "أشهر على مستوى المشروع" إلى "أسابيع"
جوهر الأمر هو — استبدال بناء نظام منفصل لكل منصة جديدة بعبارة "نظام واحد + سلسلة أدوات تتكيف تلقائيًا مع المنصة الجديدة"
أذكر هذه الأرقام ليس للحديث عن BridgeDP. بل للحديث عن أمر واحد —
نحن لا نصف قصة مستقبلية. نحن نثبت وجود هذا النوع من المنتجات عبر حقائق هندسية.
هذه الطبقة ممكنة. يمكن تجريدها. ويمكن إعادة استخدامها عبر منصات مختلفة. وقد اختارتها بالفعل 26 شركة بأقدامها.
وعند هذه النقطة، لم يعد الأمر مفهومًا نظريًا على شريحة عرض، بل أصبح حقيقة جرى التحقق منها مرارًا في الممارسة الهندسية — لكن حتى اليوم ما زالت تتركز في عمود واحد هو "القدرة الحركية".
والشكل الكامل لـ Runtime Robot OS يتجاوز بكثير عمود القدرة الحركية وحده. لكن إثبات أن أحد الأعمدة ممكن هندسيًا يعني أن للبنية الكاملة أول حجر أساس.
الطرف، والحافة، والسحابة — ثلاث طبقات للشكل الكامل
وهنا أريد أن أدفع الفكرة خطوة إلى الأمام وأرسم صورة أكبر.
لقد بنينا نواة نظام التشغيل على الطرف. لكن الشكل الكامل لـ Runtime Robot OS يتجاوز الطرف بكثير.
وسيكون له ثلاث طبقات —
الطرف (On-device)
طبقة التحكم الآني على مستوى أجزاء الألف من الثانية. تجعل كل روبوت في العالم المادي يمشي بأمان ويتحرك بثبات.
هذه هي أدنى عتبة لبقاء الروبوت "حيًا". وهي أيضًا جوهر ما تعمل عليه BridgeDP اليوم. ويجب إنجاز هذه الطبقة على جسم الروبوت نفسه، لا عبر الاعتماد على الشبكة — لأن تأخير الشبكة يتحول مباشرةً إلى سقوط الروبوت.
الحافة (Edge)
طبقة تنسيق المهارات على مستوى المشهد. تجعل عدة روبوتات داخل مجمّع أو خط إنتاج أو منزل تعمل بتعاون.
هذه الطبقة لا تتطلب زمنًا حقيقيًا على مستوى أجزاء الألف من الثانية، لكنها تتطلب تنسيقًا على مستوى الثانية. توزيع المهام بين عدة روبوتات، ومشاركة المساحة، وتكامل القدرات — هذا لا يُنجز على الطرف (لأن الطرف لا يمتلك رؤية شاملة)، ولا في السحابة (لأن تأخيرها كبير جدًا). إنه يتم عند الحافة.
السحابة (Cloud)
طبقة ترسيخ القدرات والتعلم المستمر عبر المنصات المختلفة. تجعل خبرة كل روبوت تتحول إلى قدرة لجميع الروبوتات.
هذه هي "الحديقة الدوارة للبيانات" الحقيقية — فلو تعلم روبوت في منزل ما كيف يفتح الثلاجة، يمكن لهذه القدرة — مع ضمان الأمان والخصوصية والملكية — أن تصبح قدرة مشتركة لكل الروبوتات من الطراز نفسه.
هذه الطبقات الثلاث لا غنى عن أي واحدة منها. إذا غابت طبقة الطرف، فلن ينجو الروبوت في العالم المادي؛ وإذا غابت الحافة، فلن يتمكن من التعاون في السيناريوهات الجماعية؛ وإذا غابت السحابة، فلن يملك قدرة حقيقية على التطور.
إن بناء هذه الطبقات الثلاث بشكل كامل هو الشكل الكامل لـ Runtime Robot OS. وهذا ليس مشروع سنة أو سنتين، بل مشروع هندسي على مستوى عقد.
البنية التحتية الجديدة — OS + شبكة الحوسبة
في التاريخ توجد عدة ظلال تقابل هذا الأمر.
في عصر الحواسيب الشخصية، كانت البنية التحتية الجديدة تُسمى "نظام التشغيل + العمود الفقري للإنترنت" — Windows / Linux مع TCP/IP والألياف الضوئية، فصار بالإمكان تداول التطبيقات عالميًا.
في عصر الهواتف المحمولة، كانت البنية التحتية الجديدة تُسمى "Android + 4G/5G" — حزمة تطبيقات موحدة مع شبكة لاسلكية تغطي مليارات البشر، فحدث الإنترنت المحمول كله.
وفي عصر الروبوتات، ستكون على هذا النحو —
"Runtime Robot OS + شبكة الحوسبة."
هذه هي البنية التحتية الجديدة لعصر الروبوتات.
ومكوّنانها لا غنى عن أحدهما:
Runtime Robot OS يحل سؤال: "كيف يعمل روبوت واحد بثبات وأمان واستمرار"
شبكة الحوسبة تحل سؤال: "كيف تُدار حوسبة ملايين وملايين الروبوتات عبر طبقات الطرف والحافة والسحابة وتنسَّق وتخدم بشكل موحّد"
ولا تستطيع أي شركة واحدة أن تنجز هذين الأمرين بمفردها. فشركة أنظمة التشغيل لا يمكنها أن تبني وحدها شبكة حوسبة تغطي البلد كله؛ ومقدّم البنية التحتية للشبكة والحوسبة لا يمكنه أن يطوّر من الصفر نظام تشغيل وقت التشغيل لعصر الروبوتات.
الأمر يحتاج إلى — تعاون عميق بين جهة توفير نظام التشغيل، وجهة توفير البنية التحتية للشبكة والحوسبة.
وهذا الأمر يحدث الآن. وقفنا على منصة الخطاب تلك لأننا نؤمن بأن هذه ليست مجرد رؤية؛ إنها مسار صناعي حقيقي يجري دفعه من عدة أطراف، ويحدث بالفعل الآن.
كلمة أخيرة: هذا دعوة
أريد أن أختم المقال بما قلته في نهاية الخطاب.
كل مرة يتغير فيها نموذج الحوسبة، يترك التاريخ وراءه لحظة Unix — دائمًا يخرج من يقول: نحول القطع المتفرقة إلى بنية تحتية.
في عصر الحواسيب المركزية قالها بعضهم، فجاء Unix. وفي عصر الهواتف الذكية قالها بعضهم، فجاء Android. واليوم، في عصر الروبوتات البشرية، حان دور جيلنا ليقول هذه الجملة.
هذا ليس شأن شركة واحدة. وليس شأن شركة روبوتات كاملة. وليس شأن شركة اتصالات. وليس شأن شركة شرائح. وليس شأن أي شركة منفردة.
هذه بداية عصر.
في الأشهر القادمة، سنواصل طرح أفكارنا ومنتجاتنا وممارساتنا الهندسية — واحدة تلو الأخرى — أمام القطاع. وسندعو زملاء القطاع للمناقشة والاختلاف معًا، حتى نصل بها إلى صورة أدق وأفضل.
لكن الأهم من كل هذا هو —
كل ما كتبناه اليوم ليس خاتمة، بل دعوة.
نحن نتطلع إلى أن نعمل مع كل مهندس، وباحث، ومؤسس شركة ناشئة، ومستثمر، وصانع سياسات يهتم بقطاع الروبوتات — لنعرّف معًا الشكل الذي ينبغي أن يكون عليه نظام التشغيل لهذا العصر.
إذا كنت تؤمن أيضًا بأن "القطع المتفرقة ينبغي أن تتحول إلى بنية تحتية" —
فهذه هي الدعوة.
شانغ يانغ شينغ
مؤسس & CEO BridgeDP
17 مايو 2026 · شنتشن