مقاله‌ی arXiv:2610.07832 · در صف خبرنامه
Harness Engineering for Software Engineering via Modular Executable Dev-Primitives
هرمس: مهندسی هارنس برای مهندسی نرم‌افزار با اجزای توسعه‌ی ماژولار و اجرایی
- تاریخ
- (۱۴ مهر ۱۴۰۵) 2026-10-06 تأییدشده از روی تاریخ ارسال نسخه‌ی اول در آرکایو
- نویسنده‌ها
- Haibo Jin, Xinjie Li, Peng Kuang, Haohan Wang
- نهاد نویسنده‌ها
- University of Illinois Urbana-Champaign; The Pennsylvania State University
- برچسب لابراتوار
- موضوع‌ها
خلاصه‌ی فارسی
مسئله
ایجنت‌های با دسترسی ترمینال در خودکارسازی مهندسی نرم‌افزار توانمندند، اما در گردش‌کارهای طولانی شکننده‌اند: باید وضعیت برنامه را که در فایل‌های منبع، پیکربندی، تست، وابستگی و رفتار زمان اجرا پخش است بارها بازسازی کنند، که به تاریخچه‌های طولانی، انفجار کانتکست و رانش معنایی می‌انجامد. مخزن‌های بزرگ پیدا کردن اجزای مرتبط را هم سخت‌تر می‌کنند.
روش
«اجزای توسعه» هر بخش مخزن را با یک مدل زبانی مقیم جفت می‌کنند تا آن بخش یک رابط بومی ایجنت مبتنی بر پیاده‌سازی و وابستگی‌های خودش داشته باشد و بتواند به زبان طبیعی استدلال کند، با اجزای دیگر ارتباط بگیرد و خودش را محلی اصلاح کند. چارچوب HERMES این اجزا را در مقیاس مخزن با یک سازوکار فعال‌سازی پویای آگاه از وابستگی و یک سازوکار تشخیص باگ که شواهد اجرا را به اجزای نیازمند بازنگری نگاشت می‌کند به کار می‌گیرد.
یافته‌ها
- در چهار بنچمارک مهندسی نرم‌افزار، به‌طور میانگین ۱۲٫۴ درصد از هارنس‌های پایه‌ی هم‌تراز بهتر بود.
- با مدل‌های قوی فعال‌سازی و تشخیص، حتی با اجزای Qwen3-8B در همه‌ی چهار بنچمارک در فاصله‌ی ۴٫۵ درصد از پیکربندی یکدست GPT-5.6 Sol ماند و هزینه‌ی استنتاج را روی Terminal-Bench ۴٫۰ به اندازه‌ی ۲۶٫۲ درصد کم کرد.
محدودیت‌ها
نویسنده‌ها می‌گویند روش به دلیل فراخوانی چند جزء، اجرای مخزن و تشخیص تکراری هزینه و تأخیر اضافه دارد، سودش در تنظیم‌های اشباع‌شده مثل SWE-bench Verified با قوی‌ترین مدل‌ها کمتر است و به فعال‌سازی درست اجزا و شواهد اجرای آموزنده وابسته است.
چرا مهم است
به جای این‌که یک ایجنت کل مخزن را در ذهن نگه دارد، هر بخش کد می‌تواند نماینده‌ی هوشمند خودش را داشته باشد. این کار نشان می‌دهد چنین تقسیم کاری حتی مدل‌های کوچک را به سطح مدل‌های پیشرو نزدیک می‌کند.