Kimi K3 وDeepSeek V4 وGLM-5.2 لوكلاء الهاتف: كيف تختار النموذج؟

أفضل نموذج لوكيل الهاتف ليس فائزا واحدا

عندما يبحث القارئ عن أفضل نموذج لوكيل الهاتف، فمن السهل أن يتحول السؤال إلى سباق أرقام: من الأعلى في القياسات؟ من الأرخص؟ من يملك أكبر سياق؟ لكن وكيل الهاتف لا يعمل مثل اختبار رياضي ثابت. مرة يحتاج إلى صياغة رسالة قصيرة، ومرة إلى فهم ملف طويل، ومرة إلى تخطيط خطوات داخل تطبيق، ومرة إلى قرار سريع يحتاج زمنا منخفضا ونتيجة ظاهرة على شاشة Android. لذلك لا نرى في FoneClaw فائزا واحدا لكل الحالات؛ نرى توجيها ذكيا للنموذج حسب المهمة.

يعرض تحليل MarkTechPost لمقارنة Kimi K3 وDeepSeek V4 Pro وGLM-5.2 صورة مفيدة: Kimi K3 يقود في القدرة المقاسة ضمن المقارنة، DeepSeek V4 Pro يبرز في الكلفة، وGLM-5.2 يقدم موقعا وسطا مع سرعة قوية وخيار أوزان مفتوحة. المقال نفسه يحذر ضمنيا من قراءة القياسات وحدها، لأنه يقارن القدرة والرخصة وكلفة التشغيل، لا تجربة هاتف حقيقية.

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

إذا أردت مقارنة أوسع بين النماذج نفسها، فدليل نماذج وكلاء الذكاء الاصطناعي 2026: كيف تختار النموذج المناسب؟ يعطي خريطة عامة. أما هنا فنحن نركز على التوجيه داخل وكيل الهاتف: أي نموذج لمهمة قصيرة؟ أي نموذج لسياق طويل؟ وأين تنتهي قدرة النموذج وتبدأ إجراءات Android المدعومة؟

أبعاد الاختيار: الكلفة والسرعة والسياق واللغة

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

يمكن تلخيص أبعاد الاختيار في جدول عملي:

يتصل هذا أيضا بتحسين النماذج على الجهاز. بعض المهام يمكن أن تستفيد من نموذج محلي أو سريع، بينما تحتاج مهام أخرى نموذجا أكبر عبر API. يشرح مقال تحسين نماذج LLM على الجهاز لوكلاء الهاتف في 2026 جانب السرعة والذاكرة والبطارية، بينما يركز هذا المقال على قرار التوجيه بين نماذج كبيرة ومسارات API.

في FoneClaw، هذا القرار لا يكون هدفا بحد ذاته. النموذج المختار يقود الفهم والتخطيط. بعد ذلك يتعامل وكيل الهاتف مع إجراءات Android المدعومة: فتح مسار، عرض نص، مراجعة جهة، أو طلب تأكيد. لذلك لا نسأل: من النموذج الأقوى؟ نسأل: أي نموذج يكفي للمهمة بأقل كلفة وزمن وبأعلى وضوح للمستخدم؟

لقطات من Kimi وDeepSeek وGLM وQwen وHy3

تظهر موجة يوليو 2026 نماذج كبيرة متعددة، ولكل واحد دور محتمل في توجيه وكيل الهاتف. بحسب MarkTechPost، Kimi K3 هو نموذج MoE بحجم 2.8T مع سياق مليون رمز ودعم رؤية، لكنه كان عند نشر المقارنة API-only حتى موعد نشر الأوزان المخطط. DeepSeek V4 Pro يظهر كخيار أرخص بكثير في كلفة التوليد، مع سياق مليون رمز ورخصة MIT وأوزان متاحة. GLM-5.2 أصغر من الاثنين لكنه سريع وذو أوزان مفتوحة، ويقدم وضعيات تفكير مختلفة.

تضيف تقييمات CAISI من NIST لنموذج GLM-5.2 زاوية مهمة. ذكر التقييم أن GLM-5.2 كان على الأرجح أقوى نموذج مفتوح الأوزان عند إطلاقه، وأن قدراته الإجمالية قريبة من GPT-5.2 وفق مجموعة تقييم CAISI، مع ملاحظات مختلطة حول الحماية والأمن. هذه التفاصيل مهمة لوكيل الهاتف لأن القدرة وحدها لا تكفي؛ يجب أيضا معرفة أين تكون الحماية قوية وأين تحتاج تجربة المنتج إلى قيود إضافية.

أما Qwen فيدخل من باب سباق النماذج الكبرى. يذكر تقرير South China Morning Post عن Qwen3.8 أن Alibaba عرضت Qwen3.8-Max-Preview كنموذج 2.4T ووصفت أداءه بأنه قريب من النماذج الرائدة، مع توفر عبر Token Plan ومنصات Qoder وQoderWork. Hy3 من Tencent يمثل إشارة أخرى في اتجاه نماذج تقود التخطيط داخل منتجات وواجهات API، كما أن الوصول على نمط OpenRouter يجعل التوجيه بين النماذج جزءا من بنية المنتج لا مجرد اختيار يدوي.

لكن اللقطة لا تعطي حكما نهائيا. Kimi قد يناسب التخطيط العميق والسياق الكبير، DeepSeek قد يناسب الكلفة العالية التكرار، GLM قد يناسب السرعة والأوزان المفتوحة، Qwen وHy3 قد يناسبان منظومات ومنتجات معينة. وكيل الهاتف الجيد يختار بناء على المهمة، لا على الضجة.

لماذا لا تكفي قوة النموذج لإجراءات Android؟

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

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

في حالة DeepSeek مثلا، يسأل كثيرون هل يستطيع النموذج التحكم في Android. الإجابة العملية نفسها تنطبق على كل النماذج: النموذج يفهم، ووكيل الهاتف ينجز ضمن ما هو مدعوم. لمن يريد هذا الموضوع حول DeepSeek تحديدا، يقدم مقال هل يستطيع DeepSeek التحكم في هاتف Android؟ ما يستطيع فعله وما يحتاج إلى طبقة تنفيذ سياقا قريبا، بينما نبقى هنا في موضوع توجيه النماذج.

في FoneClaw، نربط تفكير النموذج بإجراءات Android من خلال نتيجة ظاهرة وأذونات مفهومة. إذا احتاج الإجراء موافقة، تظهر قبل الإرسال أو المشاركة أو الاتصال. وإذا كانت المهمة خارج الدعم الحالي، يحصل المستخدم على مسار عملي بدلا من وعد عام. بهذه الطريقة نستفيد من Kimi أو DeepSeek أو GLM أو غيرها دون أن نخلط بين النموذج والهاتف.

كيف يتعامل FoneClaw مع النماذج القابلة للاختيار؟

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

مثال عملي: يقول المستخدم، لخص هذه الملاحظة واجعلها تذكيرين. نموذج طويل السياق يقرأ الملاحظة ويستخرج المهم. FoneClaw يعرض التذكيرين، يقترح وقتا، ويطلب التأكيد قبل الحفظ. مثال آخر: حضر ردا قصيرا على رسالة. يمكن لنموذج منخفض الكلفة وسريع أن ينجز الصياغة، ثم يعرض FoneClaw النص والمستلم قبل الإرسال. في كلتا الحالتين، النموذج لا يملك الهاتف؛ هو يقود التخطيط داخل وكيل الهاتف.

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

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

قائمة قرار لاختيار أو تبديل نموذج وكيل الهاتف

قبل اختيار Kimi K3 أو DeepSeek V4 Pro أو GLM-5.2 أو Qwen أو Hy3، ابدأ من مسار الهاتف الذي تريد دعمه. لا تجعل القرار يبدأ من جدول قياس فقط. اسأل: هل المهمة قصيرة أم طويلة؟ هل تحتاج ردودا فورية؟ هل تحتوي ملفات خاصة؟ هل تتطلب العربية أو عدة لغات؟ هل تتكرر كثيرا بحيث تصبح الكلفة مهمة؟ وهل يحتاج الوكيل إلى استخدام أدوات متعددة؟

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

الخلاصة أن أفضل نموذج لوكيل الهاتف هو النموذج المناسب للمهمة، لا أعلى اسم في كل نقاش. Kimi K3 وDeepSeek V4 Pro وGLM-5.2 وQwen وHy3 كلها إشارات إلى سوق سريع الحركة. قيمة FoneClaw هي تحويل هذا السوق إلى تجربة عملية: نموذج يخطط، ووكيل هاتف يعرض وينفذ ما يدعمه Android، ومستخدم يراجع ويؤكد في المواضع الصحيحة.