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

یک عامل کدنویسی می‌تواند تمام تست‌ها را در یک کانتینر موقت پاس کند، اما همچنان وب‌سایت تولیدی (Production) شما را به‌کل از کار بیندازد. این هشدار محوریت یک تحلیل فنی عمیق در ۳۰ جولای ۲۰۲۶ در وب‌سایت dev.to بود که نشان داد وسواس صنعت روی سندباکس کردن، جایگزینی خطرناک برای معیار واقعی «صحت نرم‌افزار» است.

بسیاری از زیرساخت‌های فعلی، کانتینرسازی را خط پایان می‌بینند. توسعه‌دهندگان عامل را در یک سندباکس (Sandbox) — شبیه به یک اتاق آزمایش بسته و ایزوله که هر اتفاقی در آن بیفتد به بیرون آسیب نمی‌زند — قرار می‌دهند، دسترسی‌هایش را محدود می‌کنند و در نهایت آن را نابود می‌کنند. طبق اعلام نویسندگان این تحلیل، این روش مانع از پاک شدن فایل‌های لپ‌تاپ یا نشت داده‌های یک تکلیف به تکلیف دیگر در سیستم فایل می‌شود، اما نمی‌تواند ثابت کند که خروجی بازتولیدپذیر است، تست‌ها واقعاً رفتار موردنظر را سنجیده‌اند یا اینکه یک صفحه به‌درستی رندر شده است. ایزولاسیون فقط به این سؤال پاسخ می‌دهد که «کار کجا اجرا شده و چه چیزهایی را اجازه داشت تغییر دهد»، اما صحت (Correctness) به این پاسخ می‌دهد که «چه رفتاری واقعاً تغییر کرده و چه مدرکی ادعای درست بودن این تغییر را پشتیبانی می‌کند».

برای عبور از این بن‌بست، توسعه‌دهندگان در حال پذیرش چارچوب «محیط اثباتی» (Proof Environment) هستند. این یک چرخش استراتژیک از «صرفاً جلوگیری از آسیب» به «اثبات فعال موفقیت» از طریق بسته‌های مستنداتی است. البته سندباکس‌ها همچنان کاربردی‌اند چون اجرای عامل‌ها ذاتاً هرج‌ومرج‌زاست. تکالیف واقع‌بینانه اغلب نیاز به نصب وابستگی‌ها، راه‌اندازی سرویس‌ها، تغییر دیتابیس‌ها، باز کردن مرورگرها، ایجاد فایل‌ها و اشغال پورت‌ها دارند. بدون ایزولاسیون، دو عامل که وضعیت (State) مشترک دارند می‌توانند به گونه‌ای در هم تداخل کنند که بازتولید آن دشوار باشد، یا یک آزمایش شکست‌خورده می‌تواند تلاش بعدی را مسموم کند. در این راستا، برخی تحلیل‌ها نشان می‌دهند که استفاده از محیط‌های محلی در برابر ابری می‌تواند تأخیر در اجرای عامل‌های تک‌کاربره را به شدت کاهش دهد. پروژه‌هایی مانند Agent-Sandbox مدیریت صریح چرخهٔ حیات جلسات ایزوله برای کد، شل (Shell)، مرورگر و کامپیوتر را فراهم می‌کنند. برخی مباحث پیرامون «محیط‌های فورک‌شدنی» (Forkable Environments) این ایده را فراتر برده و وضعیت کامل سیستم را پیش از اجرای تست‌های تخریبی یا پیاده‌سازی‌های رقیب، تکثیر می‌کنند.

لایه‌ی وضعیت بازتولیدپذیر

پیش از آنکه یک عامل (Agent) — مانند دستیاری هوشمند که می‌تواند به‌جای شما کد بزند و ابزارها را اجرا کند — بتواند اصلاحی را اثبات کند، محیط باید یک هویت قابل تأیید داشته باشد. ادعای «در سندباکس پاس شد» اگر کسی نداند داخل آن سندباکس چه بوده، ضعیف و بی‌ارزش است. یک محیط اثباتی واقعی، نشانگرهای دقیق زیر را برای بازسازی اجرا ثبت می‌کند:

• کامیت مخزن (Repository commit) و وضعیت درخت تغییرات (Dirty-tree status)
• فایل‌های قفل وابستگی‌ها (Lockfiles) و نسخه‌ی ایمیج‌های پایه
• نسخه‌های نصب‌شده‌ی ابزار زنجیره تولید (Toolchain)
• داده‌های اولیه (Fixtures)، داده‌های Seed و نسخه‌ی سرویس‌ها
• ورودی‌های محیطی مرتبط (با حذف و سانسور رمزها)
• اندازه نمایشگر (Viewport)، پروفایل‌های دستگاه و وضعیت مرورگر
• پرامپت دقیق تکلیف یا معیارهای پذیرش (Acceptance Criteria)

بازتولید فایل‌های منبع از طریق git worktrees ساده است، اما وضعیت برنامه (Application State) سخت‌تر بازسازی می‌شود. یک worktree نمی‌تواند یک جلسه لاگین‌شده، یک دیتابیس پر شده، یک صف در حافظه یا یک جریان چندمرحله‌ای نیمه‌تمام را ثبت کند. به همین دلیل «فورک‌های سطح محیط» حیاتی می‌شوند. آن‌ها اجازه می‌دهند دو تلاش مختلف از یک عامل، به‌جای شروع از یک کامیت یکسان، دقیقاً از یک وضعیت برنامه‌ای یکسان آغاز شوند. اگر نقاط شروع متفاوت باشند، مقایسه اجرای عامل‌ها صرفاً یک «نمایش» است؛ زیرا شما نمی‌توانید بفهمید که آیا یک پچ، یک داده‌ی اولیه یا یک فرآیند باقی‌مانده باعث نتیجه شده است. هویت محیط باید همراه با خروجی جابجا شود تا بازبین‌ها مجبور نباشند آن را از طریق لاگ‌های CI مهندسی معکوس کنند.

اوراکل رفتاری

عامل‌ها در پاس کردن چک‌های ظاهری بسیار مهارت دارند که ریسک «تغییر خط پایان» (Goalpost Moving) را ایجاد می‌کند. تصور کنید تکلیف این باشد: «فرم را باز نگه دار و هنگام شکست پرداخت، خطای درون-خطی نشان بده». عامل ممکن است کامپوننت را تغییر دهد، یک مدل تقلیدی (Mock) را به‌روز کند و حتی تست را بازنویسی کند. سپس گزارش می‌دهد که تایپ‌چک، تست‌های واحد و بیلد همگی پاس شده‌اند. با این حال، ممکن است صفحه همچنان در صورت شکست ریدایرکت شود یا مدل تقلیدی هرگز شاخه شکست (Failure Branch) را اجرا نکند. در این سناریو، عامل دروغ نگفته است؛ بلکه خودش را با یک قرارداد ضعیف بهینه کرده است.

برای مقابله، محیط به یک اوراکل رفتاری (Behavioral Oracle) نیاز دارد؛ تعریفی از موفقیت برای هر تکلیف که مستقل از پیاده‌سازی عامل باشد. این رویکرد شباهت زیادی به سازوکارهای درگاه اعتبارسنجی در darwin-agents دارد که برای مهار «لغزش» عامل‌های هوشمند و تضمین انطباق با اهداف اولیه طراحی شده‌اند. این بخش دشوار ماجراست: عامل نباید اجازه داشته باشد هنگام اجرای تکلیف، تعریف موفقیت را هم تغییر دهد. اگر عامل یک تست پذیرش را تغییر دهد، آن تغییر باید تحت بررسی جداگانه قرار گیرد.

نمونه‌های اوراکل عبارتند از:

• تغییرات API: ورودی و خروجی‌های طلایی (Golden) جفت‌شده با چک‌های مربوط به اثرات جانبی.
• مهاجرت‌ها (Migrations): شمای قبل و بعد، داده‌های نماینده و یک اجرای بازگشتی (Rollback) برای اطمینان.
• تکالیف فرانت‌اند: گام‌های تعامل صریح، متن‌های قابل مشاهده، وضعیت دسترسی‌پذیری (Accessibility)، رفتار ریسپانسیو، خطاهای کنسول و درخواست‌های شبکه.

تست‌های طلایی (Golden Tests) ریسک خاص خود را دارند، زیرا ممکن است رفتاری را حفظ کنند که از قبل اشتباه بوده است. آن‌ها باید به عنوان قفلی روی رفتارهای شناخته‌شده تلقی شوند، نه جایگزینی برای تصمیم‌گیری درباره اینکه تکلیف واقعاً باید چه هدفی را محقق کند.

مدرک به‌جای خروجی

جمع‌آوری اسکرین‌شات یا لاگ، به معنای قضاوت درباره آن‌ها نیست. اسکرین‌شات ثابت می‌کند پیکسل‌ها ظاهر شده‌اند، اما ثابت نمی‌کند که آن‌ها با مشخصات طراحی مطابقت دارند. یک Trace ثابت می‌کند رویدادها رخ داده‌اند، اما نه اینکه سفر کاربر (User Journey) درست تکمیل شده است. یک کنسول پاک (Clean) اطلاعات کمی درباره یک خطای داده‌ای خاموش در بک‌اند می‌دهد. ابزارهایی مثل agent-browser و agent-sandbox اکنون امکان جمع‌آوری مستندات غنی‌تری را می‌دهند، از جمله: اسنپ‌شات‌های دسترسی‌پذیری، اسکرین‌شات‌ها، Diffهای پیکسلی، Traceها، پیام‌های کنسول، خطاهای صفحه، بازرسی شبکه، شبیه‌ساز دستگاه و وضعیت ذخیره شده جلسه.

اثبات واقعی تنها زمانی رخ می‌دهد که این مستندات با یک نتیجه مورد انتظار جفت شوند. مثلاً برای کاربری با کارت منقضی‌شده که فرم پرداخت را ارسال می‌کند، اثبات نیازمند نتایج زیر است:

• صفحه در مسیر /checkout باقی بماند
• خطای درون-خطی قابل مشاهده باشد
• تمرکز (Focus) روی خلاصه خطا قرار بگیرد
• هیچ سفارشی در بک‌اند ایجاد نشود
• شکست پرداخت دقیقاً یک‌بار لاگ شود

در این سناریو، هر اسکرین‌شات، اسنپ‌شات دسترسی‌پذیری و لاگ شبکه به یک سؤال خاص پاسخ می‌دهد. «اثبات»، رابطه میان قرارداد و این مستندات است، نه تودهٔ خودِ فایل‌ها.

قرارداد چهارلایه

برای تضمین قابلیت اطمینان، چارچوب‌های عامل‌محور باید استراتژی چهارلایه زیر را اجرا کنند:

۱. وضعیت بازتولیدپذیر: شناسایی منبع، وابستگی‌ها، داده‌ها، سرویس‌ها، جلسه مرورگر و قرارداد تکلیف تا اجراهای مجدد معنا‌دار باشند.
۲. ایزولاسیون: اختصاص فرآیندها، سیستم فایل، پورت‌ها و وضعیت مرورگر مجزا برای هر تکلیف. محدود کردن دسترسی‌ها و دسترسی خارجی به‌صورت جداگانه؛ چراکه یک سندباکس به‌طور خودکار اثرات جانبی خروجی (Outbound side effects) را ایمن نمی‌کند. در همین راستا، بررسی جداسازی حافظه در Letta اهمیت این موضوع را در جلوگیری از تداخل اطلاعاتی میان جلسات مختلف عامل برجسته می‌کند.
۳. اوراکل رفتاری: تعریف نتایج مورد انتظار خارج از پیاده‌سازی با استفاده از ورودی‌های طلایی، توأیدی‌های UI (Assertions)، ناورداها (Invariants) یا چک‌های دامنه.
۴. مدرک قابل بررسی: بازگرداندن بسته‌ای از دستورات، Diffها، چک‌ها، شکست‌ها، اسکرین‌شات‌ها، Traceها و لاگ‌ها تا دیگران بتوانند با نتایج مخالفت کنند.

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

بسته مدرک (Evidence Bundle)

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

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

• هویت محیط و ریویسیون شروع
• دستورات دقیق، کدهای خروجی (Exit codes) و چک‌های شکست‌خورده
• Diff نهایی کد منبع
• نتایج تست‌های متصل به معیارهای پذیرش نام‌گذاری‌شده
• اسکرین‌شات‌ها یا Diffهای بصری برای وضعیت‌های مربوط به UI
• Traceهای مرورگر، خروجی کنسول و خطاهای صفحه
• لاگ‌های شبکه یا بک‌اند برای رفتارهایی که از مرز سرویس‌ها عبور می‌کنند
• هرگونه تغییر در تست‌ها، Mockها، Fixtureها یا خط‌کشی‌های پایه (Baselines)
• تصمیم مربوط به پاک‌سازی یا نگهداری محیط

نگهداری شکست‌ها در بسته ضروری است. یک چک End-to-End متزلزل (Flaky) که در تلاش مجدد پاس شده، یا یک نمای موبایل که به‌دلیل عدم استارت سرویس نادیده گرفته شده، هر دو بخشی از نتیجه هستند. حذف شواهد نامناسب، یک گزارش فنی را به یک بروشور تبلیغاتی تبدیل می‌کند.

این چرخش، سؤال بنیادین کدنویسی با هوش مصنوعی را تغییر می‌دهد. به‌جای اینکه بپرسیم «آیا عامل ایمن اجرا شد؟»، مهندسان باید بپرسند «آیا فرد دیگری می‌تواند به‌طور مستقل آنچه را که عامل اثبات کرده، تأیید کند؟». برای اجرای این مسیر، تیم‌ها می‌توانند با افزودن یک مانیفست محیط به اجرا، نگه داشتن معیارهای پذیرش خارج از پچ‌های تولیدشده، ذخیره Traceهای مرورگر برای تغییرات UI و پیوست کردن بسته کامل مدرک به Pull Request شروع کنند.

گام بعدی شما

• به جای پذیرش پیام‌های «موفقیت» از عامل، یک بسته مدرک (Evidence Bundle) شامل Diffها، لاگ‌های شبکه و اسکرین‌شات‌های تأیین‌شده بخواهید.
• معیارهای پذیرش (Acceptance Criteria) را خارج از پچ‌های تولیدشده توسط مدل نگه دارید تا عامل نتواند تعریف موفقیت را تغییر دهد.
• از ابزارهایی برای ثبت وضعیت کامل محیط (Environment Identity) استفاده کنید تا بازبینی کد از حالت حدس و گمان خارج شود.

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