توجيه النماذج لوكيل الهاتف: كيف تختار نموذج Android حسب المهمة؟

اختر مسار توجيه لا فائزا دائما

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

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

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

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

وجّه النموذج حسب الموثوقية والسرعة والكلفة والسياق والخصوصية

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

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

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

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

Kimi وDeepSeek وGLM كمرشحين حاليين للتوجيه

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

إشارة Kimi الحالية واضحة من إعلان GitHub عن توفر Kimi K3 في GitHub Copilot. هذا يثبت أن Kimi أصبح خيارا ظاهرا في منتج كبير لاختيار النماذج، وهي إشارة مهمة إلى تعدد المسارات. لكنه لا يثبت وحده أن Kimi هو أفضل نموذج لإرسال رسالة من Android أو حل اسم جهة اتصال أو التعامل مع إذن ناقص. كل ذلك يحتاج اختبارا داخل منتج الهاتف.

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

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

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

كيف تتعامل مع تغير الكلفة والتوفر دون كسر المهام؟

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

يعطي إعلان Google Developers عن API موحد لتوجيه النماذج عبر Google Cloud API Gateway إشارة بنية مهمة: السوق يحتاج سطحا موحدا يوجّه بين مزودين ونماذج متعددة. هذه إشارة بنية تحتية، لا إثباتا بأن كل مزود يعمل مع كل وكيل هاتف. لكنها تؤكد أن التوجيه أصبح طبقة تشغيل يجب إدارتها بسياسة واضحة.

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

لا تستخدم سعرا دقيقا غير متحقق كقاعدة دائمة. الأسعار والعروض تتغير، وقد تختلف حسب المنطقة أو الحساب أو طبقة الاستخدام. الأفضل هو بناء جدول داخلي يتحدث بلغة نسبية: مناسب للمهام المتكررة، مناسب للسياق الطويل، مناسب للمهام الحساسة، أو مناسب كبديل عند فشل المسار الأساسي. بعد كل تغيير، أعد اختبار schema، زمن الاستجابة، نتيجة Android، وسلوك الاسترداد.

قِس جودة النموذج داخل حلقة إجراء Android

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

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

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

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

تكوين استدلال النموذج بينما يحكم FoneClaw تنفيذ Android

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

ما تعلمناه من بناء FoneClaw أن النموذج لا يجب أن يحمل مسؤولية التنفيذ وحده. هو يقرأ النية، يقترح الخطة، ويجهز استدعاء القدرة. بعد ذلك يتعامل FoneClaw مع 100+ built-in tools لإجراءات Android المدعومة، ويعرض النتيجة أو خطوة الموافقة أو سبب التوقف. الإرفاق التلقائي، الاقتراح، والمسار البديل تساعد في مطابقة القدرة والسياق، لكنها لا تتجاوز موافقة المستخدم ولا تحوّل اكتشاف القدرة إلى تنفيذ حساس بصمت.

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

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

سياسة عملية لتوجيه نماذج وكيل الهاتف

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

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

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