Pinky يمنح Claude التحكم بهاتف حقيقي عبر MCP — والمدفوعات فقط بموافقتك

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

ما الذي أُعلن عنه بالضبط

بحسب منشور على X للحساب @xiaoanlab، فإن المخطط كالتالي. يعمل Pinky كخادم MCP يتصل به Claude Code أو Cursor. وعبره يحصل الوكيل على صورة شاشة جهاز حقيقي ويستطيع الضغط عليها. والدعم معلن لكل من iPhone وAndroid. الحديث لا يدور عن محاكٍ بل عن هاتف مادي، وهذا فارق مهم: ففي الأجهزة الحقيقية تظهر أخطاء لا وجود لها في المحاكي، من نزوات الكاميرا والإشعارات الفورية إلى سلوك نوافذ النظام الحوارية.

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

السؤال الأهم: من يضع يده على الزر

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

ويُشدَّد بشكل منفصل على أن القواعد تُنفَّذ بصرامة في بوابة Pinky. وهذا أمر جوهري. فإذا كان المنع قائمًا في الـ prompt النظامي فقط، فيمكن الالتفاف عليه بالحقن: نص خبيث على الشاشة يقنع النموذج بأن الدفع جائز. أما إذا كان الفحص على مستوى وكيل وسيط (proxy) بين الوكيل والجهاز، فلا يستطيع النموذج فعليًا إرسال أمر خطير دون تأكيد، مهما حاولوا إقناعه. وهذا هو المبدأ نفسه الذي يمنع في بيئات الإنتاج إعطاء الوكيل وصولًا مباشرًا إلى قاعدة البيانات، ويضع بينهما طبقة صلاحيات.

القيود وما العمل حيالها

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

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

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