معضلة تصادم المستخدم مع الوكيل: لماذا تتطلب أتمتة سطح المكتب تنفيذاً مستقلاً في الخلفية؟

تواجه وكلاء الذكاء الاصطناعي المستقلة المصممة للتعامل مع واجهات المستخدم الرسومية (GUI) خللاً تشغيلياً جوهرياً بمجرد تشغيلها على أجهزة المطورين: التنازع على مؤشر الفأرة الحقيقي ولوحة المفاتيح. فعندما تعتمد النماذج على مكتبات الأتمتة التقليدية مثل PyAutoGUI أو واجهات حقن النقرات الشائعة عبر الإحداثيات المطلقة للشاشة، يستولي الوكيل بالكامل على مؤشر النظام ويسحب تركيز النافذة النشطة (Window Focus). فإذا حاول المطور مراجعة كود برمجي أو كتابة رسالة بريد إلكتروني بينما يقوم الوكيل بملء استمارات على المتصفح أو التنقل داخل بيئة التطوير، يتصادم الطرفان على الفور. تنتهي ضربات المفاتيح في حقول إدخال خاطئة، وتُرسل النقرات إلى نوافذ عشوائية متداخلة، مما يفشل مهمة الوكيل ويعطل عمل المطور في آن واحد.

افترضت المعماريات الأولى لوكلاء استخدام الحاسوب (Computer Use) أن بيئة سطح المكتب مخصصة لمستخدم واحد فقط (Single-Tenant Environment). قد ينجح هذا الافتراض داخل بيئات سحابية افتراضية معزولة، لكنه ينهار تماماً في بيئات العمل الحقيقية. وبينما وفرت أنثروبيك أدوات متقدمة عبر إطلاق حزمة Claude Agent Stack الرسمية وتصفح الويب عبر إتاحة أداة Claude in Chrome العامة، فإن أتمتة سطح المكتب المستقلة على أجهزة المطورين تتطلب معالجة مباشرة لصراع المؤشر مع المستخدم. بالإضافة إلى ذلك، يتسبب الاعتماد الحصري على استنتاج إحداثيات البكسل (x, y) من النماذج البصرية في معدلات فشل مرتفعة، حيث تؤدي اختلافات كثافة الشاشة (DPI)، أو تغيير حجم النافذة، أو تنعيم الخطوط إلى نقر الوكيل على مساحات فارغة بدلاً من الأزرار المستهدفة.

ضمن هذا السياق التقني، يقدم مشروع cua-driver (في إصداره المستقر 0.23.2، المطور برخصة MIT بواسطة TryCua والمطور فرانشيسكو بوناتشي) إعادة هيكلة شاملة لأتمتة سطح المكتب الخاصة بالوكلاء. فبدلاً من التعامل مع نظام التشغيل كبث فيديو صامت يعتمد على سرقة الفأرة، يؤسس cua-driver مسار توجيه حتمي للمدخلات الاصطناعية في الخلفية (Background-First Synthetic Input)، ويعتمد على شجرة إمكانية الوصول الأصلية (Accessibility Tree) عبر أنظمة لينكس وماك وويندوز، مقدماً سلماً تدريجياً للتحقق من تنفيذ الأوامر عبر بروتوكول سياق النموذج (Model Context Protocol - MCP).

الأنظمة التقليدية (PyAutoGUI / وكلاء الشاشة المباشرة):
[ وكيل الذكاء الاصطناعي ] ---> يستولي على الفأرة الحقيقية ---> يسحب تركيز النافذة النشطة ---> يتعطل المطور

معمارية cua-driver (التشغيل المستقل في الخلفية عبر شجرة النظام):
[ وكيل الذكاء الاصطناعي ] (Claude Code / Codex / Hermes / نماذج محلية)
       |
       |  بروتوكول سياق النموذج (MCP stdio أو مقبس محلي Daemon Socket)
       v
+--------------------------------------------------------------------------+
|                            محرك CUA-DRIVER الأساسي                        |
|                                                                          |
|  1. طبقة الإدراك: تقنية SOM / الرؤية المجردة / شجرة إمكانية الوصول AX      |
|  2. محرك التوجيه: إرسال مباشر للأحداث الاصطناعية لسطح النافذة المستهدفة  |
|  3. سلم التحقق: confirmed -> unverifiable -> px -> foreground            |
|  4. حضور بصري مستقل: مؤشرات فارة متحركة مخصصة لكل جلسة (Lottie Cursors) |
+--------------------------------------------------------------------------+
       |                           |                            |
       v                           v                            v
  لينكس (AT-SPI / Wayland)     ماك أو إس (Cocoa AX / TCC)     ويندوز (UI Automation)

تشريح محرك توجيه المدخلات في الخلفية

يرتكز المبدأ الهندسي الأساسي لأداة cua-driver على التنفيذ الهادئ دون مقاطعة المستخدم (Non-Intrusive Background Execution). فعندما ينقر الوكيل على زر، أو يمرر شريط التمرير، أو يكتب نصاً داخل نافذة غير نشطة، يظل مؤشر الفأرة الحقيقي للمطور دون تحريك، ويبقى تركيز لوحة المفاتيح ثابتاً في محرره المفتوح، وتظل أسطح المكتب الافتراضية (Virtual Desktops) مستقرة دون أي تبديل مفاجئ.

يتطلب هذا الإنجاز تكاملاً دقيقاً مع طبقات العرض ونواة كل نظام تشغيل بدلاً من المحاكاة السطحية للمدخلات:

1. نظام لينكس (خوادم X11 وبيئات Wayland الحديثة): في بيئات X11، يوجه cua-driver أحداث الإدخال مباشرة إلى معرّفات النوافذ المستهدفة (عبر استدعاءات XSendEvent المباشرة لسطح النافذة) بدلاً من بث حركة المؤشر العامة عبر امتداد XTest. وفي بيئات Wayland الحديثة، يتكامل المشغل مع بوابة RemoteDesktop التابعة لمشروع FreeDesktop وعبر خدمات مساعدة خاصة، مستفيداً من ناقل D-Bus للوصول إلى واجهات AT-SPI (org.a11y.Bus) للتفاعل مع عناصر التطبيقات دون الحاجة إلى تنشيط النافذة على مستوى مدير النوافذ (Compositor).

2. نظام ماك أو إس (واجهات Cocoa AX ونظام صلاحيات TCC): على أنظمة Darwin، يعمل المشغل عبر واجهات تفريغ الأحداث CoreGraphics ومكتبات Cocoa Accessibility. وبدلاً من إطلاق أحداث عامة تربك سير العمل، يستهدف المشغل طبقات محددة لسطح خادم النوافذ مع التنسيق المباشر مع نظام الصلاحيات TCC (Transparency, Consent, and Control) المنسوب لعملية الوكيل المستضيف.

3. نظام ويندوز (إطار عمل UI Automation): على بيئة ويندوز، يرتبط المشغل بإطار UI Automation وطوابير رسائل النوافذ (WM_COMMAND وWM_SETTEXT ومقابض النوافذ المستهدفة HWND)، مما يتيح التفاعل البرمجي المباشر مع العناصر الرسومية دون نقل تركيز النظام ودون التسبب في وميض شريط المهام.

# فحص جاهزية النظام الفرعي وشبكة إمكانية الوصول عبر الأداة
$ cua-driver doctor --json
{
  "ok": true,
  "probes": [
    { "label": "binary", "message": "cua-driver 0.23.2 (x86_64-linux)", "status": "ok" },
    { "label": "display server", "message": "X11 (DISPLAY=:0.0)", "status": "ok" },
    { "label": "AT-SPI", "message": "org.a11y.Bus reachable via session bus", "status": "ok" }
  ]
}

أنماط الإدراك: من إحداثيات البكسل إلى فهرسة Set-of-Mark

تعاني النماذج اللغوية البصرية من صعوبة بالغة عند مطالبتها بتوليد إحداثيات عشرية دقيقة على شاشات عالية الدقة. فالنموذج الذي يعالج إطاراً بدقة 1920x1080 بعد ضغطه وتجزئته إلى 1024 رمزاً بصرياً يخطئ عادة في استهداف أيقونة صغيرة بحجم 16x16 بكسل بفارق عشرات البكسلات.

لمعالجة ظاهرة هلوسة الإحداثيات، يوفر cua-driver ثلاثة أنماط إدراك متباينة عبر إجراء الالتقاط capture:

النمط	المخرجات المستلمة	حالة الاستخدام المثالية	كفاءة استهلاك الرموز (Tokens)
som (علامات الفهرسة)	لقطة شاشة مرقمة + أوسمة على العناصر + فهرس شجرة AX	النماذج البصرية المتقدمة (Claude, GPT-4o, Gemini)	متوازنة: استهلاك صورة واحدة بالإضافة إلى مصفوفة دلالية
vision	لقطة شاشة مجردة وغير معدلة	مقارنة الفوارق البصرية والتحقق من التخطيط	تكلفة الصور القياسية
ax	شجرة إمكانية الوصول النصية فقط (JSON / Text)	النماذج النصية فقط وحلقات الوكلاء فائقة السرعة	صفر رموز صور، وسرعة استجابة تقاس بأجزاء من الثانية

في نمط som، يفحص cua-driver التسلسل الهرمي لإمكانية الوصول للتطبيق النشط، ويستخرج مربعات الحدود (Bounding Boxes) لجميع العناصر التفاعلية (أزرار، حقول إدخال، روابط، أشرطة تبويب)، ويرسم أرقاماً عالية التباين فوق كل عنصر مباشرة:

استعلام شجرة إمكانية الوصول المجمعة:
[1] AXButton: "رجوع" @ (12, 80, 28, 28)
[2] AXTextField: "شريط العناوين" @ (80, 80, 900, 32)
[3] AXButton: "تشغيل البناء" @ (990, 80, 85, 32)
[4] AXLink: "التوثيق البرمجي" @ (20, 240, 110, 20)

وبدلاً من تخمين النموذج لإحداثيات عشوائية مثل {"x": 1032, "y": 96}، يصدر الوكيل أمراً حتمياً محدداً:

{
  "action": "click",
  "element": 3,
  "capture_after": true
}

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

سلم التحقق والتصعيد التدريجي للمدخلات

من الأخطاء الكلاسيكية في وكلاء سطح المكتب افتراض أن الإجراء قد نجح لمجرد أن استدعاء الأداة انتهى دون خطأ فوري. تواجه الواجهات الحقيقية تأخيراً في التقديم (Asynchronous Rendering)، وتجمداً في بعض عقد إمكانية الوصول، وواجهات رسومية مبنية بمحركات مخصصة لا تستجيب للمدخلات الاصطناعية.

لهذا السبب، يفرض cua-driver بروتوكولاً هندسياً صارماً يقوم على سلم تحقق وتصعيد خماسي المراحل:

[ المرحلة 1: نقر العنصر في الخلفية (الافتراضي) ]
  click(element=N)
        |
        +---> أثر الإجراء: "confirmed" (تحقق فعلي عبر شجرة النظام) ---> تم بنجاح
        |
        +---> أثر الإجراء: "unverifiable" -------------------------> [ المرحلة 2: إعادة الفحص ]
        |                                                              إعادة التقاط الحالة قبل أي محاولة جديدة
        +---> أثر الإجراء: "suspected_noop" أو رفض بروتوكولي
        |
        v
[ المرحلة 3: استهداف البكسل في الخلفية ]
  click(coordinate=[x, y])
        |
        +---> أثر الإجراء: "confirmed" أو تحقق بصري مؤكد -----------> تم بنجاح
        |
        +---> أثر الإجراء: "suspected_noop" / background_unavailable
        |
        v
[ المرحلة 4: تصعيد النقر إلى الواجهة النشطة Foreground ]
  click(element=N, delivery_mode="foreground")
  (رفع النافذة مؤقتاً، تطبيق الإدخال، ثم إعادة التركيز للوضع السابق)
        |
        +---> تحقق فعلي من تغير الحالة ----------------------------> تم بنجاح
        |
        +---> تجاهل المدخلات من أطر الواجهات الحساسة
        |
        v
[ المرحلة 5: رصد حدود أطر الواجهات واللجوء للبدائل النظامية ]
  تجاوز محاكاة النقرات بالكامل (استخدام أدوات الطرفية، أو ناقل DBus، أو تعديل الملفات مباشرة)

معالجة شذوذ الأطر الرسومية: معضلة تجاهل المدخلات في أدوات Qt

كشفت الاختبارات التقنية العميقة لأداة cua-driver عن سلوك خاص في بعض أطر العمل الرسومية. فعلى سبيل المثال، تتجاهل بعض مكونات واجهات Qt (مثل عنصر KTextEditor المستخدم في تطبيقات محررات بيئة KDE كبرنامج Kate وبرنامج KWrite) ضربات المفاتيح الاصطناعية الواردة عبر X11 أو Wayland بتصميم داخلي متعمد. وفي مثل هذه الحالات، تؤكد طبقة النظام نجاح حقن الحدث، لكن ذاكرة التخزين المؤقت للنص لا تستقبل أي تغيير.

وبدلاً من الوقوع في حلقة تكرار لانهائية تستهلك الرموز والموارد، يرصد cua-driver هذا الشذوذ على الفور. فبمجرد تأكد الوكيل من عدم حدوث أي تغيير برغم تصعيد المحاولة للواجهة الأمامية، يوجه المشغل الوكيل إلى التراجع إلى واجهات النظام المباشرة: كتابة التعديل على الملف عبر أدوات الطرفية أو توجيه الأوامر عبر ناقل DBus.

التكامل مع بروتوكول سياق النموذج (MCP) وبنية خادم النظام

تعمل أداة cua-driver كخادم قياسي متوافق مع بروتوكول سياق النموذج (MCP). ويمكن لأي منصة أو عميل يدعم MCP (مثل Claude Code أو Codex أو Hermes أو Cursor) الاتصال بالمشغل مباشرة عبر قنوات الإدخال/الإخراج القياسية (stdio) أو عبر مقبس الخادم المحلي الدائم. ولتفاصيل أشمل حول التطور المعماري لبروتوكولات الخوادم المستقلة، يوضح تحليلنا حول خارطة طريق مواصفات بروتوكول سياق النموذج (MCP) التحولات الهندسية في بنية الاتصال.

# تشغيل الخادم كعملية MCP مباشرة عبر stdio للعملاء المستقلين
cua-driver mcp

# أو تشغيل الخادم الدائم كخدمة للنظام
cua-driver serve --permission-mode standard

لربط المشغل بأداة مثل Claude Code، يضاف المسار إلى إعدادات ملف MCP العام أو الخاص بالمشروع:

{
  "mcpServers": {
    "computer-use": {
      "command": "cua-driver",
      "args": ["mcp"]
    }
  }
}

عند الاتصال عبر بروتوكول MCP، توفر الأداة واجهة أوامر برمجية دقيقة ومحكمة:

capture       mode="som"|"vision"|"ax"   app="<اسم التطبيق>"
click         element=N | coordinate=[x,y]   button="left"|"right"|"middle"
double_click  element=N | coordinate=[x,y]
right_click   element=N | coordinate=[x,y]
drag          from_element=N, to_element=M (أو من/إلى إحداثيات بكسل)
scroll        direction="up"|"down"|"left"|"right"   amount=3
type          text="npm run build"
key           keys="ctrl+c" | "return" | "escape"
wait          seconds=0.5
list_apps
focus_app     app="<اسم التطبيق>"   raise_window=false

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

الحضور البصري المستقل: مؤشرات حركة خاصة بكل جلسة

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

تحل أداة cua-driver هذه المسألة عبر رسم مؤشر فأرة برمجي مستقل بالكامل على شاشة العرض. وتخصص الأداة لكل جلسة MCP نشطة مؤشراً برمجياً متحركاً يعتمد على حزم رسوم متحركة مدمجة خفيفة الوزن بصيغة Lottie عبر أداة cua-cursor-theme.

# استعراض وإدارة حزم مؤشرات الوكلاء في النظام
cua-driver cursor-theme list
cua-driver cursor-theme validate default.lottie

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

الحوكمة الأمنية، والأنماط المقيدة، والإلغاء الفوري للجلسات

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

تطبق أداة cua-driver ثلاثة أنماط تفويض محكمة:

1. النمط القياسي (Standard Mode - الافتراضي): يطلب موافقة صريحة عند محاولة تصعيد النوافذ للواجهة الأمامية أو تشغيل إجراءات نظام حساسة.
2. النمط المقيد (Bounded Mode): يحصر صلاحيات الوكيل داخل وثيقة تفويض محددة سلفاً (--capability-manifest <مسار>): تحدد التطبيقات المسموح بالتفاعل معها، والمسارات البرمجية المتاحة، والإجراءات المصرح بها، مع رفض أي نشاط يخرج عن نطاق الوثيقة فوراً.
3. النمط غير المقيد (Unrestricted Mode): يفعل صراحة عبر الوسم --dangerously-bypass-approvals للاستخدام داخل بيئات الاختبار المؤتمتة المغلقة فقط.

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

# إلغاء فوري لصلاحيات جلسة وكيل محددة
cua-driver revoke --session 7f8a91c

# إيقاف وإلغاء صلاحيات جميع الجلسات النشطة في النظام دفعة واحدة
cua-driver revoke --all

التحديات الهندسية والحدود التشغيلية

برغم الحلول التقنية المتقدمة التي توفرها أداة cua-driver، تظل هناك تحديات هندسية حقيقية في بيئات الإنتاج:

1. تعدد واختلاف مدراء نوافذ Wayland: بينما يوفر نظام X11 معرّفات نوافذ مستقرة وموحدة، تختلف بيئات Wayland (مثل GNOME Mutter وKDE KWin وwlroots) في آليات عزل الصلاحيات. وتعتمد أتمتة الخلفية تحت Wayland على بوابات سطح المكتب ومحركات الإدخال الافتراضية، مما يتطلب توافقاً دقيقاً مع توزيعة النظام المستخدمة.
2. الواجهات الرسومية ذات الرسوم المخصصة (Custom Canvases): التطبيقات المبنية عبر محركات WebGL أو DirectX أو مكتبات مثل Flutter لا تعرض في كثير من الأحيان شجرة إمكانية وصول قياسية. وفي هذه البرمجيات، يتعذر على تقنية Set-of-Mark استخراج عقد الأزرار، مما يفرض التراجع الاضطراري إلى إحداثيات البكسل البصرية.
3. أعباء المعالجة مع الأشجار الضخمة: في التطبيقات المعقدة التي تحتوي على عشرات الآلاف من عناصر الواجهة (مثل برامج التصميم الهندسي CAD أو بيئات التطوير الضخمة)، قد يستغرق مسح كامل شجرة AT-SPI أو UIA وقتاً ملموساً. ولتفادي ذلك، يجب حصر نطاق الالتقاط دائماً داخل نافذة التطبيق المستهدف (app="Chrome") للحفاظ على زمن استجابة دون 150 ميلي ثانية.

التحول المستقبلي لأتمتة سطح المكتب

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

المصادر

• مستودع مشروع TryCua على GitHub
• سجلات وإصدارات cua-driver على GitHub
• مواصفات بروتوكول سياق النموذج (MCP Specification)
• معمارية إمكانية الوصول في لينكس (Linux AT-SPI)