پروتکل رسید میزبان؛ سدی در برابر توهمات عامل‌های کدنویس درباره محیط اجرا

تصور کنید یک برنامه‌نویس ساعتی از وقتش را صرف بررسی کدی می‌کند که در ظاهر بی‌نقص است، اما در لحظه اجرا می‌پاشد چون عامل هوش مصنوعی فرض کرده سیستم‌عامل شما اوبونتو است، در حالی که شما از دبیان استفاده می‌کنید. این «توهمات محیطی» یکی از بزرگ‌ترین موانع تبدیل عامل‌های کدنویس به ابزارهای قابل اعتماد در مقیاس صنعتی هستند. در واقع، در حالی که عامل‌های کدنویس در طول دوره‌های کوتاه توسعه یا همان «اسپایک‌ها» (Spikes) مکرراً جزئیات سیستم را توهم می‌زنند، یک پروتکل جدید با اعمال یک قانون محوری از این اتفاق جلوگیری می‌کند: عاملی که نتواند یک رسید زنده از میزبان (Host Receipt) پیوست کند، نباید محیط اجرا (Runtime) را توصیف کند.

بسیاری از توسعه‌دهندگان با این تجربه تلخ روبرو شده‌اند: عامل یک وصله (Patch) تمیز ارائه می‌دهد که عالی به نظر می‌رسد، اما چون مسیر libc یا نسخه OS را اشتباه حدس زده، کد هرگز اجرا نمی‌شود. به نقل از گزارش‌های فنی، در یک مورد، یک نگهدارنده پروژه (Maintainer) با درخواست ادغامی (Pull Request) مواجه شد که در آن عامل، نسخه glibc را پین کرده بود، نام یک واحد systemd را تغییر داده بود و اعلام کرده بود که میزبان Ubuntu Noble است. در واقعیت، باکس ارزیابی یک ایمیج سبک Debian بود که هیچ systemd ای نداشت و مسیر libc آن متفاوت بود. عامل هرگز فایل /etc/os-release را نخوانده بود، اما diff ارائه شده چنان از نظر داخلی منسجم بود که در نگاه اول آماده ادغام به نظر می‌رسید.

این پیش‌فرض‌های خاموش به این دلیل از فیلتر بررسی‌ها رد می‌شوند که وصله‌های تمیز، این حقیقت را پنهان می‌کنند که هیچ‌کس واقعاً ماشین را مشاهده نکرده است. با تکیه بر چالش‌های صنعت در زمینه قابلیت اطمینان عامل‌ها، این رویکرد از «مهندسی پرامپت» برای رفع توهمات فاصله می‌گیرد. اگرچه پرامپت دادن به مدل برای اجتناب از پیش‌فرض‌ها ممکن است برای یک یا دو نوبت کمک کند، اما عادت به اختراع داده‌ها معمولاً تحت فشار زمانی بازمی‌گردد. راهکار، یک دروازه فنی سخت‌گیرانه به نام «رسید میزبان» است.

مکانیسم دروازه رسید

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

• هویت سیستم‌عامل: استخراج ID و VERSION_ID از فایل /etc/os-release.
• محیط پایتون: نسخه جزئی (Minor Version) از طریق platform.python_version() و مسیر دقیق sys.executable.
• متادیتای سیستم: نام میزبان (Hostname)، خروجی دستور uname -a و نسخه کرنل.
• بستر اجرا: دایرکتوری کاری فعلی (cwd) و همچنین شناسه‌های کاربر uid و euid مربوط به پروسه.

پس از جمع‌آوری، سیستم یک هش SHA-256 از این داده‌ها می‌سازد. اپراتور این کد (Digest) را به عنوان تنها مرجع قانونی در سیستم ردیابی مسائل (Issue Tracker) قرار می‌دهد. سپس عامل به میزبان دسترسی داده می‌شود، اما او اکیداً از ویرایش اسکریپت جمع‌آوری یا فایل رسید حاصله منع شده است. حالت فایل (File Mode) روی ۶۴۴ (قابل خواندن برای همه) تنظیم می‌شود تا عامل بتواند آن را باز کند، در حالی که دایرکتوری والد در مالکیت اپراتور باقی می‌ماند تا از جابجایی یا جایگزینی فایل‌ها جلوگیری شود.

برای «ارسال» یک وصله، عامل باید یک «فایل ادعا» (Claims File) تولید کند. این فایل باید هش اپراتور را دقیقاً نقل قول کند و با واقعیت‌های مشاهده شده در رسید مطابقت داشته باشد. اگر عامل بدون این استناد، نسخه‌ای را پین کند، نام پکیجی را بیاورد یا جزئیاتی از سیستم Init ارائه دهد، آزمایش بلافاصله متوقف (Kill) می‌شود. این سازوکار شبیه مهر ورود به یک کلوب است؛ هر کسی می‌تواند از روی فیلم توصیف کند کلوب چه شکلی است، اما دربان فقط مهر روی پوست را چک می‌کند و یک نقاشی ساده، جایگزین مهر واقعی نمی‌شود.

پروتکل ۹۰ دقیقه‌ای Spike

این گردش‌کار به صورت یک «اسپایک» (Spike) پرفشار و دقیقاً ۹۰ دقیقه‌ای طراحی شده است. این اسپایک یک فرضیه واحد را تست می‌کند و با یک تصمیم «ارسال یا توقف» (Ship-or-Kill) بدون هیچ‌گونه تمدیدی به پایان می‌رسد. این جدول زمانی صلب است تا از «جلسات مربی‌گری» جلوگیری شود؛ جایی که اپراتورها بعد از هر فراخوانی ناموفق ابزار، به صورت دستی پرامپت‌ها را اصلاح می‌کنند:

• دقیقه ۰ تا ۱۰: ده دقیقه اول متعلق به Issue Tracker است. اپراتور فرضیه، قانون توقف (Kill Rule) و یک وظیفه مجاز (مانند یک یادداشت سه خطی شامل شناسه OS و نسخه جزئی پایتون) را ثبت می‌کند. اپراتور از گسترش دامنه کار امتناع می‌کند.
• دقیقه ۱۰ تا ۴۰: اپراتور وارد میزبان ارزیابی شده، رسید را روی میزبان قرار می‌دهد و دایرکتوری را در برابر نوشتن توسط عامل قفل می‌کند.
• دقیقه ۴۰ تا ۷۰: یک اسکریپت تاییدکننده روی یک لپ‌تاپ (بدون نیاز به راه‌اندازی خط لوله یا Pipeline) اجرا می‌شود. این اسکریپت فایل ادعاها را در برابر رسید و هش موجود در Issue Tracker چک می‌کند.
• دقیقه ۷۰ تا ۹۰: بیست دقیقه آخر برای یک تلاش واحد است. اپراتور عامل را به Issue، مسیر رسید و طرح (Schema) ادعاها ارجاع می‌دهد و سپس بدون هیچ ویرایشی در حین اجرا، نظاره‌گر است.

پیاده‌سازی فنی

این پروتکل از اسکریپت‌های ساده شل (Shell) و پایتون استفاده می‌کند. جمع‌آوری‌کننده داده‌ها را از /etc/os-release و platform.python_version() می‌گیرد تا اطمینان حاصل شود که عامل نمی‌تواند به سیستم‌فایل‌های شبیه‌سازی‌شده (Mocked) تکیه کند. از درخت‌های شبیه‌سازی‌شده اجتناب می‌شود زیرا آن‌ها دقیقاً همان توهماتی را دعوت می‌کنند که این پروتکل سعی در حذف آن‌ها دارد.

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

منطق تاییدکننده (Verifier)

اسکریپت تاییدکننده، نبودِ فایل ادعا را به جای «نادیده گرفتن» (Skip)، به عنوان «توقف» (Kill) تلقی می‌کند. این کار مانع از آن می‌شود که میزبان‌های اختراعی دوباره وارد گردش‌کار شوند. فایل ادعا تنها سندی است که عامل اجازه نوشتن آن را دارد و باید هش Issue را دقیقاً نقل کند. هر چیزی که مدل در چت چاپ می‌کند، تا زمانی که آن فایل روی دیسک در کنار وصله وجود نداشته باشد، صرفاً «نمایش» (Theater) تلقی می‌شود.

قوانین خاص توقف شامل موارد زیر است:

• عدم تطبیق هش: اگر receipt_sha256 در فایل ادعا با هش اپراتور یکی نباشد.
• تضاد واقعیت: اگر os_id یا python_version با رسید زنده میزبان در تضاد باشد.
• انقضا: اگر رسید قدیمی‌تر از پنجره زمانی ۹۰ دقیقه‌ای اسپایک باشد.
• خطاهای فرمت: اگر هش Issue یک رشته ۶۴ کاراکتری SHA-256 نباشد.

هر فیلد اضافه‌ای که عامل اضافه کند — مانند جزئیات GPU، نام‌های بازاریابی توزیع‌ها یا ایمیج‌های داکر قدیمی که در حافظه‌اش مانده — به جای دقت، به عنوان «اختراع» (Invention) امتیاز منفی می‌گیرد. طرح (Schema) کوچک نگه داشته شده تا وقتی عامل شیء را با «فولکلورهای مطمئن» پر می‌کند، قانون توقف کاملاً واضح باشد.

محدودیت‌ها و ریسک‌ها

باید توجه داشت که این روش ثابت نمی‌کند وصله ایمن، درست یا ارزشمند برای ادغام است؛ بلکه فقط ثابت می‌کند عامل در یک زمان خاص، میزبان را مشاهده کرده است. ریسک‌های شناخته شده‌ای مانند اختلاف ساعت (Clock Skew) یا متادیتای دروغین کانتینرها وجود دارد که می‌تواند عامل‌های صادق را مقصر جلوه دهد. پروتکل این سوگیری به نفع «توقف» را می‌پذیرد تا مطمئن شود شواهد هرگز مورد مذاکره قرار نمی‌گیرند.

علاوه بر این، نویسنده هشدار می‌دهد که اسرار تولید (Production Secrets)، دمپ‌های مشتریان یا کش‌های ساخت اختصاصی هرگز نباید روی این میزبان‌های ارزیابی یک‌بارمصرف قرار گیرند. تیم‌هایی که اسرار تولید را روی یک سرور ارزیابی مشترک قرار می‌دهند، نباید از این رویکرد استفاده کنند.

این تغییر در عمل، معیار ارزیابی عامل‌ها را عوض می‌کند. به جای اعتماد به تاریخچه چت — که در واقع نوعی «ادبیات» است و می‌تواند دستوری را نقل کند و بدون لمس ماشین، یک کد خروجی (Exit Code) اختراع کند — اپراتورها اکنون یک لینک رمزنگاری‌شده به ماشین زنده می‌خواهند. اعداد منتشر شده در اینجا حذف شده‌اند زیرا این یک پروتکل است، نه یک جدول رده‌بندی (Leaderboard) برای برندهای دستیار هوش مصنوعی.

برای توسعه‌دهندگان، این یعنی پایان دوران «شایدِ مبهم» در ارزیابی عامل‌ها. نتیجه یا یک ارسال تمیز (Exit Status 0) است یا یک توقف قطعی (Exit Status 2)، که شکست‌های اجتماعی ناشی از مذاکره با شواهد ناقص را حذف می‌کند. لاگ‌ها، ایموجی‌ها و نمرات اعتماد (Confidence Scores) که توسط خود مدل داده شده، به عنوان کانال‌هایی که در آن میزبان‌های اختراعی «پرکار» به نظر می‌رسند، نادیده گرفته می‌شوند.

گام بعدی شما

• اگر از عامل‌های کدنویس استفاده می‌کنید، یک اسکریپت ساده برای استخراج os-release و python_version بنویسید و آن را به عنوان مرجع به مدل بدهید.
• در ارزیابی‌های خود، هرگونه ادعای مدل درباره محیطی که مدرک (Log) آن را ارائه نداده، به عنوان توهم در نظر بگیرید.
• محیط‌های ایزوله مانند MonkeyCode را برای تست‌های سریع و تخریب‌پذیر امتحان کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.