‏پشت پرده agent کرسر: چطور harness رو بهتر می‌کنن؟

کرسر یه پست فنی منتشر کرده که توضیح می‌ده چطور به‌طور مداوم روی harness ایجنت‌های کدنویسی‌اش کار می‌کنه. harness در واقع همون لایه‌ای‌ه که بین مدل زبانی و دنیای واقعی قرار می‌گیره — مدیریت context window، تعریف ابزارها، و نحوه تعامل با کاربر. هدف اصلی اینه که همون مدل پایه، داخل این لایه تنظیم‌شده، خیلی بهتر از حالت پیش‌فرضش عمل کنه.

یکی از مهم‌ترین تحولات اینه که چطور context window پر می‌شه. در ابتدای کار (اواخر ۲۰۲۴)، مدل‌ها ضعیف‌تر بودن و تیم مجبور بود خیلی چیزها رو به‌صورت استاتیک و از قبل آماده توی context بذاره — مثل ساختار پوشه‌های پروژه، کدهای مرتبط با query، و نسخه‌های فشرده فایل‌های attach‌شده. علاوه بر این، guardrailهای زیادی هم داشتن؛ مثلاً بعد از هر ویرایش، خطاهای lint و type رو به مدل نشون می‌دادن یا تعداد ابزارهایی که مدل می‌تونست در یه نوبت صدا بزنه رو محدود می‌کردن.

الان اوضاع فرق کرده. مدل‌ها قوی‌تر شدن و کرسر بیشتر به context پویا تکیه می‌کنه؛ یعنی اجازه می‌ده ایجنت خودش در حین کار، اطلاعاتی که نیاز داره رو بکشه. بیشتر اون ساختارهای استاتیک حذف شدن و guardrailها هم خیلی کمتر شدن. هنوز یه سری context استاتیک مفید مثل سیستم‌عامل، وضعیت git، و فایل‌های اخیراً باز‌شده نگه داشته می‌شه، ولی اصل کار به پویایی رسیده.

برای سنجش اینکه تغییرات واقعاً بهتر شدن یا نه، دو رویکرد موازی دارن. اول، CursorBench — یه سوئیت eval داخلی — کنار بنچمارک‌های عمومی استفاده می‌شه. دوم، آزمایش‌های آنلاین A/B که نسخه‌های مختلف harness رو روی کاربران واقعی مقایسه می‌کنه. متریک‌های ساده مثل latency و تعداد tool callها مفیدن، ولی کافی نیستن. دو متریک کلیدی‌تر هم دارن: «نرخ نگه‌داری کد» (Keep Rate) که می‌سنجه چه درصدی از کدی که ایجنت نوشته بعد از مدتی هنوز توی پروژه هست، و یه مدل زبانی که پاسخ‌های کاربر به ایجنت رو می‌خونه و می‌فهمه کاربر راضی بوده یا نه — مثلاً paste کردن stack trace نشونه واضح نارضایتیه.

یه مثال جالب: در یه آزمایش، تیم یه مدل گران‌قیمت‌تر برای خلاصه‌سازی context امتحان کرد، اما متوجه شد تفاوت معناداری در کیفیت ایجاد نمی‌کنه و صرفه نداره. همین نتیجه‌گیری‌های داده‌محور مانع هدر رفتن منابعه.

بخش مهم دیگه‌ای که به اون پرداخته می‌شه، ردیابی و رفع خطاهای ابزارهاست. وقتی یه tool call با خطا مواجه می‌شه، اون خطا توی context باقی می‌مونه و «context rot» ایجاد می‌کنه — یعنی خطاهای انباشته کیفیت تصمیم‌های بعدی مدل رو کم می‌کنن. خطاها به دسته‌های مختلف تقسیم می‌شن: InvalidArguments، UnexpectedEnvironment، ProviderError، UserAborted، Timeout و غیره. هر خطای ناشناخته یه باگ محسوب می‌شه و alert مشخصی داره. برای خطاهای «انتظاری» هم anomaly detection هست که وقتی نرخ خطا از baseline پر می‌شه، هشدار می‌ده. با یه sprint متمرکز، نرخ خطاهای ناشناخته ابزارها یه مرتبه بزرگی کاهش پیدا کرد.

نکته جالب اتوماسیون داخلیشونه: یه Automation هفتگی دارن که با استفاده از یه ایجنت، لاگ‌ها رو بررسی می‌کنه، مشکلات جدید یا افزایش‌یافته رو پیدا می‌کنه، و ticket در سیستم Linear می‌سازه یا آپدیت می‌کنه. بعدش از Cloud Agents برای کیک‌آف فیکس‌های موازی استفاده می‌کنن — یه نوع «کارخانه نرم‌افزاری» خودکار.

در نهایت، کرسر روی customize کردن harness برای هر مدل هم وقت می‌ذاره. مدل‌های OpenAI با فرمت patch-based کار می‌کنن، مدل‌های Anthropic با string replacement. این تفاوت‌ها نشون می‌ده که یه harness یکسان برای همه مدل‌ها بهینه نیست و باید به قابلیت‌ها و quirkهای هر مدل توجه کرد.

نکات کلیدی:

• harness لایه‌ای‌ه که مدل زبانی رو به دنیای واقعی وصل می‌کنه و تنظیم دقیقش می‌تونه همون مدل رو خیلی بهتر کنه
• رویکرد کرسر از context استاتیک به context پویا تغییر کرده — ایجنت الان خودش در حین کار اطلاعات می‌کشه
• «نرخ نگه‌داری کد» و تحلیل پاسخ‌های کاربر با LLM، متریک‌های کیفی مهم‌تری از latency و token countن
• خطاهای tool call باعث context rot می‌شن و باید جدی گرفته بشن
• اتوماسیون داخلی با ایجنت‌ها برای پیدا کردن و فیکس کردن باگ‌ها استفاده می‌شه
• هر مدل زبانی نیاز به تنظیمات خاص خودش داره و یه harness جهانی بهینه نیست