تصور کنید یک ماشین آزمایشگاهی مشترک را که در لحظهای تبدیل به یک نقطه ضعف امنیتی و عملیاتی میشود؛ دقیقاً زمانی که یک کارآموز، یک عامل کدنویسی (Coding Agent) را شبانهروز روی سرور رها میکند. صبح دوشنبه، ممکن است با یک وصله (Patch) کد مواجه شوید که منطقی به نظر میرسد و تمام تستها با رنگ سبز پاس کرده است، اما هیچ ردی از مجموعه پرامپتها (Prompt Pack) یا لاگهای جلسهای که منجر به تولید این کد شده، وجود ندارد. در محیطهای رایگان، زمان اجرای (Runtime) مدلها بهسرعت تغییر کرده و به سراغ وظایف همتیمیهای دیگر میرود و لاگهای جلسه قبلی به دلیل محدودیت فضا، جایگزین (Rotate) شدهاند. این شکاف باعث میشود دستاوردهای مهندسی به «افسانههای محلی» تبدیل شوند؛ نتایجی که وجود دارند اما نه قابل تکرار هستند و نه قابل بازرسی. در این وضعیت، شما نه به دلیل کمبود استعداد، بلکه به دلیل نبود یک نام مشخص در ویکی برای این اجرای خاص، متوقف شدهاید.
با تکیه بر پوششهای قبلی ما درباره اینکه چگونه SOPهای تکصفحهای از شکست وصلههای نوشته شده توسط AI جلوگیری میکنند، مشکل اصلی همچنان نوسانی بودن محیطهای اجرای رایگان است. در این محیطها، «آشپزخانه» در حالی که تیم در خواب است، آشپزهایش را عوض میکند. وقتی لاگهای جلسه چرخان (Rotate) میشوند و دسترسیهای رایگان به مدلها تغییر میکند، پیوند میان مجموعه ورودیها (Input Corpus) و تغییرات نهایی کد (Diff) قطع میشود. اگر آزمایشگاه شما در حال حاضر دسترسی رایگان به مدلها و یک سرور رایگان را به صورت مشترک به اشتراک میگذارد، باید با آن باکس مانند یک «آشپزخانه اجارهای» برخورد کنید، نه یک ایستگاه کاری شخصی. این بینظمی در مدیریت منابع میتواند منجر به حوادث مالی شود، مشابه آنچه در تحلیل ما از خطای تشخیص کلید امنیتی و هزینههای سنگین ناشی از حلقههای تکرار بیحد عاملهای کدنویسی مشاهده کردیم.
برای حل این بحران، MonkeyCode یک سیستم سختگیرانه برای «پین کردن» (Pinning) پیشنهاد میدهد. MonkeyCode میتواند آن آزمایشگاه مشترک با دسترسی رایگان به مدل و گزینه سرور رایگان را که برای کل تیم قابل دسترسی است میزبانی کند، اما خودِ نرمافزار نمیتواند خودش را پین کند. هدف این است که «امضاکننده تغییرات» (Diff Signer) — کسی که تایید میکند یک وصله پس از خواندن تغییرات توسط انسان، برای ادغام (Merge) قابل قبول است — از «مالک پین» (Pin Owner) جدا شود؛ کسی که صحت دقیق محیط اجرا، مجموعه پرامپتها و مجموعه ورودیهای استفاده شده را تضمین میکند. این سازوکار تضمین میکند که یک مجموعه تست سبز نتواند یک جلسه سندباکس غیرقابل تکرار را از دید بازرسان در آینده پنهان کند.
چهار ستون مالکیت
طبق این راهنما، تیمها باید چهار نقش مشخص را در یک صفحه ویکی واحد تعریف کنند. این نقشها میتوانند در یک تیم دو نفره توسط یک نفر ایفا شوند، اما نامها باید صریح و شفاف باشند. یک اشاره (Mention) در کانالهای چت، زمانی که لاگها قبلاً جایگزین شدهاند، به معنای مالکیت نیست. صفحه ویکی باید نامهای فعلی را در بالا و تاریخ چرخش بعدی را به صورت متن ساده نمایش دهد. اگر یک اجرای کد (Run) بازه زمانی چرخش نقشها را در بر بگیرد، مالک پین اصلی تا زمانی که ارتقا یا حذف آن ثبت شود، مسئولیت آن اجرا را بر عهده دارد.
- مالک پین (Pin Owner): پیش از آنکه هرگونه خروجی از عامل (Agent) از باکس مشترک خارج شود، فایل پین را مینویسد. اگر آزمایشگاه شلوغ باشد، این نقش باید هفتگی چرخان باشد، اما در طول یک اجرا، این خط هرگز نباید خالی بماند.
- مالک ترنسکریپت (Transcript Owner): مسئول آرشیو کردن لاگهای جلسه در کنار پین است، حتی زمانی که لاگها نامرتب و شلوغ باشند. آنها مسئول ذخیره فایل
session.transcript.txtدر کنارpin.jsonهستند. - مالک تداخل (Contention Owner): یک پنجره زمانی روی سرور رایگان اختصاص میدهد و ثبت میکند که چه کسی آن را اشغال کرده است. آنها از استفاده مجدد از باکس برای وظیفه دوم در بازه زمانی اختصاص یافته به شخص دیگر جلوگیری میکنند.
- دروازه ارتقا (Promotion Gate): تصمیم میگیرد که آیا آثار پینشده به سمت بازبینی حرکت کنند یا دور ریخته شوند. آنها باید هرگونه اثر بدون پین را رد کنند.
سازوکار فنی پینینگ
مالکیت در اینجا از طریق یک گیت فنی اجرا میشود. تحویل کار به عنوان یک چکلیست در نظر گرفته میشود، نه یک موضوع در جلسه استندآپ که پس از تماس تلفنی از یاد میرود. شما باید این چهار خط را پیش از شروع کار عامل پر کنید و اگر هر یک از خطوط خالی باشد، از خروجی گرفتن از فایلها خودداری کنید. برای کارآموزان جدید، این نامها باید یک بار با صدای بلند خوانده شوند، زیرا این نامها کل سیستم کنترل هستند.
برای خودکارسازی این روند، راهنما یک اسکریپت کمکی پایتون به نام pin_run.py ارائه میدهد. این اسکریپت یک پیشنهاد محلی است و با هیچ API میزبانی شدهای ارتباط برقرار نمیکند. این اسکریپت مکانیزمهای زیر را اجرا میکند:
- هشینگ (Hashing): از SHA-256 برای هش کردن پوشههای مجموعه پرامپت و مجموعه ورودی استفاده میکند. اسکریپت فایلها را به ترتیب مرتب شده پیمایش کرده و دایجست (Digest) را با مسیرهای نسبی و بایتهای فایل بهروز میکند.
- ثبت محیط (Environment Capture): شناسه git HEAD را از طریق دستور
git rev-parse HEADثبت کرده و نام میزبان سیستم (Hostname) را استخراج میکند. - اعتبارسنجی (Validation): اگر متغیر محیطی
PIN_OWNERموجود نباشد، اسکریپت از نوشتن فایلpin.jsonخودداری کرده و با وضعیت خروجی ۲ (status 2) متوقف میشود. - متادیتا (Metadata): شناسه اجرا (
run_id)، یک برچسب زمانی UTC و پنجره تداخل (مثلاً2026-09-16T14:00Z/2026-09-16T16:00Z) را ثبت میکند.
به کاربران دستور داده شده است که پیش از نوشتن پین، پوشههای پرامپت و ورودی را منجمد (Freeze) کنند؛ ویرایش آنها پس از نوشتن پین ممنوع است. اگر پرامپتها تغییر کنند، به جای اصلاح یک پین فعال، باید یک run-id جدید شروع شود.
گردش کار ارتقا
مرحله ارتقا (Promotion) به عنوان ساعتی مجزا از مرحله تولید در نظر گرفته میشود، حتی زمانی که وصله کوچک است و نویسنده عجله دارد. دروازه ارتقا باید توالی سختگیرانهای را پیش از تحویل Diff به امضاکننده دنبال کند. در این مرحله بحث بر سر سلیقه نیست؛ آنها فقط تصمیم میگیرند که آیا خروجی واجد شرایط بازبینی است یا خیر:
۱. بررسی هویت: باز کردن pin.json و تایید اینکه نام مالک پین با یک شخص واقعی در لیست فعلی ویکی مطابقت دارد.
۲. بررسی یکپارچگی: تایید اینکه هشهای پرامپت و ورودی هنوز با درختهای موجود روی دیسک مطابقت دارند، یا ثبت اینکه درختها جابجا شدهاند.
۳. پاکسازی امنیتی: بررسی سریع ترنسکریپت برای یافتن اسرار (Secrets)، دادههای مشتریان یا لایسنسهایی که کارآموز اجازه چسباندن (Paste) آنها را نداشته است. این مرحله برای جلوگیری از نشت دادهها حیاتی است، مشابه رویکردی که سیستم Doberman با استفاده از ردیابی آلودگی برای جلوگیری از نشت اسرار از عاملهای AI به کار میگیرد.
۴. بررسی محیط: بازپخش یا اجرای مجدد تنها در صورتی انجام شود که پین نشان دهد دسترسی به مدل و پنجره سرور هنوز همان «آشپزخانه» قبلی است.
تنها پس از آنکه دروازه ارتقا عبارت «promote» (ارتقا) یا «discard» (دور ریختن) را روی تیکت نوشت، یک امضاکننده Diff میتواند وصله را بازبینی کند.
مدیریت خطاها و لیست رد
زمانی که اختلافات در مورد ارسال کد یا اجرای مجدد پیش میآید، SOP از یک جدول تصمیمگیری به عنوان ابزاری برای بحث استفاده میکند. این جدول یک کنترل انطباقی نیست، بلکه راهی برای اجتناب از بحثهای مبتنی بر «افسانههای محلی» است. اگر دو ردیف از جدول صدق کنند، تیم باید محافظهکارانهترین اقدام را انتخاب کند.
- فقدان pin.json: خروجی را دور بریزید. Diff را بازبینی نکنید. (اقدام: دروازه ارتقا)
- تطبیق هشها و وجود ترنسکریپت: اجازه بازبینی انسانی Diff را بدهید. (اقدام: ابتدا دروازه ارتقا، سپس امضاکننده Diff)
- عدم تطبیق هشها با درختها: تحت یک run-id جدید مجدداً اجرا کنید یا دور بریزید. (اقدام: مالک پین)
- انقضای پنجره تداخل/استفاده مجدد از سرور: به عنوان غیرقابل تکرار در نظر گرفته و مجدداً اجرا کنید. (اقدام: مالک تداخل)
- وجود اسرار/دادههای مشتری در ترنسکریپت: آثار را حذف کرده و اسرار لو رفته را تغییر دهید (Rotate). (اقدام: مالک ترنسکریپت)
علاوه بر این، تیم باید یک «لیست رد» (Refuse List) را نگهداری کند. خروجیها در موارد زیر رد میشوند: اگر هیچ نام انسانی در PIN_OWNER نباشد، اگر ترنسکریپت پیش از آخرین پیام عامل قطع شده باشد، یا اگر کارهای مربوط به حوادث تولید (Production Incident) روی سرور رایگان مشترک انجام شده باشد.
پیادهسازی فنی: گیت کردن خروجی
برای تضمین رعایت قوانین، راهنما پیشنهاد میکند یک تست فرآیندی ارزانقیمت (مانند test_pin_gate.py) به خط لوله CI اضافه شود. این تست بررسی میکند که آیا دایرکتوری artifacts وجود دارد و تایید میکند که یک فایل pin.json با حجم بیشتر از صفر در کنار آن قرار دارد. این مورد به عنوان یک تست فرآیند برچسبگذاری شده است، نه تست کیفیت محصول، و از تعداد تستهای واحد (Unit Tests) جدا نگه داشته میشود. این کار تضمین میکند که اگر کسی آثار را بدون توقف برای نامگذاری اجرا کپی کند، CI با شکست مواجه شود.
محدودیتهای سیستم
این تشریفات یک یادداشت آزمایشگاهی است، نه یک اثبات رمزنگاریشده. دسترسیهای رایگان به مدل و سرورهای مشترک میتوانند بدون اطلاع قبلی رفتار خود را تغییر دهند، به این معنی که یک هش نمیتواند هر متغیری را ثبت کند. اسکریپت کمکی، مدلهای GPU، کوتاها، نام مدلها یا زمان فعال بودن (Uptime) را ثبت نمیکند، زیرا این ادعاها ساختگی خواهند بود. به دلیل چرخش دیسکها، کپی ترنسکریپت به اندازه هش حیاتی است.
برخی تیمها باید از این تشریفات صرفنظر کنند:
- توسعهدهندگان تکنفره: کسانی که به تنهایی روی یک لپتاپ کار میکنند و میتوانند هر دستوری را از تاریخچه شل (Shell History) بازپخش کنند.
- تیمهای پیشرفته: کسانی که در حال حاضر از ردیابی آزمایش (Experiment Tracking) با هشهای مجموعه داده، اسنپشاتهای محیط اجرا و گیتهای خروجی اجباری استفاده میکنند.
به طور حیاتی، این SOP نباید به عنوان مدرکی در یک ممیزی قانونی (Regulated Audit) استفاده شود و سرور رایگان مشترک نباید برای کارهای حوادث تولید، دادههای مشتری یا الزامات شبکه بسته استفاده شود. یک SOP در ویکی نمیتواند جایگزین یک محیط کنترلشده شود.
این تغییر در تمرینات، استفاده از عاملهای AI را از یک تجربه «جعبه جادویی» به یک گردش کار مهندسی منضبط تبدیل میکند. با نامگذاری یک مالک پین و حفظ یک SOP تکصفحهای که کارآموز واقعاً به آن نگاه کند، صبح دوشنبه به جای تبدیل شدن به یک داستان ترسناک درباره محیطهای ناپدید شده، به یک مسئله بازبینی فنی تبدیل میشود.
افشا: این مقاله به عنوان بخشی از فعالیتهای ترویجی محصولات MonkeyCode تهیه شده است.
گام بعدی شما
- اگر از سرورهای مشترک استفاده میکنید، یک صفحه ویکی ساده برای تعریف نقشهای مالکیت ایجاد کنید.
- اسکریپتهای ثبت هش (SHA-256) را برای ورودیهای مدلهای خود پیادهسازی کنید تا از تغییرات ناخواسته جلوگیری شود.
- یک تست ساده در CI قرار دهید که نبود فایل متادیتای اجرا را به عنوان خطا شناسایی کند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو