چگونه مهندسی هارنس، نرخ موفقیت عامل‌های کدنویس را به ۷۷٪ رساند؟

اگر هنوز گردش‌کار عامل‌های خود را دستی تنظیم می‌کنید، در حال جنگ با یک ارتش از خطاها و ناپایداری‌ها هستید. باید بدانید که بزرگ‌ترین هزینه پنهان در سیستم‌های عامل‌محور (Agentic)، نه خودِ مدل، بلکه «هارنس» یا همان محیط اجرای آن است.

در ۳۰ آوریل ۲۰۲۶، یک مقاله پژوهشی چارچوبی به نام مهندسی هارنس عامل‌محور (Agentic Harness Engineering یا AHE) را معرفی کرد که معماری عامل را به عنوان یک قرارداد قابل تایید می‌بیند. به نقل از گزارش منتشر شده در gentic.news، این رویکرد اجازه می‌دهد هارنس‌ها بدون دچار شدن به «رانش» (Drift) که در تکامل‌های آزمون-و-خطای ساده دیده می‌شود، به‌طور سیستماتیک تکامل یابند.

این چارچوب از سه لایه مجزا تشکیل شده است:

• اجزای بازگشت‌پذیر: هر بخش از هارنس به صورت یک فایل ذخیره می‌شود تا امکان بازگشت به نسخه‌های قبلی وجود داشته باشد.
• تجربه فشرده: میلیون‌ها توکنِ مسیر اجرا به شواهد عملی و قابل اجرا تبدیل می‌شوند.
• تصمیمات ابطال‌پذیر: هر تغییر با نتایج واقعی تسک‌ها سنجیده می‌شود تا یک حلقه بازخورد سخت‌گیرانه ایجاد شود.

نتایج در بنچمارک Terminal-Bench 2 تکان‌دهنده بود: نرخ موفقیت (pass@1) تنها در ۱۰ تکرار از ۶۹.۷٪ به ۷۷.۰٪ رسید. طبق گزارش این پژوهش، این عملکرد حتی از Codex-CLI که توسط انسان طراحی شده (۷۱.۹٪) و همچنین مدل‌های خود-تکامل‌یافته‌ای مانند ACE و TF-GRPO پیشی گرفته است.

همان‌طور که در تحلیل قبلی ما درباره‌ی معماری‌های خود-تکامل‌یافته اشاره کردیم، حذف دخالت دستی انسان در طراحی جریان‌های کاری، کلید رسیدن به پایداری در مقیاس است.

علاوه بر دقت، این چارچوب کاربرد عملی بالایی دارد. در بنچمارک SWE-bench-verified، مصرف توکن‌ها ۱۲٪ کاهش یافت. همچنین، این سیستم توانست بین مدل‌های مختلف منتقل شود و بهبودهایی بین ۵.۱ تا ۱۰.۱ واحد در خانواده‌های مختلف مدل‌ها ایجاد کند. این یعنی سیستم به جای بیش‌برازش (Overfitting) روی یک مدل خاص، ساختارهای بنیادی تسک را یاد می‌گیرد.

این تغییر رویکرد، بازتابی از فلسفه چارچوب Flue است که یک عامل را مجموع مدل و هارنس آن تعریف می‌کند. با خودکارسازی تکامل هارنس، توسعه‌دهندگان از تنظیمات دستی به سمت یک معماری برنامه‌ریزی‌پذیر و مشاهده‌پذیر حرکت می‌کنند.

اما سوال حیاتی این است که آیا این موفقیت در بنچمارک‌ها به پایداری در محیط‌های واقعی تولید تبدیل می‌شود یا خیر؟ این تنها آغاز ماجراست؛ اثر موج‌گونه‌ی این تصمیم بر اکوسیستم متن‌باز را در گزارش بعدی بررسی خواهیم کرد.

گام بعدی شما

• بررسی مستندات AHE برای جایگزینی تنظیمات دستی با لایه‌های ابطال‌پذیر.
• تست مدل‌های فعلی خود در بنچمارک‌های سخت‌گیرانه‌تر برای شناسایی نقاط شکست هارنس.
• مطالعه در مورد چارچوب Flue برای درک بهتر رابطه مدل و محیط اجرا.