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

تصور کنید یک عامل هوش مصنوعی در حال تست کردن اپلیکیشن شما در شبیه‌ساز iOS است، اما شما همچنان می‌توانید با لپ‌تاپ خود به راحتی کار کنید و حتی آن را ببندید. این همان تجربه‌ای است که یک توسعه‌دهنده با جداسازی محیط اجرای عامل‌ها از دستگاه اصلی به دست آورده است. این چیدمان شامل یک مک‌بوک پرو M4 Pro است که در یک سرور خانگی ترکیبی از لینوکس و مک ادغام شده است. این ساختار به توسعه‌دهنده اجازه داد تا سنگین‌ترین بخش‌های جریان‌های کاری عامل‌های هوش مصنوعی را به یک گره macOS از راه دور منتقل کند. به این ترتیب، او توانست کارهای مربوط به بیلد (Build) iOS و تست‌های شبیه‌ساز را به یک عامل بسپارد، بدون اینکه ایستگاه کاری اصلی‌اش قفل شود یا کند شود.

این تغییر، یک نقطه اصطکاک رایج در توسعه مدرن با کمک هوش مصنوعی را هدف قرار می‌دهد. در حالی که لینوکس اغلب محیط ترجیحی برای کارهای کدنویسی غیرهمزمان (Asynchronous) است، توسعه موبایل برای پلتفرم‌های اپل مستلزم داشتن macOS است. اکثر توسعه‌دهندگان معمولاً این تسک‌ها را روی لپ‌تاپ اصلی خود اجرا می‌کنند. این کار باعث مصرف شدید رم (RAM) می‌شود و مانع از آن می‌شود که دستگاه در طول جلسات طولانی که توسط عامل‌ها مدیریت می‌شود، به حالت خواب (Sleep) برود.

به گزارش وب‌سایت dev.to در ۱۰ اکتبر ۲۰۲۶، این برنامه‌نویس از استفاده از یک مک‌بوک ایر به عنوان هم کلاینت و هم ماشین بیلد، به یک معماری سه‌لایه تغییر وضعیت داد. در این ساختار جدید، یک کیس لینوکس مسئول مدیریت مخازن کد (Repositories) و کارهای برنامه‌نویسی کلی است، یک مک از راه دور وظیفه مدیریت رابط کاربری (GUI) و محیط iOS را بر عهده دارد و مک‌بوک ایر کاربر صرفاً به عنوان یک کلاینت سبک (Thin Client) برای هدایت و بازبینی عمل می‌کند. این رویکرد یادآور تجربه‌های مشابهی است که توسعه‌دهندگان دیگر برای ساخت سریع اپلیکیشن‌های مک با کمک ابزارهای کدنویسی هوش مصنوعی به کار گرفته‌اند تا سرعت توسعه را افزایش دهند.

زمینه: تکامل آزمایشگاه خانگی (Home Lab)

این ترتیب سخت‌افزاری یک‌باره اتفاق نیفتاد. همه چیز با تبدیل یک کامپیوتر قدیمی گیمینگ به یک ماشین توسعه اوبونتو (Ubuntu) شروع شد. این باکس لینوکسی به قطب مخازن، سرویس‌های توسعه و عامل‌های کدنویسی تبدیل شد. در این مرحله، مک‌بوک ایر به نقش کلاینت تنزل یافت. این تغییر به توسعه‌دهنده اجازه داد تا تسکی را به عامل بدهد و درب لپ‌تاپ را ببندد، در حالی که محیط توسعه در خانه همچنان در حال اجرا بود.

این جریان کاری مجزا (Decoupled)، تحرک قابل توجهی ایجاد کرد. توسعه‌دهنده می‌توانست از طریق یک گوشی اندروید در یک رستوران، درخواست تغییرات را ارسال کند و نتایج را روی همان دستگاه بررسی کند، در حالی که لپ‌تاپ او خاموش و در کوله‌پشتی بود. بخشی که او بیشتر از همه از آن لذت می‌برد، توانایی رها کردن کارها در حال اجرا بود؛ تسک‌های طولانی‌تر دیگر نیازی نداشتند که لپ‌تاپ حتماً مقابل او باشد تا عامل بتواند کار کند.

با این حال، یک شکاف باقی مانده بود: کارهای موبایل با React Native. از آنجا که بیلد‌های iOS و جلسات شبیه‌ساز مستلزم macOS هستند، توسعه‌دهنده مجبور بود کارهای راه دور را برای کامپایل و بازرسی به مک‌بوک ایر بازگرداند. این بدان معنا بود که عامل می‌توانست روی مخزن کد به‌صورت راه دور کار کند، اما بازرسی نهایی همچنان منابع محلی مک‌بوک ایر را می‌بلعید.

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

هسته اصلی گره macOS، یک مک‌بوک پرو M4 Pro دست‌دوم با ۴۸ گیگابایت حافظه یکپارچه (Unified Memory) است. توسعه‌دهنده در ابتدا به دنبال یک مک‌مینی بود، اما متوجه شد که گزینه‌های نو در کلمبیا گران هستند و مدل‌های دست‌دوم با حافظه کافی کمیاب‌اند. او می‌خواست از محدودیت حافظه ۱۶ گیگابایتی مک‌بوک ایر خود فاصله بگیرد تا فضای کافی برای کانتینرها، بیلد‌های iOS، شبیه‌سازها و آزمایش‌های استنتاج محلی داشته باشد. این انتخاب سخت‌افزاری دقیقاً با این واقعیت همسو است که معماری تراشه‌های اپل به دلیل حافظه یکپارچه، محیطی ایده‌آل برای اجرای مدل‌های هوش مصنوعی محلی فراهم کرده است.

یافتن ماشین مناسب سخت‌تر از حد انتظار بود. او به جستجو ادامه داد زیرا نمی‌خواست دستگاه دیگری بخرد که همان محدودیت ۱۶ گیگابایتی ایر را داشته باشد. در نهایت، یک مک‌بوک پرو دست‌دوم با تراشه M4 Pro و ۴۸ گیگابایت رم پیدا کرد. دستگاه تقریباً نو بود و حدود ۷۰ چرخه باتری داشت. قیمت درخواستی تقریباً برابر با قیمتی بود که برای یک مک‌مینی نو ۱۶ گیگابایتی می‌پرداخت و به‌طور قابل توجهی ارزان‌تر از خرید یک مک‌بوک پرو مشابه به‌صورت نو بود.

برای تبدیل این لپ‌تاپ به یک سرور بدون نمایشگر (Headless)، تجهیزات زیر به کار گرفته شد:

• یک استند عمودی برای نگه داشتن ماشین در حالت بسته و بهینه‌سازی فضا در کنار کیس لینوکس.
• یک هاب تغذیه (Powered Hub) برای اتصالات مورد نیاز.
• یک دانگل HDMI مجازی (Dummy Plug) برای فریب دادن سیستم و فعال‌سازی تنظیمات نمایشگر از راه دور.
• نرم‌افزار Amphetamine، ابزاری که برای جلوگیری از رفتن مک به حالت خواب در حالی که درب لپ‌تاپ بسته است، استفاده می‌شود.

![عنوان: مک ریموت برای عامل‌های کدنویسی من

عکس: لپ‌تاپ مک روی میز کنار پنجره، با صفحه نمایش ترمینال و کدهای برنامه‌نویسی.](https://www.dothoosh.com/media/7392302e-ea86-4209-976e-27b90bbab0d9-1-my-coding-agents-now-have-a-remote-mac-5633845e.webp)

پیاده‌سازی «استفاده از کامپیوتر» (Computer Use)

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

در یک تست عملی روی Synapse (یک اپلیکیشن همراه هوش مصنوعی شخصی)، توسعه‌دهنده یک انتخاب‌گر مدل جدید را تست کرد که طراحی شده بود تا مدل‌های متن‌باز را از طریق OpenRouter در کنار Gemini امتحان کند. این تغییر قبلاً در رابط‌های وب و موبایل اعمال شده بود. عامل با یک جریان کاری خاص موظف شد:

• باز کردن انتخاب‌گر مدل در هر دو رابط وب و موبایل.
• استفاده از قابلیت چت برای تایید تغییرات.
• ضبط تعاملات در هر دو رابط.
• ارائه یک ضبط ویدیویی نهایی و یک گزارش مکتوب.

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

جریان کاری غیرهمزمان

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

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

آزمایش‌های استنتاج محلی (Local Inference)

فراتر از ارکستراسیون عامل‌ها، ۴۸ گیگابایت حافظه یکپارچه امکان میزبانی مدل‌های محلی را فراهم می‌کند. توسعه‌دهنده در حال حاضر در حال آزمایش یک مدل محلی Qwen روی مک است. استفاده از این حافظه بالا یکی از دلایل کلیدی خرید این دستگاه بود.

این چیدمان محلی، آزمایشی جداگانه از عامل‌های کدنویسی راه دور است که همچنان از مدل‌های ابری (Hosted) استفاده می‌کنند. توسعه‌دهنده دو مورد استفاده اصلی برای مدل محلی Qwen بررسی می‌کند:

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

جذابیت اصلی، توانایی تکرار استنتاج روی سخت‌افزار شخصی بدون پرداخت صورت‌حساب ابری برای هر درخواست است. اگرچه توسعه‌دهنده اشاره می‌کند که هزینه برق و سخت‌افزار همچنان وجود دارد، اما مدل محلی راهی برای تکرار و اصلاح (Iterate) بدون هزینه‌های API هر درخواست فراهم می‌کند. او همچنان در حال یادگیری است که مدل در چه مواردی خوب عمل می‌کند و کجا به نظارت بیشتری نیاز دارد.

تحلیل: ظهور «سرور خانگی عامل‌ها»

این معماری نشان‌دهنده تغییری در نگاه توسعه‌دهندگان به سخت‌افزار است. ما در حال حرکت از ایستگاه کاری «همه-در-یک» به سمت یک «مزرعه عامل‌ها» (Agent Farm) توزیع شده هستیم. با تقسیم حجم کاری بین اوبونتو و macOS، توسعه‌دهنده چندین اصطکاک فنی را از بین می‌برد:

• تخصیص منابع: شبیه‌سازهای سنگین iOS و کانتینرها دیگر با رابط کاربری اصلی لپ‌تاپ کلاینت رقابت نمی‌کنند. مک‌بوک پرو بارهای کاری macOS را مدیریت می‌کند، در حالی که مک‌بوک ایر کلاینت قابل حمل باقی می‌ماند.
• جداسازی محیط: استفاده از دو میزبان، تداخل پورت‌ها و نیاز به تنظیمات پیچیده هنگام اجرای چندین Worktree یا کپی از سرویس‌ها روی یک ماشین را کاهش می‌دهد. این امر اصطکاک را هنگام کار روی بیش از یک تسک در یک پروژه کم می‌کند.
• تفویض تسک: توسعه‌دهنده اکنون می‌تواند ویژگی‌های کامل را به‌طور همزمان در وب و موبایل تفویض کند. او می‌تواند محیط را بر اساس تسک انتخاب کند: اوبونتو برای کدنویسی غیرهمزمان و مک‌بوک پرو برای macOS، شبیه‌سازهای iOS یا دسترسی به دسکتاپ گرافیکی.

برای یک توسعه‌دهنده عمل‌گرا، این بدان معناست که دستگاه «کلاینت» (لپ‌تاپی که با خود حمل می‌کنید) دیگر نیازی نیست یک غول سخت‌افزاری باشد. ارزش به زیرساخت خانگی منتقل می‌شود—به‌ویژه گره‌های غنی از حافظه که می‌توانند سربار بالای عامل‌های هوش مصنوعی مبتنی بر GUI را تحمل کنند. توانایی درخواست یک ضبط ویدیویی به عنوان خروجی، عامل را از یک تولیدکننده کد به یک مهندس QA (تضمین کیفیت) تبدیل می‌کند.

برای بازسازی این سیستم، باید به دنبال سخت‌افزارهای دست‌دوم Apple Silicon با حداقل ۳۲ گیگابایت رم باشید تا ماهیت حافظه‌بر شبیه‌سازهای iOS و مدل‌های زبانی بزرگ (LLM) محلی را پشتیبانی کند.

گام بعدی شما

• اگر با محدودیت رم در شبیه‌سازهای iOS مواجهید، بررسی کنید آیا می‌توانید یک گره macOS مجزا (حتی دست‌دوم) به شبکه خانگی خود اضافه کنید.
• برای تبدیل لپ‌تاپ‌های مک به سرور، از ترکیب دانگل HDMI مجازی و نرم‌افزار Amphetamine استفاده کنید.
• قابلیت‌های ضبط صفحه (مانند OBS) را به ابزارهای در دسترس عامل‌های خود اضافه کنید تا خروجی‌های بصری دریافت کنید.

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