خارطة طريق نظام FoneClaw OS: من وكيل Android اليوم إلى هاتف يعمل بالوكلاء
رؤية Dean وفريق FoneClaw لهاتف ذكاء اصطناعي مبني على AOSP: وكيل شخصي على الجهاز، صوت أولا، أزرار ثانية، شاشة ثالثة، ومنظومة Agent Plugin للخدمات المتخصصة.
- وفق أحدث معلومات FoneClaw المتاحة حتى الآن، أساس Android الحالي الذي نبني عليه هو: مساعد عائم، إرفاق مقصود للشاشة الحالية، استمرار للمهام بين Home والمساعد، موافقات مشتركة، إيقاف، واسترداد أذونات.
- الوجهة التي نبني نحوها هي FoneClaw Agent OS قائم على AOSP وهاتف FoneClaw مستقبلي يجعل الوكيل الشخصي مركز الهوية والتفضيلات والذاكرة والسياق بين الخدمات.
- ترتيب التفاعل في رؤيتنا هو الصوت أولا للتعبير عن النية، الأزرار الفعلية ثانيا للاستدعاء والتأكيد والإيقاف، والشاشة ثالثا للمراجعة والدليل والاختيار.
- منظومة Agent Plugin تحول الخدمات إلى قدرات مهنية محددة النطاق يستطيع الوكيل تركيبها حول مهمة المستخدم، مع أذونات واضحة ونتائج مرئية وسجل قابل للفحص.
من وكيل Android اليوم إلى وجهة FoneClaw Agent OS
أكتب هذه الرؤية بصفتي Dean ومعي فريق FoneClaw من داخل المنتج الذي نبنيه كل يوم. نقطة البداية اليوم هي FoneClaw كوكيل هاتف يعمل على Android، ونقطة الوصول التي نصمم نحوها هي FoneClaw Agent OS قائم على AOSP، ثم هاتف FoneClaw مستقبلي يجعل الوكيل الشخصي نقطة الانطلاق الطبيعية للنية والهوية والتفضيلات والذاكرة والسياق بين الخدمات. هذا المسار يبدأ من سؤال عملي جدا: كيف ينتقل طلب المستخدم من عبارة قصيرة إلى نتيجة هاتفية مدعومة يمكن رؤيتها وإيقافها واستردادها عند الحاجة؟
وفق أحدث معلومات FoneClaw المتاحة حتى الآن، نعتمد خط الأساس الحالي المتاح. في هذا الخط الأساس أصبح لدى المستخدم مساعد عائم قابل للتحريك، لوحة مدمجة، إرفاق للشاشة الحالية بضغطة واحدة مع استبعاد طبقات FoneClaw نفسها، واستمرارية للمهام بين Home والمساعد العائم في التنفيذ والموافقة والإيقاف واسترداد الأذونات. هذه التفاصيل تبدو صغيرة عندما ينظر إليها شخص من الخارج، لكنها بالنسبة لنا أجزاء من نظام تشغيل وكيل: نقطة استدعاء قريبة، سياق مقصود، حالة مهمة مفهومة، وسيطرة مرئية على الخطوة التالية.
نحن نبني FoneClaw Agent OS كوجهة معمارية، ونبني كل إصدار Android كمرحلة ملموسة باتجاهها. عندما يتحسن الاستدعاء بالمساعد العائم، نحن نختبر كيف يجب أن يظهر الوكيل فوق الهاتف. عندما نضيف إرفاق الشاشة الحالية، نحن نختبر كيف يشارك المستخدم السياق بإرادته. عندما نوحد الموافقات والإيقاف واسترداد الأذونات بين Home والمساعد، نحن نختبر كيف يجب أن تعيش حالة المهمة في النظام بدلا من أن تضيع بين مداخل مختلفة.
الوجهة المستقبلية واضحة في داخل الفريق: نظام قائم على AOSP، صوت أولا، أزرار فعلية ثانيا، شاشة ثالثا، ووكيل شخصي على الجهاز يملك السياق العابر للخدمات. الخدمات المهنية ستصل إلى الوكيل عبر Agent Plugins محددة النطاق، فيختار الوكيل القدرة المناسبة بدلا من أن يطلب من المستخدم إدارة كل تطبيق يدويا. لمن يريد خلفية أوسع حول معنى الهاتف الوكيل قبل قراءة رؤية FoneClaw الخاصة، يقدم دليل هاتف ذكاء اصطناعي وكيل: شرح عملي لتغير هواتف 2026 مدخلا مفيدا لفهم التحول من ميزة ذكاء اصطناعي منفصلة إلى هاتف يتمحور حول إنجاز المهام.
لماذا يربك نموذج التطبيقات التقليدي عمل الوكلاء؟
الهاتف الذكي التقليدي منظم حول التطبيقات. هذا التنظيم أعطى كل خدمة واجهتها وحسابها وتجربتها، لكنه جعل المستخدم هو من ينسق بين كل شيء: يفتح التطبيق، يبحث عن الشاشة، ينسخ المعلومة، ينتقل إلى تطبيق آخر، يمنح إذنا، ثم يراجع النتيجة. عندما تصبح المهمة مركبة، يظهر الاحتكاك بسرعة. رسالة قد تتحول إلى تذكير، عنوان قد يتحول إلى ملاحة، لقطة شاشة قد تتحول إلى طلب بحث، وإشعار قد يحتاج ردا أو تأجيلا أو إجراء داخل خدمة أخرى.
نحن نرى التطبيقات كخدمات مهمة داخل الهاتف، ونرى أن الوكيل يحتاج طريقة أفضل للتعامل معها. الواجهة الرسومية مفيدة للمستخدم البشري، وتبقى جسرا ضروريا للتوافق في مراحل كثيرة، لكنها تصبح قناة ضيقة عندما يحاول وكيل إنجاز مهمة عبر عدة خدمات. زر يتغير مكانه، حقل يحمل اسما مختلفا، شاشة تظهر بحساب آخر، أو إذن يحتاج فتح إعدادات. لذلك نربط في FoneClaw بين قراءة الحالة المرئية عند الحاجة، وأدوات Android محكومة، وموافقات واضحة، ومسارات استرداد تساعد المستخدم على متابعة المهمة.
التحول الذي نريده في FoneClaw OS هو أن تتحرك نقطة التنسيق من المستخدم إلى الوكيل الشخصي. المستخدم يطلب نتيجة، والوكيل يحدد الخدمة والقدرة والبيانات المطلوبة والإذن والموافقة والنتيجة. هذه الفكرة تنسجم مع اتجاه أوسع في منصة Android؛ إذ تعرض وثائق Android حول AppFunctions مثالا على وظائف يمكن للتطبيقات كشفها لوكلاء ومساعدين مخولين. نقرأ هذا كإشارة إلى مستقبل تتحول فيه بعض الخدمات من شاشات فقط إلى قدرات قابلة للاستدعاء بوضوح.
داخل FoneClaw، نترجم هذا الاتجاه إلى بناء منتج قابل للاختبار: نموذج مكوّن يفهم النية، حالة مهمة تتابع العمل، أذونات تظهر وقت الحاجة، ومخرجات يمكن للمستخدم فحصها. ومع التقدم نحو Agent Plugins، يصبح التطبيق أو الخدمة مزود قدرة لا متاهة شاشات. إذا أردت بنية أعمق لهذا التفكير، يشرح مقال أساس وكيل نظام التشغيل في 2026: ثلاث طبقات يحتاجها وكيل الهاتف العملي كيف تتكامل طبقات الفهم والسياسة والتنفيذ في وكيل هاتف واقعي.
الصوت أولا، الأزرار ثانيا، الشاشة ثالثا
ترتيب التفاعل في رؤية FoneClaw يبدأ من الصوت. الصوت هو أقصر طريق من النية إلى المهمة، لأن المستخدم يشرح ما يريد بدلا من البحث عن المسار داخل الواجهة. عندما يقول المستخدم: جهز ردا، لخّص هذه الشاشة، أوقف التنبيهات للاجتماع، أو رتّب هذه الخطوة، فهو يصف النتيجة. هذا هو المكان الطبيعي للوكيل: فهم الطلب، تحديد السياق، ثم اقتراح مسار مدعوم يمكن للمستخدم مراجعته.
الأزرار الفعلية تأتي في المرتبة الثانية لأنها تمنح المستخدم نقطة سيطرة موثوقة. زر للاستدعاء السريع، زر للتأكيد عندما تكون النتيجة واضحة، زر للإيقاف عندما تتغير النية أو يصبح الصوت غير مناسب، وربما زر لمسار طارئ في حالات حساسة. في الأماكن العامة، أثناء الضجيج، أو عند التعامل مع خطوة لها أثر حقيقي، الزر يختصر المسافة بين نية المستخدم وسيطرته على الوكيل.
الشاشة في المرتبة الثالثة لأنها تتحول من مركز للتنقل إلى مساحة للوضوح. على الشاشة يرى المستخدم ماذا فهم الوكيل، ما السياق المرفق، ما الخدمة أو التطبيق الذي سيتأثر، ما الإذن المطلوب، وما النتيجة قبل الموافقة. الشاشة في هاتف FoneClaw المستقبلي ليست مكانا لحمل عبء كل خطوة يدوية، بل مكانا لعرض الدليل والخيارات والحالة والسجل.
خط الأساس الحالي في FoneClaw يعطي مثالا أوليا لهذا الترتيب. المساعد العائم يقرّب الاستدعاء من أي شاشة. إرفاق الشاشة الحالية يحدث بقرار من المستخدم. الموافقات والإيقاف واسترداد الأذونات تظهر في المسار نفسه بدلا من العودة إلى بداية مختلفة. ولأن الصوت والأزرار والشاشة أدوار متكاملة، يقدم مقال هاتف ذكاء اصطناعي يعتمد على الصوت أولاً: لماذا لا تختفي الأزرار والشاشة؟ تفصيلا مستقلا لتصميم التفاعل الذي نبني عليه.
أساس AOSP وبنية FoneClaw OS حول الوكيل
نختار AOSP كأساس لأن بناء هاتف وكيل يحتاج أرضية Android مفتوحة ومتوافقة وقابلة للتطوير. تقدم وثائق Android Open Source Project قاعدة نظام مفتوحة لتطوير منصات Android-compatible، وهذا يناسب رؤيتنا: نريد الاستفادة من نضج Android، نموذج أذوناته، منظومة العتاد والخدمات، وخبرة المستخدمين الحالية، ثم نضيف فوقه طريقة تشغيل تتمحور حول الوكيل الشخصي.
بنية FoneClaw OS التي نصمم لها تبدأ من النظام والعتاد، ثم الوكيل الشخصي على الجهاز. هذا الوكيل يملك نية المستخدم وحالة المهمة والذاكرة والتفضيلات والسياق العابر للخدمات. فوق ذلك تعمل سياسة واضحة للأذونات والموافقات ومخاطر الأثر. بعد ذلك تأتي طبقة التنفيذ التي تربط الطلب بأدوات الهاتف، الخدمات، وAgent Plugins. النتيجة تظهر للمستخدم بلغة مفهومة: ما الذي سيحدث، ما الذي ينتظر الموافقة، وما الذي تم إنجازه.
هذا البناء يسمح بتوزيع ذكي بين المعالجة المحلية والخدمات المتصلة. مهمة حساسة وسريعة قد تستفيد من سياق على الجهاز. مهمة تحليلية أكبر قد تحتاج نموذجا مكوّنا أو خدمة متخصصة. المعيار الذي نتبعه في التصميم هو أقل سياق كاف لإنجاز المهمة، زمن استجابة مناسب، موافقة عند الأثر، ونتيجة مرئية. بهذه الطريقة يصبح اختيار النموذج أو الخدمة جزءا من سياسة المنتج، لا عبئا يضعه المستخدم على عاتقه في كل مرة.
في FoneClaw الحالي يعمل نموذج مكوّن على تفسير الطلب وتخطيط العمل المدعوم، بينما تنفذ أدوات Android المحكومة الأفعال ضمن نطاق واضح. وعلى صفحة ميزات FoneClaw نعرض القدرات الحالية بلغة مستقرة، ومنها 100+ أداة مدمجة ومسارات مدعومة للهاتف. هذا هو الشكل المبكر للبنية التي نوسعها: نية، سياق، سياسة، تنفيذ، موافقة، نتيجة، واسترداد.
كل إصدار يضيف طبقة من النضج. عندما تتحسن اختصارات الإعدادات، تصبح إجراءات النظام أقرب إلى اللغة الطبيعية. عندما تتحسن موثوقية لقطة الشاشة وإرفاق الشاشة الحالية، يصبح السياق أوضح. عندما تتحسن الموافقات المشتركة بين نقاط الدخول، تصبح حالة المهمة أكثر شبها بسلوك نظام تشغيل وكيل. هذه هي طريقة بناء FoneClaw OS من أساس Android عملي إلى تجربة هاتف متمحورة حول الوكيل.
من سوق التطبيقات إلى منظومة Agent Plugin
سوق التطبيقات صمم لعالم يختار فيه المستخدم التطبيق، يثبت الواجهة، ثم يتعلم خطوات كل خدمة. رؤيتنا لمنظومة FoneClaw مختلفة: Agent Plugins تقدم قدرات مهنية محددة يستطيع الوكيل استخدامها داخل مهمة. الإضافة تصف ما تستطيع فعله، ما المدخلات التي تحتاجها، ما النتيجة التي تعيدها، ما الأذونات المطلوبة، ما مستوى الأثر، وكيف تتعامل مع الفشل أو التعارض. بهذه الطريقة تصبح الخدمة قابلة للتركيب حول نية المستخدم.
عندما يقول المستخدم: رتب ملفاتي، جهز ملخصا من مستند، أرسل هذه النتيجة إلى خدمة محددة بعد موافقتي، أو احجز خطوة مهنية ضمن مسار أطول، فالوكيل يحتاج قدرة موثوقة لا واجهة يتجول فيها. Agent Plugin يعمل كعقد خدمة: توقيع، نطاق، مدخلات منظمة، مخرجات قابلة للفحص، وسجل. هذا يسمح للوكيل بتقسيم المهمة وتركيب القدرات دون تحميل المستخدم عبء التنقل اليدوي بين كل شاشة.
القدرات الحالية في FoneClaw تمهد لهذا الاتجاه من جهة تجربة المستخدم. المساعد العائم يضع الوكيل قرب أي سياق، إرفاق الشاشة الحالية يعطيه معلومة مقصودة، استمرار المهمة بين Home والمساعد يحافظ على العمل الجاري، والموافقات المشتركة تجعل الخطوة المؤثرة ظاهرة في موضعها. ومع تطور المهارات وسير العمل والإضافات، يصبح لدى الوكيل طريقة طبيعية لاختيار القدرات المهنية بدل الاعتماد على قائمة تطبيقات يفتحها المستخدم بنفسه.
نصمم Agent Plugins باعتبارها خدمات محددة النطاق. خدمة خرائط تحتاج وجهة وسياقا كافيا، خدمة ملفات تحتاج مسارا وطلبا واضحا، خدمة تواصل تحتاج مستلما ونصا وموافقة قبل الإرسال. وفي كل حالة تكون النتيجة قابلة للفحص، ويظهر أثر الفعل قبل التنفيذ عندما يكون مؤثرا. لمزيد من تفاصيل أمان القدرات القابلة للتوسيع، يشرح مقال أمان مهارات وكلاء الذكاء الاصطناعي: لماذا يحتاج وكيل الهاتف إلى فحص الأذونات أثناء التشغيل؟ كيف نربط القدرة بالإذن والموافقة وسجل النشاط.
هذا التغيير يفتح مجالا جديدا للمطورين والخدمات. بدلا من بناء واجهة كاملة لكل استخدام، يمكن للخدمة أن تقدم قدرة متخصصة يركبها الوكيل ضمن مسار أكبر. وبالنسبة للمستخدم، تتحول التجربة من البحث عن التطبيق المناسب إلى التعبير عن النية ورؤية النتيجة. هذه هي روح منظومة Agent Plugin التي نبني نحوها: خدمات مهنية دقيقة، ووكيل شخصي يرتبها حول هدف المستخدم.
الوكيل الشخصي مالك السياق العابر للخدمات
في الهاتف التقليدي، يتبع السياق كل تطبيق على حدة. تطبيق يعرف تفضيلات السفر، آخر يعرف أسلوب الرد، خدمة تعرف المواعيد، وأداة تحفظ ملفات أو ملاحظات. المستخدم هو من يجمع هذه الأجزاء ذهنيا. في FoneClaw Agent OS، يصبح الوكيل الشخصي على الجهاز هو المالك الافتراضي للسياق العابر للخدمات: الهوية التشغيلية، التفضيلات، الذاكرة، العلاقات بين المهام، وما يعرفه المستخدم عن طريقته في العمل.
هذا الترتيب يجعل البيانات تسير حسب المهمة. إذا احتاجت إضافة خدمة إلى تنفيذ حجز أو إرسال نتيجة أو معالجة ملف، يمنحها الوكيل أقل سياق كاف. السجلات الخاصة بالخدمة، مثل إيصال أو معاملة أو سجل قانوني، تبقى ضمن نطاق تلك الخدمة. أما الصورة العريضة لتفضيلات المستخدم وذاكرته وسياقه بين الخدمات فمكانها الطبيعي هو الوكيل الشخصي على الجهاز. بهذه الطريقة يصبح المستخدم هو مركز السياق، وتصبح الخدمات أطرافا متخصصة تساعد في إنجاز الطلب.
التصميم العملي لهذا النموذج يحتاج ذاكرة قابلة للفحص، تفويضا قابلا للإلغاء، حذف عناصر من الذاكرة، وسجل نشاط يفهمه المستخدم. عندما يتذكر الوكيل طريقة المستخدم في الرد أو تفضيلاته أو أسماء خدماته المعتادة، يجب أن يرى المستخدم هذه الذاكرة ويعدلها. وعندما تحتاج خدمة إلى معلومة محددة، يجب أن يكون السبب واضحا داخل سياق المهمة. هذا جزء من قيمة الوكيل الشخصي: خدمة أسرع، وسياق أقل تكرارا، وتحكم مباشر في ما يعرفه الهاتف عن المستخدم.
خط الأساس الحالي في FoneClaw يضع الأساس من خلال حالة المهمة المرئية، الموافقات المشتركة، واسترداد الأذونات، وربط الطلب بالنتيجة في نقاط دخول متعددة. هذه ليست الذاكرة الكاملة التي نصمم لها في FoneClaw Agent OS، لكنها تقوي عادة مهمة: كل سياق يدخل المسار لخدمة نتيجة واضحة، وكل إجراء مؤثر يظهر للمستخدم. ولمن يريد تفاصيل أكثر حول هذا الاتجاه، يقدم مقال وكيل ذكاء اصطناعي بسياق شخصي: كيف يفيد الهاتف دون تجاوز الحدود؟ معالجة أوسع لفكرة الذاكرة والتفويض والسياق الشخصي على الهاتف.
كيف يختلف FoneClaw عن مسارات AI OS الحالية؟
تظهر في الصناعة عدة طرق لبناء هاتف أو نظام متمحور حول الوكلاء. نحن نقرأ هذه المسارات كدلائل على أن الهاتف يتغير، ولكل شركة نقطة بدء مختلفة: مصنع هاتف، مساعد مثبت، نظام جديد، نموذج شركة، أو منصة مطورين. ما يهمنا في FoneClaw هو أن نوضح زاويتنا من داخل المنتج: وكيل Android قابل للاختبار اليوم، وجهة AOSP-based Agent OS، صوت أولا، وAgent Plugins كقدرات خدمة حول وكيل شخصي على الجهاز.
| المسار | الوضع المنشور | الفكرة المعمارية | قراءة FoneClaw للمسار |
|---|---|---|---|
| DroiClaw | تعرض Droi على صفحة DroiClaw الرسمية نظام تشغيل طرفي للذكاء الاصطناعي، مع نموذج صغير محلي ونموذج كبير سحابي، وتذكر تثبيتا مسبقا على هواتف مختارة في 2026 ودعم Skills مخصصة. | مسار OEM وتثبيت مسبق يجمع المعالجة الطرفية والسحابية ويعطي المصنع دورا رئيسيا في نشر التجربة. | نرى DroiClaw مثالا على طريق المصنع والتثبيت المسبق. طريق FoneClaw يبدأ من وكيل Android يستخدمه المستخدم اليوم، ثم يتوسع نحو Agent OS قائم على AOSP ومنظومة Agent Plugin حول الوكيل الشخصي. |
| Doubao Phone Assistant | يعرض موقع Doubao Phone Assistant الرسمي مساعدا لمهام الهاتف مع nubia M153، ويصف الجهد كتجربة مبكرة ويدعو المطورين إلى تقديم خدمات. | مساعد هاتف مرتبط بجهاز وشريك عتاد، مع دعوة للخدمات والمطورين حول مسار تشغيل الهاتف. | نقرأ Doubao Phone Assistant كمسار مساعد هاتف متصل بخدمة نموذج وجهاز محدد. في FoneClaw نوسع الفكرة نحو وكيل شخصي يملك السياق، وخدمات تظهر كAgent Plugins محددة النطاق عبر وجهة نظام مبني على AOSP. |
| Step AOS | تقرير إطلاق Step AOS وSTEPX Neo يصف تكاملا بين النموذج والوكيل والنظام والخدمات والعتاد والبيانات والحوسبة حول وكيل Amoo. | منظومة كاملة تربط النموذج والعتاد والخدمات حول فكرة التعبير عن النية بدلا من تشغيل التطبيقات يدويا. | نتقاطع مع Step AOS في أهمية النية كمركز للتجربة. تميز FoneClaw يأتي من بناء تدريجي يبدأ على Android، ومن تصميم يضع الوكيل الشخصي وAgent Plugins وسجل الإذن والنتيجة في مركز النظام. |
| HONOR Agentic OS | في إعلان HONOR Agentic OS تصف HONOR اتجاها مركزه النية والمهام، مع طبقات تشمل العتاد والنواة والنموذج والإطار والتفاعل والمنظومة، وتربطه بمفهوم Robot Phone. | مسار مصنع هاتف يدمج النظام والعتاد والتفاعل داخل منظومة OEM واسعة. | يمثل HONOR مسارا قويا من جهة العتاد والمنظومة. في FoneClaw نبدأ من سلوك الوكيل القابل للاختبار على Android ونبني نحو هاتف FoneClaw حيث يصبح الصوت والأزرار والشاشة ترتيب تفاعل مقصودا حول المهمة. |
| Xiaomi miclaw | يوضح إعلان Xiaomi HyperOS للمطورين أن miclaw وكيل ذكاء اصطناعي على مستوى النظام مبني على MiMo، وأن منصة منظومة Agent دخلت اختبارا محدودا وتدعم تطبيقات Agent موزعة عبر miclaw. | وكيل نظام داخل HyperOS ومنصة مطورين مرتبطة بمنظومة Xiaomi وأجهزتها. | نقرأ miclaw كمسار OEM مدمج داخل منظومة Xiaomi. طريق FoneClaw يتجه إلى Agent OS مستقل مبني على AOSP، مع اقتصاد Agent Plugins وخبرة يومية يملك فيها الوكيل الشخصي سياق المستخدم بين الخدمات. |
| FoneClaw | FoneClaw يعمل اليوم كوكيل هاتف Android وفق القدرات الحالية المتاحة، مع مساعد عائم، إرفاق الشاشة الحالية، استمرارية مهمة بين Home والمساعد، موافقات مشتركة، إيقاف، استرداد أذونات، ونموذج مكوّن يخطط بينما أدوات Android محكومة تنفذ. | مسار يبدأ من Android Runtime عملي ويستمر نحو FoneClaw Agent OS قائم على AOSP وهاتف FoneClaw. | نركز على الوكيل الشخصي كمالك للسياق، وعلى الصوت والأزرار والشاشة كترتيب تفاعل، وعلى Agent Plugins كخدمات مهنية محددة النطاق يستطيع الوكيل تركيبها حول نية المستخدم. |
خصصنا صفحات منفصلة لمن يريد التعمق في كل مسار صناعي: هاتف StepFun بعد الكشف: STEPX Neo ونظام Step AOS ووكيل Amoo، وهاتف Doubao Agent وNubia NaviX Ultra: ما الذي يتغير؟، وHONOR Agentic OS وRobot Phone: ما المتاح الآن وما الفرق عن وكيل Android؟، ومنظومة Xiaomi AI في 2026: MiMo وHyperOS AI وMiClaw وبديل FoneClaw. هذه الروابط تساعد القارئ على متابعة تفاصيل كل إعلان، بينما تظل هذه الصفحة مرجعنا الأساسي لرؤية FoneClaw نفسها.
القاسم المشترك بين هذه المسارات هو انتقال الهاتف من قوائم ثابتة إلى نية ومهمة وسياق. الاختلاف في نقطة التحكم: مصنع العتاد، منظومة النظام، نموذج الشركة، أو وكيل المستخدم. اختيارنا في FoneClaw هو أن يبدأ التحكم من الوكيل الشخصي على الجهاز، وأن تتصل به الخدمات كقدرات قابلة للتفويض، وأن تبقى النتيجة والموافقة والاسترداد جزءا من التجربة اليومية.
كيف يقترب تنفيذ FoneClaw الحالي من الوجهة؟
نقيس تقدم FoneClaw من خلال ما يختبره المستخدم على الهاتف. المرحلة الحالية هي وكيل Android محكوم: يلتقط الطلب، يأخذ السياق الذي يختاره المستخدم، يستخدم نموذجا مكوّنا للتخطيط، ثم ينفذ عبر أدوات Android مدعومة مع موافقات وإيقاف واسترداد. خط الأساس الحالي في FoneClaw يقوي هذه المرحلة لأنه يجعل الوكيل أقرب إلى الشاشة، ويحافظ على المهمة بين Home والمساعد العائم، ويوحّد مسارات الموافقة والإيقاف واسترداد الأذونات.
المرحلة التالية في العمل هي تكامل أعمق مع النظام وسياق محلي أكثر انتظاما. نريد أن تصبح حالة المهمة أكثر دواماً، وأن تظهر الأذونات في اللحظة الصحيحة، وأن تبقى الذاكرة الشخصية قابلة للفحص، وأن يتعامل الوكيل مع الفشل كجزء طبيعي من المهمة: إذن يحتاج تفعيل، شاشة تغيرت، خدمة غير متاحة، أو نتيجة تحتاج مراجعة. كل هذه التفاصيل تدفع FoneClaw من وكيل تطبيق إلى تجربة أقرب إلى نظام تشغيل وكيل.
بعد ذلك تأتي منصة Agent Plugin. في هذه المرحلة تصبح الخدمات المهنية عقود قدرات: توقيع، نطاق، مدخلات، مخرجات، موافقة، سجل، واسترداد. الوكيل يركب الخدمات حول نية المستخدم بدلا من أن يترك المستخدم يبحث عن التطبيق المناسب. هذا هو المكان الذي تتحول فيه منظومة FoneClaw إلى اقتصاد خدمات وكيلية؛ كل إضافة تفعل شيئا محددا بإتقان، والوكيل الشخصي ينسق بينها عبر سياق المستخدم وإذنه.
ثم تأتي وجهة FoneClaw Agent OS وهاتف FoneClaw. نستخدم AOSP كأساس، ونصمم الهاتف حول صوت أولا، أزرار فعلية ثانيا، شاشة ثالثا، ووكيل شخصي على الجهاز يملك الهوية والتفضيلات والذاكرة والسياق بين الخدمات. هذه الوجهة تقود قراراتنا الحالية في الاستدعاء، السياق، الأذونات، الإضافات، الاسترداد، وتكامل النظام.
معيار التقدم واضح بالنسبة لنا وللمستخدم: هل تكتمل المهمة المدعومة؟ هل يعرف المستخدم ما الإذن المطلوب ولماذا؟ هل يستطيع إيقاف الوكيل في اللحظة المناسبة؟ هل يستعيد المسار بعد رفض إذن أو تغير شاشة؟ هل يظل نطاق البيانات مناسبا للمهمة؟ هل تعمل الإضافات بنتائج قابلة للفحص؟ وهل يترك التنفيذ سجلا مفهوما؟ هذه الأسئلة هي طريقة قياس خارطة طريق نظام FoneClaw OS من اليوم إلى الهاتف المستقبلي.
للتجربة العملية الآن، يمكن البدء بمهمة Android بسيطة: افتح تطبيقا، أرفق الشاشة الحالية، اطلب تلخيصا أو خطوة مدعومة، راجع الموافقة، ثم جرّب الإيقاف أو استرداد الإذن. دليل التحكم في الهاتف بواسطة وكيل ذكاء اصطناعي: كيف يعمل وكيل أندرويد بأمان؟ يشرح المسار الحالي من زاوية التنفيذ. أما هذه الصفحة فتجمع الرؤية الكاملة: خط الأساس الحالي في FoneClaw هو أساس Android الذي نبني عليه، وFoneClaw Agent OS هو الوجهة التي تجعل الهاتف نفسه يدور حول الوكيل الشخصي والمهمة.