ساخت کارخانه نرم‌افزاری خودکار با سخت‌افزار خانگی و محیط ایزوله

تصور کنید یک اپلیکیشن کامل، تنها با یک پرامپت ساخته، تست و روی سرور زنده مستقر شود، بدون اینکه دست شما حتی یک بار روی کیبورد برود. توسعه‌دهنده‌ای به نام جیک ساندرز (Jake Saunders) جزئیات ساخت این «کارخانه نرم‌افزاری» را منتشر کرد؛ سیستمی که از ترکیبی از ابزارهای میزبانی شخصی و یک محیط ایزوله (Sandboxed) استفاده می‌کند تا خطر دادن دسترسی ریشه (Root) مدل زبانی به ماشین اصلی‌اش را کاملاً از بین ببرد.

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

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

زیرساخت سخت‌افزاری

به نقل از مستندات ساندرز، او برای ایجاد این محیط ایزوله از یک سرور i7 نسل ۱۰ مدل ۲۰۲۱ با ۳۲ گیگابایت رم استفاده کرد که آن را از eBay خریده بود. هدف اصلی این بود که پتانسیل تخریبی عامل هوش مصنوعی از آزمایشگاه خانگی اصلی او کاملاً جدا شود.

آزمایشگاه اصلی او شامل یک سرور i3 دو هسته‌ای مدل ۲۰۱۴ است که پنج سال است بدون وقفه در حال اجراست. این ماشین قدیمی اما وفادار، وبلاگ او و حدود ۴۵ کانتینر داکر (Docker) دیگر را میزبانی می‌کند؛ ابزارهایی که طیفی از Pi-hole تا یک پشته کامل شامل Prometheus، Loki و Grafana را در بر می‌گیرند. از آنجایی که سرور i3 دارای پورت ۴۴۳ است که از طریق روتر فوروارد شده است، ساندرز تشخیص داد که اجازه دادن به یک مدل زبانی برای دسترسی به آن بسیار خطرناک است. بنابراین، سرور i7 خریداری شده از eBay یک صفحه سفید و پاک فراهم کرد تا عامل بتواند بدون ریسک برای زیرساخت‌های موجود، فعالیت کند. در حالی که ساندرز بر میزبانی شخصی تأکید دارد، برخی تحلیل‌ها نشان می‌دهند که جایگزینی سخت‌افزار محلی با APIها می‌تواند هزینه‌های پردازش هوش مصنوعی را تا ۷۰٪ کاهش دهد.

پشته نرم‌افزاری

معماری این سیستم بر پایه Coolify است؛ یک پلتفرم سرویس (PaaS) میزبانی شخصی که بر روی داکر و Compose ساخته شده و تجربه‌ای شبیه به استقرار در Heroku را فراهم می‌کند. اجزای اصلی این پشته عبارتند از:

• Hermes: یک دستیار مجازی به سبک OpenClaw که نقش مغز عامل را ایفا می‌کند. این دستیار برای استنتاج (Inference) از Codex استفاده می‌کند (که هزینه اشتراک آن ۲۰ پوند است). Hermes دارای یک رابط کاربری وب شبیه به ChatGPT، یک سیستم فایل مشترک که از طریق Samba از میزبان داکر مونت شده و همچنین یک اتصال به تلگرام برای کنترل از راه دور است. این ساختار به ساندرز اجازه می‌دهد از طریق گوشی خود با عامل چت کند؛ سیستمی که راه‌اندازی آن تنها دو دقیقه زمان برد و به هیچ جزئیات لاگینی نیاز نداشت.
• Forgejo: یک جایگزین خودمیزبانی شده برای گیت (Git) که ذخیره کدها و اجرای خط لوله‌های CI (یکپارچه‌سازی مداوم) را مدیریت می‌کند. ساندرز Forgejo را به گیت‌هاب ترجیح داد تا مجبور نباشد توکن گیت‌هاب خود را به محیط ایزوله بدهد و همچنین محدودیت‌های API و دقایق CI گیت‌هاب را دور بزند. او همچنین یک فایل Compose برای همگام‌سازی پروژه‌ها با گیت‌هاب اضافه کرد، هرچند این کار مستلزم قرار دادن توکن GH در محیط است.
• Firecrawl: یک لایه استخراج داده (Scraping) و ترجمه خودمیزبانی شده که به عامل اجازه می‌دهد به داده‌های SERP (نتایج موتور جستجو) و وب‌اسکرپینگ در مقیاس بالا دسترسی داشته باشد. این ابزار دسترسی بسیار تمیزتری به وب را نسبت به پرامپت‌های استاندارد فراهم می‌کند.
• Tailscale: یک لایه شبکه که باعث می‌شود شبکه خانگی کاربر را دنبال کند و دسترسی امن به اپلیکیشن‌های داخلی را از هر مکانی ممکن سازد.
• Pi-hole: برای مدیریت قوانین DNS محلی جهت کاهش تبلیغات و مدیریت مسیریابی داخلی.
• Porkbun و Let’s Encrypt: برای ثبت دامنه و دریافت گواهینامه‌های SSL آنی و خودکار.
• لایه دیتابیس: سیستم می‌تواند بسته به نیاز اپلیکیشن، سرویس‌های Postgres، Redis یا هر سرویس مبتنی بر داکر دیگری را ایجاد و تخصیص دهد.

حفاظ‌ها و شبکه

اولین حفاظ کاملاً فیزیکی است: عامل روی سخت‌افزار مجزای خود قرار دارد. اگر Hermes دستور تخریبی مانند rm -rf / را اجرا کند، تنها هزینه آن چند ساعت زمان برای بازسازی سرور است.

برای کاهش بیشتر سطح حمله، سرور جدید هیچ ورودی خارجی (External Ingress) ندارد. برخلاف سرور قدیمی، پورت ۴۴۳ در این ماشین از طریق روتر فوروارد نشده است. این اقدام باعث می‌شود «تابش پس‌زمینه اینترنت» — یعنی بات‌هایی که مدام در جستجوی مسیرهایی مثل /wp-admin روی هر رکورد DNS A هستند — کاملاً حذف شود.

ساندرز برای دسترسی به اپلیکیشن‌ها از Tailscale استفاده می‌کند و سرور قدیمی را به عنوان Exit Node قرار داده است. او Pi-hole را با یک قانون dnsmasq سفارشی پیکربندی کرد: address=/internal.jakeshomelab.me/192.168.1.201. این تنظیم تضمین می‌کند که هر درخواستی برای *.internal.jakeshomelab.me به سرور جدید هدایت شود و در آنجا پروکسی معکوس Coolify ترافیک را مدیریت کند.

حل معمای SSL برای سرویس‌های شبحی

یکی از اصلی‌ترین چالش‌های فنی، تولید گواهینامه‌های SSL معتبر برای سرویس‌هایی بود که هیچ IP عمومی ندارند. ساندرز می‌خواست URLهای HTTPS معتبری داشته باشد که در شبکه Tailnet او قابل دسترسی باشند، بدون اینکه سرویس را از طریق یک رکورد A عمومی به IP خود متصل کند و آن را لو دهد. او در واقع به دنبال گواهینامه SSL برای یک «سرویس شبح» بود.

او یک چالش DNS-01 را با استفاده از API شرکت Porkbun و ابزار lego در پروکسی معکوس Traefik پیاده‌سازی کرد. مکانیزم این فرآیند به شرح زیر است:

• کلیدهای API شرکت Porkbun با دسترسی نوشتن به دامنه، در محیط Coolify اضافه می‌شوند.
• فایل Docker Compose در Coolify تغییر می‌کند تا از lego با پروایدر Porkbun استفاده کند. به طور مشخص، از فلگ‌هایی مانند --certificatesresolvers.letsencrypt.acme.dnschallenge=true و --certificatesresolvers.letsencrypt.acme.dnschallenge.provider=porkbun و --log.level=INFO استفاده می‌شود.
• هنگامی که یک URL جدید ثبت می‌شود، Traefik از طریق API یک رکورد TXT موقت در مسیر _acme-challenge.my-service.internal.jakeshomelab.me ایجاد می‌کند.
• سرویس Let’s Encrypt این چالش را تایید کرده و گواهینامه SSL را صادر می‌کند.
• در نهایت، Traefik رکورد TXT را حذف می‌کند.

این روش اجازه می‌دهد عامل هر تعداد ساب‌دومین بسازد و آن‌ها را به صورت «جادویی» با HTTPS فعال کند، در حالی که سرویس‌ها برای اینترنت عمومی نامرئی می‌مانند. اگرچه نام میزبان ممکن است در لاگ‌های شفافیت گواهینامه (Certificate Transparency Logs) ظاهر شود، اما سرویس فقط از طریق Tailnet قابل دسترسی است.

گردش‌کار خودمختار

برای تست سیستم، ساندرز از عامل خواست یک اپلیکیشن ردیابی کالری بسازد. پرامپت او مشخص می‌کرد که این یک اپلیکیشن Full-stack با SvelteKit باشد و از Drizzle و Postgres برای لایه دیتابیس، Tailwind برای CSS و طراحی موبایل‌محور استفاده کند. او به عامل دستور داد برنامه را بسازد، آن را در یک مخزن جدید به همراه تست‌ها کامیت کند، از CI عبور دهد و در نهایت روی http://calories.internal.jakeshomelab.me با استفاده از Docker Compose مستقر کند.

عامل مراحل زیر را به‌طور کاملاً خودمختار اجرا کرد:

۱. تحقیق و راه‌اندازی: ایجاد ساختار اولیه مخزن و نصب پشته درخواستی. او حتی با خواندن مستندات و بررسی MCP، مهارت استفاده از Coolify را برای خودش ساخت.
۲. توسعه: نوشتن منطق اپلیکیشن و تست‌های مربوطه و کامیت کردن کدها در مراحل منطقی.
۳. CI/CD: پیکربندی خط لوله CI در Forgejo.
۴. تکرار: کار روی خطاهای تست به‌صورت مستقل تا زمانی که خط لوله CI سبز شود. این مرحله حیاتی است، زیرا همان‌طور که در بررسی‌های ما مشخص شد، شکست لایه گزارش‌دهی و عدم توجه به کدهای خروجی (Exit Codes) یکی از دلایلی است که بسیاری از عامل‌های کدنویس در مقیاس واقعی متوقف می‌شوند.
۵. کانتینرسازی: ایجاد فایل Docker Compose برای اپلیکیشن و یک نمونه Postgres اختصاصی.
۶. استقرار: مستقر کردن کل پشته در Coolify روی URL مشخص شده.

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

امنیت و جداسازی

با وجود محیط ایزوله، ساندرز اشاره می‌کند که عامل همچنان توانایی‌های خطرناکی دارد. به دلیل کنترل عاملانه (Agentic Control)، Hermes می‌تواند:

• سرور جدید و تمام کانتینرهای در حال اجرا روی آن را نابود کند.
• مخازن کد، دیتابیس‌ها و استقرارهای فعال را حذف کند.
• هرگونه اعتبارنامه API ارائه شده را لو دهد یا سوءاستفاده کند.
• توکن‌های استنتاج را با سرعت بسیار زیاد مصرف کند.
• درخواست‌های تصادفی به بیرون بفرستد و محتوای غیرقابل اعتماد را از وب دانلود کند.
• دستگاه‌های دیگر در شبکه خانگی را که فایروال اجازه دسترسی به آن‌ها را می‌دهد، رصد کند.

مدل امنیتی فعلی بر پایه «سخت‌افزار قربانی» است. در اینجا حالت شکست از «یک LLM که لپ‌تاپ واقعی من را بازسازماندهی می‌کند» به «بازسازی یک جعبه eBay و تغییر چند کلید API» تغییر یافته است.

گام‌های بعدی برای سخت‌سازی

برای عبور از مرحله پروتوتایپ، ساندرز چندین بهبود زیرساختی را شناسایی کرده است:

• بخش‌بندی شبکه (Network Segmentation): قرار دادن سرور در یک VLAN مجزا برای مسدود کردن صریح دسترسی به سایر بخش‌های شبکه خانگی.
• محدود کردن اعتبارنامه‌ها: کاهش دامنه دسترسی هر کلید API و پیاده‌سازی چرخش (Rotation) منظم آن‌ها.
• اتوماسیون بازیابی: استفاده از بک‌آپ‌های دیتابیس Coolify در S3 و مونت‌های مشترک Docker Compose برای تبدیل بازسازی کل سرور به یک عملیات تک‌مرحله‌ای.
• درگاه‌های تایید (Approval Gates): ایجاد الزامی برای تایید انسانی قبل از اینکه عامل اقداماتی انجام دهد که واقعاً عمومی هستند یا بازگرداندن آن‌ها دشوار است.

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

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

اگر می‌خواهید این سیستم را بازسازی کنید، پیشنهاد می‌شود با بررسی مستندات Coolify شروع کنید و یک ماشین اختصاصی تهیه کنید تا ریسک دسترسی به سیستم‌عامل اصلی خود را از بین ببرید.

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