تغییر بزرگ در ابزار Kimi Code؛ ایجنت‌های موازی دیگر بدون اجازه اجرا نمی‌شوند

استارتاپ Moonshot رفتار پیش‌فرض مدیریت و هدایت ایجنت‌ها را در ابزار Kimi Code روی مدل K3.1 Pro تغییر داده است. نسخه‌های جدید Kimi Code CLI 2.3.2 و نسخه دسکتاپ 1.1.3 از این پس تمام وظایف را تنها با یک ایجنت واحد پردازش می‌کنند، مگر اینکه کاربر صراحتاً واگذاری وظایف به ایجنت‌های فرعی را درخواست کند یا حالت چندایجنت را فعال سازد.

واگذاری وظایف به ایجنت‌ها نیازمند فعال‌سازی دستی شد

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

• دستور مستقیم در پرامپت: از ایجنت صراحتاً خواسته شود که وظایف را به بخش‌های مجزا تقسیم کرده و واگذار کند.
• تنظیم قانون در فایل AGENTS.md: قوانین و نحوه واگذاری وظایف در مستندات راهنمای مخزن کد تعریف شده باشد.
• استفاده از یک مهارت (Skill): مهارتی فراخوانی شود که برای استفاده از ایجنت‌های فرعی پیکربندی شده است.
• فعال‌سازی حالت چندایجنت: کاربر حالت جمعی یا Swarm را مستقیماً روشن کند.

ایجنت فرعی (Subagent) در واقع یک پردازشگر مجزا است که بخشی از یک تسک کلی به آن سپرده می‌شود. حالت جمعی یا Swarm نیز چندین کارگزار از این دست را به‌شکل موازی هدایت می‌کند و در نهایت، خروجی‌های آن‌ها را از طریق یک هماهنگ‌کننده مرکزی ترکیب می‌نماید.

غیرفعال شدن حالت جمعی در اجراهای بدون واسط کاربری

نسخه دسکتاپ 1.1.3 نیز از همین رویکرد پیش‌فرض تک‌ایجنتی پیروی می‌کند و اجرای گروهی را تنها پس از تأیید و فعال‌سازی کاربر آغاز خواهد کرد؛ بدین ترتیب، ایجنت دیگر نمی‌تواند قابلیت AgentSwarm را به‌شکل خودسرانه اجرا کند.

این محدودیت باعث می‌شود حالت پردازش جمعی در اجراهای بدون واسط گرافیکی از طریق دستور kimi -p و همچنین کلاینت‌های پروتکل تعامل ایجنت (مانند ویرایشگر Zed) در دسترس نباشد؛ زیرا این محیط‌ها ابزار تعاملی برای روشن کردن حالت چندایجنت ندارند و امکان راه‌اندازی خودکار آن نیز حذف شده است.

دلایل عقب‌نشینی Moonshot از ساخت خودکار ایجنت‌ها

شرکت Moonshot همواره هدایت موازی ایجنت‌ها را به‌عنوان یکی از قابلیت‌های کلیدی Kimi Code مطرح می‌کرد. مدل K3.1 Pro، نخستین عضو از خانواده K3.1، با پنجره زمینه ۱ میلیون توکنی خود برای پردازش پایگاه‌های عظیم کد و اسناد حجیم طراحی شده است. پیش از این، نسخه‌های K2.6 و K2.7 ابزار Kimi Code حتی تا ۳۰۰ ایجنت فرعی هم‌زمان را پشتیبانی می‌کردند و سیستم هماهنگ‌کننده آن‌ها طوری آموزش دیده بود که کارها را به‌صورت خودکار بین ایجنت‌ها تقسیم کند.

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

اقدامات لازم برای توسعه‌دهندگان

• پرامپت‌های پیشین: اگر به اجرای موازی نیاز دارید، باید درخواست واگذاری را صراحتاً درون پرامپت قید کنید.
• پیکربندی مخزن: قواعد تکرارشونده برای تقسیم وظایف را درون فایل AGENTS.md ثبت نمایید.
• دستورات خط فرمان: برای تسک‌هایی که به هماهنگی ایجنت‌های موازی نیاز دارند، دستور /swarm <task> را به کار ببرید.
• محیط دسکتاپ: پیش از شروع کار، حالت Swarm را در تنظیمات فعال کنید.
• اتصال‌های خودکار: در نظر داشته باشید که اجراهای kimi -p و کلاینت‌های پروتکل ACP تحت سازوکار جدید به‌صورت تک‌ایجنتی باقی می‌مانند.

رابط خط فرمان همچنان دارای ایجنت‌های فرعی داخلی شامل coder، explore و plan است. فهرست دسترسی پیش‌فرض مشخص می‌کند کدام ایجنت‌ها حق دارند کارگزاران جدید ایجاد کنند؛ سازوکاری که مانع تکثیر تودرتو و بی‌رویه ایجنت‌ها می‌شود، مگر آنکه کاربر اجازه آن را صادر کند.

کاربردهای کلیدی حالت جمعی در پروژه‌ها

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

از این پس، تسک‌های معمول کدنویسی درون همان یک ایجنت انجام می‌شوند که نتیجه آن مصرف کاملاً قابل پیش‌بینی توکن‌ها و شفافیت بیشتر در فرایند اجرا است. این تغییر راهبردی در Moonshot، سیاست مدیریت ایجنت‌ها را در اختیار برنامه‌نویسان قرار می‌دهد، بدون آنکه قدرت ابزار در پردازش پروژه‌های سنگین چندایجنت مخدوش شود.