مهر
اخبار
گیت‌هاب از قابلیت عجیب Computer Use در کوپایلوت رونمایی کرد
گیت‌هاب نسخه آزمایشی و عمومی قابلیت Computer Use را برای کوپایلوت منتشر کرد؛ ابزاری که به این دستیار اجازه می‌دهد مستقیم با نرم‌افزارهای رومیزی روی ویندوز و مک کار کند، درست مثل یک انسان پشت صفحه‌نمایش.
لیست مطالب
بخش اول: قابلیت Computer Use کوپایلوت دقیقاً چیست؟
کوپایلوت تا امروز بیشتر در نقش یک همکار برنامه‌نویس شناخته می‌شد: کدی می‌نوشت، پیشنهاد می‌داد، یا در ترمینال دستور اجرا می‌کرد. اما قابلیت تازه Computer Use این دستیار را یک قدم جلوتر می‌برد و اجازه می‌دهد مستقیم با رابط گرافیکی نرم‌افزارهای رومیزی کار کند. به زبان ساده، کوپایلوت حالا می‌تواند محتوای قابل‌دسترسی یک پنجره را بخواند، روی دکمه‌ها کلیک کند، در فیلدها تایپ کند، اسکرول کند و حتی بین چند برنامه باز، داده منتقل کند. این دقیقاً همان کاری است که یک کارمند انسانی وقتی پشت صندلی می‌نشیند انجام می‌دهد، با این تفاوت که اینجا یک هوش مصنوعی فرمان را در دست دارد.
هدف گیت‌هاب از این قابلیت، پوشش دادن شکافی است که API و ابزارهای برنامه‌نویسی نمی‌توانند پر کنند: نرم‌افزارهای قدیمی، سیستم‌های داخلی سازمانی یا برنامه‌های رومیزی‌ای که هیچ رابط برنامه‌نویسی رسمی ندارند. در چنین مواردی، تا امروز تنها راه، دخالت مستقیم یک انسان بود؛ از این به بعد کوپایلوت می‌تواند این خلأ را پر کند.
بخش دوم: نحوه فعال‌سازی و تنظیمات دسترسی در ویندوز و مک
این قابلیت هم از طریق Copilot CLI و هم از طریق اپلیکیشن دسکتاپ کوپایلوت، برای نشست‌های محلی روی ویندوز و مک در دسترس است. روی مک، کوپایلوت برای خواندن صفحه و تعامل با برنامه‌ها نیاز به دو مجوز سیستمی دارد: دسترسی Accessibility و دسترسی Screen Recording. بدون این دو مجوز، قابلیت اصلاً کار نمی‌کند.
کاربران می‌توانند این قابلیت را با دستور /computer on در خط فرمان یا از داخل بخش تنظیمات اپلیکیشن فعال کنند، و دقیقاً به همان سادگی با /computer off خاموشش کنند. نکته مهم این است که این قابلیت از ابتدا و به‌طور پیش‌فرض خاموش است؛ یعنی هیچ کاربری بدون انتخاب آگاهانه، درگیر آن نمی‌شود.
بخش سوم: مدل تایید؛ چه زمانی کوپایلوت اجازه کلیک کردن دارد؟
گیت‌هاب برای این قابلیت یک سیستم تایید چندلایه طراحی کرده است. برای هر برنامه، سه حالت ممکن وجود دارد: حالت اول، اجازه فقط برای همان نشست جاری که با بسته شدن نشست از بین می‌رود. حالت دوم، اجازه همیشگی که بین اپلیکیشن دسکتاپ و خط فرمان روی همان کامپیوتر مشترک است و در نشست‌های بعدی هم باقی می‌ماند. حالت سوم، قوانین رد دسترسی هستند که همیشه اولویت بالاتری نسبت به اجازه‌های ذخیره‌شده دارند.
یک نکته فنی قابل توجه این است که حذف یک برنامه از فهرست اجازه‌های همیشگی، دسترسی را در نشست فعال فوراً لغو نمی‌کند؛ کاربر باید عملیات را متوقف کند و نشست را به‌طور کامل ببندد تا لغو دسترسی واقعاً اجرا شود. در سطح سازمانی هم مدیران فناوری اطلاعات می‌توانند از طریق پیکربندی‌های مدیریت‌شده، این قابلیت را کاملاً مسدود کنند یا برای هر نشست، تایید دستی اجباری کنند؛ این سیاست‌ها روی خط فرمان، اپلیکیشن دسکتاپ و حتی یکپارچه‌سازی داخل ویرایشگر کد اعمال می‌شوند.
بخش چهارم: چرا خودِ گیت‌هاب توصیه می‌کند اول سراغ API بروید؟
شاید عجیب به نظر برسد، اما گیت‌هاب در مستندات رسمی خودش صریحاً توصیه می‌کند که کوپایلوت همیشه باید اول از ابزارهای ساختاریافته استفاده کند: یک API، یک سرور MCP، یک دستور ترمینال، یک عملیات فایل‌سیستمی یا یک ابزار اختصاصی خودکارسازی مرورگر. کنترل دسکتاپ فقط باید آخرین گزینه باشد، دقیقاً برای زمانی که هیچ‌کدام از این راه‌ها در دسترس نیست.
دلیل این احتیاط هم کاملاً شفاف است. تعامل مستقیم با رابط گرافیکی ذاتاً غیرقابل پیش‌بینی‌تر از فراخوانی یک API است: کوپایلوت ممکن است دکمه اشتباهی را کلیک کند، در یک مرحله گیر کند یا رفتار غیرمنتظره‌ای از خود نشان دهد. از طرف دیگر، وقتی هوش مصنوعی صفحه نمایش را «می‌بیند»، هر داده حساسی که آن لحظه روی صفحه باز باشد، به‌عنوان بخشی از زمینه کاری در اختیار آن قرار می‌گیرد؛ موضوعی که برای تیم‌های امنیت سازمانی می‌تواند نگران‌کننده باشد.
بخش پنجم: کوپایلوت در برابر رقبا؛ از Operator اوپن‌ای‌آی تا Claude
اوپن‌ای‌آی و مسیر عامل‌های خودکار
این حرکت گیت‌هاب را باید در کنار تلاش‌های مشابه رقبا دید. اوپن‌ای‌آی پیش‌تر با Operator و بعدتر با عامل‌های پیشرفته‌تری مانند Dots، همین مسیر کنترل خودکار محیط دیجیتال کاربر را امتحان کرده بود. اگر می‌خواهید زمینه بیشتری درباره این شرکت و رویکردش به هوش مصنوعی عاملی داشته باشید، می‌توانید نگاهی به این معرفی کامل از اوپن‌ای‌آی در سایت ما بیندازید.
Anthropic و Claude Computer Use
Anthropic هم مدت‌هاست با قابلیت مشابهی به نام Computer Use در Claude، تجربه کنترل مستقیم رابط کاربری را آزموده است. تفاوت اصلی رویکرد گیت‌هاب در این است که این قابلیت مستقیم در ابزارهای روزمره توسعه‌دهندگان، یعنی خط فرمان و اپلیکیشن دسکتاپ کوپایلوت، جای گرفته و هدفش بیشتر خودکارسازی کارهای تکراری دفتری است، نه فقط مرورگرگردی عمومی.
اگر کنجکاو هستید که مدل‌های زبانی و دستیارهای هوش مصنوعی مختلف در عمل چه تفاوتی با هم دارند، این مقایسه میان چت‌جی‌پی‌تی و دیپ‌سیک می‌تواند دیدی خوب از نحوه سنجش عملکرد این ابزارها به شما بدهد.
بخش ششم: کاربردهای واقعی؛ از ثبت هزینه تا تست نرم‌افزار
طبق توضیح‌های گیت‌هاب، این قابلیت بیشتر برای کارهایی طراحی شده که هنوز وابسته به رابط گرافیکی هستند: ثبت و تایید گزارش‌های هزینه در نرم‌افزارهای مالی داخلی، رزرو بلیت یا هتل در سایت‌هایی بدون API عمومی، انتقال اطلاعات بین دو برنامه که با هم صحبت نمی‌کنند، و مهم‌تر از همه، تست سرتاسری نرم‌افزار؛ یعنی وقتی کوپایلوت باید دقیقاً مثل یک کاربر واقعی، مرحله به مرحله یک اپلیکیشن را امتحان کند تا باگ‌ها را پیدا کند.
برای تیم‌های کسب‌وکاری که هنوز نمی‌دانند چرا باید وقت و بودجه روی چنین ابزارهایی بگذارند، نگاهی به این تحلیل از اهمیت هوش مصنوعی در کسب‌وکار می‌تواند تصویر روشن‌تری از بازگشت سرمایه چنین اتوماسیون‌ها ارائه بدهد.
بخش هفتم: ریسک‌ها و نگرانی‌هایی که نباید نادیده گرفت
با وجود همه مزایا، کارشناسان امنیتی چند هشدار جدی درباره این نوع قابلیت‌ها مطرح کرده‌اند. وقتی یک هوش مصنوعی به رابط گرافیکی دسترسی پیدا می‌کند، عملاً هر چیزی که روی صفحه نمایش داده می‌شود، از رمزهای عبور ذخیره‌شده تا مکالمات خصوصی یا اطلاعات مالی، می‌تواند بخشی از «زمینه کاری» آن مدل شود. از طرف دیگر، رفتار عامل‌های هوش مصنوعی در محیط گرافیکی هنوز به اندازه فراخوانی API قابل پیش‌بینی نیست و احتمال کلیک اشتباه یا گیر کردن در یک حلقه تکراری وجود دارد.
برای درک بهتر محدودیت‌های فعلی هوش مصنوعی و اینکه چرا هنوز به نظارت انسانی نیاز داریم، این مقاله درباره پتانسیل و محدودیت‌های واقعی هوش مصنوعی خواندنی خوبی است. همچنین برای کسانی که می‌خواهند بفهمند چرا هنوز فاصله زیادی بین یک دستیار خودکار و یک مهندس واقعی وجود دارد، این تحلیل درباره توسعه‌دهنده تنها در برابر مهندس واقعی پیشنهاد می‌شود.
بخش هشتم: این قابلیت چه تاثیری روی کار روزمره توسعه‌دهندگان ایرانی دارد؟
برای توسعه‌دهندگان و تیم‌های فنی فارسی‌زبان، این خبر یک یادآوری مهم هم هست: هوش مصنوعی به‌سرعت از مرز نوشتن کد عبور می‌کند و وارد حوزه اجرای کارهای عملیاتی روزمره می‌شود. کسانی که هنوز با نحوه نوشتن دستور درست برای چنین ابزارهایی آشنا نیستند، بهتر است زمانی را برای یادگیری این مهارت بگذارند. این آموزش ساده پرامپت‌نویسی برای افراد تازه‌کار می‌تواند نقطه شروع خوبی باشد، و برای کسانی که می‌خواهند با کوپایلوت و سایر ابزارهای مشابه چت‌جی‌پی‌تی کار روزمره‌شان را سریع‌تر کنند، مجموعه آموزش‌های عملی چت‌جی‌پی‌تی در سایت ما منبع خوبی است.
در نهایت، این روند نشان می‌دهد که رقابت میان گیت‌هاب، اوپن‌ای‌آی و Anthropic بر سر کنترل دسکتاپ تازه شروع شده و در ماه‌های آینده قطعاً شاهد نسخه‌های پخته‌تر و رقیب‌های بیشتری در این حوزه خواهیم بود. برای دنبال کردن همه این اخبار به محض انتشار، می‌توانید سری به بخش اخبار هوش مصنوعی سایت بزنید.
پرسش‌های پرتکرار
آیا قابلیت Computer Use کوپایلوت رایگان است؟
این قابلیت در حال حاضر به‌عنوان پیش‌نمایش عمومی در دسترس کاربران کوپایلوت است و هنوز هزینه جداگانه‌ای برای آن اعلام نشده؛ استفاده از آن در چارچوب پلن فعلی کوپایلوت هر کاربر انجام می‌شود.
آیا این قابلیت روی لینوکس هم کار می‌کند؟
در این مرحله از پیش‌نمایش، کوپایلوت Computer Use فقط برای نشست‌های محلی روی ویندوز و مک معرفی شده و خبری از پشتیبانی لینوکس در دسترس نیست.
آیا کوپایلوت بدون اجازه می‌تواند کاری روی کامپیوتر من انجام دهد؟
نه؛ این قابلیت به‌طور پیش‌فرض خاموش است و برای هر برنامه باید یا اجازه موقت یا اجازه همیشگی صادر شود؛ قوانین رد دسترسی هم همیشه در اولویت هستند.
آیا این قابلیت جایگزین API و اتوماسیون برنامه‌نویسی‌شده می‌شود؟
نه، و گیت‌هاب هم دقیقاً همین را توصیه کرده است؛ کنترل دسکتاپ باید فقط آخرین گزینه باشد، برای زمانی که هیچ API یا ابزار ساختاریافته دیگری در دسترس نیست.
نسخهٔ فوری این مطلب در تلگرام: اینجا بخوانید
