تصور کنید به جای جابهجایی میان دهها تب ترمینال برای چک کردن وضعیت سرورهای مختلف، تمام عاملهای هوش مصنوعی خود را در یک داشبورد واحد کنترل کنید. در ۸ سپتامبر ۲۰۲۶، Herdr نسخه ۰.۹ را منتشر کرد؛ یک بازنگری ساختاری که اجازه میدهد یک رابط کاربری متنی (TUI) واحد، سرورهای مستقل در ماشینهای مختلف را مدیریت کند.
زمینه: عصر محاسبات توزیعشده
برای اکثر توسعهدهندگان، لپتاپ دیگر موتور اصلی پردازش نیست، بلکه شبیه به یک فرمان است که دستورات را به جای دیگری میفرستد. اجرای عامل (Agent) — مثل دستیاری دیجیتال که میتواند بهطور مستقل وظایف پیچیده را انجام دهد — برای چندین ساعت، معمولاً نیازمند یک سرور مجازی (VPS) یا مکمینی اختصاصی است تا لپتاپ مجبور نباشد ۲۴ ساعته روشن بماند. این تغییر نشاندهنده ترندی است که در آن توسعهدهندگان از لپتاپهای خود به عنوان کلاینت استفاده میکنند تا از تکیه کامل به سختافزار محلی اجتناب کنند و نیاز به صرف هزاران دلار برای خرید سختافزارهای گرانقیمت و قابلحمل را کاهش دهند. در این راستا، درک معیارهای کلیدی برای انتخاب محل اجرای کدهای عامل میتواند به توسعهدهندگان کمک کند تا بهینهترین زیرساخت را برای نیازهای خود برگزینند.
همانطور که در تحلیلهای قبلی ما دربارهی زیرساختهای توزیعشده اشاره کردیم، جداسازی محیط توسعه از محیط اجرا یک ضرورت است. Herdr پیش از این با بیش از ۷۰۰ هزار دانلود و نزدیک به ۱۰۰۰ افزونه، زیربنای لازم را برای این گسترش داشت. جامعه بزرگی از کاربران از این ابزار برای مدیریت عاملها و ماشینهای محلی استفاده میکردند و از قابلیت موجود --remote برای اتصال به اهداف دوردست بهره میبردند. با این حال، یک گلوگاه بزرگ باقی مانده بود: تا پیش از این، کاربران مجبور بودند برای هر هدف دوردست، کلاینتهای Herdr مجزایی را در تبهای مختلف ترمینال باز نگه دارند.
به نقل از وبلاگ herdr.dev، تیم توسعه مجبور به بازنویسی کامل نحوه ساخت اپلیکیشن شد؛ زیرا ابزارهای مدیریت ترمینال (Multiplexers) موجود مثل tmux یا Zellij از این قابلیت پشتیبانی نمیکنند که یک کلاینت TUI واحد، سرورهای مستقل را مدیریت کند. در گذشته، Herdr دارای یک کلاینت و یک سرور بود، اما هر کلاینت تنها به یک سرور متصل میشد و تمام موارد روی همان سرور رندر میشد. برای آوردن چندین سرور به این ساختار، یا باید یک سرور مرکزی برای تجمیع تمام اتصالات ایجاد میشد و یا تغییر کلی در محل قرارگیری رابط کاربری (UI) صورت میگرفت.
جزئیات: پیادهسازی فنی
در معماری جدید نسخه ۰.۹، رابط کاربری بیرونی در سمت کلاینت رندر میشود، در حالی که سرورها صرفاً جلسات (Sessions) و نماهای ترمینال را حفظ میکنند. این جداسازی اجازه میدهد کلاینت، سرورهای مستقل را در یک TUI واحد جمع کند. این تغییر ساختاری همچنین مسیر را برای بهبودهای عملکردی آینده باز میکند، زیرا کلاینت بیش از پیش از زمان اجرای برنامه (Runtime) مستقل شده است.
کاربران اکنون میتوانند ماشینهای دوردست را با استفاده از دستور herdr machine add [name] (مثلاً herdr machine add workbox) ادغام کنند. طبق مستندات این نسخه، پیشنیازهای این سیستم عبارتند از:
- دسترسی SSH: ماشینها باید از طریق SSH، چه در شبکه محلی و چه از طریق اینترنت، قابل دسترس باشند.
- ابزارهای اتصال: سیستم با اهداف استاندارد SSH یا شبکههای لایه دوم (Overlay Networks) مثل Tailscale سازگار است.
- پایداری جلسه: عاملها حتی پس از قطع اتصال کلاینت، روی ماشینهای دوردست مربوط به خود به کار ادامه میدهند.
- رابط یکپارچه: فضای کاری، تبها و عاملهای ماشین دوردست در کنار موارد محلی در یک TUI واحد در دسترس قرار میگیرند.
با این حال، در حالی که TUI اکنون این ماشینها را تجمیع میکند، رابط خط فرمان (CLI) عاملها همچنان به یک سرور محدود است. در نسخه فعلی، عاملهای مستقر در ماشینهای مختلف نمیتوانند یکدیگر را ببینند یا با هم تعامل داشته باشند. توسعهدهنده Herdr اشاره کرده است که همکاری متقاطع عاملها (Cross-machine collaboration) — جایی که عاملها بتوانند یکدیگر را در سرورهای مختلف پیدا کرده و با هم کار کنند — هدف اصلی بهروزرسانیهای آینده است. این چشمانداز با استاندارد Agent Plugins 1.0 همسو است که تلاش میکند قابلیتهای عاملها را در محیطهای مختلف قابلحمل و یکپارچه کند.
این چرخش راهبردی به معنای حرکت گستردهتر به سمت مدل «کلاینت-سرور» برای توسعه هوش مصنوعی است. با جداسازی Runtime از رابط کاربری، Herdr به کاربران اجازه میدهد قدرت محاسباتی خود را بدون افزایش هزینههای سختافزاری برای دستگاههای قابلحمل، مقیاسپذیر کنند. این ابزار محیط محلی توسعهدهنده را به یک مرکز فرماندهی برای ناوگانی از عاملهای توزیعشده تبدیل میکند.
برای کاربر نهایی، این به معنای پایان «خستگی از تبها» (Tab Fatigue) است. دیگر نیازی نیست به خاطر بسپارید کدام عامل روی کدام VPS در حال اجراست؛ فقط کافی است در همان رابط کاربری، ماشین را تغییر دهید. این گام برای کسانی که گردشهای کاری عاملمحور (Agentic) پیچیده و چندساعته دارند که باعث هنگ کردن لپتاپهای معمولی میشود، حیاتی است.
مسیر رسیدن به نسخه ۱.۰
در نگاه به آینده و نسخه ۱.۰، نقشه راه شامل Herdr Cloud است. این لایه پیشرو قصد دارد نیاز به پیکربندی دستی SSH یا تنظیمات پیچیده شبکه را به طور کامل از بین ببرد تا کاربران بتوانند هر ماشین — خواه یک محیط Sandbox، ماشین مجازی یا سرور دوردست باشد — را تنها با یک دستور به حساب خود متصل کنند.
لایه ابری به عنوان یک واسط رمزنگاریشده برای ترافیک ترمینال عمل میکند و رمزنگاری سرتاسری (End-to-end encryption) بین ماشینها و کلاینت Herdr را تضمین میکند. نکته بسیار مهم این است که Herdr Cloud فقط ماشینها را به هم متصل میکند و میزبان عاملها برای کاربر نیست.
هدف نهایی، جابهجایی کامل جلسات (Total Session Mobility) است. توسعهدهنده آیندهای را متصور است که در آن یک جلسه عامل بتواند در میانه مسیر گردش کار، از یک ماشین به ماشین دیگر منتقل شود؛ به گونهای که دیگر نیازی نباشد کاربر پیش از شروع تسک، تصمیم بگیرد که آن وظیفه روی کدام سختافزار زندگی کند. این سطح از انعطافپذیری، هدف نهایی Herdr در مسیر رسیدن به نقطه عطف نسخه ۱.۰ است. برای مدیریت دادهها در چنین ساختارهای توزیعشدهای، میتوان از الگوهای معماری تحلیل داده در شبکههای توزیعشده بهره برد تا از گسستگی اطلاعات در ماشینهای مختلف جلوگیری شود.
برای شروع استفاده از این قابلیتها در امروز، توسعهدهندگان میتوانند به نسخه ۰.۹ بهروزرسانی کرده و اهداف SSH خود را پیکربندی کنند. کسانی که میخواهند در آینده از تنظیمات SSH عبور کنند، میتوانند در لیست انتظار Herdr Cloud ثبتنام کنند.
گام بعدی شما
- اگر از چندین VPS برای اجرای مدلها استفاده میکنید، به نسخه ۰.۹ بهروزرسانی کرده و ماشینهای خود را با دستور
machine addتعریف کنید. - برای حذف پیچیدگیهای SSH در آینده، در لیست انتظار Herdr Cloud ثبتنام کنید.
- جریانهای کاری خود را به گونهای بازبینی کنید که از قدرت محاسباتی دوردست به جای فشار به سختافزار محلی استفاده شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو