وكيل ذكاء اصطناعي بسياق شخصي: من إشارات الهاتف إلى إجراء Android محكوم

ما السياق الشخصي في مهمة هاتف واحدة؟

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

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

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

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

طبقات سياق وكيل الهاتف

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

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

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

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

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

اختر أقل سياق يكفي للمهمة

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

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

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

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

من السياق إلى إجراء Android مرئي

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

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

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

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

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

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

متى يضلل السياق وكيل الهاتف؟

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

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

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

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

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

اختبار آمن لوكيل واعٍ بالسياق

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

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

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

1. اختر مهمة منخفضة المخاطر وقابلة للرجوع.
2. حدد الإشارات المسموح استخدامها قبل البدء.
3. توقع النتيجة والموافقة المطلوبة.
4. شغّل المهمة وافحص النتيجة داخل التطبيق نفسه.
5. أوقف أو ألغِ السياق الاختياري بعد الاختبار.
6. أعد التجربة مع تغيير واحد فقط.
7. وسّع الاستخدام فقط عندما ترى تفسيرًا واستردادًا واضحين.

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

كيف نصمم FoneClaw حول السياق المفيد؟

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

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

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

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

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