أطلقت ميتا Muse Glimmer، وهو نموذج متعدد الوسائط بحوالي 30 مليار معلمة، يدعم سياقًا بمستوى 128K ويعمل على أجهزة بذاكرة فيديو 24GB. تم إطلاق النموذج بموجب ترخيص Apache 2.0، ويستخدم GQA لتقليل استهلاك KV Cache، مع دمج بنية هجينة للانتباه المحلي والعالمي لتقليل تكلفة الحساب للسياقات الطويلة، ويوفر نسختين مكمّنتين لتناسب أجهزة ذاكرة فيديو مختلفة. يحتوي وحدة الرؤية على مشفر إدراك ViT مستقل لمعالجة لقطات الشاشة والمعلومات الظاهرة، وتم إدخال On Policy Distillation أثناء مرحلة التدريب لتغطية حالات الانحراف في المهام الطويلة. يعتمد مكون DFlash لتسريع الاستنتاج على Block Diffusion للتنبؤ المتوازي بالرموز، مما يحقق تحسينًا في سرعة الترميز بنسبة 3 أضعاف تقريبًا على RTX 5090. أظهر النموذج أداءً ممتازًا في معايير Agent مثل MCP Atlas وDeepSearch QA، لكنه لا يزال يمتلك مجالًا للتحسين في سيناريوهات GUI البحتة مثل OSWorld Verified.

كاتب المقال، المصدر: LeiFeng.com

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

يتم إطلاق هذا النموذج بموجب ترخيص Apache 2.0، مع توفر نسختين مكمّنتين بـ 4 بت، ومحرّك بصري مستقل، ومكوّن تسريع الاستدلال DFlash، بالإضافة إلى خيارات النشر المحلي مثل llama.cpp وMLX وExecuTorch.

على الرغم من أن حجم المعلمات البالغ 30B والسياق البالغ 128K لا يُعدّان نادرَين اليوم، فإن المشكلة تكمن في أن ميتا تريد أن تقوم به ليس مجرد محادثة عادية، بل إنشاء نموذج تشغيل كامل لوكيل محلي.

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

في هذه المرحلة، ستتضح وتنمو بسرعة العديد من المشكلات التي لم تكن واضحة في سياقات المحادثة. كيف يمكن تضمين سياق 128K في ذاكرة GPU المحدودة؟ كيف يمكن إدارة الحالة التاريخية مع تزايد عدد لقطات الشاشة؟ كيف يستمر النموذج بعد فشل استدعاء الأداة؟ وما مدى تأثير كمية كبيرة من رموز الاستدلال على إبطاء عملية التحليل؟

تمحور التصميم التقني لـ Muse Glimmer حول هذه المشكلات الأساسية. فبدلاً من الاعتماد على بنية جديدة بارزة واحدة لحل جميع الأمور، أجرت تنازلات جريئة في Attention وKV Cache وطريقة التدريب والكمية وDecode.

إذا كانت النماذج المحلية السابقة تهدف إلى "التشغيل"، فإن هدف Muse Glimmer هو "العمل بسلاسة واستمرارية مثل النماذج السحابية".

عند النظر إلى هذه الأجزاء معًا، يصبح من الأسهل فهم سبب جعل ميتا لها على هذا النحو مقارنة بمشاهدتها منفصلة كـ 30B أو 128K.

كيفية ضغط سياق 128K داخل ذاكرة GPU بسعة 24GB

تستخدم Muse Glimmer 52 طبقة Dense Transformer، بحجم مخفي قدره 6656، مع 32 رأس استعلام، ولكن فقط رأسين لـ KV.

الانتباه لا يعالج السياق الكامل في كل طبقة، بل يستخدم طريقة دورية تتكون من ثلاثة انتباهات محلية يتبعها انتباه عالمي.

يتعامل Local Attention فقط مع 2048 رمزًا مجاورًا، بينما يتحمل Global Attention تبادل المعلومات على مسافات أبعد.

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

تحتوي كل طبقة من Muse Glimmer على 2 رؤوس KV فقط، مع بعد رأس قدره 128. ووفقًا للحساب التقريبي بتنسيق BF16، فإن كل رمز في طبقة واحدة يشغل حوالي 1024 بايت من KV.

إذا تم حفظ جميع الطبقات الخمسة والخمسين بسياق كامل بحجم 128K، فستحتاج ذاكرة KV تقريبًا إلى 6.5 غيغابايت. لكن Muse Glimmer يحتوي فعليًا على 39 طبقة محلية و13 طبقة عالمية. الطبقات المحلية تحتاج فقط إلى الحفاظ على نافذة انزلاقية بحجم 2048 رمزًا، بينما فقط الطبقات العالمية تحتاج إلى حفظ السياق الطويل الكامل.

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

إذا لم تستخدم 2 رأس KV، بل حفظت KV مستقلة لجميع الرؤوس الـ32 كما في MHA التقليدي، ففي نفس الظروف، سيزداد حجم ذاكرة KV نظريًا حوالي 16 مرة، ليصل مباشرة إلى أكثر من 20 غيغابايت.

يتجاوز كاش KV المنفصل وحدة GPU واحدة بسعة 24 جيجابايت. هنا يتم استخدام طريقتين فعليًا. يقلل GQA من عدد قيم KV التي يجب حفظها لكل رمز، بينما يقلل الانتباه المحلي من عدد الطبقات التي تحتاج إلى حفظ كاش KV كامل على المدى الطويل.

بعد إتمام هذه الخطوة، يصبح تكميم الأوزان ذا معنى. يبلغ وزن Muse Glimmer K Quant 17GB حوالي 16.8 جيجابايت، ووحدة التصور حوالي 1.4 جيجابايت، وDFlash حوالي 1.6 جيجابايت، مما يجعل المجموع قريبًا من 20 جيجابايت. هذا الإصدار موجه للأجهزة ذات ذاكرة فيديو بسعة 24 جيجابايت، بينما تُوجَّه مجموعة أخرى بحجم حوالي 20 جيجابايت من Dynamic K Quant للأجهزة ذات سعة 32 جيجابايت.

لا تختلف مجموعتا التكميم الكمي فقط في حجم الملف. ضمن متوسط فقدان الدقة البالغ 15 معيارًا قدمته ميتا، فإن التكميم الديناميكي K يبلغ حوالي 0.2%، بينما يبلغ التكميم K بحجم 17 جيجابايت حوالي 1.0%.

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

يُعد سياق 128K لـ Muse Glimmer ممكنًا ضمن هذا المزيج. يُقلل الانتباه أولاً من حسابات التحويل، ثم تقلل GQA من ذاكرة KV، وأخيرًا يتم ضغط أوزان النموذج عبر التكميم.

هذا الحل له أيضًا تكلفة. لا يمكن لطبقات Local البالغ عددها 39 الوصول مباشرة إلا إلى 2048 رمزًا مجاورًا، ويجب أن تنتقل المعلومات البعيدة عبر طبقة Global. لذلك، القدرة على إدخال 128K لا تساوي القدرة على استخدام كامل 128K بشكل مستقر.

نتائج Meta's Beam128K تشير إلى أن هذا الهيكل المختلط بين المحلي والعالمي لا يزال يمتلك قدرة جيدة على استخدام المعلومات على مسافات طويلة، لكنه يحل مشكلة السياق الطويل، وليس الذاكرة طويلة المدى. ما هي المعلومات التي يجب حفظها، وما هي التي أصبحت قديمة، ومتى يجب تحديث الحالة، لا يزال يتطلب معالجة من قبل Agent Runtime.

هذه المسألة ستكون أكثر وضوحًا عند وصولها إلى وكيل الرؤية.

128K ليست مساحة غير محدودة

تحتوي Muse Glimmer أيضًا على مشفر إدراك ViT G 14 بحجم حوالي 1.8 مليار معلمة، مخصص لمعالجة لقطات الشاشة والصفحات الإلكترونية والمخططات والمستندات. يمكن تحويل صورة واحدة إلى ما يصل إلى 4096 رمز بصري.

إنها حاليًا مدخلات نصية وصورية، ومخرجات نصية، وليست دمجًا لجميع الوسائط في نموذج توليد واحد.

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

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

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

الأول مسؤول عن تحويل الشاشة الحالية إلى معلومات يمكن للنموذج فهمها، بينما الثاني يقرر أي حالات سابقة لا تزال ذات قيمة وأيها يجب حذفها. وبالتالي، فإن 128K تشبه أكثر تقديم مساحة عمل أكبر للوكيل، بدلاً من إلغاء إدارة الحالة.

وأثناء تفاعل الوكيل باستمرار مع البيئة، تبدأ المشكلة في الانتقال من ما رآه النموذج إلى ما فعله النموذج للتو.

هذا يدخل إلى جزء تدريب Muse Glimmer.

كيف تستمر بعد انحراف العميل

Muse Glimmer مُستخلصة من Muse Spark الأكبر.

تُقسّم ميتا التدريب إلى التدريب الأولي، والتدريب المتوسط، والتدريب النهائي. يُستخدم التدريب الأولي تقطيع اللوجيت، ويُضاف في التدريب المتوسط مزيد من سياقات طويلة، ومسارات استدلال، وبيانات وكيل، ويُضاف في التدريب النهائي SFT وتقسيم سياسة على الموقع والتعلم المعزز.

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

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

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

افترض أن المسار الصحيح للمعلم هو من A إلى B، ثم إلى C، وأخيرًا إلى D. إذا تعلم الطالب دائمًا بيانات المعلم فقط، فسيرى مرارًا وتكرارًا الانتقال من A إلى B ومن B إلى C. لكن أثناء التشغيل الفعلي، قد ينتقل الطالب في الخطوة الأولى إلى حالة B مختلفة.

من هذه اللحظة، تغيرت البيئة، ولا يمكن لـ B إلى C في مجموعة التدريب أن يخبر النموذج مباشرة بكيفية التعامل مع الوضع الحالي. هنا يلعب تقطيع السياسة دوره. يبدأ الطالب بإجراء عملية Rollout بنفسه، ويدخل إلى الحالات التي سيولدها فعليًا، ثم يتلقى إشرافًا من نموذج أقوى على هذه الحالات.

لذلك، لا تحتوي بيانات التدريب فقط على المسار المثالي للمعلم، بل تغطي أيضًا الحالات الخاطئة التي ينشئها الطالب بنفسه. وهذا مرتبط بـ "استرداد الفشل" الذي يشدد عليه Muse Glimmer.

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

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

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

سؤالان متتاليان

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

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

تستخدم ميتا في المعيار العام قوة استدلال عالية. وهذا يؤدي إلى DFlash.

فك تشفير Transformer هو ذاتي التراجع. يجب انتظار الرمز الثاني حتى يُنتج الرمز الأول، ويُعتمد الرمز الثالث على الرمز الثاني. يمكن قبول ذلك لردود تضم مئات الرموز، لكن مهمة الوكيل قد تُنتج آلافًا أو حتى عشرات الآلاف من الرموز بشكل تراكمي.

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

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

استبدل DFlash هذا القسم بـ Block Diffusion.

حجم كتلة DFlash لموديل Muse Glimmer هو 16، مما يسمح بالتنبؤ المتوازي بمجموعة من الرموز المرشحة. لكن Drafter لا يكفي أن يكون أسرع فقط. إذا كانت التخمينات غير دقيقة، فسيقوم النموذج الرئيسي برفض عدد كبير من الرموز المرشحة، وسيختفي سريعًا الميزة السرعة السابقة.

لذلك يقوم DFlash أيضًا بقراءة الميزة المخفية في الطبقات 1 و13 و25 و37 و49 من Muse Glimmer مباشرةً، ويعطي هذه التمثيلات الوسيطة إلى Drafter الذي يحتوي على 5 طبقات فقط. وهكذا لا يحتاج Drafter إلى إعادة فهم السياق الكامل، بل يستفيد مباشرةً من التمثيلات الداخلية التي شكلها النموذج الرئيسي بحجم 30B.

هذه الميزات لا تُستخدم فقط في الإدخال مرة واحدة، بل تُحقن باستمرار في مفاتيح وقيم طبقات Drafter لتجنب التدهور التدريجي مع عمق الشبكة.

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

لذلك، يمنح DFlash وزن خسارة أعلى للرموز التي تسبق Block، ويخفضه تدريجيًا للرموز اللاحقة. إنه يُحسّن أطول بادئة مقبولة ممكنة، وليس فقط السعي وراء متوسط الدقة على 16 موضعًا. في بيانات K Quant 17GB التي قدمتها Meta، ارتفعت سرعة التفسير على RTX 5090 من حوالي 74.9 رمز/ثانية إلى 233.4 رمز/ثانية.

إذا تراكمت مهمة عامل توليد 10000 رمز، فإن النظر فقط إلى الـ Decode، فإن الأول يتطلب حوالي 134 ثانية، والثاني حوالي 43 ثانية. ستتضمن المهام الحقيقية أيضًا الـ Prefill وتنفيذ الأدوات وانتظار الشبكة، لكن بالنسبة للعوامل ذات قوة الاستدلال العالية، فإن هذا الفرق سيؤثر بشكل واضح على تجربة المهمة الكاملة.

ستزيد قوة الاستدلال العالي من توليد الرموز، ويتولى DFlash تقصير هذا الوقت. سيزيد السياق الطويل من ذاكرة KV، ويتولى GQA وAttention المحلي تقليل استخدام الذاكرة. أما التكميم، فيستمر في الحفاظ على أوزان النموذج ضمن حدود قدرة بطاقات الرسوميات الاستهلاكية.

إضافةً إلى ذلك، أظهر Muse Glimmer أداءً جيدًا على معايير Agent مثل MCP Atlas وDeepSearch QA وGaia2. تتطلب هذه المهام سلاسل تنفيذ أطول.

يحتاج MCP Atlas إلى نموذج لاختيار واستدعاء الأدوات بين خوادم MCP متعددة. يتطلب DeepSearch QA البحث المستمر وفتح الصفحات والبحث عن المعلومات، ثم الاستمرار في التنفيذ بناءً على النتائج الجديدة. أما Gaia2 فيحاكي تطبيقات ذات حالة مثل البريد الإلكتروني والتقويم والجهات الاتصال، كما أن البيئة نفسها تتغير أثناء تنفيذ المهمة.

هذه المهام تتماشى بشكل جيد مع طريقة تدريب Muse Glimmer. لكنها لم تحافظ على نفس الميزة في OSWorld Verified وTerminalBench وSWE Bench Verified. على سبيل المثال، حصل Muse Glimmer على 65.9 في OSWorld Verified، بينما حصل Qwen3.6 27B على 75.6. وفي TerminalBench 2.1، حصل Muse Glimmer على 51.7، بينما وصل الآخر إلى 60.7.

توزيع قدراته أصبح واضحًا بالتالي. يتفوق Research Agent، والتعاون مع الأدوات، ومهام الحالة الطويلة، بينما لا تزال هناك مساحة واضحة للتحسين في سيناريوهات GUI النقي، وواجهة السطر الأوامر، وبعض مهام Agent البرمجة. لا يمكن فهم هذه الدرجات بالكامل وفقًا لقوائم النماذج التقليدية.

تتأثر نتائج Agent Benchmark أيضًا بـ System Prompt وTool Definition وScaffold وعدد خطوات التنفيذ القصوى ومعاملات العينة وحتى نموذج التقييم. كما أوضحت Meta نفسها أن أدوات Agent وSystem Prompt المستخدمة من قبل النماذج الخارجية قد لا تكون مُحسَّنة بشكل أمثل لها.

لذلك، في مرحلة العامل، أصبح من الصعب越來越 صعوبة تقييم الحالة الكاملة من خلال مقارنة نقاط التفتيش بشكل منفصل. الأمان يمثل مشكلة مشابهة.

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

مسار قدرات واضح

يمكن في النهاية ربط جميع مسارات تقنية Muse Glimmer في سلسلة واضحة نسبيًا.

يتم التحكم في حجم النموذج حول 30B، مع تقليل تكلفة ذاكرة GPU لسياق 128K باستخدام GQA وLocal Attention، ويُمكّن التكميم النموذج من العمل على أجهزة بسعة 24GB و32GB، ويقوم Perception Encoder بقراءة البيئة البصرية، ويغطي On Policy Distillation الحالات المنحرفة في المهام الطويلة، ويمنح Reasoning Strength المطورين التحكم في ميزانية الاستدلال، بينما يعالج DFlash التأخير الناتج عن كمية كبيرة من رموز الاستدلال.

لم تُثبِت Muse Glimmer أن النموذج المحلي بحجم 30B يمكنه استبدال نموذج Frontier السحابي، لكنها أثبتت أن النهاية النهائية للنموذج المحلي بحجم 30B لا تكمن في الحجم فقط، بل في الهندسة النظامية التي تُوازن بين جميع القيود الصلبة. لقد دمجت بالفعل أصعب أربع قيود في الوكلاء المحليين — ذاكرة العرض، السياق، إدراك حالة البيئة، وسرعة الاستدلال — ضمن تصميم نظام واحد.

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