توقف وكيل Claude AI، الذي كان بإمكانه ملء كل حقل نصي في نموذج ويب، تماماً عند الخطوة الأخيرة عندما حاول إرفاق ثلاث صور، مما كشف عن قصور غير موثق في معالجة رفع الملفات في تطبيق سطح المكتب (Desktop App). تكمن أهمية هذا الفشل في أنه يحول عملية أتمتة تبدو كاملة وشاملة (end-to-end) إلى عملية تتطلب تدخلاً يدويًا، مما يجبر المطورين على إعادة التفكير في كيفية بناء سير عمل مدفوع بالذكاء الاصطناعي.

لماذا تظهر هذه المشكلة الآن

تعمل وكلاء Claude في ثلاث بيئات: واجهة سطر الأوامر (CLI)، أو إضافة Visual Studio Code، أو تطبيق سطح المكتب (Desktop App) المستقل. في بيئة CLI، يقرأ الوكيل ملفًا من دليل تمت إضافته إلى الجلسة ويرفعه دون أي مشكلة. أما تطبيق سطح المكتب فلا يتبع هذا السلوك؛ فحتى عندما يكتب الوكيل ملفًا في مجلده المؤقت الخاص، يرفض التطبيق عملية الرفع، مستشهدًا بتعريف داخلي للملفات "المشتركة" (shared) لا يظهر أبدًا في الوثائق العامة.

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

ما الذي جربه المطورون

  • إضافة الملفات إلى مجلد الجلسة الذي ينشئه التطبيق.
  • استخدام أداة "directory-connect" التي تسمح للوكيل برؤية مجلد المضيف.
  • إرفاق الصور مباشرة في نافذة الدردشة.
  • إنشاء مجلد رفع يدوي وتوجيه النموذج إليه.

أنتجت كل هذه الأساليب نفس خطأ الرفض. نافذة المتصفح التي تعرض مربع حوار اختيار الملفات تعمل في وضع "القراءة فقط" بالنسبة لأتمتة سطح المكتب. يمكن للوكيل رؤية مربع الحوار ولكنه لا يستطيع النقر بداخله أو كتابة مسار، لذا تفشل حيل أتمتة واجهة المستخدم (UI-automation).

"باب خلفي" هش

الطريقة الوحيدة التي نجحت استخدمت حافظة Windows:

  1. يقوم نص PowerShell برمجياً بنسخ الملف المستهدف إلى الحافظة.
  2. يرسل الوكيل ضغطة مفاتيح Ctrl + V.
  3. يستقبل المتصفح حدث اللصق ويرفع الملف.

هذه الحيلة تعمل، لكنها تمسح حافظة المستخدم، وتقتصر على نظام Windows، وقد تتعطل مع أي تحديث لتطبيق سطح المكتب. إنها ليست حلاً مستدامًا لخطوط الإنتاج (production pipelines).

ما يعنيه هذا القصور حقًا

المشكلة الأساسية ليست خطأً برمجياً (bug)؛ بل هي سطح غير موثق يعامل أذونات الملفات كخاصية للتطبيق المضيف بدلاً من كونها مجرد علامة (flag) في نظام الملفات. في بيئة CLI، يرث الوكيل صلاحية القراءة الخاصة بالعملية، لذا يمكن رفع أي ملف تستطيع الجلسة رؤيته. أما في تطبيق سطح المكتب، فإن وقت التشغيل (runtime) يعزل عرض نظام الملفات الخاص بالوكيل، مما يسمح فقط بالملفات التي تستوفي معايير "المشاركة" (shared) المخفية.

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

مسارات موثوقة للمضي قدماً

إذا كان سير العمل يتطلب رفع ملفات، فلدى المطورين ثلاثة خيارات موثوقة:

  • تشغيل الوكيل من CLI. تحترم هذه البيئة أذونات نظام الملفات الخاصة بالجلسة وترفع الملفات دون خطوات إضافية.
  • استخدام إضافة VS Code. تحاكي الإضافة نموذج أذونات CLI، مما يسمح للوكلاء بقراءة ورفع الملفات التي يمكن للمحرر رؤيتها.
  • ترك خطوة الرفع للإنسان. إجراء يدوي سريع لمدة دقيقتين أفضل من قضاء ساعات في هندسة حل بديل هش.

اختيار الخيارين الأولين يعني تشغيل الأتمتة خارج تطبيق سطح المكتب.

الخلاصة

قدرة رفع الملفات في وكلاء Claude AI ليست عالمية عبر جميع بيئات التشغيل؛ بل تعتمد على كيفية تشغيل الوكيل. للحصول على أتمتة موثوقة، تعامل مع CLI وإضافة VS Code باعتبارهما البيئتين الوحيدتين اللتين تحترمان أذونات نظام الملفات بشكل موثوق. عند استخدام تطبيق سطح المكتب، خطط لعملية تسليم يدوي أو اقبل حيلة الحافظة الهشة. إن تجاهل هذا التمييز يمكن أن يحول نصاً برمجياً سلساً وشاملاً إلى عملية تصحيح أخطاء (debugging) مكلفة.

المصدر: https://dev.to/mxhlix/my-agent-filled-in-every-field-on-the-form-it-could-not-attach-the-three-images-23kh