گروه QwenLM روز ۱۹ سپتامبر نسخهٔ ۰٫۲۴٫۱ ابزار برنامه‌نویسی Qwen Code را منتشر کرد. مهم‌ترین تغییر برای کسانی که چند عامل هوش مصنوعی را در یک روند کاری به خدمت می‌گیرند، ساده‌تر شدن تعیین اختیارات هر مرحله است. اکنون می‌توان هنگام فراخوانی یک زیروعامل، نام ابزارهایی را که اجازه دارد به کار ببرد مشخص کرد. در فهرست تغییرات، کتابخانه‌ای برای کار با مرورگر بر پایهٔ Playwright هم دیده می‌شود؛ بااین‌حال، وجود این کتابخانه به معنی آماده بودن قابلیت مرورگر در برنامهٔ خط فرمان نیست. توضیحات فنی سازندگان به‌روشنی این دو موضوع را از هم جدا می‌کند.

فرض کنید یک روند خودکار ابتدا پرونده‌های پروژه را می‌خواند، سپس چند فرمان محدود اجرا می‌کند و در پایان گزارشی می‌نویسد. اگر همهٔ مراحل به تمام ابزارهای موجود دسترسی داشته باشند، اشتباه در دستور یا تنظیمات می‌تواند دامنهٔ اثر بیشتری پیدا کند. از سوی دیگر، اگر توسعه‌دهنده صرفاً با دیدن نام «مرورگر» در فهرست تغییرات تصور کند قابلیت کامل آن نصب شده، برنامه‌ای طراحی خواهد کرد که شاید در محیط واقعی اجرا نشود. برای ارزیابی نسخهٔ تازه، هم باید محدودهٔ اختیارات زیروعامل را سنجید و هم وضعیت واقعی قابلیت مرورگر را بررسی کرد.

هر زیروعامل فقط ابزارهای مورد نیاز خود را بگیرد

در تغییر تأیید و ادغام‌شدهٔ پروژه، گزینهٔ tools به فراخوانی agent() اضافه شده است. برای نمونه، یک مرحله می‌تواند فقط read_file و run_shell_command را درخواست کند. این درخواست با فهرست ابزارهایی که نوع عامل از پیش مجاز به استفاده از آن‌هاست تطبیق داده می‌شود و محدودیت‌ها و ممنوعیت‌های موجود نیز اعمال می‌شوند. در نتیجه، نوشتن نام یک ابزار جدید به‌خودی‌خود مجوز تازه‌ای ایجاد نمی‌کند. فهرست نهایی از همان سازوکار اعلام ابزارهای عامل عبور می‌کند که قبلاً در پروژه وجود داشته است.

در روش قدیمی‌تر، توسعه‌دهنده با disallowedTools فهرست بلندبالایی از ابزارهای ممنوع را می‌نوشت. مشکل این بود که با افزوده‌شدن یک ابزار تازه یا سرور MCP، فهرست ممنوعیت به‌راحتی ناقص می‌شد. اکنون می‌توان برای هر مرحله از ابتدا گفت چه چیزهایی لازم است. هنگام بازبینی نیز می‌توان دربارهٔ تک‌تک ابزارهای مجاز پرسید چرا آن مرحله به آن‌ها نیاز دارد. این مزیت از طراحی منتشرشده به دست می‌آید؛ Aipolix عملکرد امنیتی قابلیت را در یک آزمون مستقل اندازه‌گیری نکرده است.

جزئیات پیاده‌سازی اهمیت دارد. فهرست باید نام دقیق ابزارها را داشته باشد؛ علامت جایگزین عمومی، نام کلی یک سرور MCP یا نام ویژهٔ exec پذیرفته نمی‌شود. در حالتی که عامل ابزارها را از مسیر اجرای کد فراخوانی می‌کند، exec همچنان باقی می‌ماند، اما ابزارهای قابل‌فراخوانی از آن مسیر محدود می‌شوند. نام نادرست ممکن است پیش از راه‌اندازی زیروعامل باعث رد درخواست شود. یک محدودیت دیگر نیز در توضیحات سازندگان آمده است: حتی اگر نامی معتبر باشد، ممکن است ابزار مورد نظر در نشست نهایی قابل‌دسترسی نباشد و عامل ابزار کمتری از انتظار دریافت کند. پس بررسی تنظیمات کافی نیست؛ فهرست واقعی ابزارهای اعلام‌شده را هم باید دید.

چرا اضافه‌شدن کتابخانهٔ مرورگر به معنی آماده بودن آن نیست؟

بخش تازهٔ مرورگر یک رابط برنامه‌نویسی با نوع‌های مشخص است که روی Playwright ساخته شده و در محیط Node REPL ماندگار کار می‌کند. در طراحی آن، انتخاب عنصرهای صفحه از راه مشخصات معنایی، ارجاع به اجزای سند و مختصات تصویری به یک موتور مشترک متصل‌اند. مدیریت زبانه‌ها، جابه‌جایی میان صفحه‌ها، ورود اطلاعات، تصویر گرفتن و هماهنگی بارگیری فایل‌ها از امکانات این زیرساخت‌اند. اما وجود چنین کدی در مخزن ثابت نمی‌کند که استفاده‌کنندهٔ معمولی برنامهٔ خط فرمان به همهٔ این امکانات دسترسی دارد.

سازندگان مسیر تکمیل را به سه بخش تقسیم کرده‌اند: نخست خود کتابخانه و قراردادهای ارتباطی، سپس اتصال به مرورگر Chrome با برنامهٔ واسط و افزونه، و سرانجام افزودن همهٔ این اجزا به محصول اصلی. در توضیح درخواست ادغام مرحلهٔ اول صریحاً آمده است که این مرحله نه کار با مرورگر را در خط فرمان فعال می‌کند و نه مجوزهای افزونهٔ مرورگر را تغییر می‌دهد. محدودیت یک نشست برای هر کاربر سیستم‌عامل، نبود پشتیبانی ویندوز در همان مرحله و تکرار نشدن بعضی آزمون‌های لینوکس نیز در سند ذکر شده‌اند. این‌ها محدودهٔ آزمون گزارش‌شده از سوی سازندگان است، نه نتیجهٔ آزمایش مستقل ما.

پیش از به‌روزرسانی چه چیزهایی را آزمایش کنیم؟

پیشنهاد تحلیلی Aipolix این است که دو آزمون جدا انجام شود. برای کنترل اختیارات، یک روند کوتاه بسازید، برای زیروعامل فهرست محدودی بنویسید و ثبت کنید در عمل کدام ابزارها در اختیارش قرار می‌گیرند. سپس فراخوانی ابزار خارج از فهرست را امتحان کنید و در صورت استفاده از حالت اجرای کد، همان آزمایش را در آن حالت نیز تکرار کنید. اگر وابستگی به ابزارهای MCP وجود دارد، نام دقیق و در دسترس بودن آن‌ها را بررسی کنید. برای مرورگر، به‌جای اعتماد به نام کتابخانه در فهرست تغییرات، وجود اتصال Chrome و مرحلهٔ یکپارچه‌سازی را در همان نسخه و محیط نصب‌شده کنترل کنید.

تغییر دیگری نیز در این انتشار وجود دارد: رویداد مربوط به هدف فعال دیگر در جریان خروجی تولید نمی‌شود. برنامه‌هایی که مشخصاً به آن رویداد وابسته‌اند باید پیش از ارتقا سازگاری خود را بررسی کنند. این نکته به معنی حذف تمام رویدادهای خروجی نیست.

حاصل نسخهٔ تازه یک امکان واقعی برای کاهش دسترسی زیروعامل‌ها و زیرساختی برای قابلیت مرورگر در آینده است. فهرست ابزارهای مجاز جایگزین همهٔ لایه‌های حفاظت از سامانه نمی‌شود؛ اضافه‌شدن کتابخانه نیز به‌تنهایی عرضهٔ قابلیت نهایی نیست. معیار درست برای یک تیم مهندسی، مشاهده و آزمودن امکانات در نسخه و محیط اجرایی است که واقعاً در اختیار دارد.

منابع
- توضیحات رسمی نسخهٔ ۰٫۲۴٫۱
- پیاده‌سازی فهرست ابزارهای مجاز
- جزئیات و مراحل ساخت قابلیت مرورگر
- تغییر رویداد هدف فعال