‏kiro-trace: وقتی Kiro از اجراهای خودش اشکال‌هاشو پیدا می‌کنه

تیم Kiro تو این پست توضیح می‌ده چطور یه سیستم داخلی به اسم kiro-trace ساختن که از روی اجراهای واقعی خود Kiro، مشکل‌هاشو پیدا و درست می‌کنه. مثالی که باهاش شروع می‌کنن جالبه: یه جمله تو توضیح ابزار خوندن فایل و جستجو، یه ادعای غلط درباره‌ی harness (یعنی لایه‌ای که مدل رو اجرا می‌کنه و ابزارها رو بهش می‌ده) داشت و ۶۱,۷۴۲ بار به مدل رسیده بود، بدون اینکه کسی متوجه بشه.

نویسنده‌ها می‌گن بزرگ‌ترین خطر تو این جور حلقه‌ها اینه که خود agent تغییرشو داوری کنه. یه بار نزدیک بود تغییری رو منتشر کنن که هم task بیشتری حل می‌کرد هم token کمتری مصرف می‌کرد. ولی با تفکیک نتیجه‌ها بر اساس host معلوم شد تقریباً کل بهبود از یه اجرای شانسی بوده. برای همین سه نقش رو کاملاً جدا نگه می‌دارن: Kiro که بهتر می‌شه، حلقه‌ای که تغییر پیشنهاد می‌ده، و یه gate که کد ساده‌ست و تصمیم می‌گیره. آخرش هم یه آدم merge رو تأیید می‌کنه.

حلقه به جای اجرای کل benchmark تو هر دور، یه مجموعه‌ی کوچیک از taskهای شکست‌خورده می‌سازه که حالت‌های مختلف خرابی رو پوشش بده. وقتی Kiro یه task رو خراب می‌کنه، چند agent مرجع (مدل‌ها و agentهای قوی دیگه) همون task رو با همون ورودی اجرا می‌کنن و فرقشون می‌شه سرنخ رفع مشکل. داوری هم روی delta انجام می‌شه، یعنی هر بار یه نسخه‌ی کنترل بدون تغییر هم کنارش اجرا می‌شه تا معلوم بشه بهبود واقعاً از همون تغییره. اجراهایی هم که agent جواب رو از اینترنت پیدا کرده کنار گذاشته می‌شن.

چند نمونه از تغییرهایی که merge شد: حذف همون جمله‌ی غلط، حذف راهنمایی‌ای که مدل رو به صدا زدن ابزاری می‌فرستاد که اصلاً وجود نداشت، کم کردن حدود ۸۳ درصد از دوباره‌خوندن فایل‌های تغییرنکرده، و رفع باگی که حدود یک از هر هشت جستجوی فایل رو بی‌صدا خالی برمی‌گردوند. یه تغییر هم باعث شد وقتی مدل به جای boolean رشته‌ی "true" می‌فرسته، فراخوانی ابزار رد نشه و تو تلاش بعدی اصلاح بشه.

مثال کامل‌تر، compaction هست، یعنی وقتی گفتگو به سقف context می‌رسه و Kiro خلاصه‌ش می‌کنه تا یه نمونه‌ی تازه ادامه بده. مشکل این بود که خلاصه با یه لیست خام از پیام‌های قدیمی کاربر تموم می‌شد و agent گاهی به یه task خیلی قدیمی برمی‌گشت. kiro-trace یازده پرامپت مختلف رو مقایسه کرد و راه‌حل، حذف اون لیست و گذاشتن یه خلاصه‌ی کوتاه با قالب ثابت به همراه آخرین پیام‌ها بود. امتیاز retention (یعنی چقدر از اطلاعات لازم برای ادامه‌ی کار بعد از خلاصه‌سازی می‌مونه) از ۰.۸۲ به ۰.۹۲ رسید.

بزرگ‌ترین تغییر هنوز منتشر نشده: یه پروفایل کوچیک‌تر از ابزار و پرامپت که روی Terminal-Bench 2.1 به pass@1 (یعنی درصد taskهایی که بار اول حل می‌شن) ۸۲.۴ درصد در برابر ۷۷.۵ درصد رسیده، اونم با حدود یک‌سوم هزینه‌ی token. تیم می‌گه چون این تغییر ابزارهای پیش‌فرض همه‌ی کاربرها رو عوض می‌کنه، بیشتر یه تصمیم محصوله تا benchmark. توصیه‌ی اصلی‌شون هم اینه که اول حذف کردن رو امتحان کنید، بعد اضافه کردن.

نکات کلیدی:

• kiro-trace تو هفته‌ی اول ۸ pull request باز کرد که ۷ تاش merge شد و هیچ‌کدوم تو code review برنگشت.
• قبول یا رد هر تغییر با کد قطعیه، نه با خود مدل، و آخرش یه آدم merge رو تأیید می‌کنه.
• هر بار یه اجرای کنترل بدون تغییر هم اجرا می‌شه تا فقط delta همون تغییر سنجیده بشه.
• اصلاح compaction امتیاز retention رو از ۰.۸۲ به ۰.۹۲ رسوند.
• پروفایل کوچیک‌تر روی Terminal-Bench 2.1 به ۸۲.۴ درصد در برابر ۷۷.۵ درصد رسیده ولی هنوز منتشر نشده.
• هر رفع مشکل تأییدشده یه تست دائمی به مجموعه‌ی regression اضافه می‌کنه.