سندباکس پایدار شکل کار ایجنت کدنویسی را عوض میکند
بیشتر دموهای ایجنت کدنویسی سال گذشته روی محیط دورریختنی سوار بودند. یک کانتینر بالا بیاور، ریپو را کلون کن، یک دستور بزن، ماشین را بنداز دور. برای بنچمارک باریک یا تولید یکباره کد کافی است. وقتی ایجنت کار مهندسی واقعی میکند میشکند: نصب وابستگی، فهم شکل مونوریپو، تست تکراری، ساخت مصنوع، دیباگ سرور توسعه، و برگشت بعد از مکث.
سندباکس پایدار اعتراف به این است که کار ایجنت وضعیت دارد. نه فقط تاریخچه چت. وضعیت فایلسیستم، مدیر بسته، کش بیلد، فایل تولیدشده، لاگ، نتیجه ابزار، و هویتی که بشود همان محیط اجرا را بعداً ادامه داد. تا وقتی دورش سیستم نسازی کوچک به نظر میرسد.
جزئیات API یک فروشنده را اینجا اصل نگیر. اصل فشار معماری است: محیط اجرا از «این دستور را در جعبه جدا بزن» به «این فضای کاری نامدار را مدیریت کن» عوض میشود. این دو محصول متفاوتاند.
مدل دورریز مفید بود، ولی نشت داشت
سندباکس دورریز مرز تمیز میدهد. نقطه قوتش همین است. کد نامطمئن را اجرا میکنی، شعاع انفجار را محدود میکنی، و وضعیت تصادفی را بین کارها حمل نمیکنی. برای خیلی از بارها دقیقاً همین را میخواهی.
ولی ایجنت کدنویسی بهندرت تابع خالص است. بخش معناداری از وقتش صرف قابل استفاده کردن محیط میشود قبل از اینکه به مسئله اصلی برسد. بسته نصب میکند، کش را گرم میکند، سرویس را بالا میآورد، مهاجرت را روی دیتابیس تست میزند، و یاد میگیرد کدام دستور تست واقعی است و کدام فقط در README آرزو شده.
اگر محیط بعد از هر نشست ناپدید شود، ایجنت همان مالیات را دوباره میدهد. بدتر، طراحی محصول معمولاً با چپاندن زمینه بیشتر داخل پرامپت جبران میکند. مدل رونوشت بزرگتر میگیرد، ولی ماشین همان وضعیت مشخصی را از دست میدهد که کار را تکرارپذیر میکرد.
این معامله غلط است. رونوشت میتواند توضیح دهد چه شد. نمیتواند جایگزین فایلسیستمی شود که هنوز خروجی تست شکستخورده، فیکسچر تولیدشده، یا درخت بستهای را دارد که ایجنت واقعاً استفاده کرد.
هویت مهمتر از خود ذخیره است
وقتی محیط نام پایدار دارد، بقیه سیستم میتواند دربارهاش حرف بزند. در UI مدیریت نشانش بدهی، با سیاست نگهداری پاکش کنی، با برچسب مستأجر جدا کنی، و وقتی کاربر برگشت ادامهاش بدهی. سندباکس از اجراکننده پنهان دستور به منبعی تبدیل میشود که اپ مالکش است.
ابزارهایی که دور این مدل جمع شدهاند، مثل گرفتن یا ساختن، انشعاب، حذف، قلاب ازسرگیری، و برچسب، به همین درد میخورند. بدون نام، اینها میانبر اسکریپتاند. با نام، چرخه عمر محصولاند.
قبل از تکیه به رفتار پیشفرض یک SDK، در کد خودت بنویس این اجرا کدام کلاس است. پیشفرض راحت پلتفرم نباید سیاست نگهداری تو باشد.
پایداری حافظه محصول نیست
اینجا تیمها اگر حواسشان نباشد شل میشوند. سندباکس پایدار حافظه ایجنت به معنای محصول نیست. نباید انباری بیسقف شود برای هر فکر، راز، وابستگی، و آزمایش شکستخورده. پایداری فایلسیستم وضعیت عملیاتی مشخص است. حافظه، دانش انتخابشدهای است که باید رفتار بعدی را عوض کند. این دو قاعده جدا میخواهند.
نگه داشتن `node_modules`، یک SQLite تولیدشده، مصنوع تست شکستخورده، و کش بیلد داخل اسنپشات میتواند معقول باشد. نگه داشتن یادداشت مبهمی مثل «سیستم احراز هویت عجیب است» بهعنوان حافظه پایدار محصول، مگر اینکه محدود و به شواهد بسته شود، از بیفایده بدتر است.
برعکسش هم درست است. حافظه کوتاه ریپو، مثل «مسیر API زیر `src/server/routes` است نه `app/api`»، لازم نیست فایل متنی تصادفی داخل سندباکس باشد. سندباکس را وضعیت ازسرگیری حساب کن. حافظه را قضاوت قابل استفاده دوباره. قاطی کردنشان سیستمی میسازد که سخت بازرسی میشود و سختتر اعتماد.
هزینه جزو طراحی است
اسنپشات خودکار ذخیره جدا از محاسبه مصرف میکند. این جزئیات باید شکل ساختن را عوض کند. پایدار بهصورت پیشفرض برای کار طولانی یا چندبار ازسرگیریشده خوب است. برای هر وظیفه ایجنت خودبهخود خوب نیست.
اگر کار فقط محیط تمیز میخواهد تا یک وصله را lint کند و نتیجه را برگرداند، پایداری ممکن است دورریز باشد. اگر کار داده حساس مشتری را لمس میکند یا مصنوع عظیم میسازد، پایداری بیسروصدا مسئله پاکسازی میشود.
بار را حداقل به سه کلاس جدا کن و این جداسازی را در کد صریح کن:
- بررسی دورریز، که سندباکس نباید پایدار بماند.
- تحقیق قابل ازسرگیری، که پایداری برای ساعتها یا چند روز مفید است.
- فضای کاری بلندمدت، که پایداری عمدی است و مالک، نگهداری، و حسابرسی دارد.
هر اجرا را به ارث پیشفرض یکسان نگذار چون مسیر آسان SDK همان بوده.
انشعاب ویژگی خوابآلود است
انشعاب از یک محیط گرم ممکن است به اندازه خود پایداری مهم شود. ایجنت اغلب باید بدون تعهد به یک مسیر جستجو کند. یک شاخه اصلاح حداقلی را امتحان میکند. یکی وابستگی را بالا میبرد. یکی کامپوننت را از نو مینویسد. در مدل پایدار، محیط گرم میتواند پایه آزمایش کنترلشده باشد.
ریسک این است که انشعاب را بهجای سیاست، جادو نشان بدهی. انشعاب اسم، نسب، پاکسازی، و قاعده ارتقای مصنوع به اجرای اصلی میخواهد. وگرنه تودهای از اسنپشات گران داری و اطمینانی نداری کدامیک diff نهایی را ساخته.
چرخه اجرا را قبل از پرامپت بنویس
اگر این را داخل محصول ایجنت کدنویسی میساختم از پرامپت مدل شروع نمیکردم. از چرخه اجرا شروع میکردم. سندباکس باید در سیستم جا داشته باشد، نه جزئیات پنهان پیادهسازی.
چند قاعده کسلکننده کافی است. هر سندباکس پایدار مالک، هدف، و انقضا دارد. هر اجرا دستورهایی را که وضعیت فایلسیستم را عوض کردهاند ثبت میکند. راز در لحظه اجرا تزریق میشود، نه اینکه داخل فایل پایدار نوشته شود. مصنوع بزرگ یا عمداً ارتقا پیدا میکند یا قبل از اسنپشات حذف میشود. بررسی ساده پیشفرضش حالت ناپایدار است. نشست ازسرگیریشده قبل از ادامه، وضعیت ریپو را با چیزی که انتظار داری مقابله میکند.
هیچکدام از اینها درخشان نیست. فرق دمویی است که دو بار کار میکند با سیستمی که تیم میتواند عملیاتی کند.
پایداری هیجانانگیز نیست چون یک `npm install` را ذخیره میکند. هیجانانگیز است چون به کار ایجنت یک جای پایدار میدهد. ایجنت دیگر فقط یک فراخوانی مدل با ابزار نیست. کارگری است داخل محیط نامدار، با وضعیت، هزینه، ریسک، و چرخه عمر. از این زاویه روشن میشود چه چیز بماند، چه چیز دور ریخته شود، چه چیز تأیید بخواهد، چه چیز حسابرسی بخواهد، و چه چیز باید پاک شود.
پاسخ عاقلانه این نیست که هر سندباکس تا ابد پایدار بماند. پایداری را یک اولیه معماری حساب کن. برای تحقیق، کار توسعه قابل ازسرگیری، و گردش کار چندمرحلهای که خود محیط پیشرفت مفید را نگه میدارد روشن کن. برای بررسی دورریز خاموش کن. وقتی جستجو ارزانتر از بحث با طرح است منشعب کن. وقتی کارش تمام شد حذف کن.
پرسشهای کوتاه
**همه ایجنتهای کدنویسی باید سندباکس پایدار داشته باشند؟** نه. بررسی یکباره را دور بریز. پایداری را برای کاری بگذار که برگشت به همان درخت فایل ارزش دارد.
**راز را در اسنپشات ذخیره کنم؟** نه. تزریق در زمان اجرا. اسنپشات را طوری حساب کن که ممکن است دیرتر کسی غیر از همان نشست بازش کند.
**انشعاب را به کاربر نشان بدهم؟** فقط اگر اسم، نسب، و قاعده حذف دارد. انشعاب بینام صورتحساب است نه قابلیت.