یک عامل Claude AI که میتوانست تمام فیلدهای متنی یک فرم وب را پر کند، در مرحله نهایی هنگام تلاش برای پیوست کردن سه تصویر، متوقف شد و یک محدودیت مستند نشده در مدیریت آپلود فایل در Desktop App را آشکار کرد. این شکست از این جهت اهمیت دارد که یک اتوماسیون بهظاهر کامل و سرتاسری (end-to-end) را به یک فرآیند تحویل دستی تبدیل میکند و توسعهدهندگان را مجبور میکند در نحوه ساخت جریانهای کاری مبتنی بر هوش مصنوعی بازنگری کنند.
چرا این مشکل اکنون ظاهر شده است
عوامل Claude در سه محیط اجرا میشوند: رابط خط فرمان (CLI)، افزونه Visual Studio Code، یا اپلیکیشن دسکتاپ (Desktop App) مستقل. در CLI، عامل یک فایل را از دایرکتوری اضافه شده به نشست (session) میخواند و بدون مشکل آن را آپلود میکند. Desktop App این رفتار را ندارد. حتی زمانی که عامل فایلی را در پوشه موقت خود مینویسد، اپلیکیشن آپلود را رد میکند و به تعریفی داخلی از فایلهای «اشتراکی» (shared) استناد میکند که هرگز در مستندات عمومی ظاهر نمیشود.
این تفاوت زمانی آشکار شد که یک کاربر اتوماسیونی ساخت که یک فرم را پر میکرد، روی «save draft» کلیک میکرد و سپس سعی میکرد سه تصویر را پیوست کند. فیلدهای متنی بدون نقص پر شدند، اما مرحله آپلود هر بار با خطا مواجه میشد.
توسعهدهندگان چه چیزهایی را امتحان کردهاند
- افزودن فایلها به پوشه نشست (session folder) که اپلیکیشن ایجاد میکند.
- استفاده از ابزار directory-connect که به عامل اجازه میدهد یک پوشه میزبان را ببیند.
- پیوست کردن مستقیم تصاویر در پنجره چت.
- ایجاد یک پوشه آپلود دستی و هدایت فرم به آن.
تمام این روشها منجر به همان خطای رد شدن (rejection error) شدند. پنجره مرورگری که دیالوگ انتخاب فایل (file-picker) را نمایش میدهد، برای اتوماسیون دسکتاپ در حالت فقط خواندنی (read-only) اجرا میشود. عامل میتواند دیالوگ را ببیند اما نمیتواند داخل آن کلیک کند یا مسیری را تایپ کند، بنابراین ترفندهای اتوماسیون رابط کاربری (UI-automation) شکست میخورند.
یک «درب پشتی» شکننده
تنها روشی که موفقیتآمیز بود از کلیپبورد ویندوز استفاده کرد:
- یک اسکریپت PowerShell فایل مورد نظر را در کلیپبورد کپی میکند.
- عامل کلیدهای Ctrl + V را ارسال میکند.
- مرورگر رویداد چسباندن (paste) را دریافت کرده و فایل را آپلود میکند.
این راهکار کار میکند، اما کلیپبورد کاربر را پاک میکند، محدود به ویندوز است و ممکن است با هر بهروزرسانی Desktop App از کار بیفتد. این یک راه حل پایدار برای خطوط تولید (production pipelines) نیست.
این محدودیت واقعاً به چه معناست
مسئله اصلی یک باگ نرمافزاری نیست؛ بلکه یک سطح مستند نشده است که مجوزهای فایل را به جای یک پرچم ساده در سیستم فایل، به عنوان ویژگی اپلیکیشن میزبان در نظر میگیرد. در CLI، عامل دسترسی خواندنیِ فرآیند را به ارث میبرد، بنابراین هر فایلی که نشست بتواند ببیند، قابل آپلود است. در Desktop App، محیط اجرا (runtime) دیدگاه سیستم فایلِ عامل را ایزوله میکند و تنها اجازه دسترسی به فایلهایی را میدهد که معیارهای پنهان «shared» را برآورده کنند.
از آنجایی که این محدودیت در معماری Desktop App نهفته است، راهکارهای جایگزینی که بر دستکاری رابط کاربری یا پوشههای موقت تکیه دارند، موفق نبودهاند.
مسیرهای قابل اعتماد برای آینده
اگر یک جریان کاری به آپلود فایل نیاز دارد، توسعهدهندگان سه گزینه قابل اعتماد دارند:
- اجرای عامل از طریق CLI. این محیط به مجوزهای سیستم فایلِ نشست احترام میگذارد و بدون مراحل اضافی آپلود میکند.
- استفاده از افزونه VS Code. این افزونه مدل مجوز CLI را بازسازی میکند و به عاملها اجازه میدهد فایلهایی را که ویرایشگر میبیند، بخوانند و آپلود کنند.
- سپردن مرحله آپلود به انسان. یک اقدام دستی سریع دو دقیقهای، بهتر از ساعتها صرف مهندسی یک راهکار شکننده است.
انتخاب دو گزینه اول باعث میشود اتوماسیون خارج از Desktop App اجرا شود.
خلاصه کلام
قابلیت آپلود فایل در عوامل Claude AI در تمام محیطهای اجرا یکسان نیست؛ بلکه به نحوه اجرای عامل بستگی دارد. برای اتوماسیون قابل اعتماد، با CLI و افزونه VS Code به عنوان تنها محیطهایی برخورد کنید که به طور قابل اطمینان به مجوزهای سیستم فایل احترام میگذارند. هنگام استفاده از Desktop App، برای یک تحویل دستی برنامهریزی کنید یا یک راهکار شکننده مبتنی بر کلیپبورد را بپذیرید. نادیده گرفتن این تفاوت میتواند یک اسکریپت سرتاسری روان را به یک تمرین عیبیابی پرهزینه تبدیل کند.