محصول
۲۱ مقاله که به این محصول مربوط است. جستجو و فیلتر در همین فهرست
آیا ایجنت کدنویسی عمومی هنوز به هارنس مخصوص هر محیط نیاز دارد؟
انتظار می‌رود مدل‌های قوی‌تر روال‌های کار را خودشان بسازند و برتری هارنس‌های دست‌ساز توسعه‌دهنده کم شود. این مقاله می‌پرسد چرا این برتری هنوز باقی است و آیا می‌شود یک ایجنت مستقل از محیط را بدون مهندسی مخصوص هر محیط بهتر کرد. نویسنده یک ایجنت مبتنی بر کدکس را
داور ایجنت ترمینال را فقط وقتی صدا بزن که ایجنت می‌گوید کار تمام شد، و به او یک کپی از سیستم بده
جست‌وجو در زمان اجرا می‌تواند کارایی ایجنت را بالا ببرد: چند عمل جایگزین امتحان می‌شود و یک «داور» شاخه‌های امیدوارکننده را انتخاب می‌کند. اما در محیط‌های ترمینال، ایجنت فقط بخش کوچکی از وضعیت بزرگ سیستم را می‌بیند. نویسنده‌ها دیدند جست‌وجوی درختی مونت‌کارلو ک
خودآگاهی ایجنت: تشخیص این‌که تسک شدنی نیست، درست عمل کردن بر اساسش، و پای حرفش ماندن
ایجنت‌های پیشرو در محیط‌هایی کار می‌کنند که تسکی که حل‌شدنی به نظر می‌رسد، ممکن است پیش‌نیازی نداشته باشد، خواسته‌های متناقض داشته باشد یا مانعش فقط وسط اجرا معلوم شود؛ مثلاً فایلی که باید ویرایش شود اصلاً وجود ندارد. ایجنت باید فرق بگذارد بین «این تسک شدنی نی
ساخت محیط‌های طولانی با پاداش پیشرفت متراکم، از روی یک «جهان پنهان» کاملاً مشخص
ایجنت‌های طولانی‌مدت که ساعت‌ها تا روزها روی کار ارزشمند کار می‌کنند، توجه زیادی گرفته‌اند، ولی مدل‌های متن‌باز در این کارها ضعیف‌اند، عمدتاً به خاطر نبود داده‌ی آموزشی و دستور آموزش کارآمد. تسک‌های طولانی و پیچیده سخت ساخته و تأیید می‌شوند و پاداششان پراکنده
آموزش بازیابی از خطا برای ایجنت‌های ترمینال، با انشعاب از وضعیت‌های شکست خود ایجنت
ایجنت‌های ترمینال در کارهای کدنویسی پیچیده توانا هستند، اما اغلب در اجرای طولانی نمی‌توانند از خطا بازیابی شوند، مثلاً از یک دستور غلط یا پیاده‌سازی معیوب، و در نهایت تسک شکست می‌خورد. ایجنت ReTerm با یادگرفتن بازیابی از تسک‌های ناموفق خودش بهتر می‌شود. یک خط
ایجنت‌ها با تسک‌های مبهم یا ناقص چه می‌کنند؟ بنچمارکی روی ترکیب‌های مختلف مدل و هارنس
تعریف مبهم یا ناقص تسک هم اجرا را برای ایجنت سخت می‌کند و هم پرسیدن سؤال روشن‌کننده را. اما واکنش ایجنت‌ها به این شکاف‌های اطلاعاتی در مدل‌ها و هارنس‌های مختلف به‌خوبی شناخته نشده است؛ مثلاً اگر کاربر نگوید خروجی باید با چه قالبی ذخیره شود، ایجنت می‌پرسد، حدس
مقاوم کردن خودکار بررسی‌کننده‌های محیط‌های ایجنتی در برابر تقلب، با حلقه‌ی هکر و ترمیم‌کار
محیط‌های ایجنتی با بررسی‌کننده‌های برنامه‌ای، نتیجه‌های پیچیده را به پاداش تبدیل می‌کنند. اما می‌شود به این بررسی‌کننده‌ها حمله کرد تا به ایجنتی که تسک را انجام نداده و تقلب کرده نمره‌ی کامل بدهند؛ مثلاً ایجنت به جای درست کردن کد، فایل تست را عوض کند. این هم ا
خودکارسازی چرخه‌ی داده با ایجنت‌های ترمینال: ایجنتی که محیط آموزشی برای خودش می‌سازد
ایجنت‌های ترمینال تسک‌های مهندسی نرم‌افزار و پژوهش علمی را با اجرای دستور در ترمینال حل می‌کنند. آموزششان با یادگیری تقویتی به محیط‌های متنوع و قابل تأیید نیاز دارد، اما این محیط‌ها هنوز بیشتر به دست پژوهشگران انسانی طراحی می‌شوند و عرضه‌شان فقط به سرعت کار آن
از مشاورت بپرس: یادگیری این‌که ایجنت ارزان کِی از مدل قوی‌تر کمک بگیرد
برای تعادل کارایی و هزینه، گردش کار ایجنتی می‌تواند از یک مدل ارزان برای اجرا استفاده کند و فقط گاهی با یک مدل قوی‌تر مشورت کند. در این سیستم‌های اجراکننده و مشاور، اجراکننده خودش تصمیم می‌گیرد کِی کمک بخواهد، پس این تصمیم به خودارزیابی وابسته است، در حالی که
بازگشت به وضعیت‌های توسعه: اسنپ‌شات کامل سندباکس کِی به ایجنت‌های کدنویسی کمک می‌کند
ایجنت‌های کدنویسی اغلب پیش از شکست پیشرفت مفیدی دارند، اما تلاش دوباره از صفر وضعیت ماشینی را که در طول کار ساخته شده دور می‌ریزد. پس بازیابی از شکست یک مسئله‌ی جست‌وجوی جالب است: اگر وضعیت‌های میانی محیط پیشرفت معنادار را حفظ کنند، بازگرداندن و انشعاب از آن‌ه
نگاهی دقیق‌تر به بهینه‌سازی جعبه‌سیاه ایجنتی: بنچمارکی میان‌دامنه‌ای برای ایجنت‌های بهینه‌ساز
بهینه‌سازی جعبه‌سیاه در بسیاری از مسئله‌های علمی و مهندسی پیش می‌آید که هر ارزیابی هدف گران و محدود است، مثل تنظیم پایگاه داده یا طراحی تراشه. ایجنت‌های مدل زبانی با ترکیب معنای تسک، محاسبه، ابزارهای بهینه‌سازی و تصمیم‌گیری مبتنی بر بازخورد راه تازه‌ای پیشنهاد
کوتریس: دستورالعمل داده برای آموزش ایجنت‌های ترمینال با هم‌تکاملی هارنس و مدل
توانایی ایجنت ترمینال هم به وزن‌های مدل بستگی دارد و هم به هارنسی که پرامپت را قالب‌بندی، ابزارها را متصل و خطاها را بازیابی می‌کند. روش‌های هم‌تکاملی هر دو را بهتر می‌کنند، اما مسیرهای تولیدشده در جست‌وجوی هارنس را اغلب یک بافر بازپخش یکپارچه می‌بینند و نادید
هرمس: مهندسی هارنس برای مهندسی نرم‌افزار با اجزای توسعه‌ی ماژولار و اجرایی
ایجنت‌های با دسترسی ترمینال در خودکارسازی مهندسی نرم‌افزار توانمندند، اما در گردش‌کارهای طولانی شکننده‌اند: باید وضعیت برنامه را که در فایل‌های منبع، پیکربندی، تست، وابستگی و رفتار زمان اجرا پخش است بارها بازسازی کنند، که به تاریخچه‌های طولانی، انفجار کانتکست
پیدا کردن جفت مناسب: تعامل مدل و هارنس در تسک‌های ایجنتی
انتخاب یک سیستم ایجنتی یعنی انتخاب هم مدل زبانی و هم هارنسی که مدل از طریق آن عمل می‌کند. سؤال این است که آیا یک مدل، هارنس یا جفت قوی وقتی شرایط عوض می‌شود قوی می‌ماند یا نه. نویسنده‌ها ۶۶ پیکربندی را ارزیابی کردند: چهار هارنس قابل پیکربندی، یعنی OpenHands، D
اکتیوسدلر: یادگیری برنامه‌ی درسی خودکار برای بهینه‌سازی هارنس ایجنت
بهینه‌سازی خودکار هارنس می‌تواند ایجنت‌ها را با به‌روزرسانی مکرر پرامپت‌ها، رابط ابزارها و منطق کنترل از بازخورد اجرا بهتر کند. اما روش‌های موجود عمدتاً نحوه‌ی به‌روزرسانی را بهینه می‌کنند و این را ثابت می‌گذارند که کدام سناریوهای آموزشی بازخورد را تولید می‌کن
اوپن‌کولب: چارچوب کدنویسی چندایجنتی با همکاری برنامه‌پذیر و زمان اجرای کنترل‌پذیر
سیستم‌های کدنویسی چندایجنتی برای حل تسک‌های پیچیده‌ی مهندسی نرم‌افزار با همکاری طراحی شده‌اند، اما ارزیابی‌های موجود فرض می‌کنند سازمان پیکربندی‌شده وفادارانه اجرا می‌شود، در حالی که واقعیت فرق دارد؛ مثلاً ایجنت بازبین ممکن است اصلاً کد را بازبینی نکند. این شک
اپرا: چارچوب منتقد کلامی برای ایجنت‌های کدنویسی بلندمدت که اصلاح‌ها را تا حل مشکل دنبال می‌کند
ایجنت‌های کدنویسی بلندمدت به اصلاح به‌موقع نیاز دارند، اما بازخورد وقتی کار جاری را اشتباه ارزیابی کند یا به مشکل اصلی نپردازد، بی‌اثر یا حتی مضر است. منتقدهای موجود روی ارزیابی مسیر و تولید بازخورد تمرکز دارند اما به ندرت دنبال می‌کنند پس از رساندن بازخورد چه
کلیف‌کامپکشن: فشرده‌سازی کم‌هزینه برای ایجنت‌های کدنویسی بلندمدت
ایجنت‌ها اغلب روی مسائل پیچیده‌ای کار می‌کنند که میلیون‌ها توکن کانتکست لازم دارند و به دلیل پنجره‌ی کانتکست محدود باید بین جلسه‌ها فشرده‌سازی کنند. فشرده‌سازی‌هایی که محتوا را بازنویسی می‌کنند ممکن است با هر دور اطلاعات را تحریف کنند و رانش کانتکست انباشته شو
فایر: مهندسی زمان اجرا بر پایه‌ی شکست برای ایجنت‌های قابل اعتماد
ایجنت‌ها اغلب به یک راه‌حل کارا می‌رسند اما نمی‌توانند آن را پیوسته تحویل دهند؛ یعنی در یک اجرا موفق‌اند و در اجرای بعدی همان تسک شکست می‌خورند. نویسنده‌ها «سیاست‌های زمان اجرا» را بررسی کردند: دستورهای هدفمند زبان طبیعی و منع کنش‌ها که هارنس در وضعیت‌هایی که
مطالعه‌ی تجربی طراحی هارنس برای ایجنت‌های کدنویسی: کدام جزء واقعاً مهم است؟
هارنس‌های کدنویسی شکل می‌دهند ایجنت‌ها چطور توانایی مدل را به کارایی بلندمدت مهندسی نرم‌افزار تبدیل کنند، اما کارهای موجود معمولاً هارنس‌ها را سیستم‌های یکپارچه ارزیابی می‌کنند و اثربخشی تک‌تک اجزا نامعلوم می‌ماند. نویسنده‌ها یک هارنس کدنویسی سبک با حلقه‌ی اجر
رکوریس: تکامل بازگشتی حافظه‌ی تجربی و کاری برای هارنس‌های ایجنت بلندمدت
خودبهبودی بازگشتی در تسک‌های بلندمدت سخت است، چون تاریخچه‌ی رو به رشد وضعیت تسک را مبهم می‌کند و فراخوانی مهارت‌ها را نابجا می‌کند؛ مثلاً ایجنت مهارتی را که برای دستور اولیه مناسب بود، بعد از عوض شدن وضعیت هم دوباره فرا می‌خواند. معماری Recuris دو حافظه را جفت