شرح الجهاز الافتراضي الآمن Meta Muse: لماذا تحتاج وكلاء الذكاء الاصطناعي الذين يعملون دائمًا إلى حاسوبهم الخاص

يقدم Meta Muse إجابة ملموسة على نحو مدهش عن سؤال تجنبته صناعة الذكاء الاصطناعي إلى حد كبير: أين يعيش وكيل الذكاء الاصطناعي الشخصي فعليًا؟

إجابة Meta ليست «داخل تطبيق الدردشة». يحصل كل مستخدم لـ Muse على حاسوب مخصص في السحابة، مزود بالتخزين والذاكرة والمتصفح ونظام الملفات والمهام الخلفية وحدود الأمان الخاصة به. وهذا مهم لأن الوكيل الذي يواصل العمل بعد إغلاق حاسوبك المحمول يحتاج إلى ما هو أكثر من نموذج قوي. إنه يحتاج إلى مكان دائم يعيش فيه.

ما هو Meta Muse وكيف يعمل؟

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

يكمن الجزء المهم في بنيتها. إذ يوفر Muse Spark نموذج الاستدلال، لكن الوكيل نفسه يعمل من خلال Muse Secure VM. وتحتفظ هذه الآلة الافتراضية بملفات المستخدم وبيانات الخدمات المتصلة، مع منح Muse متصفحًا وأدوات وموارد حوسبة ومساحة عمل مستمرة.

يفصل هذا بين مفهومين غالبًا ما يُتعامل معهما على أنهما مفهوم واحد: النموذج الذي يستدل والكمبيوتر الذي يعيش فيه الوكيل.

ما هي Muse Secure VM؟

تصف Meta خدمة Muse Secure VM بأنها حاسوب سحابي مخصص لكل مستخدم. وهي آلة افتراضية معزولة تعمل بنظام Linux، وتضم متصفحًا خاصًا بها، إلى جانب قدر كافٍ من وحدة المعالجة المركزية والذاكرة والتخزين لتجميع التعليمات البرمجية، وتطوير Skills مخصصة، وتشغيل وكلاء فرعيين متزامنين، وتنفيذ مهام cron.

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

هذا تحول معماري كبير. فـ Muse أقرب إلى منح وكيل الذكاء الاصطناعي محطة عمل خاصة به، بدلًا من تضمين مساعد آخر داخل هاتف المستخدم.

لماذا يحتاج وكيل الذكاء الاصطناعي إلى حاسوبه الخاص؟

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

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

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

هل تواصل Meta Muse العمل في الخلفية؟

نعم. صممت Meta‏ Muse لمواصلة العمل بعد أن يحدد المستخدم هدفًا لها، بدلًا من اشتراط بقاء التطبيق مفتوحًا في كل خطوة. ويمكن لآلتها الافتراضية المخصصة أيضًا تشغيل وكلاء فرعيين متزامنين ومهام cron مجدولة.

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

يتطلب هذا النمط توافرًا مستمرًا. يجب أن يظل حاسوب الوكيل متاحًا حتى عندما لا يكون حاسوب المستخدم متاحًا.

أين تخزّن Muse الملفات والذاكرة وحالة الوكيل؟

تقول Meta إن الآلة الافتراضية المخصصة للمستخدم تعمل بوصفها مصدر السجل لكل ما يُوضَع في Muse. وتُخزَّن حالة التطبيق الدائمة في PostgreSQL خارج خلية تشغيل الوكيل الرئيسية، بينما تبقى الملفات وبيانات مساحة العمل داخل بيئة الآلة الافتراضية المخصصة.

يختلف هذا عن الاعتماد كليًا على سياق النموذج. فقد ينسى النموذج الرموز القديمة، أو يختصر محادثة، أو يُستبدل بنموذج أحدث. أما الملفات وقواعد البيانات الدائمة فتستمر رغم هذه التغييرات.

من المرجح أن يصبح هذا الفصل مهمًا على نحو متزايد للوكلاء الشخصيين: يمكن استبدال الاستدلال؛ أما الحالة الدائمة فلا ينبغي أن تكون كذلك.

كيف تحمي Muse كلمات المرور وبيانات الاعتماد؟

تُمنع Muse عمدًا من رؤية بيانات الاعتماد الفعلية التي تستخدمها. وتُخزَّن رموز OAuth وغيرها من الأسرار بواسطة خدمة مصادقة منفصلة خارج خلية تشغيل الوكيل، بينما تُنفَّذ العمليات التي تتطلب بيانات اعتماد عبر عمليات أكثر إحكامًا من حيث التحكم.

يتبع المتصفح المبدأ نفسه. فعندما يُدخل المستخدم كلمة مرور، يمكن أن تنتقل مباشرةً إلى مخزن بيانات اعتماد محمي، ثم تُحقن لاحقًا في المتصفح دون كشف كلمة المرور لوكيل Muse الرئيسي.

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

ما هو Meta Muse Sentinel؟

تضع Meta وكيلًا ثانيًا، هو Sentinel، خارج بيئة التشغيل الرئيسية لـ Muse. ويُعد Sentinel الجهة المخوّلة بمنح الأذونات لإجراءات الموصلات واتصالات الشبكة الصادرة: يمكن لـ Muse اقتراح إجراء، لكنه لا يستطيع ببساطة أن يقرر بنفسه السماح بهذا الإجراء.

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

وهذا مهم خصوصًا لأن حقن الأوامر يظل مشكلة مفتوحة. قد تحتوي صفحات الويب والملفات ومخرجات الأدوات على تعليمات ضارة، لذلك تتعامل Meta مع البيانات الخارجية على أنها غير موثوقة محتملًا، بدلًا من افتراض أن النموذج سيتعرف دائمًا على الهجوم.

هل تُعد Muse Secure VM مجرد بيئة معزولة؟

إنها أكثر تعددًا في الطبقات من حاوية واحدة. داخل كل آلة افتراضية، تعمل البنية الأساسية لـ Muse، ومساحة العمل، والأدوات، والملفات الثنائية في systemd-nspawn خلية التشغيل. يُطابق المستخدم الجذر داخل تلك الخلية مستخدمًا غير مميّز على المضيف، بينما تُقيَّد إمكانات النواة الخطرة واستدعاءات النظام.

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

تلخّص Meta التصميم بشكل جيد: النموذج الذهني الصحيح هو مجالان أمنيان معزولان على جهاز واحد، وليس وكيل ذكاء اصطناعي يتمتع بوصول غير مقيّد إلى الجذر.

هل يمكن لـ Meta الوصول إلى البيانات داخل Muse Secure VM؟

مع توفر Secure VM عند الإطلاق، نعم في بعض الظروف. تقول Meta إن السياسات التشغيلية تقيّد وصول الموظفين، لكن البنية الحالية لا تمنع Meta تقنيًا من الوصول إلى بيانات الآلة الافتراضية عند الحاجة إلى دعم الخدمة أو تأمينها أو تشغيلها.

هذا التمييز مهم. فالعزل عن المستخدمين الآخرين والعزل عن موفر السحابة هما ضمانان مختلفان للخصوصية.

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

ما هي Muse Confidential VM؟

تخطط Meta لإطلاق Muse Confidential VM أكثر قوة في وقت لاحق من عام 2026. والهدف هو تشفير الآلة الافتراضية بحيث لا تتمكن حتى Meta من الوصول إلى البيانات الموجودة داخلها، مع تصميم يتيح تدقيقها خارجيًا.

يكشف هذا عن تسلسل هرمي مهم للخصوصية:

لذلك، لا يُعد «السحابي» و«الخاص» نقيضين. تتمثل الأسئلة الحقيقية في: من يتحكم في الجهاز؟ ومن يتحكم في مفاتيح التشفير؟ وما الذي يغادر الجهاز؟ وأي المكونات موثوقة؟

هل الخادم المنزلي بديل عن Muse Secure VM؟

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

يتضمن نموذج أمان Muse العزل أثناء التشغيل، وإحلال بيانات الاعتماد، وتقييد الاتصالات الصادرة عبر الشبكة، وإنفاذ السياسات بشكل مستقل، والمصنّفات، وبوابات الموافقة. إن منح حاوية Docker ببساطة إمكانية الوصول إلى مجلد المنزل وعدة مفاتيح API لا يعادل ذلك.

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

آلة افتراضية سحابية مقابل خادم منزلي: أين ينبغي أن يعمل وكيل دائم التشغيل؟

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

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

هل يحتاج وكيل ذكاء اصطناعي متاح دائمًا إلى وحدة معالجة رسومات قوية؟

ليس بالضرورة. يساعد Muse نفسه على توضيح سبب عدم وجوب التعامل مع «خادم الوكيل» و«خادم الاستدلال» على أنهما مترادفان.

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

ماذا تكشف Meta Muse عن مستقبل الذكاء الاصطناعي الشخصي؟

قد لا يكون الشيء الأكثر إثارة الذي بنته Meta من أجل Muse هو Muse Spark. بل قد يكون قرار منح الوكيل كمبيوتر خاصًا به.

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

لذلك قد تنقسم حزمة الذكاء الاصطناعي الشخصي المستقبلية إلى طبقتين قابلتين للاستبدال: محرك استدلال وكمبيوتر وكيل. قد يكون محرك الاستدلال من Meta أو OpenAI أو Anthropic أو نموذجًا محليًا. أما الكمبيوتر الدائم فقد يكون آلة افتراضية مُدارة في السحابة، أو خادمًا منزليًا مملوكًا لل用户، أو مزيجًا من الاثنين.

إجابة Muse هي كمبيوتر مخصص في سحابة Meta. لكن الدرس الأهم أكثر استدامة: يحتاج الذكاء الاصطناعي المتاح دائمًا إلى مكان يعيش فيه.

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

هل يعمل Meta Muse محليًا؟

لا. يعمل Muse في آلة افتراضية مخصصة في سحابة Meta. ويتصل تطبيق Muse أو واجهة الويب ببيئة الوكيل البعيدة تلك.

هل يعمل Meta Muse دائمًا؟

صُمم Muse للعمل في الخلفية وتنفيذ المهام طويلة الأمد، ويمكن لآلته الافتراضية تشغيل مهام cron مجدولة ووكلاء فرعيين متزامنين. ومع ذلك، تظل المهام الفردية معتمدة على الأذونات، وتوافر الخدمة، وسياسات تنفيذ Muse.

هل Muse Secure VM جهاز فعلي منفصل؟

لا. إنها آلة افتراضية مخصصة، ما يعني أن المستخدم يحصل على بيئة حوسبة افتراضية معزولة، وليس خادمًا فعليًا مخصصًا.

أين يخزّن Meta Muse ذاكرته؟

تقول Meta إن الآلة الافتراضية المخصصة هي النظام المرجعي لبيانات Muse. وتُخزَّن حالة التطبيق الدائمة في PostgreSQL، بينما تظل الملفات الأخرى وبيانات مساحة العمل داخل بيئة الآلة الافتراضية الخاصة بالمستخدم.

هل تستطيع Meta رؤية البيانات داخل Muse Secure VM؟

لا يمنع إصدار الإطلاق Meta تقنيًا من الوصول إلى بيانات الآلة الافتراضية عند الضرورة لتشغيل الخدمة أو دعمها أو تأمينها. وتقول Meta إن السياسات التشغيلية تقيّد هذا الوصول. أما الآلة الافتراضية السرية المخطط لها، فمن المفترض أن تمنع Meta نفسها تشفيريًا من قراءة البيانات.

هل يستطيع Muse رؤية كلمات المرور الخاصة بي؟

صممت Meta نظام Muse بحيث لا يتلقى الوكيل الرئيسي كلمات المرور الفعلية أو بيانات اعتماد الخدمات المتصلة. تُحفظ الأسرار في مخزن منفصل لبيانات الاعتماد، وتُزوَّد بها العمليات المصرح لها من دون كشفها مباشرةً للوكيل.

ماذا يفعل Muse Sentinel؟

Sentinel هو وكيل أذونات منفصل يقيّم إجراءات الموصل والوصول إلى الشبكة. يمكن لـ Muse اقتراح إجراء، لكن Sentinel يحدد ما إذا كان مسموحًا به أو مرفوضًا أو يتطلب موافقة المستخدم.

هل يمكن لوكيل ذكاء اصطناعي شخصي أن يعمل على خادم منزلي؟

نعم. يمكن للخادم المنزلي استضافة مكونات الوكيل الدائمة، مثل الملفات، وقواعد البيانات، والذاكرة، وأنظمة RAG، والمهارات، والأدوات، والأتمتة، والنسخ الاحتياطية. وتتطلب إعادة إنشاء العزل وحماية بيانات الاعتماد في نظام مُدار مثل Muse هندسة أمنية إضافية.

هل يحتاج خادم وكيل الذكاء الاصطناعي إلى وحدة معالجة رسومات؟

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

هل الخادم المنزلي أكثر خصوصية من Muse Secure VM؟

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