هارنسدِو پرسشی عملیتر از بیشتر معیارهای ارزیابی عاملها مطرح میکند: آیا یک مدل زبانی میتواند چارچوب نرمافزاری پیرامون یک عامل دیگر را طراحی کند و سپس همان چارچوب را بهمرور بهبود دهد؟ پژوهشگران بهجای تمرکز صرف بر پاسخ نهایی، زیرساخت قابلاجرای عامل را ارزیابی کردهاند. نتیجه یک مشکل مهم را برای سامانههای خودبهبوددهنده آشکار میکند: نسخهای که روی وظایف قابلمشاهده بهتر شده، ممکن است روی وظایف پنهان یا با یک مدل اجراکننده دیگر ضعیفتر شود.
این تفاوت مهم است، چون بخش بزرگی از کنترلهای عملیاتی در همین چارچوب قرار دارند: شکستن کار به مراحل کوچکتر، فراخوانی ابزار، نگهداری وضعیت، تلاش دوباره پس از خطا، بررسی خروجی و تعیین زمان توقف. اگر عامل بتواند این لایه را تغییر دهد، ارزیابی خود مدل دیگر کافی نیست. چارچوب اجرایی به یک مصنوع نرمافزاری نسخهدار تبدیل میشود که باید مانند هر انتشار نرمافزاری دیگر کنترل شود.
ارزیابی از پاسخ نهایی به زیرساخت اجرایی منتقل میشود
پیشچاپ هارنسدِو که اول سپتامبر ثبت شده، دو مرحله دارد. در مرحله ساخت، شش مدل سازنده در چهار حوزه و پنج معیار پاییندستی، چارچوبهای عامل تولید میکنند و در مجموع ۲۲۰۷ نمونه یکتا بررسی میشود. نقطه شروع عمداً ضعیف است و حلقه عامل، منطق تجزیه کار، سیاست ابزار، مدیریت زمینه، وضعیت پایدار، بررسیکننده، تلاش دوباره و قانون توقف ندارد. بنابراین هر عملکرد معناداری وابسته به چیزی است که مدل سازنده واقعاً اضافه میکند.
چارچوبهای تولیدشده قابل اجرا هستند، اما کیفیت آنها در حوزههای مختلف یکسان نیست. نویسندگان گزارش میکنند که در برنامهنویسی و جستوجو یا پژوهش هنوز از نمونههای بالغ ساختهشده بهدست انسان عقبترند، در حالی که در برخی وظایف نوشتن و آزمایشهای یادگیری ماشین میتوانند به سطح نمونههای مرجع انتخابشده برسند یا از آنها عبور کنند.
ضعف اصلی در انتقال به شرایط دیگر دیده میشود
مرحله تکامل برای استفاده عملی مهمتر است. پروژه ۷۳ نسخه رسمی را در ۹ مسیر بهینهسازی دنبال میکند. طبق صفحه پروژه، مجموعهای که تغییرها را هدایت میکند و مجموعه پنهان فقط در ۳۴ مورد از ۶۴ تغییر نسخه، یعنی ۵۳.۱ درصد، جهت یکسانی نشان میدهند. همچنین فقط دو مورد از ۹ نسخهای که بهعنوان نسخه نهایی انتخاب شدهاند، روی مجموعه پنهان نیز بهترین نسخه بودهاند.
عملکرد یک چارچوب با تغییر مدل اجراکننده هم میتواند عوض شود. در یکی از آزمایشهای گزارششده، جایگزینی اجراکننده با یک مدل ثابت جمینای باعث میشود سه مورد از چهار مسیر بهینهسازی نتیجه منفی بگیرند. پس اجراکننده را نمیتوان جزئی قابلتعویض فرض کرد؛ بخشی از سامانهای است که باید ارزیابی شود.
تغییر چارچوب باید مانند انتشار نرمافزار مدیریت شود
مهمترین نتیجه این پژوهش این نیست که عاملها اکنون میتوانند بهطور خودکار عاملهای بهتری بسازند. دادهها برای چنین نتیجهای بیش از حد متغیرند. نتیجه محکمتر این است که تغییر خودکار زیرساخت عامل، یک مسئله مدیریت نسخه و انتشار نرمافزار ایجاد میکند.
هر نسخه باید هویت تغییرناپذیر داشته باشد، مجموعهای مستقل از وظایفی که تغییر را ایجاد کردهاند برای تأیید نهایی استفاده شود، مدل اجراکننده ثبت شود و امکان بازگشت به نسخه قبلی وجود داشته باشد. ارتقا به نسخه جدید باید تنها زمانی انجام شود که محدودیتهای از پیش تعیینشده برای افت کیفیت، هزینه، تأخیر و رفتارهای مرتبط با ایمنی رعایت شده باشند.
این روش از نگاه صرف به رتبه یا امتیاز دقیقتر است. بهبود در یک معیار میتواند در محیط واقعی به پسرفت تبدیل شود. هارنسدِو این مسئله را با بررسی تغییر بین نسخهها نشان میدهد، نه فقط با مقایسه امتیاز نهایی.
وجود یک سازوکار در کد به معنی فعال بودن آن نیست
پروژه همچنین بررسی میکند که آیا اجزای تولیدشده واقعاً هنگام اجرا استفاده میشوند یا نه. از میان ۱۰۸ نمونه مؤلفه، ۱۸ مورد هرگز در زمان اجرا مشاهده نشدهاند و همه آنها به وضعیت یا حافظه مربوط بودهاند. یازده مصنوع نرمافزاری یک ساختار وضعیت تعریف میکنند، اما فقط یکی امکان ذخیره وضعیت را در اختیار میگذارد، فقط یکی ثبت دورهای نقطه بازیابی را پیادهسازی میکند و پروژه در ۲۶۶۷۹ مسیر اجرای وظیفه حتی یک رویداد ثبت نقطه بازیابی مشاهده نکرده است.
این یافته برای حاکمیت و اطمینان عملیاتی مهم است. بررسی ایستای کد میتواند نشان دهد یک کنترل وجود دارد، اما ثابت نمیکند که آن کنترل در شرایط لازم اجرا میشود. همین مسئله درباره تلاش دوباره، بررسیکنندهها، حافظه، کنترل مجوز و سازوکارهای ایمنی هم وجود دارد.
نتیجه عملی برای تیمهای فنی
هارنسدِو هنوز یک پیشچاپ است. مدلها، معیارها و سامانههای مرجع انتخابشده محدودند و تحلیل پنهان پس از تثبیت مرحله تکامل عمدتاً بر مهندسی نرمافزار تمرکز دارد. بنابراین این نتایج اثبات نمیکنند که تکامل خودکار چارچوب عامل بهطور کلی ناامن یا ناکارآمد است.
با این حال، پژوهش یک الگوی ارزیابی مفید ارائه میکند. اگر عامل بتواند لایه هماهنگکننده خودش را تغییر دهد، واحدی که باید در انتشار کنترل شود دیگر فقط مدل نیست. مدل، چارچوب اجرایی، اجراکننده، سیاست ابزار، سامانه وضعیت و فرایند ارتقا باید با هم بهعنوان یک واحد بررسی شوند.
پرسش درست این است: آیا همین نسخه مشخص از سامانه، در یک ارزیابی مستقل بهتر شده و آیا کنترلهایش واقعاً هنگام اجرا فعال بودهاند؟ برای تیمهایی که به سمت عاملهای خودبهبوددهنده میروند، این پرسش مبنای قابلدفاعتری برای اجازه انتشار است.