محصول
۳۲ مقاله که به این محصول مربوط است. جستجو و فیلتر در همین فهرست
مقاله‌ی Enforcing Code Reasoning in Agentic Scaffold for More Effective Issue Resolution (16 Oct 2026، چانگ‌شو لیو، ریحانه جباروند و همکاران، آزمایشگاه Intelligent-CAT-Lab) مسئله: ایجنت‌های کدنویسی وقتی یک باگ واقعی را در ریپو حل می‌کنند، گاهی درباره‌ی خود کد
راهنمایی‌هایی که به بنچمارک‌های کدنویسی اضافه می‌شوند، گاهی جواب را لو می‌دهند
بنچمارک‌ها مسیر پیشرفت هوش مصنوعی را تعیین می‌کنند، اما تعریف تسک در آن‌ها دو جور خراب می‌شود. اگر تسک ناقص تعریف شده باشد، راه‌حل باید حدس بزند (مثلاً اسم تابعی را که تست‌ها انتظار دارند نمی‌داند) یا حتی به تقلب و دور زدن پاداش رو بیاورد. اگر بیش از حد تعریف
مقاله‌ی TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents (15 Oct 2026، آرون لی و همکاران، از جمله یون استویکا، بین یو و جیان‌فنگ گائو) مسئله: ایجنت‌های کدنویسی مثل کلاد کد، کدکس و کوپایلت CLI گران شده‌اند و بخش بزرگی از این هزینه تکر
یاد دادن به ایجنت کدنویسی که از اطلاعاتی که همین الان در کانتکستش هست استفاده کند
کدنویسی قابل اعتماد در سطح ریپو یعنی ایجنت نه فقط کد درست بنویسد، بلکه محدودیت‌ها را در طول تعامل طولانی رعایت کند و به بازخورد ابزارها واکنش نشان دهد. تحلیل نویسنده‌ها نشان داد ایجنت‌ها اغلب به اطلاعاتی که همین حالا در کانتکست دارند عمل نمی‌کنند؛ مثلاً پیام خ
تقطیر کانتکست فقط روی بخش‌هایی از پاسخ شاگرد که واقعاً باید اصلاح شوند
مدل‌های زبانی برای بهتر شدن در طول استفاده باید از تجربه‌ی تعامل یاد بگیرند. «تقطیر کانتکست» راه امیدوارکننده‌ای است: اطلاعات ممتازی که از تجربه به دست آمده (مثلاً «این ابزار با این آرگومان خطا می‌دهد») به یک معلم داده می‌شود و رفتار معلم به شاگردی منتقل می‌شو
پاداش تست واحد به مدل یاد می‌دهد زیادی ویرایش کند و باگ خیالی بسازد؛ راه‌حل، پاداش برای ویرایش دقیق
یادگیری تقویتی با تست واحد دستور رایج پس‌آموزش مدل‌های کد است، اما تست واحد فقط می‌پرسد برنامه‌ی نهایی پاس می‌شود یا نه. نویسنده‌ها دیدند این پاداش در اشکال‌زدایی نرخ پاس را بالا می‌برد، ولی هم‌زمان به مدل یاد می‌دهد بیشتر از لازم ویرایش کند و در کدی که درست ا
آموزش بازیابی از خطا برای ایجنت‌های ترمینال، با انشعاب از وضعیت‌های شکست خود ایجنت
ایجنت‌های ترمینال در کارهای کدنویسی پیچیده توانا هستند، اما اغلب در اجرای طولانی نمی‌توانند از خطا بازیابی شوند، مثلاً از یک دستور غلط یا پیاده‌سازی معیوب، و در نهایت تسک شکست می‌خورد. ایجنت ReTerm با یادگرفتن بازیابی از تسک‌های ناموفق خودش بهتر می‌شود. یک خط
سنجش تست‌های تولیدشده فراتر از بازتولید باگ: آیا تست، پچ درست را می‌پذیرد و پچ غلط را رد می‌کند؟
ایجنت‌های کدنویسی با تست‌های تولیدشده تصمیم می‌گیرند آیا یک پچ نیازهای مسئله را برآورده می‌کند. تستی که روی برنامه‌ی باگ‌دار شکست می‌خورد و بعد از پچ مرجع پاس می‌شود، هنوز ممکن است پچ غلطی را بپذیرد یا پچ درستی را رد کند؛ مثلاً تستی که فقط بررسی می‌کند خطا پرت
از مشاورت بپرس: یادگیری این‌که ایجنت ارزان کِی از مدل قوی‌تر کمک بگیرد
برای تعادل کارایی و هزینه، گردش کار ایجنتی می‌تواند از یک مدل ارزان برای اجرا استفاده کند و فقط گاهی با یک مدل قوی‌تر مشورت کند. در این سیستم‌های اجراکننده و مشاور، اجراکننده خودش تصمیم می‌گیرد کِی کمک بخواهد، پس این تصمیم به خودارزیابی وابسته است، در حالی که
همه‌ی پچ‌های درست یکسان اجرا نمی‌شوند: کارایی زمان اجرای پچ‌های ایجنت‌ها در رفع مسئله‌های ریپو
بنچمارک‌هایی مثل SWE-bench پچ‌ها را فقط با پاس شدن تست‌های درستی ارزیابی می‌کنند و کارایی زمان اجرای پچ‌های درست تقریباً بررسی نشده است؛ دو پچ ممکن است هر دو تست را پاس کنند ولی یکی ده برابر کندتر باشد. طراحی بار کاری کارایی برای هر نمونه گران است. نویسنده‌ها
کیفیت، نه فقط نتیجه: امتیازدهی ساختاری به مسیرهای ایجنت کدنویسی برای انتخاب داده‌ی آموزشی
ایجنت‌های کدنویسی باز معمولاً با آموزش نظارت‌شده روی مسیرهایی آموزش می‌بینند که پچ نهایی‌شان تست‌ها را پاس کرده است. این فیلتر کیفیت فرایند را نادیده می‌گیرد: مسیری که در نهایت موفق شده ممکن است الگوهای ناکارآمد داشته باشد، مثل بررسی تکراری فایل‌ها، استفاده‌ی
آیا ایجنت‌ها می‌توانند باگ را در نرم‌افزار تعاملی خودشان پیدا کنند؟ بنچمارکی بدون گزارش باگ
ایجنت‌های کدنویسی بیشتر به جای پاسخ متنی، نرم‌افزار تعاملی می‌سازند، ولی بسیاری از باگ‌های چنین نرم‌افزاری فقط بعد از تعامل چندمرحله‌ای ظاهر می‌شوند. امروز کاربر باید باگ را پیدا کند و منتظر رفع آن بماند. بنچمارک‌های موجود معمولاً فرض می‌کنند باگ از قبل شناخته
خودپاداش‌دهی رفتاری برای ایجنت‌های مهندسی نرم‌افزار: فراتر از پاداش دودویی قبول یا رد تست
یادگیری تقویتی با پاداش قابل تأیید با تست‌های اجرایی نظارت قابل اعتمادی به ایجنت‌های مهندسی نرم‌افزار می‌دهد، اما پاداش دودویی بین مسیرهایی که کیفیت اشکال‌زدایی‌شان خیلی متفاوت است فرقی نمی‌گذارد. مثلاً دو مسیری که هر دو تست را رد می‌کنند، یکی ممکن است تا نزدی
کیدنس: راهنمایی راهبردی برای ایجنت‌های کدنویسی با پایشی که بسامد بازرسی را با سلامت اجرا تنظیم می‌کند
پایشگرهای زمان اجرا با بررسی مسیر ایجنت کدنویسی و دادن راهنمایی اصلاحی هنگام رفتار نادرست، قابلیت اطمینان را بالا می‌برند. اما یا در فاصله‌های ثابت بازرسی می‌کنند، که هنگام خطای جدی دیر می‌رسند و در اجرای سالم سربار بی‌فایده دارند، یا به قاعده‌های اکتشافی سخت
ایجنت‌اوولور: خودتکاملی سراسری سیستم از طریق اجرای تسک، با مدل پایه‌ی ثابت
یک ایجنت می‌تواند تسکی را کامل کند بدون این‌که روش کارش بهتر شود. تبدیل تجربه‌ی تسک به توانایی قابل استفاده‌ی مجدد نیاز دارد جزء تغییرکرده به ارزیابی و استفاده‌ی بعدی‌اش وصل شود. سیستم AgentEvolver برای توسعه‌ی توانایی حین اجرای تسک ساخته شده و مدل پایه را ثاب
کرونوس: استدلال ایجنت‌های کد روی تاریخچه‌ی تکامل نرم‌افزار با گراف درخواست‌های ادغام گذشته
درخواست‌های ادغام تاریخی تصمیم‌های طراحی، قیدهای سازگاری و الگوهای پیاده‌سازی پشت وضعیت فعلی کد را ثبت می‌کنند. تجربه‌ی مرتبط با یک تسک تازه ممکن است در چند تغییر مرتبط پخش باشد که توضیحاتشان روی نگرانی‌های متفاوتی تأکید دارند، پس جست‌وجوی معنایی ساده آن‌ها را
فهم کد گلوگاه ایجنت‌های کدنویسی است، نه فقط ویرایش آن
بنچمارک‌های مخزن‌محور مثل SWE-bench اغلب فرض می‌کنند تعداد خطوط ویرایش‌شده سختی تسک را پیش‌بینی می‌کند، اما کنترل ضعیف این داده‌ها روی نوع کد و تسک باعث می‌شود نتوان فهمید کدام توانایی واقعاً خطاهای ایجنت را تعیین می‌کند. مثلاً یک اصلاح یک‌خطی ممکن است نیاز به
پیش از آن‌که بتوانند حل کنند: پیش‌بینی کارایی ایجنت کدنویسی پس از آموزش، از روی مدل پایه
کدام نسخه‌ی پایه ارزش یک دور گران پس‌آموزش ایجنتی را دارد؟ معیار سرتاسری pass@K می‌سنجد آیا رفتار موفق در توزیع مدل پایه هست، اما برای کدنویسی ایجنتی مناسب نیست، چون بسیاری از مدل‌های پایه حتی نمی‌توانند فراخوانی ابزار درست‌قالب تولید کنند. تسک‌های تک‌مرحله‌ای
کوتریس: دستورالعمل داده برای آموزش ایجنت‌های ترمینال با هم‌تکاملی هارنس و مدل
توانایی ایجنت ترمینال هم به وزن‌های مدل بستگی دارد و هم به هارنسی که پرامپت را قالب‌بندی، ابزارها را متصل و خطاها را بازیابی می‌کند. روش‌های هم‌تکاملی هر دو را بهتر می‌کنند، اما مسیرهای تولیدشده در جست‌وجوی هارنس را اغلب یک بافر بازپخش یکپارچه می‌بینند و نادید
وقتی زیرایجنت‌ها موازی کار می‌کنند: نویدها و دام‌های هم‌روندی پویا در تسک‌های کدنویسی بلندمدت
با پیشرفت ایجنت‌های کدنویسی از تسک‌های محدود به توسعه‌ی بلندمدت، هم‌روندی پویا راهی برای بزرگ کردن کارهای پیچیده است: ایجنت حین اجرا تصمیم می‌گیرد آیا و چطور زیرایجنت‌های هم‌زمان بسازد. در تسک‌های کوتاه توان مدل نتیجه را تعیین می‌کند، اما در توسعه‌ی طولانی هما
بنچمارک‌های ایجنت کدنویسی باید با جریان تسک کاربرانشان منطبق باشند
ارزیابی ایجنت‌های کدنویسی می‌کوشد تا حد ممکن واقع‌گرا باشد، اما بنچمارک‌های برگرفته از گزارش‌های مشکل فقط یک نوع درخواست را می‌سنجند. در واقعیت کاربران در یک جلسه سؤال می‌پرسند، برنامه‌ریزی می‌کنند، بازبینی و بازسازی می‌خواهند و مدام بین این نوع‌ها جابه‌جا می
اسپک‌گارد: اثبات خراب بودن یک تسک پیش از آن‌که ایجنت تقلب کند
با استقرار گسترده‌ی ایجنت‌های کدنویسی مستقل، خطر این‌که ناسازگاری‌های تصادفی یا عمداً تزریق‌شده در تسک‌ها به رفتار خطرناک ایجنت منجر شود جدی است. کارهای قبلی نشان داده‌اند ایجنت‌ها در چنین تسک‌هایی به‌ندرت تعارض را گزارش می‌کنند و به جایش تقلب می‌کنند، مثلاً ت
یادگیری تقویتی مشروط به شکست برای ایجنت‌های مهندسی نرم‌افزار بلندمدت
مهندسی نرم‌افزار در سطح مخزن یک تنظیم بلندمدت چالش‌برانگیز است. کارهای اخیر ایجنت‌ها را با روش‌هایی مثل GRPO آموزش می‌دهند که چند مسیر مستقل برای هر مسئله نمونه‌گیری و پاداش پایانی را در یک گروه ثابت مقایسه می‌کنند. اما این روش بازخورد تأییدکننده از وصله‌های ش
هارنس چه می‌خرد؟ بیشتر توکن: سنجش اثر هارنس با مدل ثابت در SWE-bench
ایجنت کدنویسی یک مدل زبانی است که در هارنس پیچیده شده: پرامپت سیستمی، مجموعه‌ی ابزار و مدیریت کانتکست. هارنس‌های تولیدی هر روز نسخه می‌دهند، فروشنده‌ها از بهبود نرخ پاس با تغییر هارنس می‌گویند و جدول‌های رتبه‌بندی هارنس‌ها را آزادانه قاطی می‌کنند. اما به ندرت
اتوکامپکت: آموزش ایجنت کدنویسی برای تصمیم درباره‌ی زمان فشرده‌سازی کانتکست
ایجنت‌های کدنویسی تسک‌های مهندسی نرم‌افزار در سطح مخزن را با مسیرهای طولانی بررسی کد، جست‌وجو، ویرایش و تست حل می‌کنند. با پیشرفت تسک، کاوش‌های قبلی کهنه می‌شوند، پس مدیریت کانتکست فقط جلوگیری از سرریز نیست: ایجنت باید تصمیم بگیرد کِی فشرده کند، کدام وضعیت کار
اوپن‌کولب: چارچوب کدنویسی چندایجنتی با همکاری برنامه‌پذیر و زمان اجرای کنترل‌پذیر
سیستم‌های کدنویسی چندایجنتی برای حل تسک‌های پیچیده‌ی مهندسی نرم‌افزار با همکاری طراحی شده‌اند، اما ارزیابی‌های موجود فرض می‌کنند سازمان پیکربندی‌شده وفادارانه اجرا می‌شود، در حالی که واقعیت فرق دارد؛ مثلاً ایجنت بازبین ممکن است اصلاً کد را بازبینی نکند. این شک
اپرا: چارچوب منتقد کلامی برای ایجنت‌های کدنویسی بلندمدت که اصلاح‌ها را تا حل مشکل دنبال می‌کند
ایجنت‌های کدنویسی بلندمدت به اصلاح به‌موقع نیاز دارند، اما بازخورد وقتی کار جاری را اشتباه ارزیابی کند یا به مشکل اصلی نپردازد، بی‌اثر یا حتی مضر است. منتقدهای موجود روی ارزیابی مسیر و تولید بازخورد تمرکز دارند اما به ندرت دنبال می‌کنند پس از رساندن بازخورد چه
مطالعه‌ی تجربی طراحی هارنس برای ایجنت‌های کدنویسی: کدام جزء واقعاً مهم است؟
هارنس‌های کدنویسی شکل می‌دهند ایجنت‌ها چطور توانایی مدل را به کارایی بلندمدت مهندسی نرم‌افزار تبدیل کنند، اما کارهای موجود معمولاً هارنس‌ها را سیستم‌های یکپارچه ارزیابی می‌کنند و اثربخشی تک‌تک اجزا نامعلوم می‌ماند. نویسنده‌ها یک هارنس کدنویسی سبک با حلقه‌ی اجر
نسخه‌ی تأییدشده‌ی SWE-Bench Pro: بنچمارک قابل اعتماد برای ایجنت‌های مهندسی نرم‌افزار
بنچمارک SWE-Bench Pro استاندارد ارزیابی ایجنت‌های مهندسی نرم‌افزار روی تسک‌های دشوار سطح مخزن شده است، اما ارزیابی‌اش دو منبع عدم اطمینان دارد: تقلب در پاداش از طریق نشت راه‌حل طلایی یا اطلاعات پنهان ارزیابی، مثلاً خواندن پاسخ از تاریخچه‌ی گیت؛ و مشکلات کیفیت
یادگیری تقویتی چندهارنسی برای ایجنت‌های کدنویسی: سود آموزش در برابر وابستگی به هارنس
سیستم‌های اخیر ایجنت‌های کدنویسی را با یادگیری تقویتی روی مسیرهای جمع‌آوری‌شده از چند هارنس اجرا آموزش می‌دهند. اما بهبود زیر هارنس‌های آموزشی این پرسش را باز می‌گذارد که آیا به رابط‌های دیده‌نشده منتقل می‌شود و چطور به نرمال‌سازی پاداش وابسته است. نویسنده‌ها
سوئی-مم: یادگیری مدیریت تطبیقی حافظه برای ایجنت‌های کدنویسی بلندمدت
ایجنت‌های مهندسی نرم‌افزار بلندمدت باید تاریخچه‌ی طولانی و پرنویز تعامل را با بودجه‌ی محدود کانتکست مدیریت کنند. روش‌های موجود به گردش‌کارهای فشرده‌سازی ایستا تکیه دارند یا قیدهای سختی بر زمان و دانه‌بندی فشرده‌سازی می‌گذارند، و مدیریت حافظه و حل مشکل را با هم
پکت: هم‌آموزی با ردپای ممتاز برای ایجنت‌های چندنوبتی استفاده از ابزار
ایجنت‌های چندنوبتی ابزار باید در چند نوبت استدلال کنند، ابزار فرا بخوانند و با مشاهده‌ها تطبیق یابند. پس‌آموزش آن‌ها سخت است: یادگیری تقویتی با وجود هم‌خوانی با حالت استنتاج از پاداش پراکنده و تخصیص اعتبار ضعیف رنج می‌برد، و تنظیم دقیق نظارت‌شده روی ردپاهای مت