حذف قوانین متنی ساده بر خلاصه‌سازی مدل‌های زبانی در عامل‌های کدنویس برتری دارد

بهینه‌سازی حلقه‌ی اجرای یک هوش مصنوعی — یا همان هارنس (Harness) — اکنون به اندازه خودِ مدل برای عملکرد مهندسی نرم‌افزار حیاتی است. طبق گزارشی که در ۱۸ سپتامبر ۲۰۲۶ در arxiv.org منتشر شد، موفقیت یا شکست یک عامل (Agent) در وظایف طولانی‌مدت، مستقیماً به نحوه‌ی مدیریت فضای اقدام و زمینه (Context) بستگی دارد. این چالش‌ها با یافته‌های اخیر همسو است که نشان می‌دهد نقص در مدیریت اجرا یکی از دلایل اصلی شکست عامل‌های کدنویس در محیط‌های رقابتی است.

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

پژوهشگران ۱۷۶ تنظیمات مختلف را روی چهار مدل با استفاده از محک‌های SWE-Bench Verified و Terminal-Bench 2.1 ارزیابی کردند. بر اساس مستندات این تحقیق، چندین موازنه فنی کلیدی شناسایی شده است:

• مدیریت زمینه: استفاده از حذف قوانین‌محور (Rule-based elision) پیش از خلاصه‌سازی توسط مدل زبانی بزرگ (LLM)، بیشترین بهره‌وری را داشت. طبق یافته‌ها، اکثر این مزایا ناشی از جلوگیری از شکست‌های مربوط به سرریز زمینه بود، نه لزوماً بهبود استدلال.
• برنامه‌ریزی: برای مدل‌های ضعیف‌تر، برنامه‌ریزی مانند یک داربست برای افزایش صحت عمل می‌کند؛ اما برای مدل‌های قدرتمند، این مرحله صرفاً هزینه‌ها را کاهش می‌دهد و تأثیر ناچیزی بر دقت نهایی دارد.
• فضای اقدام: مدل‌هایی که مهارت بالایی در bash دارند، در محیط‌های مبتنی بر bash-only بسیار مؤثرتر عمل می‌کنند و هزینه‌های آن‌ها به‌طور قابل‌توجهی کمتر از مدل‌هایی است که از ابزارهای پیش‌فرض استفاده می‌کنند. این رویکرد یادآور استراتژی DeepSeek در تبدیل قابلیت‌های LLM به پلاگین‌های کاربردی برای ساخت عامل‌های خودمختار است.

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

توسعه‌دهندگان باید اکنون هارنس‌های خود را نه به عنوان سیستم‌های ثابت، بلکه به عنوان اجزای ماژولاری ببینند که باید متناسب با سطح مهارت مدل زبانی زیربنایی تنظیم شوند.

گام بعدی شما

• بررسی کنید آیا عامل‌های شما برای کارهای ساده از ابزارهای پیچیده استفاده می‌کنند یا می‌توانند با دستورات مستقیم bash هزینه را کاهش دهند.
• استراتژی مدیریت زمینه را از خلاصه‌سازی‌های گران‌قیمت LLM به سمت قوانین حذف متنی (Elision) ساده ببرید.
• سطح برنامه‌ریزی عامل را بر اساس قدرت مدل (ضعیف در برابر قدرتمند) بازنگری کنید.

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